Subject: Re: IPP> MOD - UPDATE FOR STATUS CODE KEYWORDS IN THE MODEL DOCUMENT [spool-space-full]

From: Tom Hastings <[email-masked]>
Date: Fri, 23 May 1997 12:37:43 PDT

I agree with Bob, we don't want an error for disk full, since that complicates
clients that would have to take some action.  Instead the PrintJob or
SendDocument blocks until the disk space problem takes care of itself.

The disk filling up is similar to a non-spooled Printer jamming or running
out of paper.  A really smart client could/should open up another channel
on the Printer URL and do periodic Get-Attribute for the "printer-state" and
"printer-state-reasons" attributes to watch for the 'stopped' state
and the reasons: 'media-needed' and 'paper-jam'.  A simple client need not
bother, since all of these conditions ('spool-space-full' on a spooling Printer 
and media-needed' and 'paper-jam' on a non-spooled, non-queuing Printer) the 
Printer shall just termporarily hang the data transfer until the condition gets 
cleared up.  (NOTE: RPC-time out problems, if IPP is ever layered on RPC).

ISSUE: Should we add a value to the "printer-state-reasons" attribute:
'spool-space-full' so that such a smart client could tell
on a Get-Attributes operation?

ISSUE: Should we add a Printer attribute that indicates the amount of
spooling space available, in K octets?  Say: "spooling-space-available"?
Then a smart client could tell whether to even try when it has a really
large amount of document data to send.

Tom

At 13:48 05/21/97 PDT, Robert Herriot wrote:
>Good job. I have some comments below
>
>Bob Herriot
>
>> From [email-masked] Wed May 21 12:48:36 1997
>> 
> 
>
>I'm not sure if this is a useful error, or even likely to happen.

Paper jams or media-needed do happen on non-spooled Printers.  But we want
to require that the Printer must hang, don't we?  In order to make it
easy for simple clients.  Smarter ones can do as Jay Martin's Printer
applications do, namely, poll on another channel for printer-state.

>
>> 
>> 4.4.4.5 server-error-printer-error (IPP)
>> 
>> A printer error, such as a paper jam, occurs while the IPP Printer
>> processes a Print-Job or Send-Data operation.  The response shall contain
>> the Job Status with the specific error and should contain a Message
>> describing the error.  An IPP application should check the Job Status
>> in the response for the specific error.
>
>
>
>
>I would expect the client to block on a write and that it wouldn't
>clear until the server got enough space to write the data.
>
>> 
>> 4.4.4.6 server-error-write-fault (IPP)
>> 
>> A write error, such as a memory overflow (i.e. the document data
>> exceeds the memory of the Printer) or a disk full condition, occurs
>> while the IPP Printer processes a Print-Job or Send-Data operation.
>
>
>
>With the changes from last week where all Printers support PrintJob
>(1 document per job) and some support CreateJob/SendJobData (1 or
>more documents per job), this message isn't needed. The error
>server-error-operation-not-implemented handles this problem instead.

I agree.

>
>> 
>> 4.4.4.7 server-error-too-many-documents-in-job (IPP)
>> 
>
>