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

Michael Sweet mike at easysw.com
Tue Jul 11 07:56:34 EDT 2000


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)

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

I'm sure my list isn't complete.

Authentication is a big problem - how do we "proxy authenticate"
a request?

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?

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...

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



More information about the Ipp mailing list