IPP Mail Archive: RE: IPP> FW: Thoughts on the new Move-Job

IPP Mail Archive: RE: IPP> FW: Thoughts on the new Move-Job

RE: IPP> FW: Thoughts on the new Move-Job operation

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Fri Mar 24 2000 - 13:01:03 EST

  • Next message: Michael Sweet: "Re: IPP> FW: Thoughts on the new Move-Job operation"

    Hi Michael and Tom,

    My comments are below, preceded by 'ira>'.

    Please see in particular at the end my comments on the
    use of 'collection' for the new 'printer-xri-supported'
    attribute that 'repairs' our previous mistake in IPP
    with the three musketeers.

    - Ira McDonald, consulting architect at Sharp Labs America
      High North Inc

    -----Original Message-----
    From: Michael Sweet [mailto:mike@easysw.com]
    Sent: Wednesday, March 22, 2000 5:55 AM
    To: Hastings, Tom N
    Cc: ipp
    Subject: Re: IPP> FW: Thoughts on the new Move-Job operation

    "Hastings, Tom N" wrote:
    > Michael, Ira, Bob, and I have been exchanging email on the Move-Job
    > operation as a result of last week's IPP telecon. We have a few
    > issues left. But here is where we are for tomorrow's IPP telecon,
    > 3/22.

    As usual, I won't be able to "attend" the telecon... :(

    My comments are below...

    > ...
    > ISSUE 01: There is some debate as to whether to ALLOW the Move-Job
    > operation to be supported when the job is in the 'processing' state.
    > If it is allowed, it would be a MAY, not a MUST, because some
    > systems will have problems with accounting if the same job-id is
    > reused for the job again if some resources had been consumed.

    See my other comments on this; to summarize, I think we'll need to
    allow the "move-job" operation to create a new job-id and job-uri
    as needed by the implementation. The new job-id should not be
    REQUIRED, since this will open up another can of worms with
    accounting and job persistence - e.g. doubling the server's disk/
    memory requirements if document files are persistent until purged.
    (something that CUPS 1.1 supports)

    ira> I agree with the caveat that the reused job-id MUST represent
    ira> a job which NEVER entered the 'processing' state on the original
    ira> Printer - otherwise it becomes an avenue for an accounting
    ira> exploit that runs a job twice and gets charged once.

    > ...
    > 2. In case the Printer defaults are different for the new Printer,
    > we need to specify that the new Printer's defaults will be used when
    > the job is processed, even if they differ from the defaults of the
    > old Printer.

    This makes sense, since in the absense of job template attributes the
    printer defaults (which the client may be oblivious to) are used
    anyways by Create-Job, Send-Job, and Send-URI.

    ira> I agree.

    > ...
    > "printer-uri" (or old "job-uri") and the new "printer-uri".

    Which should be called "job-printer-uri" to avoid ambiguitity with
    the printer-uri used to identify the job.

    ira> Not sure which Printer URI is being renamed above. I'd
    ira> suggest that an operation attribute in 'Move-Job' be called
    ira> 'target-printer-uri' or 'new-printer-uri' for clarity.

    > ...
    > ISSUE 02: Ok to REQUIRE that the "ipp-attribute-fidelity" operation
    > attribute be copied to the Job object, if the Move-Job operation is
    > supported?

    Yes. Similarly, if the new printer object does not support the
    attributes provided, and ipp-attribute-fidelity is true, then
    a client-error-conflicting-attributes error needs to be returned
    and the job is not moved.

    ira> I agree.

    > 6. Finally, do we want to make Move-Job be like the Job Creation
    > operations and specify that the Move-Job response MUST be the same
    > as the Print-Job response:


    ira> I agree.

    > ...
    > ISSUE 03: Ok that Per-Job Subscriptions are automatically updated to
    > be for the new job (whether the job-id changes or not)?

    This is a sticky problem; if the job-id (and job-uri) changes, then
    the recipient of the notifications may not know what the notification
    is for (e.g. I am subscribed to job 5, I move the job, now I am
    subscribed to job 6???)

    Obviously we'll need a "move-job" event subscription, and that
    event needs to provide the new job-id, job-printer-uri, and
    job-uri attributes for the job (whether the job-id has changed or

    ira> This is covered by the notification content including the
    ira> 'subscriber-user-data' opaque element (intended for client
    ira> use to specify a useful correlation handle). In the Job
    ira> Monitoring MIB we have the (normally client constructed)
    ira> 'jmJobSubmissionID' for reliable correlation. In IPP
    ira> notifications we also have 'job-name' (client supplied)
    ira> in the standard bindings, which could be used for client
    ira> correlation of the 'old' and 'new' jobs and their events.

    > ISSUE 04: Should there be a new 'job-moved' event or is moving a
    > job, just another operation that generates the 'job-created' (along
    > with Print-Job, Print-URI, and Create-Job)?

    I think we need it. If we end up requiring a new job-id (something
    I'd rather not do), then we also need to add a new job-state value
    for "job-moved", since "completed", "cancelled", and "aborted" do
    not make sense.

    ira> I agree that we need 'job-moved' as an event AND also in
    ira> 'job-state-reasons'. We MUST NOT add a new 'job-state'.
    ira> This would break all existing IPP and Job Monitoring MIB
    ira> implementations. The Xerox MFP I worked with in the past
    ira> on this feature transitioned the 'old' job to 'job-state'
    ira> of 'cancelled' and 'job-state-reasons' of 'job-moved'.

    > 10. ISSUE 05: For all of us to consider:
    > Should we add this operation to the Set Job and Printer Spec
    > (because it is similar to scope and usage to the Set-Job-Attributes
    > and Set-Printer-Attribute spec), add it to the Administrative Set2
    > spec, or keep it as a separate spec?

    It might make sense to include it there. However, I think we've
    identified enough issues that move-job may be large enough to make
    it a separate spec all by itself.

    ira> I think we should add 'Move-Job' to the existing IPP Admin
    ira> Operations spec (aka 'set2' which was a terrible name...).
    ira> It does NOT belong in the IPP Set Operations spec.

    > ...
    > spec to go out for last call soon (as soon as we agree on the
    > collection syntax encoding). On the other hand, if we are far from
    > ...

    Once again, let me voice my *lack* of support for the collection
    syntax, as it will needlessly complicate implementation and support
    of IPP. The new "printer-xri-supported" attribute could use a new
    compound value tag ("xri") that would provide a URI and two keywords
    to cover what is needed for that attribute (and other similar
    situations we're likely to run into)

    ira> Thanks Michael - I personally think we've already got 'complex'
    ira> syntaxes for such things as resolution and that 'xri' would
    ira> make a dandy base syntax to add to IPP.
    ira> I'm VERY unhappy with the use of 'collection' syntax to add
    ira> 'printer-xri-supported' attribute to IPP/1.x.

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

    This archive was generated by hypermail 2b29 : Fri Mar 24 2000 - 13:10:48 EST