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

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

Herriot, Robert Robert.Herriot at pahv.xerox.com
Fri Jul 13 15:47:42 EDT 2001


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 at sharplabs.com]
> Sent: Thursday, July 12, 2001 6:40 PM
> To: 'don at 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 at lexmark.com [mailto:don at 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 at 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 at interlock.lexmark.com> on
> 07/11/2001 06:42:47 PM
> 
> To:   "'Hastings, Tom N'"
> <hastings%cp10.es.xerox.com at interlock.lexmark.com>,
>       "Bergman, Ron" 
> <Ron.Bergman%Hitachi-hkis.com at interlock.lexmark.com>
> cc:   "ipp (E-mail)" <ipp%pwg.org at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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"
> 
> 
> 



More information about the Ipp mailing list