Question:
1.28 What MUST an IPP object do if Create-Job never gets an Add-Document or
Send-Document with 'last-document' set to 'true'?
Should the IPP object close the job after some period of time and:
1. move the job to the 'aborted' state with the 'aborted-by-system'
job-state-reasons value set
2. move the job to the 'pending-held' state (with some new job-state-reason
indicating an incomplete job, or
3. move the job to the 'pending' state and print the job?
What if the job never had any Add-Document or Send-Document operations, so
that the job has no documents?
IPP Bake Off
Discussion:
The IPP object should close the job after some period of time and:
1. For spooling applications - move the job to the 'aborted' state with the
'aborted-by-system' job-state-reasons value set.
2. For non-spooling applications - move the job to the 'pending-held' state
with a job-state-reason of "incomplete-job" and an administratively set
time-out (probably somewhere between 30 seconds and 4 min.).
3. As a fallback - move the job to the 'pending' state and print the job? (A
form of natural aging)
These notions should be described in the IIG. This basically addresses
system latencies that may occur during the process of performing a create
job based job submission. In general, the Create-Job form of submission is
intended to flow as a rapid sequence of operations without large
discontinuities in time between related operations. We should note the
caution that we are defining a tuning attribute, here, and thereby may
effect overall system performance. The notion here is that it is not our
intent for the sever to keep partially constructed job submissions on hold
for long periods of time. We couldn't actual agree on a figure but we expect
it to be somewhere between 30 sec to 4 minutes. The real number should be
determined empirically and information updated in the IIG.
The editor found the following discussion in Section 3.3.1 Send-Document
Operation, including a reference to the "multiple-operation-timeout" Printer
attribute which is defined in Section 4.4.28 of the June Model spec:
Since the Create-Job and the send operations (Send-Document
or Send-URI operations) that follow can occur over arbitrarily long periods
of time, each Printer object must decide how long to "wait" for the next
send operation. The Printer object OPTIONALLY supports the
"multiple-operation-timeout" attribute. This attribute indicates the
maximum number of seconds the Printer object will wait for the next send
operation. If the Printer object times-out waiting for the next send
operation, the Printer object MAY decide on any of the following semantic
actions:
1. Assume that the Job is an invalid job, start the process
of changing the job state to 'aborted', and clean up all resources
associated with the Job. In this case, if another send operation is finally
received, the Printer responds with an "client-error-not-possible" or
"client-error-not-found" depending on whether or not the Job object is still
around when it finally arrives.
2. Assume that the last send operation received was in fact
the last document (as if the "last-document" flag had been set to 'true'),
close the Job object, and proceed to process it (i.e., move the Job's state
to 'pending').
3. Assume that the last send operation received was in fact
the last document, close the Job, but move it to the 'pending-held' to allow
an operator to determine whether or not to continue processing the Job by
moving it back to the 'pending' state.
Each implementation is free to decide the "best" action to
take depending on local policy, the value of "ipp-attribute-fidelity",
and/or any other piece of information available to it. If the choice is to
abort the Job object, it is possible that the Job object may already have
been processed to the point that some media sheet pages have been printed.
We discussed that we had forgotten that the June Model and Semantics
document contains a "multiple-operations-time-out" Printer Description (see
section 4.4.28) that allows the IPP Printer to indicate the length of time
before it closes down multi-document jobs that haven't had another operation
performed on them.
We agreed to the following:
1. Clarify that "multiple-operations-time-out" is a "minimum", not a promise
to close the job after exactly that much time.
2. We reconfirmed that it is a requirement of the IPP Printer to clean up
such jobs, not the client.
3. The "multiple-operations-time-out" attribute is an OPTIONAL attribute,
but that an IPP Printer MUST support the "multiple- operations-time-out"
Printer Description attribute if it supports the Create-Job and
Send-Document operations, i.e., if it supports multi-document jobs.
4. The system administrator can set the "multiple-operations-time-out"
attribute to any value. He/she is not restricted to a one to four minute
value. Instead, the one to four minute value will be the RECOMMENDED
default value for this attribute.
ACTION ITEM (Tom): Update the proposed text for Issue 1.28 for another two
week review.
Proposed Answer:
Replace the last two paragraphs and three actions in MOD 3.3.1 (see
Discussion above for the current text) with:
Since the Create-Job and the send operations (Send-Document
or Send-URI operations) that follow could occur over an arbitrarily long
period of time for a particular job, a client MUST send another send
operation within an IPP Printer defined minimum time interval after the
receipt of the previous request for the job. If a Printer object supports
multiple document jobs, the Printer object MUST support the
"multiple-operation-time-out" attribute (see section 4.4.28). This
attribute indicates the minimum number of seconds the Printer object will
wait for the next send operation before taking some recovery action.
An IPP object MUST recover from an errant client that does
not supply a send operation with a "last-document" set to 'true', sometime
after the minimum time interval specified by the Printer object's
"multiple-operation-time-out" attribute. Such recovery MAY include any of
the following recovery actions:
1. Assume that the Job is an invalid job,
start the process of changing the job state to 'aborted', add the
'aborted-by-system' value to the job's "job-state-reasons" attribute, if
supported, and clean up all resources associated with the Job. In this
case, if another send operation is finally received, the Printer responds
with an "client-error-not-possible" or "client-error-not-found" depending on
whether or not the Job object is still around when the send operation
finally arrives.
2. Assume that the last send operation
received was in fact the last document (as if the "last-document" flag had
been set to 'true'), close the Job object, and proceed to process it (i.e.,
move the Job's state to 'pending').
3. Assume that the last send operation
received was in fact the last document, close the Job, but move it to the
'pending-held' and add the 'submission-interrupted' value to the job's
"job-state-reasons" attribute, if supported. This action allows the user or
an operator to determine whether to continue processing the Job by moving it
back to the 'pending' state or to cancel the job.
Each implementation is free to decide the "best" action to
take depending on local policy, the value of "ipp-attribute-fidelity",
whether any documents have been added, whether the implementation spools
jobs or not, and/or any other piece of information available to it. If the
choice is to abort the Job object, it is possible that the Job object may
already have been processed to the point that some media sheet pages have
been printed.
Change the description for Section 4.4.28 "multiple-operation-time-out"
from:
4.4.28 multiple-operation-time-out (integer(1:MAX))
This Printer attributes identifies how long (in seconds) the Printer object
waits for additional Send-Document or Send-URI operations to follow a
still-open multi-document Job object before taking one of the actions
indicated in section 3.3.1.
to:
4.4.28 multiple-operation-time-out (integer(1:MAX))
This Printer attributes identifies the minimum time (in seconds) that the
Printer object waits for additional Send-Document or Send-URI operations to
follow a still-open multi-document Job object before taking one of the
actions indicated in section 3.3.1.
It is RECOMMENDED that vendors supply a value for this attribute that is
between 60 and 240 seconds. A system administrator MAY set this attribute
to any value, including values outsides this range.
Tom Hastings
(310) 333-6413
Tom Hastings
(310) 333-6413