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

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

Hastings, Tom N hastings at cp10.es.xerox.com
Mon Mar 5 19:03:26 EST 2001


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 at 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 at HITACHI-HKIS.COM]
Sent: Friday, February 23, 2001 07:53
To: IMAGING at 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>>





More information about the Ipp mailing list