IPP Mail Archive: IPP> MED - Thoughts on the all-in-one name

IPP> MED - Thoughts on the all-in-one name string for the Appendix of the Media Name standard

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Wed Apr 04 2001 - 18:38:30 EDT

  • Next message: Manros, Carl-Uno B: "IPP> SEC - Security Issue Discussion in IETF50 IPP WG Meeting in Minn eapolis"

    Ron,

    Here are some thoughts for the Media Names Standard appendix about
    concatenating fields to make an all-in-one name string that could be used as
    keyword values of the IPP/1.1 "media" Job Template attribute. I hope people
    will comment, especially those who have advocated the all-in-one name string
    fills an important need (which I agree with).

    The Media Names standard already has three fields:

    Media Type Name:
      stationery, transparency, envelope, envelope-plain, envelope-window,
    continuous, continuous-long, continuous-short, tab-stock, pre-cut-tabs,
    full-cut-tabs, multi-part-form, labels, multi-layer, screen, screen-paged,
    photographic, cardstock

    Media Size Self Describing Name:
      [prefix] size-name "." short-dim "-" long-dim

    Media Color Name:
      'no-color', 'white', 'pink', 'yellow', 'blue', 'green', 'buff',
    'goldenrod', 'red', 'gray', 'ivory', 'orange'

    and we've agreed to add Media Coating names:
      'none', 'glossy', 'high-gloss', 'semi-gloss', 'satin', 'matte'

    Assumption: that the three fields in our current draft MUST be present in
    an all-in-one name string and in order, separated by "." without any need to
    name the fields, since they all must be present:

      Media Type Name "." Media Size Self Describing Name "." Media Color Name

    Examples:

    stationery.na-letter.8500-11000.white
    stationery.iso-a4.iso-a4.2100-2970.white
    photographic.na-5x7.5000-7000.white
    transparency.na-letter.8500-11000.no-color
    envelope.na-9x11.9000-11000.blue

    From the PWG IEEE-ISTO 5100.3 IPP Production Printing Extension, we have 7
    additional member attributes of the "media-col" collection that could be
    fields in an all-in-one name string:

    media-pre-printed:
      'blank', 'pre-printed', letter-head'

    media-hole-count:
      '0', '1', '2', '3', ...

    media-order-count:
      '1', '2', '3', ...

    media-weight-metric:
      '80', ...

    media-back-coating:
      'none', 'glossy', 'high-gloss', 'semi-gloss', 'satin', 'matte'

    media-front-coating:
      'none', 'glossy', 'high-gloss', 'semi-gloss', 'satin', 'matte'

    media-recycled:
      'none', 'standard'

    I'm using these 7 fields from the PWG 5100.3 as examples of how to extend
    the all-in-one string name that could be used with the IPP/1.1 "media" Job
    Template attribute. Whether our Appendix should give these as examples, or
    just give the pattern for additional fields, needs to be decided.

    These 7 additional fields are OPTIONAL in two senses:

      a. the implementation doesn't support the concept
      b. the implementation does support the concept, but the usual value of the
    field is 'none' for most media instances.

    6 of the 7 fields have a natural 'none' value that could be represented by
    the omission of the field, rather than a specific value: pre-printed=blank,
    hole-count=0, order-count=1, back-coating=none, front-coating=none,
    recycled=none. Only weight-metric always needs a value if weight is
    supported.

    Whether or not these "optional" fields could occur in any order would depend
    on the standard that references the Media Name standard.

    I see three different approaches to combining the remaining 7 optional
    fields into an all-in-one name string, from most rigorous for machine
    parsing to simplest for human recognition.

    a. have each field start with a field name and a special character. Since
    "_" is the only character in IPP keyword syntax not used, I'm suggesting
    using it as the delimiter character. Example fields: 'recycled_standard',
    'hole-count_3', 'front-coating_matte'

    b. have each field start with a field name set off by 'hyphen'. Examples:
    'recycled-standard', 'hole-count-3', 'front-coating-matte'

    c. don't have field names at all. Just depend on the values not colliding.
    Examples: 'recycled', 'matte'. But that can't be done for the numeric
    values, for weight, hole count, order count, so need prefix or suffix for
    them. Examples: '3-hole', 'order-count-2'

    Here are the 5 examples above with each of the three methods:

    a. field names set off with "_":

    stationery.na-letter.8500-11000.white.weight-metric_80
    stationery.iso-a4.iso-a4.2100-2970.white.weight-metric_80.pre-printer_letter
    -head
    photographic.na-5x7.5000-7000.white.weight-metric_80.front-coating_matte
    transparency.na-letter.8500-11000.no-color.weight-metric_80.hole-count_3
    envelope.na-9x11.9000-11000.blue.weight-metric_80.recyled_standard

    b. field names set off with "-":

    stationery.na-letter.8500-11000.white.weight-metric-80
    stationery.iso-a4.iso-a4.2100-2970.white.pre-printer-letter-head
    photographic.na-5x7.5000-7000.white.weight-metric-80.front-coating-matte
    transparency.na-letter.8500-11000.no-color.weight-metric-80.hole-count-3
    envelope.na-9x11.9000-11000.blue.weight-metric-80.recycled-standard

    c. no field names, except for numeric data:

    stationery.na-letter.8500-11000.white.80gpsm
    stationery.iso-a4.iso-a4.2100-2970.white.letter-head
    photographic.na-5x7.5000-7000.white.80gpsm.matte
    transparency.na-letter.8500-11000.no-color.80gpsm.3-holes
    envelope.na-9x11.9000-11000.blue.80gpsm.recycled

    Someone had asked a question about the Media Coating as to whether we were
    just defining the name values or whether we were also defining the
    attributes, so that the coating for the front could be specified separately
    from the back. So we probably need to pick something for our Appendix for
    the Coating for front versus back.

    Comments?

    Thanks,
    Tom

    -----Original Message-----
    From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com]
    Sent: Wednesday, April 04, 2001 08:02
    To: 'Hastings, Tom N'; Bergman, Ron
    Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade
    (E-mail); Michael Sweet
    Subject: RE: min and max size and the creeping scope of the media
    standard [all-in-one names]

    Tom,

    Based upon the IPP restriction, the period is acceptable.

    As far as having some parameters optional in the string, my preference
    is no. Every parameter must have a value. This keeps processing the
    string simple and additional parameters can be added without breaking
    any old applications.

            Ron

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Tuesday, April 03, 2001 7:13 PM
    To: Bergman, Ron
    Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade
    (E-mail); Michael Sweet
    Subject: RE: min and max size and the creeping scope of the media
    standard [all-in-one names]

    Ron,

    While slash is kind of clear, the problem is that it can't be used as an IPP
    keyword for the "media" attribute. IPP 'keyword' values can only be all
    lower case letters, digits, ".", "-", and "_". We wouldn't want to have IPP
    encode these all in one names using the 'name' attribute syntax, since IPP
    RECOMMENDs case insensitivity (upper case allowed and equivalent to lower
    case) for the 'name' attribute syntax values. I don't see any problem with
    using the "." to separate fields in the all-in-one names, since the media
    size field must have a "." within it as well. With ".", the names are like:

       stationery.na-letter.8500-11000.white.none

    which really reads pretty well. The fact that the Media Size Self
    Describing Name field is made up of two fields: Media Size Name and
    Dimensions, doesn't both me and still fits our syntax.

    But if there is objection to this dual use of ".", the underscore ("_")
    character is also available in the IPP 'keyword' syntax. Using the
    underscore character the names would look like:

       stationery_na-letter.8500-11000_white_none

    But if we use underscore to separate the fields, what will we use if we want
    to make fields optional, such as the Media Coating, which will usually want
    to be 'none'? There aren't any more IPP 'keyword' characters left.

    I had suggested that we might want to put the name of the field as a prefix
    separated by "_", if the field can be left out. Then we could have:

       stationery.na-letter.8500-11000.white -- meaning no coating

    and:

       stationery.na-letter.8500-11000.white.coating_matte

    when a coating other than none was wanted.

    Or we could just bite the bullet and always carry coating 'none' along in
    the names, since these names are intended for program to program
    communication and have no optional field mechanism. We could leave the idea
    of optional fields to the future (as long as we don't use up "_" now).

    Tom

    -----Original Message-----
    From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com]
    Sent: Tuesday, April 03, 2001 18:39
    To: 'Hastings, Tom N'; Bergman, Ron
    Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade
    (E-mail); Michael Sweet
    Subject: RE: min and max size and the creeping scope of the media
    standard [new subject]

    Tom,

    The all-in-one could be postponed. I was thinking it should be an
    appendix in the Media Names standard as the recommended method of
    concatenating the defined media names to create a single media
    definition. Even so, it could be first published as an addendum
    and then later integrated into the standard in next years update.

    If we are close to having an agreement, it could be added now.
    I have no problem with your proposal. One thought I had was
    replacing the period as a separator between names with a slash(/).
    This might be easier on a parser, since the period is now the
    separator in the size name. So your example would be:

            stationery/na-letter.8500-11000/white/none

    Or, would a different character be better?

            Ron

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Tuesday, April 03, 2001 5:51 PM
    To: Bergman, Ron
    Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade
    (E-mail); Michael Sweet
    Subject: Re: min and max size and the creeping scope of the media
    standard [new subject]

    Looks good to me for the min and max. I agree that it fits within the scope
    of the standard.

    About the creeping scope of the media standard, I agree that UPnP doesn't
    need the all-in-one, but IPP could really use it. But if everyone keeps
    adding requirements, we'll never get what we seem to have good agreement on
    done. How about stopping the current version with:

      Media Type Names
      Media Color Names
      Media Finish Names
      Media Size Self Describing Names

    and then add the all-in-one as a companion PWG standard which augments this
    standard and which also has any other fields needed as well? Much as I'd
    like to see the all-in-one for IPP for use with the existing "media" Job
    Template attribute, I think that it can wait a few months. Also I suspect
    that it will take more debate and design.

    Tom

    -----Original Message-----
    From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com]
    Sent: Tuesday, April 03, 2001 17:31
    To: 'Hastings, Tom N'; Michael Sweet; Bergman, Ron
    Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade
    (E-mail)
    Subject: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4
    down- loaded

    Tom,

    I have added the following:

    5.2.5 The size-name "max" shall be reserved to indicate an upper
      size limit of either a device or application. Also, the size-name
      "min" shall be reserved to indicate a lower size limit. Example:
      For a device that can process forms as small as 2 x 3 inches to
      18 x 36 inches:
         na-custom-max.18000-36000 and na-custom-min.2000-3000

    This is part of the custom size section (5.2). My original concern
    was how this was to be presented. This paragraph keeps within my
    guidelines as more applicable to media and not a device.

    I am quite sensitive to the issue of expansion of the scope of this
    project. Keep in mind that this started out as a simple compilation
    of all known media sizes. We have since added color, type, finish,
    and now there is a proposal for an all-in-one format. There also
    have been rejected proposals for media feed direction, printing
    orientation, and others that I have already forgotten.

    Not that what has been added is bad, we just have to be somewhat
    selective as to what is included. On the one hand, I am hearing
    that the UPnP project needs this completed before the meeting
    this month and then I see all the additions everyone wants. When
    sonething is added, it may add a nice feature, but it also pushes
    out the completion date.

            Ron

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Tuesday, April 03, 2001 14:23
    To: Harry Lewis; Mark VanderWiele
    Cc: Mark_Hamzy/Austin/IBM%IBMUS; IPP Group; Norbert Schade;
    owner-ipp@pwg.org; Pete Zannucci; UPD group
    Subject: RE: UPD> Re: IPP> min/max custom size values

    Harry and Mark,

    To build on your idea (you turned me around), we could take the current IPP
    "media" attribute and define how to concatenate the keyword values in the
    Media Standard to make new IPP keywords, to make a "joined syntax".

    If we did that and put the concatenation rules into the Media standard
    itself, then we would be defining Media Names (something that the current
    draft says we aren't doing - see the Media Name definition in Section 2
    Terminology, but we can just change that statement).

    We can just put the rules for combining the keyword values together. We
    don't need to add any more tables.

    All we need to do is pick the order and the separator character.

    For order, how about in order of decreasing significance:

    Media Type Name
    Media Size Name
    Media Color Name
    Media Coating Name (we've agreed to add this fourth set of names)

    For a separator character, I suggest that we use the ".", which we are
    already using as a separator character in the MediaSize.

    Examples of Media Names:

    stationery.na-letter.8500-11000.white.none
    stationery.iso-a4.iso-a4.2100-2970.white.none
    photographic.na-5x7.5000-7000.white.matte
    transparency.na-letter.8500-11000.no-color.none
    envelope.na-9x11.9000-11000.blue.none

    For the first three fields, they MUST all be present. But what about Media
    Coating. The values are: 'none', 'glossy', 'high-gloss', 'semi-gloss',
    'satin', 'matte'

    If this were the last field ever, then we could say if it is missing, then
    it means 'none'. But I suspect that we want to be able to keep adding
    fields in the future (or that implementers might want to be able to add
    fields). Do we need to introduce keywords for those fields that can be
    omitted, such as Media Coating?

    The equal sign (=) would be more natural to set off keywords from values.
    However, to be compatible with IPP, the only unassigned character in IPP
    keywords is "underscore" (_). So think of the "coating_" as a prefix on the
    values.

    So the above 5 examples would be:

    stationery.na-letter.8500-11000.white
    stationery.iso-a4.iso-a4.2100-2970.white
    photographic.na-5x7.5000-7000.white.coating_matte
    transparency.na-letter.8500-11000.no-color
    envelope.na-9x11.9000-11000.blue

    Only the third one has the keyword coating, since it is the only one that
    has a coating that isn't 'none'. We probably have to define a canonical
    order for keywords presence or absence, in order to eliminate different
    orderings being equivalent, correct?

    Comments?

    Tom

    -----Original Message-----
    From: Harry Lewis [mailto:harryl@us.ibm.com]
    Sent: Tuesday, April 03, 2001 13:37
    To: Hastings, Tom N
    Cc: Mark_Hamzy/Austin/IBM%IBMUS; IPP Group; Mark VanderWiele; Norbert
    Schade; owner-ipp@pwg.org; Pete Zannucci; UPD group
    Subject: RE: UPD> Re: IPP> min/max custom size values

    I think one of the things that might be encouraging Mark to recommend a
    "joined syntax" is the rate at which we keep inventing and/or applying new
    access protocols to this information (SNMP, IPP, uPnP etc.). If we were to
    define a joined syntax that concatenates the necessary information to
    "use" the media in the device (including Media Size, Media Type, Media
    Source, Media Name) there would be a greater chance of adoption across
    protocols (new and revised).
    ----------------------------------------------
    Harry Lewis
    IBM Printing Systems
    ----------------------------------------------

    "Hastings, Tom N" <hastings@cp10.es.xerox.com>
    Sent by: owner-ipp@pwg.org
    04/03/2001 01:30 PM

     
            To: Mark VanderWiele <markv@us.ibm.com>, Norbert Schade
    <norbertschade@oaktech.com>
            cc: UPD group <upd@pwg.org>, IPP Group <ipp@pwg.org>, Pete
    Zannucci
    <pzaan@us.ibm.com>, Mark_Hamzy/Austin/IBM%IBMUS <hamzy@us.ibm.com>
            Subject: RE: UPD> Re: IPP> min/max custom size values

     

    Mark,

    I agree that real applications need to know about combinations of media
    attributes. However, each print protocol has different ways to deal with
    that. So I think it is wiser for the Media standard to just list the
    names
    of the various characteristics and leave it to the various Print protocols
    do deal with combinations.

    Ok?

    For example, have you seen the IEEE-ISTO PWG 5100.3 Production Printing
    Extension, which does combine the media attributes into a collection, so
    that combinations can be configured by the administrator. However, even
    that spec does not have a way for the client to query the supported
    combinations. Last summer and fall, the IPP WG considered a proposal for
    a
    Resource object that had a number of operations to create, delete, and
    query
    Resource objects of a defined type. Media was a suggested type. Then the
    group agreed that IPP should really have distinct set of operations for
    each
    object type, so that we need to write a spec for the Media object that has
    operations, like Create-Media, Delete-Media, Get-Media-Attributes,
    Get-Media
    (with a filter).

    Are you interested in seeing such a spec and reviewing and/or contributing
    to it?

    An another example or a print protocol that deals with the combinations
    problem, the UPnP EnhancedLayoutPrint template defines a GetMargins
    operation in which the input parameters are MediaType and MediaSize and
    the
    output parameter is the four margins. If the client supplies a
    combination
    of MediaType and MediaSize that is not supported, the Printer MUST return
    an
    error code.

    Thanks,
    Tom

    -----Original Message-----
    From: Mark VanderWiele [mailto:markv@us.ibm.com]
    Sent: Friday, March 30, 2001 07:44
    To: Norbert Schade
    Cc: UPD group; IPP Group; Pete Zannucci; Mark_Hamzy/Austin/IBM%IBMUS
    Subject: Re: UPD> Re: IPP> min/max custom size values

    Careful, we may be making the same mistake we made in IPP where the form
    size, media type, and tray are returned separately causing user interface
    nightmare since all three of these really must be selected together and
    represent the actual configuration of the printer. Therefore, I would
    propose that when we have settled in on a syntax for the form size, media
    type, and tray we go one step further and define a way to join the fields
    so that the proper constraints can be represented. Perhaps a simple "+"
    character. Again, form size by itself is meaningless.

    Regards,
    Mark VanderWiele
    IBM, Linux Tecnology Center
    512-838-4779, t/l 678-4779
    MARKV@IBMUS
    email: markv@us.ibm.com



    This archive was generated by hypermail 2b29 : Wed Apr 04 2001 - 18:42:22 EDT