Michael wrote:
>
>kugler@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.
>> ...
-Carl
This archive was generated by hypermail 2b29 : Tue Jul 11 2000 - 15:29:59 EDT