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