IPP Mail Archive: IPP> Editorial comments on the "PWG M

IPP Mail Archive: IPP> Editorial comments on the "PWG M

IPP> Editorial comments on the "PWG Media Size Standardized Names" Dra ft D0.3

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Mon Mar 05 2001 - 19:03:26 EST

  • Next message: Manros, Carl-Uno B: "RE: IPP> I-D ACTION:draft-ietf-ipp-install-02.txt"

    Ron,

    Great job at producing this draft! Its very readable and short. A number
    of us reviewed it at Xerox and we like the table organization as well (but
    see separate comment about '-envelope' and MediaType exception which I won't
    repeat in these editorial comments).

    Here are some editorial comments. They probably don't need to be covered at
    the meeting, unless some reviewer wants to being up something in particular
    (or disagree with my suggestions).

    1. It would help to produce a line numbered .pdf version for ease of making
    comments.

    2. Do you want to down load the .doc file too. Then the meeting could make
    changes if they wanted to. I created a /media-sizes sub-directory under
    /pwg.

    3. First line of Abstract is:
    This document specifies standard names to be used to indicate media sizes in
    other PWG standards.

    The next sentences say that this PWG standard will be used by other
    standards as well, such as the Printer MIB, IPP, IPP FAX, UPnP, and wireless
    standards. Therefore, replace "other PWG standards" with "other standards".

    4. Since many of these other standards are already published, they cannot
    contain references to this PWG Standard. Therefore, it would also help to
    identify the attributes in these other standards in which these Media Size
    names are intended to be used, such as:

    Printer MIB (RFC 1759) and Printer MIB v2, Appendix B, Media Size Names ...

    IPP/1.1 Model and Semantics (RFC 2911), "media" Job Template attribute

    The standards that are still under development can contain a reference to
    this PWG standard in their definitions, such as:

    UPnP BasicPrint Template, MediaSize parameter

    UPnP EnhancedLayoutPrint Template, MediaSize parameter

    5. Page 4, section 1, Introduction: We should also reference existing
    practice as specified in the PPD and GPD specifications.

    6. Page 5, section 2, Terminology: The current definition of ASCII is:

    ASCII American Standards Code for Information Exchange. A character set
    encoding with printable
    characters defined in the range 0x21 to 0x7E. Normally refers to a US
    character set, but variants are
    defined for many national languages. Equivalent to ISO 8859-1 character set
    encoding.

    The term ASCII should always and only mean the ANS X3.4-1988 standard, same
    as in all IETF standards. ASCII does NOT mean the national character sets
    and does not mean ISO 8859-1. In an 8-bit environment, the 8th bit MUST be
    0 for ASCII. I suggest using the definition from the IPP References
    section:

    [ASCII]
            Coded Character Set - 7-bit American Standard Code for Information
    Interchange (ASCII), ANSI X3.4-1986. This standard is the specification of
    the US-ASCII charset.

    7. Page 5, section 2, Terminology: I suggest adding the term Media Size
    Self Describing Name. Then add a shorter form, say, Media Size Name, so we
    can distinguish these names from Media Name and Media Type Name. Perhaps
    even add these latter two terms as well.

    8. Then consistently use first letter capitalization for terms to clearly
    indicate that they are intended to be the specialized terms in the
    Terminology section.

    9. Page 5, section 3, need to explain the "Alias (common) names" column.

    10. Page 5, section 3.1, 1st paragraph reads:

    This new format has the media size embedded within the string and allows a
    device to operate without a media name to media size table.

    I find it clearer to use the terms "dimension" to mean something that has a
    number, rather than the vaguer word "size", since this document uses size to
    be a name. The above paragraph with the above editorial suggestions would
    read:

    This new format has the media dimensions embedded within the string and
    allows a device to operate without a media size name to media dimensions
    table.

    11. Page 5, section 3.1, we need to use ABNF. We also need to limit the
    characters in this standard to a much smaller subset of ASCII: Only lower
    case a-z, 10 decimal digits, ".", "-", and maybe "_". This is the set
    allowed in IPP keywords. Of course we need to be clear that the other
    standards that use this standard may also require all lower case, allow
    upper and lower case (as being equivalent), or require all upper case. Here
    is a crack at the ABNF:

          media_size_name = [na-] name "." short_dim "-" long_dim

          name = lowalpha *( lowalpha | digit | "-" | "_" )

          short_dim = *digit

          long_dim = *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"

          digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
                     "8" | "9"

    I specifically chose "short" and "long", not "width" and "length" so that
    there is absolutely no connation of orientation in the two numeric fields.

    I also chose "name", since I wanted to use the shorter Media Size Name for
    the whole thing, not just the component before the ".".

    This ABNF will then remove the need to describe the syntax in words, i.e.,
    delete the following sentences:

    The prefix string shall be separated from the mediaName by a hyphen (0x2D).

    The mediaName can consist of multiple words, with each word separated by a
    hyphen (0x2D).

    The mediaName shall contain only US-ASCII characters using the codes 0x21
    through 0x2D and 0x2F through 0x7E. A period (0x2E) must not be present in
    the mediaName.

    The widthDim is separated from the lengthDim by a hyphen (0x2D).

    No decimal values (i.e. periods) shall be present within a media size
    dimension.

    Symbol characters (0x21 through 0x2F, 0x3A through 0x3F, 0x5B through 0x5F,
    and 0x7B through 0x7E) are not prohibited, with the exception of the period
    (0x2E), but are not encouraged.

    12. Section 3.1.4 General, the following sentence needs clarification:

    Media Size Self Describing Names are not case sensitive but will always be
    presented in this standard
    using lower case characters.

    While Media Size Self Describing Names are presented using all lower case in
    this standard, other standards that use these names, MAY:

      a. also require only lower case as in this standard
      b. allow lower and upper case to be used with the same meaning as the
    names in this standard, i.e., case insensistive matching
      c. require all upper case letters to be used with the same meaning as the
    names in this standard

    13. Section 3.2 Custom Media Size Name Format

    Using the ABNF, sections 3.2.1 through 3.2.4 can be compressed into the
    following single line of ABNF:

          media_size_name = [na-] "custom-" name "." short_dim "-" long_dim

    14. Tables.

    A number of us reviewed the document at Xerox and we liked the organization
    and ordering of the entries in the tables (by increasing size of the smaller
    dimension) and the grouping of entries separated by blank lines (when there
    was another logical group. But this ordering should be explained.

    15. Section 4 Conformance: I suggest that any standard referencing this
    standard needs to specify whether the names MUST be all lower case, may be
    mixed case with the same meaning, or MUST be all upper case. We also need a
    URL so they can publish the reference to this standard.

    16. Section 5 IANA Considerations ISSUE 1

    IANA has a registry of media names. We need to say something about whether
    or not we are using it to publish our names and why.

    17. Internationalization Considerations ISSUE 2

    Wow. If we allow any other charsets for custom names, which does seem
    reasonable, then we have to modify the ABNF for custom names. Yes, we
    should be modern and mention UTF-8. Unfortunately, if we were to allow any
    charset, such as national use charsets or EBCDIC, our ABNF becomes
    incredibly hairy. Also there would have to be a way to convey the charset
    in what ever protocol was being use, so we'd have to add that requirement on
    the standard that was referencing out standard. I'm not sure we want to go
    there.

    Thanks,
    Tom

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Wednesday, February 28, 2001 11:50
    To: ipp (E-mail); pwg (E-mail)
    Subject: PWG> FW: Update to Media Sizes Document (version D0.3)

    I've created a sub-directory for the PWG media-sizes project and copied D0.3
    version into it:

    ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-size-03.pdf

    I've also copied the versions of Jim Lo's original document in .doc, .pdf,
    and .html:

    ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.html
    ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.doc
    ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.pdf

    Also two RFCs the deal with media from the Internet Fax group:

    RFC 2879 - Content Feature Schema for Internet Fax (V2)
    RFC 2534 - Media Features for Display, Print, and Fax

    ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2879.txt
    ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2534.txt

    Tom

    -----Original Message-----
    From: Bergman, Ron [mailto:Ron.Bergman@HITACHI-HKIS.COM]
    Sent: Friday, February 23, 2001 07:53
    To: IMAGING@FORUM.UPNP.ORG
    Subject: Update to Media Sizes Document (version D0.3)

    I did not receive any comments on the D0.2 version, so this update only
    includes the missing paragraphs plus some corrections i discovered.

    I hope this can be reviewed in the UDPF and/or the IPP meetings in Tampa.
    Since I am not able to attend these meetings, someone needs to take good
    notes.

            Ron Bergman
            Hitachi Koki Imaging Solutions
     <<pwg-media-size-03.pdf>>



    This archive was generated by hypermail 2b29 : Mon Mar 05 2001 - 19:09:01 EST