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

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

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

From: kugler@us.ibm.com
Date: Mon Jul 10 2000 - 19:21:06 EDT

  • Next message: Manros, Carl-Uno B: "IPP> ADM - We now open the envelope - And the WINNER IS...."

    Carl-Uno wrote:
    >Your first solution now requires a whole IPP client implementation in your
    >printer, a considerable extra burden, and what do you do if the job is
    >accepted by the New Printer, but with some unsupported attributes? How
    >do you report back to the original client?
    I claim that if you have an IPP server implementation, you've got most of
    what you need to make an IPP client. Accepting IPP requests and generating
    IPP responses really isn't much different from generating IPP requests and
    accepting IPP responses. The only difference between a request and a
    response is the interpretation of the op-code/status field. In general,
    the client can be much simpler than the Printer (no REQUIRED operations or
    attributes to support, just a few attributes that MUST be supplied).

    If the job is accepted by the New Printer, but with some unsupported
    attributes, the New Printer's Print-Job response to the Old Printer will
    have a status-code of 0x0001 and a list of unsupported attributes. This
    reponse gets forwarded to the client as the response to the Move-Job

    >The second suggested solution seems to require that you return all your
    >print data to the client, not such a good idea if you have several

    True, this solution would have problems with multi-document Jobs. Maybe we
    need a Get-Document op, too, and some way to indicate to the client that
    the requested Job is a multi-doc Job.

    >or is doing print-by-reference (and the data has already been fetched by
    I would think that if the data has already been fetched, then the request
    could be converted from Print-URI to Print-Job.

    >Hence, both of your suggested solutions have issues (or limitations if you
    The multi-document problem seems to be the most troublesome. I think
    solution 1) could handle it with a multi-part response to the Move-Job
    operation, containing the Create-Job and Send-Document responses.

    >Not sure I have any better solution to offer though...:-(
    >-----Original Message-----
    >From: kugler@us.ibm.com [mailto:kugler@us.ibm.com]
    >Sent: Monday, July 10, 2000 2:14 PM
    >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
    >> to the Job and Printer Administrative Operations spec that I just
    >> 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
    >(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
    >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 : Mon Jul 10 2000 - 19:29:37 EDT