IPP Mail Archive: RE: IPP> New CUPS 1.1 beta and set-job-att

IPP Mail Archive: RE: IPP> New CUPS 1.1 beta and set-job-att

RE: IPP> New CUPS 1.1 beta and set-job-attributes extension [why not use "job-sheets"?]

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Tue Mar 21 2000 - 17:59:25 EST

  • Next message: Michael Sweet: "Re: IPP> New CUPS 1.1 beta and set-job-attributes extension [why not use "job-sheets"?]"

    Michael,

    I wasn't completely clear on my suggestion about adding new keywords to
    "job-sheets" Job Template attribute. My intention was that you consider
    adding three new keywords to the existing IPP/1.1 "job-sheets" (type3
    keyword | name) Job Template attribute that you are already supporting in
    CUPS. I had not intended that you implement the 'collection' attribute
    syntax at all. Unfortunately, the spec that I referred to (PPE spec) did
    have the 'collection it too.

    So making my suggestion again, how about just adding the following keywords
    to the CUPS "job-sheets" (type3 keyword | name) Job Template attribute,
    instead of adding the two new "banner-start" and "banner-end" Job Template
    attributes?

    In other words, just add the following three keywords to "job-sheets":

      'job-start-sheet' A job sheet MUST be printed to indicate the start of the
    job.

      'job-end-sheet' A job sheet MUST be printed to indicate the end of the
    job.

      'job-wrap-sheets' Job sheets MUST be printed to indicate the start and end
    of
    all the output associated with the job.

    (If you don't like the name of the last one, suggest a better name for us to
    agree on, like 'job-start-and-end-sheets').

    ISSUE: Does it make sense to have an end sheet without a start sheet? If
    not, we should eliminate the 'job-end-sheet' value.

    Wouldn't it be simpler to use these values in CUPS, rather than introducing
    two new Job Template attributes?

    About collections:

    On the subject of "job-sheets" and "media" and collections that is in the
    PWG "Production Printing Extension" (PPE) spec:

    I agree that neither you (nor anyone else) should implement the PPE spec at
    this time (with its 'collection' attribute syntax extension to
    "job-sheets"). The PPE spec has been reviewed only slightly by the PWG and
    has already has push back on extending "job-sheets" (type3 keyword | name)
    and "media" (type3 keyword | name) by adding the 'collection' attribute
    syntax to the IPP/1.1 attributes to give:

      "job-sheets" (type3 keyword | name | collection) and
      "media" (type3 keyword | name | collection)

    Instead, the suggestion for the next version of the PPE spec is to add two
    new OPTIONAL attributes and leave the IPP/1.1 attributes as they are. Then
    we would have:

      "job-sheets" (type3 keyword | name) and
      "job-sheets-col" (collection)
     
      "media" (type3 keyword | name) and
      "media-col" (collection)

    If the Printer supports the "xxx-col" (collection) Job Template attribute,
    it MUST also support the (simpler) IPP/1.1 "xxx" (type3 keyword | name) Job
    Template attribute.

    The "media-col" collection has all sorts of member attributes that represent
    the characteristics of media, such as "media-size", "media-weight",
    "media-color", etc.

    The "job-sheets-col" (collection) attribute would have the following member
    attributes:

       "job-sheets (type3 keyword | name)
       "media" (type3 keyword | name)

    that allow a production printing client to control the media on which the
    job start and/or end sheet is printed.

    Tom

    -----Original Message-----
    From: Michael Sweet [mailto:mike@easysw.com]
    Sent: Monday, March 20, 2000 19:33
    To: Hastings, Tom N
    Cc: IPP Mailing List
    Subject: Re: IPP> New CUPS 1.1 beta and set-job-attributes extension
    [why not use "job-sheets"?]

    "Hastings, Tom N" wrote:
    > ...
    > Wouldn't it be simpler to use these values in CUPS, rather than
    > introducing two new Job Template attributes?

    1. The PPE uses COLLECTIONS for this stuff
    2. Collections are still being defined.
    3. CUPS currently does not do anything with collections (it will
       store the raw data, but that is all)
    4. Without collections the job-sheets attribute cannot support
       what CUPS needs to do.

    Given those things, it is unlikely in the EXTREME that we will
    change our design this close to a final release.

    It is *possible* that we can change the names of the attributes
    to "job-sheets-*", however I am concerned that we might step on
    future attributes. Possible names:

        job-sheets-supported
        job-sheets-start-default
        job-sheets-end-default
        job-sheets-start
        job-sheets-end

    At least that would be in line with the IPP spec, but that also
    means we must support "job-sheets" and "job-sheets-default". I'm
    not sure how we would map that given the ambiguity in the spec...

    Another possibility might be to overload the "name" value to use
    "start,end" for the "job-sheets" and "job-sheets-default" attributes,
    however that might break clients that try to compare them against
    the "job-sheets-supported" values.

    In any case, any change we make now CANNOT include support for the
    PPE spec.

    -- 
    ______________________________________________________________________
    Michael Sweet, Easy Software Products                  mike@easysw.com
    Printing Software for UNIX                       http://www.easysw.com
    

    -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, March 20, 2000 14:06 To: Michael Sweet Cc: IPP Mailing List Subject: RE: IPP> New CUPS 1.1 beta and set-job-attributes extension [why not use "job-sheets"?]

    Michael,

    There are two new Job Template attributes: "banner-end" and "banner-start" that CUPS/1.1 is introducing that I was curious about. It was our intention that the IPP/1.0 "job-sheets" (type3 keyword | name) Job Template attribute would perform the function that your two new Job Template attribute are performing. While we only had two values defined in IPP/1.0 and IPP/1.1: 'none' and 'standard', we thought that it would be simple to add more values whenever someone wanted.

    In fact, the PWG "Production Printing Attributes, Set1" spec proposes three new keywords for use with the IPP/1.1 "job-sheets" Job Template attribute:

    job-start-sheet A job sheet MUST be printed to indicate the start of the job.

    job-end-sheet A job sheet MUST be printed to indicate the end of the job.

    job-wrap-sheets Job sheets MUST be printed to indicate the start and end of all the output associated with the job.

    Wouldn't it be simpler to use these values in CUPS, rather than introducing two new Job Template attributes?

    From your CUPS spec:

    4.1.1 Print-Job Request

    The following groups of attributes are supplied as part of the Print-Job Request:

    Group 1: Operation Attributes

    Natural Language and Character Set: The "attributes-charset" and "attributes-natural-language" attributes as described in section 3.1.4.1 of the IPP Model and Semantics document.

    "printer-uri" (uri): The client MUST supply a URI for the specified printer.

    Group 2: Job Template Attributes

    "banner-end" (name(127)): (CUPS 1.1 and higher) The client OPTIONALLY supplies a banner page that is printed after any files in the print job. The name of "none" is reserved to indicate that no banner page should be printed. If the client does not specify this attribute then the value of the "banner-end-default" printer object attribute is used.

    "banner-start" (name(127)): (CUPS 1.1 and higher) The client OPTIONALLY supplies a banner page that is printed before any files in the print job. The name of "none" is reserved to indicate that no banner page should be printed. If the client does not specify this attribute then the value of the "banner-start-default" printer object attribute is used.

    Other Job Template Attributes

    Comments? Tom

    -----Original Message----- From: Michael Sweet [mailto:mike@easysw.com] Sent: Monday, March 13, 2000 05:44 To: IPP Mailing List Subject: IPP> New CUPS 1.1 beta and set-job-attributes extension

    Hi, All!

    We're getting close to the second beta release of CUPS 1.1. Part of the next beta release is support for the set-job-attributes operation (see draft-ietf-ipp-job-printer-set-ops-01.txt)

    HOWEVER

    The current implementation of the set-job-attributes in CUPS will support changing of the job-printer-uri attribute, which is currently marked as READ-ONLY in the spec. I've mentioned this problem before, but let me summarize once again:

    1. The job-printer-uri attribute needs to be changeable to support a "move-job" type operation. 2. We can eliminate certain "special case" problems such as moving jobs to a different server by restricting the new URIs to the same server, or allowing the server to reject changes if they are not possible (e.g. SHOULD support moving to a different server, MUST support moving to a different printer object on the same server...) 3. To support implementations that maintain a separate job ID space for each printer object, the set-job-attributes operation would then also report the current job-id and job-uri attributes in the response data.

    Our current options with CUPS are to ship it with a non-conforming implementation of set-job-attributes, or register yet another extension operation that performs exactly the same functionality as set-job-attributes but allows the job-printer-uri attribute to be changed.

    Thoughts?

    -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com



    This archive was generated by hypermail 2b29 : Tue Mar 21 2000 - 18:08:50 EST