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

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

  • Next message: Hastings, Tom N: "RE: IPP> OPS - Ok that the 'any-value' out-of-band value has an a ttribute value? [URGENT email discussion needed]"


    Thanks for pointing out this issue on the current Set-Job-Attributes

    The IPP WG has debated whether or not operations should have side effects,
    such as whether or not the Set-Job-Attributes operation should move a job
    from one Printer to another, if the "job-uri" attribute is modified.
    Generally, we have tried to avoid side-effects. Also we have tended to
    separate into separate operations things that might not be supported by
    everyone. Then we get better interoperability.

    The ISO DPA (Document Printing Application) WG also debated this same issue
    back in the mid 1990s when doing Part 3 of ISO 10175. For ISO DPA we came
    up with the Resubmit-Job operation in which the Printer acts like a client
    and submits the identified (pending or held) job to the indicated target
    Printer (using the ordinary Create-Job operation). The target Printer MUST
    do all of the validation. As far as the target Printer is concerned, the
    old Printer is just like any other client submitting a job. If any
    validation fails, then the new Printer returns the results (including the
    unsupported and/or conflicting attributes) to the original Printer which in
    turn returns the results to the client. Thus the Resubmit-Job Response to a
    client looks like the response to a Create-Job: the new "job-id" and
    "job-URL" is returned as part of the response, along with the job state and
    the position in the queue.

    Then you don't need the quirk in the Set-Job-Attributes response of
    sometimes returning the "job-id" and "job-uri" depending on whether or not
    the user modified the "job-uri". Also IPP Create-Job returns the
    "job-state", "job-state-reasons", and position in the queue, all things
    which Set-Job-Attributes is unlikely to return.

    Also what is the setting of the "ipp-attribute-fidelity" when moving the
    job? It is true or false? Another advantage of having a new operation,
    like Resubmit-Job, is that it can have the "ipp-attribute-fidelity" as an
    input operation attribute. Adding "ipp-attribute-fidelity" to
    Set-Job-Attributes is another complication we have avoided by making
    "job-uri" READ-ONLY.

    In actual practice, the IPP Resubmit-Job only got implemented for the same
    server, so that in fact the same Job object was re-used. You mention this
    possibility as well in your point 2 below. So I guessing that the IPP WG
    might want to have a simpler operation than Resubmit-Job, say, called
    "Move-Job", which would be restricted to the same server. In any case, the
    same principle would hold, that it would be a separate operation, not a side
    effect of setting the "job-uri" attribute of the job.

    So I would recommend that you make another private operation for moving jobs
    and keep "job-uri" READ-ONLY. Then you avoid some of the complexities that
    I noted above. Also you would probably be more in line with what might
    happen in IPP in the future as well. Finally, it also makes your
    Set-Job-Attributes response not have any special surprises for the client.

    Comments everyone?


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


    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.


    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 14 2000 - 14:23:56 EST