IPP Mail Archive: Re: IPP> OPS - Redirect-Job (a ka Move-Job

IPP Mail Archive: Re: IPP> OPS - Redirect-Job (a ka Move-Job

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

From: kugler@us.ibm.com
Date: Tue Jul 11 2000 - 15:18:45 EDT

  • Next message: Hastings, Tom N: "IPP> NOT - Comments on the IPP Notification Spec, 'indp' and 'mailto' Delivery Method Documents"

    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.

    >> ...


    This archive was generated by hypermail 2b29 : Tue Jul 11 2000 - 15:29:59 EDT