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 A dmin (Set2) spec

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Wed Jul 12 2000 - 03:18:56 EDT

  • Next message: Hastings, Tom N: "IPP> RE: NOT - mailto Delivery Method and SMS [I changed the Subject o f this thread]"

    See my comments preceded by TH>

    Tom

    -----Original Message-----
    From: kugler@us.ibm.com [mailto:kugler@us.ibm.com]
    Sent: Tuesday, July 11, 2000 08:35
    To: McDonald, Ira
    Cc: Manros, Carl-Uno B; ipp@pwg.org
    Subject: RE: IPP> OPS - Redirect-Job (a ka Move-Job) included in Job and
    P rinter A dmin (Set2) spec

    Ira wrote:
    >
    >Hi Carl and Carl-Uno,
    >
    >This discussion is off base. By mutual agreement on this
    >list, we PURPOSELY restricted the particular operation
    >Redirect-Job to same server (that is, the same top level
    >scheduler for IPP and other print jobs on the same hardware).
    >
    Is "server" defined anywhere in the specs? Is "scheduler" defined anywhere
     in the specs?

    >A separate REAL Move-Job operation (as powerful as the ISO DPA
    >operation,
    What ISO DPA operation are you referring to? My copy of ISO/IEC 10175
    lists only these Administration Port operations: PromoteJob, InterruptJob,
    PauseJob, and ResumeJob. (The User Port operations are Print, ModifyJob,
    CancelJob, and ListObjectAttributes.)

    TH> See ISO DPA Part 3 which has Resubmit-Job.

    >which has zero known implementations in shipping
    >DPA-based products)
    IBM Infoprint Manager is certainly based on ISO 10175-1, and it implements
    the "pdresubmit" command:

    "Use the pdresubmit command to resubmit an existing job to a specific
    logical
    destination. The logical destination can be in the same server as the
    logical
    destination to which the job was first submitted or a different server. You
     can only
    resubmit jobs that have the current job state of held, pending, retained,or
    unknown.

    TH> A wise decision. We should do the same for the heavy weight Move-Job
    too.
    TH> I also think we should limit Redirect-Job to 'pending' and
    'pending-held' and not allow 'processing'.

    "If the logical destination specified is in a different server, the old
    server resubmits
    the job with all of its current attributes to the new server. Infoprint
    includes any
    default attributes associated with the old server so that the new job
    remains as
    similar as possible to the old job. If the new server accepts the job, it
    assigns a new
    global job identifier and the old global job identifier becomes invalid.

    (see http://publib.boulder.ibm.com/pubs/pdfs/prsys/54454753.pdf)

    > is a fine thing to describe. But making
    >one operation fit all sizes is bad design in the practical
    >world of policy-based system admin - more specific operations
    >is always more desirable, because authorization doesn't have
    >to go inside the IPP 'application/ipp' package for the operation
    >attributes, just checks whether 'this' user may perform 'that'
    >operation.
    IMO, authorization should be based on objects, not operations. This is
    really important for enterprise-scale systems. For an example, take a look
    at how authorizations work in Windows 2000 with Active Directory (which is
    based, at least partially, on LDAP and Kerberos).

    TH> Authorization is based on objects firstly, but then some operations on
    those objects depend on authorization. For example, a lot more users can do
    a Get-Printer-Attributes on the Printer object that can do a Pause-Printer
    on that same Printer object.

    >
    >Cheers,
    >- Ira McDonald
    >
    >PS - Michael Sweet specifically wants this limited 'Redirect-Job'
    >operation for the CUPS system to load balance and otherwise
    >recover within a single server (with perhaps multiple subordinate
    >actual IPP Printers in network connected devices). And he also
    >wants the present ambiguity, where the 'job-id' of the resulting
    >'redirected job' may or may not be different from the 'job-id'
    >when it was first instantiated on a different IPP Printer object.
    >That kind of behavior would NOT be acceptable in true 'Move-Job'
    >(all accounting systems would break).
    >
    Seems irregular for the WG to make decisions on the basis of accomodating
    specific vendors.

         -Carl

    >
    >-----Original Message-----
    >From: kugler@us.ibm.com [mailto:kugler@us.ibm.com]
    >Sent: Monday, July 10, 2000 4:21 PM
    >To: Manros, Carl-Uno B
    >Cc: ipp@pwg.org
    >Subject: RE: IPP> OPS - Redirect-Job (a ka Move-Job) included in Job and
    >Printer A dmin (Set2) spec
    >
    >
    >
    >
    >Carl-Uno wrote:
    >>
    >>Carl,
    >>
    >>Your first solution now requires a whole IPP client implementation in
    your
    >>printer, a considerable extra burden, and what do you do if the job is
    >>accepted by the New Printer, but with some unsupported attributes? How
    >much
    >>do you report back to the original client?
    >>
    >I claim that if you have an IPP server implementation, you've got most of
    >what you need to make an IPP client. Accepting IPP requests and
    generating
    >IPP responses really isn't much different from generating IPP requests and
    >accepting IPP responses. The only difference between a request and a
    >response is the interpretation of the op-code/status field. In general,
    >the client can be much simpler than the Printer (no REQUIRED operations or
    >attributes to support, just a few attributes that MUST be supplied).
    >
    >If the job is accepted by the New Printer, but with some unsupported
    >attributes, the New Printer's Print-Job response to the Old Printer will
    >have a status-code of 0x0001 and a list of unsupported attributes. This
    >reponse gets forwarded to the client as the response to the Move-Job
    >operation.
    >
    >>The second suggested solution seems to require that you return all your
    >>print data to the client, not such a good idea if you have several
    >documents
    >
    >True, this solution would have problems with multi-document Jobs. Maybe
    we
    >need a Get-Document op, too, and some way to indicate to the client that
    >the requested Job is a multi-doc Job.
    >
    >>or is doing print-by-reference (and the data has already been fetched by
    >the
    >>printer).
    >>
    >I would think that if the data has already been fetched, then the request
    >could be converted from Print-URI to Print-Job.
    >
    >>Hence, both of your suggested solutions have issues (or limitations if
    you
    >>want).
    >>
    >The multi-document problem seems to be the most troublesome. I think
    >solution 1) could handle it with a multi-part response to the Move-Job
    >operation, containing the Create-Job and Send-Document responses.
    >
    >>Not sure I have any better solution to offer though...:-(
    >>
    >>Carl-Uno
    >>
    >>-----Original Message-----
    >>From: kugler@us.ibm.com [mailto:kugler@us.ibm.com]
    >>Sent: Monday, July 10, 2000 2:14 PM
    >>To: ipp@pwg.org
    >>Subject: Re: IPP> OPS - Redirect-Job (a ka Move-Job) included in Job and
    >>Printer A dmin (Set2) spec
    >>
    >>
    >>
    >>
    >>"Hastings, Tom N" <hastings@c...> wrote:
    >>> I added Move-Job (renamed to Redirect-Job since no job movement is
    >>required)
    >>> to the Job and Printer Administrative Operations spec that I just
    >posted.
    >>...
    >>> 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.
    >>
    >>I thought of a couple of ways to do a more general, true Move-Job
    >operation
    >>(maybe these have already been discussed and I've missed it). Given a
    >>Client, an Old Printer, and a New Printer, the object is to get the job
    >>from the Old Printer to the New Printer.
    >>
    >>1) A Move-Job request sent from the Client to the Old Printer causes the
    >>Old Printer to become an IPP client to the New Printer. The Old Printer
    >>sends a Print-Job request to the New Printer. When the Old Printer
    >>receives the Print-Job response from the New Printer, it returns this to
    >>the Client as the Move-Job response. (If the job was accepted, this
    >>response includes the new job-printer-uri, job-id, and job-uri, so the
    >>Client can now track the job on the New Printer.)
    >>
    >>2) Instead of a new Move-Job operation, define two new operations: one
    >>which "inhales" the Job from the Old Printer into the Client, and another
    >>which "exhales" it from the Client to the New Printer. What should these
    >>new operations be called? Hmm, ..., ... ! IPPness indeed! On second
    >>thought, maybe the exhale operation is redundant: the client could just
    do
    >>a Print-Job. So, all we need is a new Get-Job operation that allows the
    >>Client to pull the complete Job back from the Old Printer so that it can
    >be
    >>sent to the new Printer with a Print-Job request.
    >>
    >>Okay, what are the fatal holes in these proposals?
    >>
    >> -Carl
    >>
    >



    This archive was generated by hypermail 2b29 : Wed Jul 12 2000 - 03:27:24 EDT