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

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

  • Next message: Internet-Drafts@ietf.org: "IPP> I-D ACTION:draft-ietf-ipp-notify-poll-01.txt"

    Don,

    Yes, the mail message was the complete spec. You bring up a lot of good
    questions that need to be answered.

    Most of them deal with the nasty problem of when the job has started
    processing. I was against even allowing this. However, there were others
    who wanted to allow an implementation to accept Redirect-Job when the job
    was in the 'processing' (or 'processing-stopped') states, but it is NOT
    REQUIRED. All the messy questions/issues that you bring up further
    convinces me that the spec should be changed to say that the Printer MUST
    reject the job if the job is in the 'processing' or 'processing-stopped'
    states.

    Then the only other questions remaining is what happens to the old job. If
    the old job has the same job-id/job-uri then as far as clients are concerned
    there isn't an old job. So if the implementation does generate a new job-id
    and/or "job-uri", then we should say that the old job ceases to exist.

    See specific answers below.

    Tom

    -----Original Message-----
    From: don@lexmark.com [mailto:don@lexmark.com]
    Sent: Sunday, July 09, 2000 17:10
    To: ipp@pwg.org
    Cc: hastings@cp10.es.xerox.com
    Subject: RE: IPP> OPS - Redirect-Job (a ka Move-Job) included in Job and
    Printer A dmin (Set2) spec

    I hope the text in the note is the complete text from the document because
    I'm
    doing this on the plane and haven't downloaded the document yet. So if
    these
    questions are answered in the document, let me know.

    Here we go:

    1) What happens to the job on the original printer? The document doesn't
    say.

    TH> Needs to be fixed. However, the idea of Redirect-Job (as opposed to
    Move-Job/Resubmit-Job) is that there doesn't appear to the client that a
    copy of the job was made. If the "job-id" is the same, there isn't an old
    job as far as the client is concerned. However, if there is a new job id,
    we need to say something like the old job id no longer specifies a job.

    2) If the job is in the middle of printing does it complete on printer 1 and
    then also print on the redirected printer, say printer 2?

    TH> This is an example of the messiness that happens when the operation is
    accepted while the job is 'processing'. In order to keep the simple,
    not-copy model, it would seem that the job on printer 1 is canceled, but
    since the job still exists on the new Printer, the old job should disappear,
    rather than being canceled and going to the Job History, etc. But it did
    use some resources...
     

    3) Does printer 1 generate a notification that the job was deleted and
    redirected?

    TH> Probably, should have a redirected event, but if there is a new job id,
    then the Event Notification needs to have both the old and the job-id.
    Otherwise, the Notification Recipients could get confused.

    4) If the job was redirected and the last page got printed on printer 1
    anyway
    (always that race condition!!) should printer 1 generate an end of job
    notification?

    TH> Again the nasty problems if Redirect-Job is allowed on a 'processing'
    job.

    5) If the job has been redirected, what is the state of that job on printer
    1
    afterwards? Does it matter if any of it printed? Do we need to create a
    new
    state ... "redirected" ... to deal with this?

    TH> How about either a 'job-redirected' value for "job-state-reasons" or, if
    its important to know the old job-id, add a Job Description attribute:
    "job-old-id"?

    6) If the job partially printed on printer 1 and it broke in mid-job, can
    the
    job be "Continued" on printer 2 starting with the next page, i.e. the page
    that
    would have printed next on printer 1 if it hadn't broken?

    TH> Wow! Maybe continuing in the middle is what MUST happen if the job is
    in the processing state (and the implementation accepts the request at all).
    That maybe what users really want (if supported), and solves some of the
    accounting problems as well, since the job uses only one job's worth of
    resources.

    I suspect "a lively discussion will ensue."

    TH> yup!

    **********************************************
    * Don Wright don@lexmark.com *
    * Chair, Printer Working Group *
    * Chair, IEEE MSC *
    * *
    * Director, Strategic & Technical Alliances *
    * Lexmark International *
    * 740 New Circle Rd *
    * Lexington, Ky 40550 *
    * 859-232-4808 (phone) 859-232-6740 (fax) *
    * (Former area code 606 works until 10/1) *
    **********************************************

    imcdonald%sharplabs.com@interlock.lexmark.com on 07/08/2000 01:40:30 PM

    To: hastings%cp10.es.xerox.com@interlock.lexmark.com,
          ipp%pwg.org@interlock.lexmark.com
    cc: (bcc: Don Wright/Lex/Lexmark)
    Subject: RE: IPP> OPS - Redirect-Job (a ka Move-Job) included in Job and
          Printer A dmin (Set2) spec

    Hi Tom,

    Very nice clean formulation of Redirect-Job. I like it
    without any changes at all.

    Cheers,
    - Ira McDonald, consulting architect at Xerox and Sharp
      High North Inc

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Friday, July 07, 2000 4:51 AM
    To: ipp
    Subject: IPP> OPS - Redirect-Job (a ka Move-Job) included in Job and
    Printer A dmin (Set2) spec

    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.
    It is based on the requirements that we discussed by email last May. Please
    send any comments to the DL, since we will discuss this at next week's IPP
    WG meeting.
    12.5 Redirect-Job operation
    This OPTIONAL operation allows a client to redirect a not-completed job to
    another Printer on the same server. Redirect-Job is defined to be a Job
    Creation operation, along with the Print-Job, Print-URI, and Create-Job
    operations. Thus all semantics that apply to Job Creation operations also
    apply to this operation. For example, the new Printer validates the job
    using all of its "xxx-supported" attributes and either accepts or rejects
    the job. If the job is rejected, it remains in its original state before
    the Redirect-Job operation was attempted. As an other example, the Job
    inherits the defaults for the new Printer (since the defaults aren't copied
    onto the Job object when it is created, but are applied when the job is
    processed - see [ipp-mod]). Finally, this operation generates a
    'job-created' event as does any Job Creation Operation.
    In order to preserver the "ipp-attribute-fidelity" semantics that the
    original client supplied when the job was first created, each Job Creation
    Operation copies the "ipp-attributes-fidelity" (boolean) operation attribute
    o the job as a Job Description attribute, if the Redirect-Job operation is
    supported. Then the "ipp-attribute-fidelity" attribute is re-used by the
    new Printer during its job validation, unless the client performing the
    Redirect-Job operation supplies the "ipp-attribute-fidelity" operation
    attribute.
    This operation is limited to redirecting a job to another Printer on the
    same server. Thus the same copy of the job MAY be used, depending on
    implementation. Also, depending on implementation, the new Printer MAY
    generate a new job-id and job-uri, or use the same one. In either case the
    response contains the "job-id" and "job-uri" for the redirected job as for
    any Job Creation operation. If the new Printer does assign a new "job-id"
    and "job-uri", then it MUST automatically update an Per-Job Subscription
    objects that are associated with the job.
    The Printer MUST accept this operation whenever the job is in the 'pending'
    or 'pending-held' states. The Printer MUST reject this operation whenever
    the job is in the 'completed', 'aborted', or 'canceled' states and return
    the 'client-error-not-possible' status code. Whether the Printer accepts
    this operation when the job is in the 'processing' or 'processing-stopped'
    states depends on implementation.
    Access Rights: The authenticated user (see [ipp-mod] section 8.3) performing
    this operation must either be the job owner (as determined in the Job
    Creation operation) or an operator or administrator of the Printer object
    (see [ipp-mod] Sections 1 and 8.5).
    The Redirect-Job Request have the same attribute groups and attributes as
    the Create-Job operation (see [ipp-mod] section 3.2.4), plus the new
    "job-message-from-operator" operation attribute (see section 5). In
    addition, the following operation attributes are defined:
         Target:
              Either (1) the "printer-uri" (uri) plus "job-id"
    (integer(1:MAX)) or (2) the "job-uri" (uri) operation attribute(s) which
    define the target for this operation as described in [ipp-mod] section
    3.1.5. The client MUST supply this attribute and the Printer MUST support
    it.

         new-printer-uri (uri):
              The URI of another Printer on the same server. The client
    MUST supply this attribute and the Printer MUST support it.

         ipp-attribute-fidelity (boolean):
              The client MAY supply this attribute, but the Printer MUST
    support it. It indicates whether or not the Job Template attributes on the
    Job object MUST be supported by the new Printer. If the client omits this
    attribute, the new Printer uses the value copied to the job as a Job
    Description attribute when the job was originally created. The Job
    Description attribute is not affected by the value supplied in this request,
    so that the original user's intent is preserved across multiple Redirect-Job
    operations.
    The Redirect-Job Response has the same attribute groups, attributes, and
    status codes as the Create-Job operation (see [ipp-mod] section 3.2.4). The
    following status codes have particular meaning for this operation:
         'client-error-not-possible' - the job was in the 'completed',
    'aborted', or 'canceled' states or the implementation does not support the
    Redirect-Job operation on a job when it is in the 'processing' or
    'processing-stopped' states.
         'client-error-not-found' - the target job was not found.
         'client-error-attributes-or-values-not-supported' - the specified
    Printer is not supported for redirection, i.e., the URI was not amongst the
    Printer's "redirection-printers-supported" (1setOf uri).

    Send any comments to the DL. We will review this at next week's IPP WG
    meeting.

    Tom



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