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 : Sat Jul 08 2000 - 13:51:57 EDT