IPP> OPS - Redirect-Job (a ka Move-Job) included in JobandPrinter A dmin (Set2) spec

IPP> OPS - Redirect-Job (a ka Move-Job) included in JobandPrinter A dmin (Set2) spec

IPP> OPS - Redirect-Job (a ka Move-Job) included in JobandPrinter A dmin (Set2) spec

kugler at us.ibm.com kugler at us.ibm.com
Tue Jul 11 15:18:45 EDT 2000

Michael wrote:
>kugler at us.ibm.com wrote:
>> ...
>> 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.
>A Server object would be a good addition, and it would allow us to
>use standard server operations instead of our current extension ops.
>(CUPS-Get-Printers, CUPS-Get-Classes, etc.)
I agree.  Server seems to keep creeping into IPP, whether we want it to or
not (e.g., wording in PRO about what the "printer-uri" attribute is for, in
discussions about Shutdown operations, etc.).  Enumerating the printers
available on a server is common need. (I like Microsoft's Web
Point-and-Print;  it would be nice to have a standard way to do something
similar:  point your web browser at a server and get a list of printers;
click on a printer to automatically download and install the driver and
configure the client).

>I think a Queue object will usually map directly to a printer object,
>but even with CUPS queues can be "classes" that map to one or more
>printer objects, so that would make sense.
Our queues sit between logical printers and actual printers.  A queue
receives jobs from one or more logical printers and schedules and sends
them to one or more actual printers.

>We've also been toying with the idea of a "multicast" type of queue,
>so you could have the same job fan out to multiple printer objects.
>We're still not sure how to handle the notification requirements with
>this type of setup, tho...
Tivoli Output Manager (see
http://www.tivoli.com/products/index/output_mgr/) has some good ideas here.

>> ...
>> >    5. How do we pass authentication information to the new
>> >       server?
>> >
>> The same way it was received by the old Printer.
>However, that won't work with Digest authentication, since the
>hostname, nonce, etc. will be different.  Also, one would hope
>that users have different passwords on each IPP server.
How do HTTP proxy servers handle this?  Could we use the same mechanism?
Anyway, I'm sure Printer-to-Printer resubmission wouldn't work with
SSL|TLS, unless the source Printer itself were authorized to submit Jobs to
the destination Printer, since SSL|TLS is designed specifically to prevent
a "man-in-the-middle" from impersonating a user.  However, I think the
Get-Job/Print-Job approach to moving jobs would solve this.  I'm coming
around to the idea that multiple methods might be required to completely
solve the Move-Job problem.  It makes a big difference whether we're
talking about QUALDOCS, office printing, or production printing use cases.

>> ...


More information about the Ipp mailing list