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.
Harry Lewis
IBM Printing Systems
harryl@us.ibm.com
Harry,
I don't see the conflict between Issue 5 and 20 resolutions that you =
see in
the V1.2 Issues List.
Issue 5 deals with what a non-spooling printer does when it is printing =
the
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 =
status.
Issue 20 deals with what a non-spooling printer does when it receives a
SUBSEQUENT create request, while it is still accepting data and =
processing a
create request.
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 =
and
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 =
allow
the job to complete normally.
Suggested clarification (same as Issues 4 and 20):
=20
Clarify the IPP/1.1 Model and Semantics document that IPP Printers MUST =
NOT
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 =
flow
controls the data off. Otherwise, only a partial job will be produced, =
when
a whole job would be produced when the problem is attended to.
=20
Clients MUST NOT close the channel when flow 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.
20) ISSUE: Non-spooling printers accept/reject additional jobs
Some IPP Printer implementations reject a second Print-Job (or =
Create-Job)
while they are processing a Print-Job. Other IPP Printer =
implementations,
such as forwarding servers and non-spooling printers, accept some =
number of
subsequent jobs, but flow control them off until the first job is =
finished.
Suggested clarification (same as Issues 4 and 5):
=20
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:
=B7 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).
=20
=B7 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.
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, =
MAY
accept jobs that it does not have enough space for. In such a =
situation, 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 =
a
printer has too little space for starting new jobs, it MAY reject a job =
with
an error of 'server-error-busy'. When receiving such an error, a client =
MUST
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 =
enough
memory'. However, the layer that launched the print submission (e.g. an =
end
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 =
portion of
the document.
TH comment:
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 =
request.
So maybe we should change "job" to "create request":
When a printer has too little space for starting new jobs, it MAY =
reject a
new create request by returning a 'server-error-busy' status code in =
the
create operation response. See section 14.1.5.8. When receiving such =
an
error, a client MUST be prepared to keep submitting a create request =
until
the IPP Printer accepts the create request.
Tom