IPP> OPS - Redirect-Job (a ka Move-Job) included in Job andPrinter A dmin (Set2) spec

IPP> OPS - Redirect-Job (a ka Move-Job) included in Job andPrinter A dmin (Set2) spec

IPP> OPS - Redirect-Job (a ka Move-Job) included in Job andPrinter A dmin (Set2) spec

kugler at us.ibm.com kugler at us.ibm.com
Tue Jul 11 14:35:32 EDT 2000



Michael wrote:
>kugler at us.ibm.com wrote:
>> ...
>> 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
>> ...
>
>This may be the case for some implementations (it certainly is for
>CUPS - the client and server share 99% of the HTTP and IPP
>processing code)
>
That's the case in our implementations, too.

>However, the issue is not whether the IPP server can generate an
>IPP request to send to another server.  Moving a job to the new
>server potentially requires:
>
>    1. Encryption
>    2. Authentication
>    3. Transferring multiple files for a job
>    4. Handling of attribute conflicts
>    5. Getting a response back to the client with the
>       new printer-uri, job-uri, and job-id before the
>       client times out
>
Clients shouldn't time out.  To quote the IPP Model:  At job submission
time, a Printer object, especially a non-spooling Printer, MAY accept jobs
that it does not have enough space for.  In such a situation, a Printer
object MAY stop reading data from a client for an indefinite period of
time.  A client MUST be prepared for a write operation to block for an
indefinite period of time

Similarly, the client should be prepared for a Move-Job operation to block
for an indefinite period of time.

>I'm sure my list isn't complete.
>
>Authentication is a big problem - how do we "proxy authenticate"
>a request?
>
This is where the Get-Job/Print-Job approach could be useful.  The client
sucks the Job back from the old Printer and then submits it to the new
Printer in the usual way.

>The multiple file per job issue is another problem - if the
>destination doesn't support Create-Job and Send-Document, how
>do you map the move then?
>
I would simply fail the Move-Job request with
server-error-operation-not-supported.

>The timeout issue is real - imagine transferring a 200MB
>document to another printer that only supports Print-Job?
>You'd have to wait until the document is sent to get the
>new job-id and associated attributes - the client might
>give up waiting on the response, and then reissue the
>request, etc...
>
Again, clients shouldn't time out.  Non-idempotent requests shouldn't be
retried, at least without human intervention.

>--
>______________________________________________________________________
>Michael Sweet, Easy Software Products                  mike at easysw.com
>Printing Software for UNIX                       http://www.easysw.com

     -Carl





More information about the Ipp mailing list