I forgot to mention two things yesterday.
1. Issues #4 and #5 are essentially the same issue with regard to the fix.
2. The issue of a client keeping a channel open permanently is especially
important for clients which are print servers. A server must avoid printing
multiple document fragments and it can only do so by avoiding multiple
transmissions of a document. However, a client that supports a user should
also keep the channel open so a user isn't surprised (as I stated
yesterday).
Bob Herriot
Yesterday's message with no changes below:
> -----Original Message-----
> From: Herriot, Robert [mailto:Robert.Herriot at pahv.xerox.com]
> Sent: Monday, March 29, 1999 5:22 PM
> To: 'ipp group'
> Subject: IPP>MOD: Issue #4 client closes slow channel
>>> I am emailing this issue ("client closes slow channel") to
> make sure that
> there is consensus for the editorial change that we are about
> to make in the
> model document for IPP/1.1.
>> 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.
>