IPP Mail Archive: RE: IPP> OPS - Redirect-Job (a ka Move-Jo

RE: IPP> OPS - Redirect-Job (a ka Move-Job) included in Job and Printer A dmin (Set2) spec

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Wed Jul 12 2000 - 03:19:18 EDT

  • Next message: Hastings, Tom N: "RE: IPP> OPS - Redirect-Job (a ka Move-Job) included in JobandPri nter A dmin (Set2) spec"

    Carl,

    There is no fatal hole in your proposal. It is what has been in ISO DPA as
    the Resubmit-Job operation for more than 6 years. However, it has proven
    hard to implement (in DPA). I think that it is much easier in IPP, since
    the defaulting of the first Printer doesn't change the job so that when it
    is forwarded to the next Printer then the next Printer reapplies the
    defaults.

    One minor problem, is that the first Printer may have substituted some
    attributes or values that it didn't support. So when the first Printer
    Resubmits to the second Printer, more attributes may be lost. This is not
    really a problem, but something that users will have to live with.

    However, the idea of Move-Job, renamed to Redirect-Job, was to get the
    simple case of when a copy of the job isn't necessary, because it lives on
    the same host before and after.

    So I believe that there needs to be two distinct operations. The
    Redirect-Job only works for a small set of Printers specified by:

    redirection-printers-supported" (1setOf uri)

    while the Move-Job (Resubmit-Job) works for any Printer. Also Move-Job
    could also work for completed/aborted/canceled jobs.

    Hopefully, the client could hide the fact that there are two operations, by
    just showing one action to the user and then using Redirect-Job when it
    could, else using Move-Job.

    Tom

    -----Original Message-----
    From: kugler@us.ibm.com [mailto:kugler@us.ibm.com]
    Sent: Monday, July 10, 2000 14:14
    To: ipp@pwg.org
    Subject: Re: IPP> OPS - Redirect-Job (a ka Move-Job) included in Job and
    Printer A dmin (Set2) spec

    "Hastings, Tom N" <hastings@c...> wrote:
    > I added Move-Job (renamed to Redirect-Job since no job movement is
    required)
    > to the Job and Printer Administrative Operations spec that I just posted.
    ...
    > This operation is limited to redirecting a job to another Printer on the
    > same server.

    This limitation seems a bit restrictive, particularly since the IPP Model
    doesn't even define a server object.

    I thought of a couple of ways to do a more general, true Move-Job operation
    (maybe these have already been discussed and I've missed it). Given a
    Client, an Old Printer, and a New Printer, the object is to get the job
    from the Old Printer to the New Printer.

    1) A Move-Job request sent from the Client to the Old Printer causes the
    Old Printer to become an IPP client to the New Printer. The Old Printer
    sends a Print-Job request to the New Printer. When the Old Printer
    receives the Print-Job response from the New Printer, it returns this to
    the Client as the Move-Job response. (If the job was accepted, this
    response includes the new job-printer-uri, job-id, and job-uri, so the
    Client can now track the job on the New Printer.)

    2) Instead of a new Move-Job operation, define two new operations: one
    which "inhales" the Job from the Old Printer into the Client, and another
    which "exhales" it from the Client to the New Printer. What should these
    new operations be called? Hmm, ..., ... ! IPPness indeed! On second
    thought, maybe the exhale operation is redundant: the client could just do
    a Print-Job. So, all we need is a new Get-Job operation that allows the
    Client to pull the complete Job back from the Old Printer so that it can be
    sent to the new Printer with a Print-Job request.

    Okay, what are the fatal holes in these proposals?

         -Carl



    This archive was generated by hypermail 2b29 : Wed Jul 12 2000 - 03:35:35 EDT