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

From: Wagner,William (wwagner@netsilicon.com)
Date: Thu May 10 2001 - 14:07:22 EDT

  • Next message: Manros, Carl-Uno B: "RE: IPP> Comments on Media Size Objectives"


    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


    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).

    - 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


    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"
            cc: <IMAGING@FORUM.UPNP.ORG>, <ipp@pwg.org>
            Subject: RE: IPP> Comments on Media Size Objectives



    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
    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.


    > -----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
    > 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