Hi Don,
I withdraw all of my objections. I concede that a clean, closed
ABNF with only the currently registered class names is better.
I talked with Tom Hastings and Bob Herriot about this yesterday
afternoon and I believe they both agree with this approach (one
ABNF expression for standard class names and a _second_ ABNF
expression for the rules for new class names registered in the
future).
I think everyone agrees that we need to complete and publish
the PWG Media standard ASAP.
Cheers,
- Ira McDonald, consulting architect at Sharp and Xerox
High North Inc
-----Original Message-----
From: don@lexmark.com [mailto:don@lexmark.com]
Sent: Friday, July 13, 2001 10:25 AM
To: McDonald, Ira
Cc: 'don@lexmark.com'; Bergman, Ron; 'Hastings, Tom N'; ipp (E-mail)
Subject: RE: IPP> MED - Proposed final ABNF for Media Size Self
Describing Names
Ira, et al:
Then I would suggest we tell people not to do what you describe as new LEGAL
names could be created and must be dealt with properly.
WARNING: This ABNF is not meant for unfiltered consumption.
**********************************************
* Don Wright don@lexmark.com *
* Chair, Printer Working Group *
* Chair, IEEE MSC *
* Member, IEEE SA Board of Governors *
* Member, IEEE-ISTO Board of Directors *
* *
* Director, Alliances & Standards *
* Lexmark International *
* 740 New Circle Rd *
* Lexington, Ky 40550 *
* 859-825-4808 (phone) 603-963-8352 (fax) *
**********************************************
"McDonald, Ira" <imcdonald%sharplabs.com@interlock.lexmark.com> on
07/12/2001
09:40:07 PM
To: "'don@lexmark.com'"
<"Don_Wright/Lex/Lexmark.LEXMARK"@sweeper.lex.lexmark.com>, "Bergman,
Ron"
<Ron.Bergman%Hitachi-hkis.com@interlock.lexmark.com>
cc: "'Hastings, Tom N'"
<hastings%cp10.es.xerox.com@interlock.lexmark.com>,
"Bergman, Ron" <Ron.Bergman%Hitachi-hkis.com@interlock.lexmark.com>,
"ipp
(E-mail)" <ipp%pwg.org@interlock.lexmark.com> (bcc: Don
Wright/Lex/Lexmark)
Subject: RE: IPP> MED - Proposed final ABNF for Media Size Self Describing
Names
Hi folks,
There's a misunderstanding of use cases going on here.
ABNF is routinely compiled directly into tailored parsers.
If the 'reg-name' production isn't there, then no LEGAL
newly registered name which IS known to a printer can be
used successfully by an existing client or intermediate
proxy, because it fails the ABNF rules.
This is not a hypothetical case.
Cheers,
- Ira McDonald
-----Original Message-----
From: don@lexmark.com [mailto:don@lexmark.com]
Sent: Thursday, July 12, 2001 11:20 AM
To: Bergman, Ron
Cc: 'Hastings, Tom N'; Bergman, Ron; ipp (E-mail)
Subject: RE: IPP> MED - Proposed final ABNF for Media Size Self
Describing Names
I care and I agree with Ron on this.
**********************************************
* Don Wright don@lexmark.com *
* Chair, Printer Working Group *
* Chair, IEEE MSC *
* Member, IEEE SA Board of Governors *
* Member, IEEE-ISTO Board of Directors *
* *
* Director, Alliances & Standards *
* Lexmark International *
* 740 New Circle Rd *
* Lexington, Ky 40550 *
* 859-825-4808 (phone) 603-963-8352 (fax) *
**********************************************
"Bergman, Ron" <Ron.Bergman%Hitachi-hkis.com@interlock.lexmark.com> on
07/11/2001 06:42:47 PM
To: "'Hastings, Tom N'"
<hastings%cp10.es.xerox.com@interlock.lexmark.com>,
"Bergman, Ron" <Ron.Bergman%Hitachi-hkis.com@interlock.lexmark.com>
cc: "ipp (E-mail)" <ipp%pwg.org@interlock.lexmark.com> (bcc: Don
Wright/Lex/Lexmark)
Subject: RE: IPP> MED - Proposed final ABNF for Media Size Self Describing
Names
Tom,
As I said in my last email, I believe that separating the registration
requirements from the media size name ABNF is cleaner. It is then very
obvious that the class-xx name is restricted to the given names. Addition
of reg-class-xx-name to the media size names ABNF muddies the water. When
this is only in a section that describes the requirements for new class
names, everything is clean. The best way to define that the parser must be
able to deal with new names is with text, not the ABNF.
I don't see anyone else commenting on this issue. Does that mean that no
one cares?
Ron
-----Original Message-----
From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
Sent: Wednesday, July 11, 2001 12:19 PM
To: Bergman, Ron
Cc: ipp (E-mail)
Subject: RE: IPP> MED - Proposed final ABNF for Media Size Self
Describing Names
So to be clear about the issue about how to represent the ABNF for future
registered class names:
(a) in the ABNF in the Media Standardized Name standard itself and
(b) the ABNF in the flat file on the PWG server
(a) For the ABNF in the standard to which sending implementations and
receiving implementations are to conform, should the ABNF include the
reg-class-in-name and reg-class-mm-name productions or not in the single
ABNF? If the productions for the registered class names is removed from the
single ABNF, then they will appear later in the document explaining what the
syntax is for additional registered class names (as in the D0.9 draft).
So should the first productions in the standard be:
media-size-self-describing-name =
( class-in "_" size-name "_" short-dim "x" long-dim "in" ) |
( class-mm "_" size-name "_" short-dim "x" long-dim "mm" )
class-in = "na" | "asme" | "oe" | "custom" | reg-class-in-name
class-mm = "iso" | "jis" | "jpn" | "prc" | "roc" | "om" | "custom" |
reg-class-mm-name
reg-class-in-name = ( lowalpha | digit ) *( lowalpha | digit | "." )
reg-class-mm-name = ( lowalpha | digit ) *( lowalpha | digit | "." )
or:
media-size-self-describing-name =
( class-in "_" size-name "_" short-dim "x" long-dim "in" ) |
( class-mm "_" size-name "_" short-dim "x" long-dim "mm" )
class-in = "na" | "asme" | "oe" | "custom"
class-mm = "iso" | "jis" | "jpn" | "prc" | "roc" | "om" | "custom"
with a later section in the standard saying that additional class-in and
class-mm names will be registered with the following syntax:
class-in-name = ( lowalpha | digit ) *( lowalpha | digit | "." )
class-mm-name = ( lowalpha | digit ) *( lowalpha | digit | "." )
(b) The same questions are repeated for the first ABNF that appears in the
PWG server (and which also appears in the standard as the first snap shot).
The answers to (a) and (b) don't have to be the same. However, it may be
less confusing if the ABNF can be the same for:
(1) the ABNF for conformance to the standard
(2) the first ABNF to appear on the PWG server, and
(3) the snap shot copy of that first ABNF to appear in the standard
Then this ABNF can appear only once in the standard.
Tom
-----Original Message-----
From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com]
Sent: Tuesday, July 10, 2001 17:20
To: 'Hastings, Tom N'; Bergman, Ron
Cc: ipp (E-mail)
Subject: RE: IPP> MED - Proposed final ABNF for Media Size Self
Describing Names
Tom,
But they will be in "a single production", since the ABNF will always be
updated with the new registered values. I call that everyone agreed that
the ABNF did not have to explicitly indicate that new values can be added.
I like to hear from some developers that will "implement according to the
ABNF" on this subject.
Ron
-----Original Message-----
From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
Sent: Tuesday, July 10, 2001 5:07 PM
To: Bergman, Ron
Cc: ipp (E-mail)
Subject: RE: IPP> MED - Proposed final ABNF for Media Size Self
Describing Names
Ron wrote:
I see you added "reg-class-xx-name" to the class-name definition. It seems
like this definition is better handled as in D0.9. Otherwise, it could be
interpreted to mean that arbitrary values can be added without registration.
This is probably getting a little picky, but we want the ABNF to be a
stand-alone specification.
But if you remove the "reg-class-in-name" and "reg-class-mm-name"
productions from the ABNF, then an implementation that follows the ABNF
strictly, cannot accept a registered name that was registered AFTER the code
was shipped. I think there will be objections from those who commented that
all of the ABNF for conforming names should be in a single production, not
in several pieces in the standard.
Tom
-----Original Message-----
From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com]
Sent: Tuesday, July 10, 2001 16:22
To: 'Hastings, Tom N'; Bergman, Ron
Cc: ipp (E-mail)
Subject: RE: IPP> MED - Proposed final ABNF for Media Size Self
Describing Names
Tom,
I spoke with Norbert yesterday concerning the syntax change to "custom" and
he thought it was a good change. Since he probably has the most complete
implementation using the media size names, I suspect this will not be an
issue with anyone else.
I agree that the ABNF should be included in the specification. But it
should be noted that it is only a snap-shot in time and should never be used
for more than an example. The "real ABNF must ALWAYS be obtained from the
referenced file. I am not sure what you mean by...
"Another reason to include the ABNF in the standard is that fetching the
current ABNF from the web site isn't required (for an implementation or an
implementer)."
but it seems that an implementer would always want to see the latest. In
practice, I don't expect to see many updates to the ABNF, but it should be
pointed out that an update is possible. (I will add text that provides the
appropriate warning.)
I see you added "reg-class-xx-name" to the class-name definition. It seems
like this definition is better handled as in D0.9. Otherwise, it could be
interpreted to mean that arbitrary values can be added without registration.
This is probably getting a little picky, but we want the ABNF to be a
stand-alone specification.
Ron
-----Original Message-----
From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
Sent: Monday, July 09, 2001 2:46 PM
To: Bergman, Ron
Cc: ipp (E-mail)
Subject: RE: IPP> MED - Proposed final ABNF for Media Size Self
Describing Names
I should have pointed out that the name field will now be required for a
custom size name, as well as standardized names, whereas in Draft D0.9 the
name field was optional in custom names.
There are two advantages to requiring a name field in a custom size name:
1. The syntax for custom and standard names becomes the same, simplifying
implementation (since both will require a name).
2. It is good practice for an administrator when defining a custom size to
invent some sort of a name to suggest the size's use to its users.
Ron,
About your second question, I see I wasn't clear about whether or not the
ABNF would appear in the standard or only in the PWG FTP site. I think that
the first ABNF (current with version 1.0 of the standard) should be in the
standard, including the commenting, so that implementations can see what to
expect in case they choose to fetch the current (updated) ABNF from the PWG
site.
When we post the final approved standard, we should also post the ABNF flat
file which will be identical to what is in the standard. Only when we
register a new size name that needs a new class name, will we need to update
the ABNF flat file on the PWG server. Periodically, but not more frequently
than, say, once a year, we will update the standard with new size names and
any new class names that have been registered in the meantime.
Another reason to include the ABNF in the standard is that fetching the
current ABNF from the web site isn't required (for an implementation or an
implementer).
Tom
-----Original Message-----
From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com]
Sent: Monday, July 09, 2001 11:23
To: 'Hastings, Tom N'; ipp (E-mail)
Subject: RE: IPP> MED - Proposed final ABNF for Media Size Self
Describing Names
Tom,
It should be pointed out that this does change the current syntax for custom
size names, in that the "size-name" will be mandatory. This part is
optional in the current draft.
Also, I would like a clarification. Does this proposal completely remove
the size ABNF from the document? Or, is the ABNF included with a note
indicating where to get the latest? Although it may be somewhat confusing,
it would be cleaner to only include the reference to the ABNF.
Ron
-----Original Message-----
From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
Sent: Monday, July 09, 2001 10:57 AM
To: ipp (E-mail)
Subject: IPP> MED - Proposed final ABNF for Media Size Self Describing
Names
Ron and I want to publish a final version of the Media Standardized Name
standard for Last Call. There are three standards that require its use, so
we need to complete the Media standard. One is UPnP Basic Printing
Template. Another is IPP FAX.
Please send any comments on this proposed ABNF BEFORE we publish the next
draft. Silence will be interpreted as agreeing with the ABNF.
****************************************************************
Please send any comments by Tuesday, July 17, 2001.
****************************************************************
There has been the suggestion on the mailing list that the ABNF should be a
single production, including the custom part and the future registered class
name part as is common practice.
We are also agreeing to retain the explicit list of class names in the ABNF.
When a new size name is registered which needs a new class name, then the
ABNF will be updated to include the new class name. The updated ABNF will
be available on the PWG site as a flat text file in a published and stable
URL.
Advantages of this approach:
1. All of the ABNF for the Media Size Self Describing Name is specified as a
single ABNF production, so that code can be written that will be stable,
even as new media size names are registered with new class names. This is
the common practice for other standards that use ABNF.
2. Which class names go with which units is part of the ABNF, so that it is
clear that using the wrong set of units with a class name violates the ABNF
and permits a parser to detect such mal-formed ABNF.
3. Using a single "custom" class name (rather than one for in and one for
mm) simplifies the parsing for custom names because the parser needs to look
for one special prefix ("custom"), as with Media Type and Media Color,
rather than for, say, "custom-in" and "custom-mm" class names. Since
administrators are defining the custom sizes, not vendors, whether they
choose in or mm units will depend on their users.
Disadvantages of this approach:
1. When new class names are registered, the existing parsers won't be able
to validate that the units are correct, unless they access the PWG web site
for the current ABNF. (The standard will NOT require implementations to
access the PWG web site to get the current ABNF, nor does it require that
implementations detect corrupt names that use the wrong units).
The ABNF flat file will have comments at the beginning to identify the date
and version of the standard and the date and version of the ABNF. The ABNF
date and minor version number will be updated every time it is updated. The
ABNF follows RFC 2234.
Here is the proposed final ABNF as it will appear in the flat file on the
PWG site in:
ftp://ftp.pwg.org/pub/pwg/standards/pwg5101-abnf.txt:
; ABNF for the Media Size Self-Describing Name
; Part of the IEEE/ISTO 5101.1 Media Standardized Names standard
; For use with the IEEE/ISTO 5101.1 Standard Version 1.0, July 9, 2001
; ABNF version 1.0, July 9, 2001
; This ABNF is updated whenever a new media size class name is registered
; according to the procedures of IEEE/ISTO 5101.1.
media-size-self-describing-name =
( class-in "_" size-name "_" short-dim "x" long-dim "in" ) |
( class-mm "_" size-name "_" short-dim "x" long-dim "mm" )
class-in = "na" | "asme" | "oe" | "custom" | reg-class-in-name
class-mm = "iso" | "jis" | "jpn" | "prc" | "roc" | "om" | "custom" |
reg-class-mm-name
reg-class-in-name = ( lowalpha | digit ) *( lowalpha | digit | "." )
reg-class-mm-name = ( lowalpha | digit ) *( lowalpha | digit | "." )
size-name = ( lowalpha | digit ) *( lowalpha | digit | "-" )
short-dim = dim
long-dim = dim
dim = integer-part [fraction-part] | "0" fraction-part
integer-part = non-zero-digit *digit
fraction-part = "." *digit non-zero-digit
lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" |
"j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" |
"s" | "t" | "u" | "v" | "w" | "x" | "y" | "z"
non-zero-digit = "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
This archive was generated by hypermail 2b29 : Sat Jul 14 2001 - 12:18:09 EDT