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 andPrinter A dmin (Set2) spec

From: Michael Sweet (mike@easysw.com)
Date: Tue Jul 11 2000 - 07:56:34 EDT

  • Next message: Michael Sweet: "IPP> ANNOUNCEMENT: Common UNIX Printing System 1.1"

    kugler@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@easysw.com
    Printing Software for UNIX                       http://www.easysw.com

    This archive was generated by hypermail 2b29 : Tue Jul 11 2000 - 08:06:19 EDT