IPP Mail Archive: RE: IPP> Comments on Media Size Objectives

IPP Mail Archive: RE: IPP> Comments on Media Size Objectives

RE: IPP> Comments on Media Size Objectives [improved requirement #3]

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Wed May 16 2001 - 12:39:00 EDT

  • Next message: Hastings, Tom N: "IPP> RE: Revised ABNF per Monday's Phone Conference [today's telecon s uggestion]"

    Paul,

    This standard is not trying to also provide the human readable description
    of the media. That is a good thing, but in some protocol standard, not in a
    name standard that is intended to be independent of protocol and be used by
    multiple protocols. How could we possibly standardize on free form
    descriptions of media?

    This standard is dealing with size of the media, both its name and its
    dimensions. This string with both values in it wants to be treated as a
    name, i.e., that the recipient can just do a string compare with a list of
    recognized/supported values, without conversion or parsing. However, for a
    client that may want to display the list of the Printer's supported media
    sizes, we wanted to allow such a client to be able to display both the name
    of the size and the dimensions of the size without having to have a built-in
    table. The client can have a built-in table if it wants to, but it doesn't
    have to. If the client gets a name it doesn't recognize, it can parse the
    string and get both the name and the dimensions and display them both to the
    user. And the really dumb client can display the strings as received by the
    Printer without parsing.

    The agreed requirements have been:

            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.

    But I think we need to add to number 3 to get in the idea that we want both
    the name of the size and the dimensions to be in the same attribute so that
    the client doesn't need to have a table or can handle a new standard or
    custom size from the Printer. How about:

            3. Although primarily intended for machine readability, Names
    should have some relation to common names. A client need not have a
    built-in table
    of media size names and their dimensions in order to be able to accept from
    a Printer
    all of its supported media sizes and display the size names and their
    dimensions to a user.
    Also a newer version of a Printer may support additional standard media size
    names and be
    able to interoperate with an older client. 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.

    Comments?

    Tom

    -----Original Message-----
    From: pmoore@netreon.com [mailto:pmoore@netreon.com]
    Sent: Tuesday, May 15, 2001 18:36
    To: Hastings, Tom N
    Cc: Herriot, Robert; don@lexmark.com; McDonald, Ira; 'Harry Lewis';
    carl@manros.com; ipp@pwg.org
    Subject: RE: IPP> Comments on Media Size Objectives

    Actually I wasnt saying that - I made a mistake - the requirements do say
    that
    you want the name of the size and the size. So now I would rephrase my
    comment
    to - "why do you want the name of the size as well as the size in the same
    attribute?"

    Once again the requirement is mixing human readable with machine readable.

    Why not make a human readable media-description ("Pink A4", "glossy letter -
    use
    it and you owe me 50cents a sheet",...)

    and a machine readable set of attributes (media-size, media-finish, ...)

    When you (Tom) asked me how big A4 is my reply would be "I dont care" - the
    media description tells me its A4. If I want to know how big it is I will
    click
    the little box marked 'media properties' and up will come all the little
    details.

    "Hastings, Tom N" <hastings@cp10.es.xerox.com> on 05/15/2001 06:04:17 PM

    To: "Herriot, Robert" <Robert.Herriot@pahv.xerox.com>, Paul
    Moore/AUCO/US@AUCO
    cc: don@lexmark.com, "McDonald, Ira" <imcdonald@sharplabs.com>, "'Harry
          Lewis'" <harryl@us.ibm.com>, carl@manros.com, ipp@pwg.org

    Subject: RE: IPP> Comments on Media Size Objectives

    No, Paul asked us whether or not our intent was to also convey the name of
    the size [sounds like Alice in Wonderland, doesn't it], as well as the
    dimensions, and we answered yes.

    For example, most metric users don't really know the size of A4, but they
    know that is the media they want. A client that doesn't have a data base,
    wants to be able to display the A4 name to the user (along with the
    dimensions). So we want both name and dimensions.

    Tom

    -----Original Message-----
    From: Herriot, Robert
    Sent: Tuesday, May 15, 2001 11:57
    To: pmoore@netreon.com; Hastings, Tom N
    Cc: don@lexmark.com; McDonald, Ira; 'Harry Lewis'; carl@manros.com;
    Hastings, Tom N; IMAGING@FORUM.UPNP.ORG; ipp@pwg.org
    Subject: RE: IPP> Comments on Media Size Objectives

    I have come to the same conclusion as Paul, namely that the size
    ("8.5x11in")is the only important information and that the name "letter" or
    "foo" is at best informational and at worst a distraction that can make
    someone believe that us-a4.8x11in and wizo-vend-foo-bang.8x11in are
    different.

    > -----Original Message-----
    > From: pmoore@netreon.com [mailto:pmoore@netreon.com]
    > Sent: Thursday, May 10, 2001 2:50 PM
    > To: Hastings, Tom N
    > Cc: don@lexmark.com; McDonald, Ira; 'Harry Lewis'; carl@manros.com;
    > Hastings, Tom N; IMAGING@FORUM.UPNP.ORG; ipp@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@cp10.es.xerox.com> on 05/10/2001
    > 02:21:03 PM
    >
    > To: don@lexmark.com, "McDonald, Ira" <imcdonald@sharplabs.com>
    > cc: "'Harry Lewis'" <harryl@us.ibm.com>, carl@manros.com,
    > "Hastings, Tom N"
    > <hastings@cp10.es.xerox.com>, IMAGING@FORUM.UPNP.ORG,
    > ipp@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@lexmark.com [mailto:don@lexmark.com]
    > Sent: Thursday, May 10, 2001 13:27
    > To: McDonald, Ira
    > Cc: 'Harry Lewis'; carl@manros.com; Hastings, Tom N;
    > IMAGING@FORUM.UPNP.ORG; ipp@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@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@interlock.lexmark.com> on
    > 05/10/2001
    > 12:55:01 PM
    >
    > To: "'Harry Lewis'" <harryl%us.ibm.com@interlock.lexmark.com>,
    > carl%manros.com@interlock.lexmark.com
    > cc: "Hastings, Tom N"
    > <hastings%CP10.ES.XEROX.COM@interlock.lexmark.com>,
    > IMAGING%FORUM.UPNP.ORG@interlock.lexmark.com,
    > ipp%pwg.org@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@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 : Wed May 16 2001 - 12:40:38 EDT