Tom,
I generally agree with Harry. The objectives sound more like a
justifications and implementation considerations for what has been decided
rather than basic objectives. The point may be moot now, but I seem to
recall the objective was to list standard names. Having information in the
names that allowed size determination of unrecognized names was an added
feature. Then having the names human readable as a fallback was added still
later. I suggest a simpler set of objectives (not implementation
details)reflecting what we have been hearing is:
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
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
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.
This base objective and two added-on objectives are addressed by Harry's
comment. This is a solution not an objective.
"The "Standard Media Name" will contain 3 parts,
1. Naming Authority
2. Name
3. Dimension"
We can add objectives:
10. Be able to register additional Media Names [naming authority?;
units?] after the standard is approved.
12, 13 Design the syntax to facilitate Client Software and Recipient
Software parsing
With respect to vendor specific ID, Harry and Ira's suggestion sounds good.
I would suggest that:
1. Since the vendor/organization is the naming authority, I suggest that
this term be considered the "class".
In the much more likely event that the vendor-specific name is not
recognized, the application would display vendor as well as the other name
parts. I suggest that any time the name is not machine recognized, the class
would be displayed.
2. If the vendor ID is regarded as a class, then I suggest that the class
should be delineated as a separate field
3. If the 'x-nnn" form is used, then having the nnnxmmm for size is
confusing and the nnn-mmm form is preferable
-----Original Message-----
From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
Sent: Thursday, May 10, 2001 12:55 PM
To: 'Harry Lewis'; carl@manros.com
Cc: Hastings, Tom N; IMAGING@FORUM.UPNP.ORG; ipp@pwg.org
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@us.ibm.com]
Sent: Thursday, May 10, 2001 10:44 AM
To: carl@manros.com
Cc: Hastings, Tom N; IMAGING@FORUM.UPNP.ORG; ipp@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@manros.com>
05/09/2001 10:35 PM
Please respond to carl
To: "Harry Lewis" <harryl@us.ibm.com>, "Hastings, Tom N"
<hastings@CP10.ES.XEROX.COM>
cc: <IMAGING@FORUM.UPNP.ORG>, <ipp@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@pwg.org [mailto:owner-ipp@pwg.org]On Behalf Of Harry
> Lewis
> Sent: Wednesday, May 09, 2001 9:13 PM
> To: Hastings, Tom N
> Cc: IMAGING@FORUM.UPNP.ORG; ipp@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
> ----------------------------------------------
>
This archive was generated by hypermail 2b29 : Thu May 10 2001 - 14:09:02 EDT