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 11:51:29 EDT 2000

Michael wrote:
>kugler at us.ibm.com wrote:
>> ...
>> > 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.
>When we approached this topic before, we had a lot of discussion
>about how to implement this.  IIRC the issues were:
>    1. The job-id and job-uri might change, depending on the
>       implementation.
I don't think that should be a problem, as long as the client requesting
the move is informed of the new ID and URI.

>       Several people stated that it had to change for
>       accounting to work properly, although I personally don't
>       agree with that opinion...
>    2. Requiring the server to transfer jobs to another server
>       was not acceptable to a lot of people.
I don't know what a server is in IPP.  We've got Printer, Job, and
Document.  I wouldn't mind having a Server object though, along with a
Queue object.  We (IBM) have considered implementing these as extensions.

>    3. What about job template options that don't map to the new
>       printer object?
If "ipp-attribute-fidelity" is true, then the job will be rejected by the
new printer.  Otherwise, you'll get status 0x0001 and the new printer will
do what it can.

>    4. What if the old server doesn't support encryption, etc.
>       required by the new server?
Then the operation fails.

>    5. How do we pass authentication information to the new
>       server?
The same way it was received by the old Printer.

>    6. How do we handle errors (can't transfer job to remote
>       server, etc.)
The client is informed in the response to the Move-Job operation and/or by
notifications, polling, etc.

>I'm sure I'm missing something here.
>The crux of the problem is that there is a definite need for a
>"move job" operation, but implementing it fully to handle
>transferring of jobs to remote servers can be tricky and may
>not be possible for embedded implementations (personally I wonder
>if that will be an issue - I don't see embedded implementations
>supporting many of these ops that are geared towards printing
I agree with you.  It should always be an OPTIONAL operation.

>The proposed Redirect-Job operation sidesteps some of the harder
>issues and will allow us to partition the functionality a bit.
>That is, provide a "lightweight" redirect and a heavier Move-Job
>operation rather than a single heavy Move-Job op with several
>printer attributes describing what type of movement is supported.
>In other words, Redirect-Job need only support local movement,
>while Move-Job needs to handle all cases (local and remote,
>authentication, encryption, etc.) with the corresponding
I could see this argument if the Redirect-Job target were a different
Device within a Printer.  But since the target is a different Printer, and
server is undefined, this operation seems poorly specified to me.


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

More information about the Ipp mailing list