Carl wrote:
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.
The IPP Model explains server, and how it relates to the protocol and the
IPP Printer object. However, it doesn't introduce "server" as a formal
object, just as it doesn't introduce "output device" as a formal object.
However, from a client's point of view, it can discover to which Printer's
the Printer can Redirect jobs because the Printer supports the Redirect-Job
for the Printers specified in the Printer's "redirection-printers-supported"
(1setOf uri).
Tom
-----Original Message-----
From: kugler@us.ibm.com [mailto:kugler@us.ibm.com]
Sent: Tuesday, July 11, 2000 08:51
To: Michael Sweet
Cc: ipp@pwg.org
Subject: Re: IPP> OPS - Redirect-Job (a ka Move-Job) included in Job
andPrinter A dmin (Set2) spec
Michael wrote:
>
>kugler@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
>systems)
>
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
>overhead.
>
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.
-Carl
>--
>______________________________________________________________________
>Michael Sweet, Easy Software Products mike@easysw.com
>Printing Software for UNIX http://www.easysw.com
This archive was generated by hypermail 2b29 : Wed Jul 12 2000 - 03:47:03 EDT