Reading over the latest (I hope) issues list (v1.2) the suggested
clarification for issues 5 and 20 seem to conflict regarding what a
non-spooling printer should do if it can't accept a job.
5 - IPP printer MUST not return error ... rather (must) flow control...
20 - MAY reject with "server-error-busy" or may flow control.
IBM Printing Systems
I don't see the conflict between Issue 5 and 20 resolutions that you =
the V1.2 Issues List.
Issue 5 deals with what a non-spooling printer does when it is printing =
CURRENT job as it is being sent, say, with Print-Job, and runs into a
problem, such as media jammed. The Printer MUST NOT return an error =
Issue 20 deals with what a non-spooling printer does when it receives a
SUBSEQUENT create request, while it is still accepting data and =
Here is what version 1.2 Issue 5 and 20 say:
5) ISSUE: Client closes stopped device
When a non-spooling printer is accepting data and putting it on media =
runs into a problem, such as paper out or paper jam, what should it do?
Returning an error is not user friendly, if fixing the problem would =
the job to complete normally.
Suggested clarification (same as Issues 4 and 20):
Clarify the IPP/1.1 Model and Semantics document that IPP Printers MUST =
return an error status code during a Print-Job operation when a device
problem, such as jam or out of paper. Instead, the IPP Printer object =
controls the data off. Otherwise, only a partial job will be produced, =
a whole job would be produced when the problem is attended to.
Clients MUST NOT close the channel when flow controlled off. Clients =
do Get-Printer-Attributes and determine state of the device. Alert =
the printer is stopped. Let user decide whether to abort the job
transmission or not.
20) ISSUE: Non-spooling printers accept/reject additional jobs
Some IPP Printer implementations reject a second Print-Job (or =
while they are processing a Print-Job. Other IPP Printer =
such as forwarding servers and non-spooling printers, accept some =
subsequent jobs, but flow control them off until the first job is =
Suggested clarification (same as Issues 4 and 5):
Also clarify the IPP/1.1 Model and Semantics document that the =
actions are conforming for non-spooling IPP Printer objects: After
accepting a create job operation, a non-spooling IPP Printer MAY =
=B7 Reject any subsequent create job operations while it is busy =
and/or processing an accepted job request and return the =
=B7 Accept up to some implementation-defined subsequent create job =
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 =
as in 1 above.
Client MUST NOT close the channel when flow controlled off. Clients =
are rejected with a 'server-error-busy' status code MAY retry =
try another IPP Printer, and/or subscribe for a 'ready-for-job' event =
we have notification specified.
The proposed actual text for fixing the above issues in Section 3.1.8:
At job submission time, a Printer, especially a non-spooling Printer, =
accept jobs that it does not have enough space for. In such a =
Printer MAY stop reading data from a client for an indefinite period of
time. A client MUST be prepared for a write operation to block for an
indefinite period of time (See section 5.1 on client conformance). When =
printer has too little space for starting new jobs, it MAY reject a job =
an error of 'server-error-busy'. When receiving such an error, a client =
be prepared to keep submitting a job until the job submission succeeds. =
and in Section 5.1 contains the following new paragraph:
A client MUST NOT allow a channel to close because of a transport layer
time-out while sending data to a printer (i.e. flow-controlled off) for
whatever reason, e.g. 'out of paper' or 'job ahead hasn't freed up =
memory'. However, the layer that launched the print submission (e.g. an =
user) MAY close the channel in order to cancel the job. When a client
closes a channel, a printer MAY print all or part of the received =
Perhaps the last two sentences of the section 3.1.8 addition could be
mis-interpreted to mean reject the job AFTER accepting the create =
So maybe we should change "job" to "create request":
When a printer has too little space for starting new jobs, it MAY =
new create request by returning a 'server-error-busy' status code in =
create operation response. See section 220.127.116.11. When receiving such =
error, a client MUST be prepared to keep submitting a create request =
the IPP Printer accepts the create request.