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
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.
3. What about job template options that don't map to the new
4. What if the old server doesn't support encryption, etc.
required by the new server?
5. How do we pass authentication information to the new
6. How do we handle errors (can't transfer job to remote
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
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
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com