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

RESEND: IPP> OPS - Redirect-Job (a ka Move-Job) included in Job a nd Printer Admin (Set2) spec

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Tue Jul 18 2000 - 16:25:52 EDT

  • Next message: Manros, Carl-Uno B: "IPP> ADM - New Internet-Drafts to the IETF Secretariat - RESEND from 7 /14"

    I'm resending this lost message.

    Tom

    -----Original Message-----
    From: Hastings, Tom N
    Sent: Friday, July 14, 2000 16:52
    To: 'kugler@us.ibm.com'
    Cc: Michael Sweet; ipp@pwg.org
    Subject: RE: IPP> OPS - Redirect-Job (a ka Move-Job) included in Job and
    Printer Admin (Set2) spec

    Section 1 has:

    The Internet is a distributed computing environment where requesters of
    print services (clients, applications, printer drivers, etc.) cooperate and
    interact with print service providers. This model and semantics document
    describes a simple, abstract model for IPP even though the underlying
    configurations may be complex "n-tier" client/server systems.

    Further in section 1.1 after the Figure:

    An IPP Printer object encapsulates the functions normally associated with
    physical output devices along with the spooling, scheduling and multiple
    device management functions often associated with a print server. Printer
    objects are optionally registered as entries in a directory where end users
    find and select them based on some sort of filtered and context based
    searching mechanism (see section 16). The directory is used to store
    relatively static information about the Printer, allowing end users to
    search for and find Printers that match their search criteria, for example:
    name, context, printer capabilities, etc. The more dynamic information,
    such as state, currently loaded and ready media, number of jobs at the
    Printer, errors, warnings, and so forth, is directly associated with the
    Printer object itself rather than with the entry in the directory which only
    represents the Printer object.
    IPP clients implement the IPP protocol on the client side and give end users
    (or programs running on behalf of end users) the ability to query Printer
    objects and submit and manage print jobs. An IPP server is just that part
    of the Printer object that implements the server-side protocol. The rest of
    the Printer object implements (or gateways into) the application semantics
    of the print service itself. The Printer objects may be embedded in an
    output device or may be implemented on a host on the network that
    communicates with an output device.

    Section 2.1:

    Some examples of configurations supporting a Printer object include:
    1) An output device with no spooling capabilities
    2) An output device with a built-in spooler
    3) A print server supporting IPP with one or more associated output devices
    3a) The associated output devices may or may not be capable of spooling jobs
    3b) The associated output devices may or may not support IPP

     Legend:

    ##### indicates a Printer object which is
          either embedded in an output device or is
          hosted in a server. The Printer object
          might or might not be capable of queuing/spooling.

    any indicates any network protocol or direct
          connect, including IPP

    embedded printer:
                                              output device
                                            +---------------+
     O +--------+ | ########### |
    /|\ | client |------------IPP------------># Printer # |
    / \ +--------+ | # Object # |
                                            | ########### |
                                            +---------------+

    hosted printer:
                                            +---------------+
     O +--------+ ########### | |
    /|\ | client |--IPP--># Printer #-any->| output device |
    / \ +--------+ # Object # | |
                           ########### +---------------+
                                                             

                                             +---------------+
    fan out: | |
                                         +-->| output device |
                                     any/ | |
     O +--------+ ########### / +---------------+
    /|\ | client |-IPP-># Printer #--*
    / \ +--------+ # Object # \ +---------------+
                         ########### any\ | |
                                         +-->| output device |
                                             | |
                                             +---------------+

    We didn't want to introduce the Server as an object for the same reason that
    we didn't want to introduce the output device as an object. It wasn't
    necessary for our simple client-server protocol.

    For the Redirect-Job, the "redirection-printers-supported" Printer Attribute
    is all that is necessary for a Printer to indicate to which other Printers
    it is willing to redirect output. We don't need to introduce a Server
    object to help with the simple Redirect-Job that redirects jobs among
    Printers on the same server.

    Ok?

    Tom

    -----Original Message-----
    From: kugler@us.ibm.com [mailto:kugler@us.ibm.com]
    Sent: Thursday, July 13, 2000 14:48
    To: Hastings, Tom N
    Cc: Michael Sweet; ipp@pwg.org
    Subject: RE: IPP> OPS - Redirect-Job (a ka Move-Job) included in Job
    andPr inter A dmin (Set2) spec

    The only definition of "server" that I can find in the Model is this:

    > An IPP server is just that part of the Printer object that implements the
    server-side protocol.

    Putting that together with this statement from the Redirect-Job spec:

    > This operation is limited to redirecting a job to another
    > Printer on the same server.

    yields a peculiar model. Looked at from an OO point of view, the first
    statement implies that a Printer contains a server, in a one-to-one
    relationship. However, the second statement implies that a server contains
    one or more Printers. This seems confusing and somewhat
    self-contradictory.

         -Carl

    "Hastings, Tom N" <hastings@cp10.es.xerox.com> on 07/12/2000 01:18:59 AM

    To: Carl Kugler/Boulder/IBM@IBMUS, Michael Sweet <mike@easysw.com>
    cc: ipp@pwg.org
    Subject: RE: IPP> OPS - Redirect-Job (a ka Move-Job) included in Job andPr
          inter A dmin (Set2) spec

    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 : Tue Jul 18 2000 - 16:36:53 EDT