IPP Mail Archive: RE: IPP> MED - Proposed final ABNF for Med

IPP Mail Archive: RE: IPP> MED - Proposed final ABNF for Med

RE: IPP> MED - Proposed final ABNF for Media Size Self Describing Names

From: Herriot, Robert (Robert.Herriot@pahv.xerox.com)
Date: Fri Jul 13 2001 - 15:47:42 EDT

  • Next message: McDonald, Ira: "RE: IPP> MED - Proposed final ABNF for Media Size Self Describing Names"

    Ira,

    If you are correct that ABNF is routinely compiled into tailored parsers,
    then the grammar has an additional problem of too much look-ahead. The
    parse cannot determine whether to reduce to class-in or class-mm (at the
    beginning of the production) until it reaches a "mm" or "in" at the end of
    the production.

    > -----Original Message-----
    > From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
    > Sent: Thursday, July 12, 2001 6:40 PM
    > To: 'don@lexmark.com'; Bergman, Ron
    > Cc: 'Hastings, Tom N'; Bergman, Ron; ipp (E-mail)
    > 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 : Fri Jul 13 2001 - 15:49:32 EDT