Attendees: Ron Bergman, Ira McDonald, Carl-Uno Manros, Don Wright, Tom
Hastings
We think that the non-participants will be able to go along with our
decisions, the summary of which is:
Class names are explicit and separated by "_" for easy parsing.
Units are explicit as either "mm" or "in" as the last two characters of the
Dimensions Field.
Each class name is defined for use only with a single size unit (either "mm"
or "in" units).
The ABNF will tie the "na", "oe", and "asme" class names to "in" units, and
any other class names MUST be "mm".
It will be possible to register new class names which MUST include the units
(either "mm" or "in").
If a class name needs "in" units, the registration process will also require
adding that class name to the ABNF in order to tie it to "in" units and
syntax.
The dimensions are separated by the "x" character which is drawn from
mathematics (times) and seems to be sufficiently language independent not to
be a problem.
The boiled down requirements will be merged into the beginning of the
document.
See TH> in the decision tree below for more details.
Tom
-----Original Message-----
From: Hastings, Tom N
Sent: Thursday, May 10, 2001 18:30
To: 'pwg-announce at pwg.org'
Cc: UPnP Print and Imaging WG <IMAGING at FORUM. UPNP. ORG>
(E-mail)
Subject: RESEND: Agenda for telecon, Mon 5/14, 1-2 PM PDT
(4-5 EDT): Media Size Std decision tree
Please do not reply to the pwg-announce DL. Reply to ipp at pwg.org
and/or imaging at forum.upnp.org.
Its clear from the reactions to the set of requirements and the 6
issues that was our proposed agenda, that we really need a decision tree
agenda instead. This mail message replaces the previous agenda for the
telecon. I've down-loaded the agenda/decision tree:
ftp://ftp.pwg.org/pub/pwg/media-sizes/media-size-decision-tree-010510.pdfftp://ftp.pwg.org/pub/pwg/media-sizes/media-size-decision-tree-010510.doc
I've also copied the agenda/decision tree into this mail message as
plain text, so you can read it either way:
Monday, May 14, 1-2 PM PDT (4-5 PM EST)
Phone: (415) 228-4883, passcode: 74584#
(Xerox folks: 8*534-6413) [confirmation code:
5954723]
Definition of the term "Field"
For purposes of this discussion, the term "Field" means a part of
the Media Size Self Describing Name, that is separated by a special
character, namely "_", which is easily scanned for and cannot occur except
as a field separator.
Agreed Requirements
The boiled down requirements (thanks, Bill), that we think we can
all agree to are:
[Hastings, Tom N] We agreed that these boiled down requirements
should be added to the Scope section of the document (many of them are there
already).
1. Intent is program to program communication of media
names. It is
not intended for use as internal representation within a program.
2. Names are to contain size information so that Recipient
Software (Client or Printer) that receives an unrecognized name can still
determine the intended size. Constraints and limitations include cut sheet
only, definition of only English and Metric dimensional units, restrict the
names to use the
characters for IPP keywords
[Hastings, Tom N] TH> Reword to "use in and mm units"
3. Although primarily intended for machine readability,
Names
should have some relation to common names. Also, Names should be
structured
to present some useful information if presented directly to a user
when the
names are not recognized by the machine, which includes both the
name of the
media size and its dimensions.
10. Be able to register additional Media Names, including
new Class field/Naming authorities, after the standard is approved.
12, 13 Design the syntax to facilitate parsing by Recipient
(Client and Printer) Software
[Hastings, Tom N] Need to add the requirement about indicating
Alias (Common Names) and Legacy names.
However, the following detailed design decision issues need to be
resolved. We are trying to decide between one or a combination of the
following syntactic methods:
a. original UPnP/HTML way (but with _ field separator):
iso-a4_210x297mm,
na-letter_8.5x11in
b. Maui (D03-D07) way: iso-a4.2100-2970, na-letter.8500-11000
c. Portland decision: iso_a4_210-297, na_letter_8.5-11
d. All 1000ths of mm: iso-a4.210000-297000, na-letter.215900-279400
e. Units as a separate third field: iso-a4_210-297_mm,
na-letter_8.5-11_in
Decision Tree
From the unanimous decision on the May 2 telecon for method a and
the email push back since then, we are only considering combinations of
methods a, c, and e. The decision tree has several branches, depending on
the answers that we agree to:
1. Should there be a separate Class Field (separated by
underscore from the Media Name field) which must always be present and which
is used to indicate the naming authority, standards body, country,
geographic region, or application area? So far we have the following
classes: na, iso, jis, jpn, prc, roc, om (for other metric), oe (for other
english). Examples:
YES: iso_a4_210..., na_letter_8.5... goto 3
NO: iso-a4_210..., na-letter_8.5... goto 2
[Hastings, Tom N] We agreed YES. A client that
displays names to users has a lot of possibilities: Whether or not to
display the class name at all (which may depend on the class name). If
displaying the class name, it can be localized separately from the rest of
the name and/or the client can convert the "_" to space or hyphen. Also the
rules for interworking with existing deployed implementations of standards,
such as IPP and the Printer MIB, are straightforward: convert the "_" to "-"
and drop the Dimensions Field.
2. (not separate class field, the class information is
part of the Name Field separated by a hyphen): Does the class part of the
Name Field have to be present? If it does, then we need to invent some
miscellaneous class part, such as "oe" for other english and "om" for other
metric. If we don't, then we just omit the class part when we can't think
of a good class part. Examples:
YES: om-folio_210...or eu-folio_210 goto 4
NO: folio_210... goto 4
3. (Separate Class Field): Can the Class Field contain
a hyphen? Examples:
YES: vend-lexmark_neat-size_7...
custom-lexmark_neat-size_7
x-lexmark_neat-size_7... goto 4
NO: lexmark_neat-size_7...
custom_lexmark-neat-size_7... goto 4
[Hastings, Tom N] We agreed NO, but it could
contain "."
4. Do non-standard names invented by *users* have to be
syntactically distinguishable with a "custom" Class Field in order to submit
to Printers that have been configured to indicate that they support custom
sizes? Examples:
YES: custom_new-size_7... goto 5
NO: new-size_7... goto 5
[Hastings, Tom N] YES, in order that they not be
confused with standard names by Recipients and people.
5. Do non-standard names invented by *system
administrators* which they use to configure their Printer supported
capabilities have to be syntactically distinguishable with a "custom" Class
Field? Examples:
YES: custom_new-size_7... goto 6
NO: new-size_7... goto 6
[Hastings, Tom N] YES, same reasons.
6. Do printer vendors need non-standard sizes that
aren't registered (or do they simply register their size names as new
standardized size names)?
YES: goto 7
NO: goto 8
[Hastings, Tom N] NO, vendors should register any
new sizes they need as standard names.
7. (Vendor names must appear) For non-standard sizes
invented by Printer vendors that aren't registered does the vendor's name
have to appear somewhere in the media name? Examples:
a. In Class: lexmark_neat-size_7... goto 8
b. In Class: vend-lexmark_neat-size_7... goto 8
c. In Class: custom-lexmark_neat-size_7... goto 8
d. In Name: na_lexmark-neat-size_7... goto 8
e. neither: na_neat-size_7... goto 8
8. Do we want to limit the units to mm and in forever
in standardized names?
Yes: goto 9
No: goto 9
[Hastings, Tom N] YES
9. Do the units have to appear explicitly in the
Dimensions Field (or does the Class Field imply the units)? If we choose
the NO case, we have to answer: what happens when new Class Field names are
registered. Examples:
YES: iso_a4_210x297mm, na_letter_8.5x11in goto
10
NO: iso-a4_210x297, na-letter_8.5x11 goto
11
[Hastings, Tom N] YES, However, Each class name is
defined for use only with a single size unit (either "mm" or "in") as part
of the class name definition.
The ABNF will tie the "na", "oe", and "asme" class
names to "in" units, and any other class names MUST be "mm" units.
It will be possible to register new class names
which MUST define which units are to be used (either "mm" or "in").
If a new class name needs "in" units, the
registration process will also require adding that class name to the ABNF in
order to tie it to "in".
10. (explicit dimensions): Should the character that
separates the smaller from the larger dimension be "x" or "-"?
"x": iso_a4_210x297mm, na_letter_8.5x11in goto
12
"-": iso_a4_210-297mm, na_letter_8.5-11in goto
12
[Hastings, Tom N] YES. The dimensions are
separated by the "x" character which is drawn from mathematics (times) and
seems to be sufficiently language independent not to be a problem, given the
input from a number of Asian Internationalization experts.
11. (implicit dimensions): Should the character that
separates the smaller from the larger dimension be "x" or "-"?
"x": iso_a4_210x297, na_letter_8.5x11 goto
12
"-": iso_a4_210-297, na_letter_8.5-11 goto
12
12. Should the standard say anything about what the
Recipient Software does if it detects that the Media Class and Media Name
combination don't match the Dimensions Field? Choices are MUST/SHOULD/MAY
for:
a. Its outside the scope of the standard
b. Its implementation-dependent
c. Use the Media Class and Media Name combination as
the intended size
d. Use the Dimensions Field as the intended size
e. Reject/ignore/substitute the name, since it is in
error
[Hastings, Tom N] Senders MUST NOT send standard
names with non-standard sizes or standards sizes with non-standard names.
If Recipients can detect such an error, they MUST treat it as an error.
However, it is OPTIONAL for a Recipient to detect such errors.