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 Job and P rinter Admin (Set2) spec

From: kugler@us.ibm.com
Date: Tue Jul 18 2000 - 17:54:31 EDT

  • Next message: Hastings, Tom N: "RE: IPP> Question concerning job-hold-until"

    I like option 4.

    However, I think the inhale-job/exhale-job option actually needs two new
    operations: Get-Job (not Get-Job-Data, because it also gets the
    attributes), and Get-Document (for multi-doc jobs).

         -Carl

    "Hastings, Tom N" <hastings@cp10.es.xerox.com> on 07/18/2000 02:19:53 PM

    To: Carl Kugler/Boulder/IBM@IBMUS, "Hastings, Tom N"
          <hastings@cp10.es.xerox.com>
    cc: Michael Sweet <mike@easysw.com>, ipp@pwg.org
    Subject: RE: IPP> OPS - Redirect-Job (a ka Move-Job) included in Job and P
          rinter Admin (Set2) spec

    I agree that the following language is too restrictive:

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

    How about something like:

    Which Printers the Printer supports for the Redirect-Job operation is
    indicated by the values of the "redirection-printers-supported" (1setOf
    uri)
    Printer Description attribute. An implementation MAY limit the list of
    Printers to ones on the same "server" and/or in the same security domain.

    Now, if a Printer implementation actually solves the security problem of
    delegation of access control and also is implemented to become a client and
    perform a Create-Job on any other Printer on the network, then we have 4
    alternatives for the spec:

    1. Only have one operation and probably change its name back to Move-Job,
    since it MAY (but NEED NOT) make a copy of the Job and submit it to another
    Printer (on another host). Then use the new 'any' OOB to indicate an
    implementation that is willing to move the job to any other Printer.

    2. Have two operations, one called Redirect-Job and has a limited list and
    a
    second operation, called Move-Job. If Move-Job is implemented, the Printer
    MUST support sending the job to any Printer on the network.

    ISSUE: Or is there an in between implementation, where there are several
    servers in the same security domain, to the Printer has to be like a client
    and send the job to another network node, but since it is in the same
    security domain, it is straightforward to do. If there is the in-between
    case, then just having a single operation (alternative 1) makes the most
    sense, since implementers are free to limit the Printers or not, depending
    on server and/or security considerations.

    3. Don't have either of these operations, but instead as suggested by Carl,
    have a single operation that gets the Job and its data, say, Get-Job-Data,
    from the Printer. Then the client can submit the job to any Printer (at
    the
    cost of two transfers of data, rather than one) using Create-Job. Then the
    client cancels the old copy of the job using Cancel-Job.

    4. Have Redirect-Job for redirection between Printers on the same "server"
    (or security domain), i.e., where a copy is not needed (or the security
    problems are manageable), and Get-Job-Data (plus Create-Job and Cancel-Job)
    for moving a job from any Printer to any other Printer.

    Comments?

    Tom

    -----Original Message-----
    From: kugler@us.ibm.com [mailto:kugler@us.ibm.com]
    Sent: Tuesday, July 18, 2000 09:38
    To: Hastings, Tom N
    Cc: Michael Sweet; ipp@pwg.org
    Subject: RE: IPP> OPS - Redirect-Job (a ka Move-Job) included in Job and
    P rinter Admin (Set2) spec

    Tom wrote:
    ...
    >>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.
    >>
    >Then I don't think you need to introduce a little 's' "server", either.
    >It's an implementation detail whether or not the
    >"redirection-printers-supported" are on the same server. You only need to
    >specify the protocol. If an implementation can meet the spec, it doesn't
    >matter how it does it. You don't need to specify an architecture
    involving
    >a "server". (If there is a reason that "server" is important, then I'm
    >still not getting it.)
    >
    >TH> I think you are getting it. We don't need to introduce the concept of
    >"server" at all for Redirect-Job. All that is necessary is that a Printer
    >(object) be able to enumerate the Printers to which it is willing to
    >redirect a job. A Printer indicates this list in the values of its
    >"redirection-printers-supported".
    >
    This then brings us back around to my original point, which is that this
    wording in the spec is too restrictive:

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

    For example, in our case, we should be able to redirect a Job to any
    Printer on a server that's in the same "namespace" (or "cell"), even though
    a namespace may contain multiple servers.

         -Carl



    This archive was generated by hypermail 2b29 : Tue Jul 18 2000 - 18:05:14 EDT