Specifically, we plan to clarify that clients MUST NOT allow the channel to
close because of a transport layer time-out while sending data to a printer
(i.e. flow-controlled off) for whatever reason including 'out of paper' or
'job ahead hasn't freed up enough memory'. However, the layer that launched
the print submission (e.g. an end user) MAY cause the channel to close by
canceling the job. When a client closes a channel a printer MAY print all
or part of the received portion of the document.
It is important that the right layer cancel a job that is not progressing.
If a user cancels a stalled job, it is because the user has decided for some
reason not to wait any longer and the user will not be surprised to get some
portion of a printed document. If an underlying part of a client cancels
the job because of a time-out, the client will probably try the job again
and again until the job completes. The user will be surprised to get one or
more fractional documents plus (perhaps) a full document. The worst case is
where a user gets many fractional copies of a document and never a whole.
("Why does the printer keep printing the first 6 pages of my 10 page
document?") This could occur if a particular page takes a long time to
render and always times out on the same page.
Bob Herriot
--------------------------------
Full details of issue below:
4) ISSUE: Client closes slow channel
Some IPP Printer implementations, such as forwarding servers, want to accept
an IPP job, even though the down stream channel is being used at the moment
by another job stream that the device supports. Rejecting the job would
mean that an IPP job might never get in, since these other protocols queue
the request.
However, some clients close the channel when it is flowed controlled off for
too long a time?
Suggested clarification (same as Issues 5 and 20):
Clarify the IPP/1.1 Model and Semantics document that Clients MUST NOT close
the channel when flowed controlled off. Clients SHOULD do
Get-Printer-Attributes and determine state of the device. Alert user if the
printer is stopped. Let user decide whether to abort the job transmission
or not.
Also clarify the IPP/1.1 Model and Semantics document that the following
actions are conforming for non-spooling IPP Printer objects: After
accepting a create job operation, a non-spooling IPP Printer MAY either:
1. Reject any subsequent create job operations while it is busy
transferring and/or processing an accepted job request and return the
'server-error-busy (0x0507).
2. Accept up to some implementation-defined subsequent create job
operations and flow control them to prevent buffer overflow. When the
implementation-defined number of jobs is exceeded, the IPP Printer MUST
return the 'server-error-busy' status code and reject the create job request
as in 1 above.
Client MUST NOT close the channel when flow controlled off. Clients that
are rejected with a 'server-error-busy' status code MAY retry periodically,
try another IPP Printer, and/or subscribe for a 'ready-for-job' event when
we have notification specified.