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

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

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

  • Next message: Herriot, Robert: "IPP>NOT IETF talk on notification"

    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.

    The issues are listed.

    Tom

    -----Original Message-----
    From: Hastings, Tom N
    Sent: Friday, March 17, 2000 11:51
    To: Sweet, Michael
    Cc: 'Hastings, Tom'; Herriot, Bob; Zehler, Peter; Shepherd, Michael;
    'McDonald, Ira at Sharp'; Manros, Carl-Uno B
    Subject: Thoughts on the new Move-Job operation

    Michael,

    I'd like to add a few more semantics to the IPP Move-Job operation from you
    starting point in your email below and wanted to get your reaction. If we
    all agree, I'll crank out a complete proposal this Monday for this
    Wednesday's telecon:

    (As a comment, lets also agree that we can also have a fancy Resubmit-Job
    operation sometime in the future, which causes a Printer to act like a
    client and submit the job to any other Printer. So anyone who wants that
    fancy stuff will NOT try to get it into our simple Move-Job operation, ok?
    Then we can keep Move-Job simple.)

    1. We need to agree for which job states the Move-Job MUST be accepted,
    which ones it MAY be accepted and which states it MUST be rejected. I
    propose:

       'pending-held', 'pending' - MUST be accepted
       'processing', 'completed', 'aborted', 'canceled' - MUST be rejected.

    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.

    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.

    3. If the new Printer would reject the job, then the move returns an error
    and the job remains unchanged on the old Printer.

    4. Make the Move-Job operation request be as much like a Create-Job request
    as possible, with the exception that the client MUST supply the "job-id"&old
    "printer-uri" (or old "job-uri") and the new "printer-uri".

    5. Which brings up the question of "ipp-attribute-fidelity". If an operator
    moves the job, it would be good if the original fidelity were preserved. In
    other words, if the user has submitted with fidelity 'true', the operator
    should perform the move with 'true'. If the user has submitted the job with
    fidelity 'false', then the operator should do the same. If the
    "ipp-attribute-fidelity" is omitted in the Move-Job request, the Job's
    original "ipp-attribute-fidelity" supplied in the Job Creation operation is
    used. The Move-Job operation does not update the Job's
    "ipp-attribute-fidelity" (in case another Move-Job operation is done, so
    that the user's original intent is preserved).

    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?

    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:

     - MUST include the "job-uri", "job-id", "job-state" and "job-state-reasons"
     - If supported, MUST include the "job-state-message" and
    "number-of-intervening-jobs"

    I suggest for consistency, that we make the Move-Job response be identical
    to the Print-Job response. Ok?

    7. Clarify that the implementation MAY change the "job-id" and/or the
    "job-uri" and REQUIRE the "job-id" and "job-uri" to be returned in the
    response, in case the implementation changes it. Always returning the
    "job-id" makes it more like the Job Creation operations.

    8. Add to the Notification Specification: Any Per-Job Subscriptions move
    with the job. If the implementation does change the "job-id", then the
    Subscription object is changed automatically.

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

    9. Probably need to add a new Job event to the Notification Specification:
    'job-moved' which has both the old and new job-ids in the notification
    content, in case they are different.

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

    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?

    ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-job-printer-set-ops-000308.pdf

    We should add it if we are roughly in agreement, because we want the Set
    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 agreement on
    Move-Job, we should keep it separate from the Set spec (and the Set2 spec).

    Thanks,
    Tom

    -----Original Message-----
    From: Manros, Carl-Uno B
    Sent: Friday, March 17, 2000 11:09
    To: Hastings, Tom; McDonald, Ira at Sharp
    Subject: FW: Your Set-Printer-Attributes operation

    FYI,

    Carl-Uno

    -----Original Message-----
    From: Michael Sweet [mailto:mike@easysw.com]
    Sent: Friday, March 17, 2000 11:00 AM
    To: Manros, Carl-Uno B
    Subject: Re: Your Set-Printer-Attributes operation

    [geez, I need to clone myself or something... I *did* plan on
     calling in for the phone conf. but was called away at the last
     minute...]

    "Manros, Carl-Uno B" wrote:
    > ...
    > Everybody on the call agreed that it was too much of a hack to let
    > the modification of the Printer-URI have the side effects associated
    > with moving the job to another printer, and were agreed to try to
    > convince you that it is a bad idea.

    :)

    > As an alternative, if we helped you to quickly spec up a new
    > operation to achieve what you need, in what we consider a more
    > professional way, would you be willing and able to change your
    > implementation?

    Yes. My main concerns were that a) there wasn't any alternate in the
    works, and b) we didn't want to create yet another CUPS-specific
    extension if we didn't have to.

    > This is not a new problem to several members of the group, so we
    > should be able to put together a new better solution in a matter of
    > weeks (even though it will take a lot longer to get it through the
    > whole formal IETF process afterwards).
    >
    > Would you be open to solving the problem that way?

    Sure. In the meantime I'll be updating our IPP implementation
    document for a new "CUPS-Move-Job" operation, and then maybe we
    can wrap that operation in the appropriate IETF language/format
    for the formal extension proposal.

    Quick outline of the new operation:

        CUPS-Move-Job Request

            attributes-charset
            attributes-natural-language
            job-uri *or* printer-uri + job-id
            requesting-user-name (optional, "SHOULD")
            job-printer-uri

        CUPS-Move-Job Response

            attributes-charset
            attributes-natural-language

        Possible errors: successful-ok, client-error-not-found,
                         client-error-not-possible,
                         client-error-forbidden

    Of course, there are things such as unsupported attributes or
    document formats we need to deal with for the general IPP
    implementation (not generally an issue for CUPS), but that's
    what we're planning on implementing for CUPS...

    -- 
    ______________________________________________________________________
    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 - 21:08:30 EST