Bill's third boiled down requirement is:
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.
Part of the "useful information" is the size name, so perhaps we need to
clarify the requirement to be:
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.
Quick, can you tell me what the mm dimensions are for A4 paper? If I gave
you two media choice of 210x297mm or 225x297mm, would you know which one
was A4? Both metric sizes are in our standard?
Tom
-----Original Message-----
From: pmoore at netreon.com [mailto:pmoore at netreon.com]
Sent: Thursday, May 10, 2001 14:50
To: Hastings, Tom N
Cc: don at lexmark.com; McDonald, Ira; 'Harry Lewis'; carl at manros.com;
Hastings, Tom N; IMAGING at FORUM.UPNP.ORG; ipp at pwg.org
Subject: RE: IPP> Comments on Media Size Objectives
if the intent is to convey the media size to the app why do we care about
vendor
names etc. Why isnt the size just sent ("8.5x11in"). Why does the media size
attribute have to include a name at all - are lexmark inches somehow
different
from kinko inches?
What is the difference between us-a4.8x11in and wizo-vend-foo-bang.8x11in if
the
purpuse of this spec is to convey the size of the media. It seems that the
intent is not to convey the size of the media but the name of the size too -
this is a quite different thing (the requirements dont say anything about
conveying the name of the size).
"Hastings, Tom N" <hastings at cp10.es.xerox.com> on 05/10/2001 02:21:03 PM
To: don at lexmark.com, "McDonald, Ira" <imcdonald at sharplabs.com>
cc: "'Harry Lewis'" <harryl at us.ibm.com>, carl at manros.com, "Hastings, Tom
N"
<hastings at cp10.es.xerox.com>, IMAGING at FORUM.UPNP.ORG, ipp at pwg.org
(bcc:
Paul Moore/AUCO/US)
Subject: RE: IPP> Comments on Media Size Objectives
I agree with Don that a more user-friendly vendor extension mechanism should
be used, such as vend-lexmark, or custom-lexmark, if we need a printer
vendor extension mechanism at all.
A formal extension mechanism that the IETF uses is important for names in
which the entire semantics is *implied* by the name, such as a MIME type.
However, for our Media Size Self Describing Names the entire semantics
(i.e., dimensions) of the size name is actually contained in the name
itself.
A more fundamental question is why would a Printer vendor that has a custom
media size, not want to put it into our Media Standard now? We'd just add
it with no vendor name needed.
If the printer vendor invents the size after our standard is published,
we've got to have a way to add/register more standard size names anyway, so
the Printer vendor just gets the new size registered with the PWG using
normal standard syntax without the vendor needing to be identified in the
name.
Only, if a vendor really wants his name in the media name, do we need to
decide how to do that. We can decide then whether this company name is a
new Naming Authority field or this company name should be part of the Media
Name field. For example, if Lexmark has a new size, say playing-card, that
they really want to have the Lexmark name appear, the name could be
registered as:
lexmark_playing-card_2x4in (If we add Lexmark as a Naming Authority)
na_lexmark-playing-card_2x4in (If Lexmark wants to make the name be
under the na Naming Authority).
Tom
-----Original Message-----
From: don at lexmark.com [mailto:don at lexmark.com]
Sent: Thursday, May 10, 2001 13:27
To: McDonald, Ira
Cc: 'Harry Lewis'; carl at manros.com; Hastings, Tom N;
IMAGING at FORUM.UPNP.ORG; ipp at pwg.org
Subject: RE: IPP> Comments on Media Size Objectives
All:
The problem is that if the driver has no knowledge of a new standardized
paper
size and it tries to parse and display the name, the end user will have
absolutely no idea that "vend-641" is Lexmark defined paper size. He might
be
able to do something with "vend-Lexmark"
**********************************************
* Don Wright don at lexmark.com *
* Chair, Printer Working Group *
* Chair, IEEE MSC *
* *
* Director, Alliances & Standards *
* Lexmark International *
* 740 New Circle Rd *
* Lexington, Ky 40550 *
* 859-825-4808 (phone) 603-963-8352 (fax) *
**********************************************
"McDonald, Ira" <imcdonald%sharplabs.com at interlock.lexmark.com> on
05/10/2001
12:55:01 PM
To: "'Harry Lewis'" <harryl%us.ibm.com at interlock.lexmark.com>,
carl%manros.com at interlock.lexmark.com
cc: "Hastings, Tom N" <hastings%CP10.ES.XEROX.COM at interlock.lexmark.com>,
IMAGING%FORUM.UPNP.ORG at interlock.lexmark.com,
ipp%pwg.org at interlock.lexmark.com (bcc: Don Wright/Lex/Lexmark)
Subject: RE: IPP> Comments on Media Size Objectives
Hi,
A whole lot of IETF protocols (e.g., SLP attribute names) use the
universal IETF convention of 'x-nnn-' as a prefix where 'nnn'
is the vendors decimal enterprise number assigned by IANA.
It's clean and simple and never ambiguous (no two vendors will EVER
have the same enterprise number).
Cheers,
- Ira McDonald
-----Original Message-----
From: Harry Lewis [mailto:harryl at us.ibm.com]
Sent: Thursday, May 10, 2001 10:44 AM
To: carl at manros.com
Cc: Hastings, Tom N; IMAGING at FORUM.UPNP.ORG; ipp at pwg.org
Subject: RE: IPP> Comments on Media Size Objectives
Well, again, I think it is challenging the elasticity of the main goal
which was to establish one authoritative list of STANDARD media sizes. In
an XML encoding I can picture distinguishing media name as belonging to a
"standard" vs. "private" naming authority. If we MUST accommodate this
goal in the compromise syntax, I guess I suggest a convention of the
"class" or "naming authority" such as
"vend-xxx"
where xxx could be the name of a vendor or customer.
Again, I believe it would be better to keep the media names in this list
we are collecting STANDARD and fairly SIMPLE.
----------------------------------------------
Harry Lewis
IBM Printing Systems
----------------------------------------------
"Carl-Uno Manros" <carl at manros.com>
05/09/2001 10:35 PM
Please respond to carl
To: "Harry Lewis" <harryl at us.ibm.com>, "Hastings, Tom N"
<hastings at CP10.ES.XEROX.COM>
cc: <IMAGING at FORUM.UPNP.ORG>, <ipp at pwg.org>
Subject: RE: IPP> Comments on Media Size Objectives
Harry,
I think I have to agree with you on most points. In particular I like your
suggestion to change the name as the current name carries too much
semantic
connotations, which can easily be misinterpreted.
The one important issue I still see is whether we want to lay down some
rules for how to add "private names" which are not in our list, be it by a
vendor or by end customers.
Carl-Uno
> -----Original Message-----
> From: owner-ipp at pwg.org [mailto:owner-ipp at pwg.org]On Behalf Of Harry
> Lewis
> Sent: Wednesday, May 09, 2001 9:13 PM
> To: Hastings, Tom N
> Cc: IMAGING at FORUM.UPNP.ORG; ipp at pwg.org> Subject: IPP> Comments on Media Size Objectives
>>> 18 objectives for a "2-bit" "name" field!
>> Comments...
>> 1. We have a compromise, not an optimization (for machine parsing).
> Suggest the concept of "facilitate" be stressed over "optimize".
>> 4. Edit - "Only include the name in its native units" (delete "each").
>> 5. Dump this goal!! (additional units) This has been a rat trap!
> The compromise syntax we are developing is too stressed by this
> goal. Save this for a full fledged schema.
>> 6. I think the notion of "self describing" has been misinterpreted.
> Some feel a description should contain more (margins etc.). Some
> think "self describing" means easy to read and distinguish. It
> might be better to simply state... "The "Standard Media Name" will
> contain both a "Name" part and a "Dimension" part."
>>> 7,8,9. I think these can all be replaced by simply extending the above
> (6) to read "The "Standard Media Name" will contain 3 parts,
> 1. Naming Authority
> 2. Name
> 3. Dimension
>> 10. Given (6,7,8,9 - above) this is just stating the obvious. This
> registry
> is a simple list. If we find stuff we've missed, we help ourselves
add
> it. If we missed a galaxy or universe our there, somewhere... (i.e.
> an entire naming authority) or if we want to establish a new name
> space, we can readily do so.
>> On and On... I don't know about the rest. Glazed donuts come to mind.
> Or... a real schema development effort!
>> ----------------------------------------------
> Harry Lewis
> IBM Printing Systems
> ----------------------------------------------
>