So... I would (perhaps grossly) distill this to
1. If a printer gags while accepting a job... it must flow control (THAT
JOB) until the problem is corrected.
2. If a printer is having jobs thrown at it too fast, maybe because of (1),
maybe just because..., the printer can choose to flow control or reject any
job(s) is hasn't actually started accepting.
Now, I see the distinction. Thanks, Tom.
Harry Lewis
IBM Printing Systems
harryl@us.ibm.com
"Hastings, Tom N" <hastings@cp10.es.xerox.com> on 04/06/99 05:05:20 PM
To: Harry Lewis/Boulder/IBM, ipp@pwg.org
cc:
Subject: RE: IPP> Issue - 5 and 20 conflict
--0__=GT4D6kwm4SS7ntBH6vf0MmbyUG4Vjt0gsOTahntmbzlBMm7VJU8CPx8V
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-transfer-encoding: quoted-printable
-----Original Message-----
From: harryl@us.ibm.com [mailto:harryl@us.ibm.com]
Sent: Monday, April 05, 1999 14:23
To: ipp@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@us.ibm.com
Harry,
I don't see the conflict between Issue 5 and 20 resolutions that you se=
e 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 process=
ing
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 a=
nd
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 al=
low
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 use=
r 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-J=
ob)
while they are processing a Print-Job. Other IPP Printer implementatio=
ns,
such as forwarding servers and non-spooling printers, accept some numbe=
r of
subsequent jobs, but flow control them off until the first job is finis=
hed.
Suggested clarification (same as Issues 4 and 5):
Also clarify the IPP/1.1 Model and Semantics document that the followin=
g
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 transf=
erring
and/or processing an accepted job request and return the 'server-error-=
busy
(0x0507).
=B7 Accept up to some implementation-defined subsequent create job oper=
ations
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 th=
at
are rejected with a 'server-error-busy' status code MAY retry periodica=
lly,
try another IPP Printer, and/or subscribe for a 'ready-for-job' event w=
hen
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, M=
AY
accept jobs that it does not have enough space for. In such a situatio=
n, 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 enou=
gh
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 porti=
on
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 reque=
st.
So maybe we should change "job" to "create request":
When a printer has too little space for starting new jobs, it MAY rejec=
t a
new create request by returning a 'server-error-busy' status code in th=
e
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 un=
til
the IPP Printer accepts the create request.
Tom
=
--0__=GT4D6kwm4SS7ntBH6vf0MmbyUG4Vjt0gsOTahntmbzlBMm7VJU8CPx8V--