-----Original Message-----
From: harryl at us.ibm.com [mailto:harryl at us.ibm.com]
Sent: Monday, April 05, 1999 14:23
To: ipp at pwg.org
Subject: IPP> Issue - 5 and 20 conflict
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 at 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):
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.
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):
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:
· 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).
· 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