IPP>MOD: Issue #4 client closes slow channel and Issue #5 cli ent closes stopped device

IPP>MOD: Issue #4 client closes slow channel and Issue #5 cli ent closes stopped device

IPP>MOD: Issue #4 client closes slow channel and Issue #5 cli ent closes stopped device

Herriot, Robert Robert.Herriot at pahv.xerox.com
Tue Mar 30 16:35:16 EST 1999


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.  
> 



More information about the Ipp mailing list