IPP> OPS - Redirect-Job (a ka Move-Job) included in Job and Printer A dmin (Set2) spec

IPP> OPS - Redirect-Job (a ka Move-Job) included in Job and Printer A dmin (Set2) spec

IPP> OPS - Redirect-Job (a ka Move-Job) included in Job and Printer A dmin (Set2) spec

don at lexmark.com don at lexmark.com
Sun Jul 9 20:10:24 EDT 2000


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.

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?

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

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?

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?

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?

I suspect "a lively discussion will ensue."

**********************************************
* Don Wright                 don at 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 at interlock.lexmark.com on 07/08/2000 01:40:30 PM

To:   hastings%cp10.es.xerox.com at interlock.lexmark.com,
      ipp%pwg.org at 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 at 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







More information about the Ipp mailing list