IPP Mail Archive: Re: IPP> Re: IPP- Printer state

Re: IPP> Re: IPP- Printer state

Tom Hastings (hastings@cp10.es.xerox.com)
Mon, 16 Mar 1998 16:25:36 PST

At 12:04 03/12/1998 PST, Puru Bish wrote:
>
>Thanks, Tom for clarifying the issue.
>
>I still have a question - should an IPP server behave the same
>way even when it does not spool any job?

You mean what should an IPP Printer object implemented in a server
that does not spool jobs, but forwards jobs onto a single device directly
(perhaps using IPP or some other device protocol), but the device
to which it forwards jobs is shutdown?

I would think that the following response might be the best:

The server would reject the Create-Job and return the error code:
'server-error-service-unavailable'.
Then the client could query the Printer's "printer-state" and see 'stopped'
and the Printer's "printer-state-reasons" and see 'error-shutdown'.

Do others agree?

Tom

>
>-PB
>
>>From hastings@cp10.es.xerox.com Wed Mar 11 17:57:09 1998
>
>>Yes, the Printer object implemented in a server object does accept the
>>job even though the device is powered down.
>>
>>And the requester MAY get an indication that there is a problem,
>because
>>the job's OPTIONAL "job-state-reason" attribute that MAY be returned in
>the
>>Print-Job response containing the value: 'printer-stopped'
>>(or 'printer-stopped-partly' in the case that only some of the fan-out
>>printers are stopped). Unfortunately, the requeseter will NOT get this
>>indication in the response, if the IPP Printer object does not
>implement
>>the OPTIONAL "job-state-reasons" attribute.
>>
>>The client can then query the Printer's "printer-state"
>>and "printer-state-reasons" attribute and see that the "printer-state"
>>is 'stopped' and the "printer-state-reasons" is 'error-shutdown'
>>('warning-shutdown' if only some of the fan-out printers are shutdown).
>>
>>
>>The explanation of the 'stopped' state on page 89 of the Model document
>>says (in its entirity of two paragraphs):
>>
>>'5' 'stopped': If a Printer receives a job (whose required resources
>are
>>ready) while in this state, such a job SHALL transit into the pending
>state
>>immediately. Such a job SHALL transit into the processing state only
>after
>>some human fixes the problem that stopped the printer and after jobs
>ahead
>>of it complete printing. The "printer-state-reasons" attribute SHALL
>>contain at least one reason, e.g. media-jam, which prevents it from
>either
>>processing the current job or transitioning a pending job to the
>processing
>>state.
>>
>>Note: if a Printer controls more than one output device, the above
>>definition implies that a Printer is stopped only if all output devices
>are
>>stopped. Also, it is tempting to define stopped as when a sufficient
>>number of output devices are stopped and leave it to an implementation
>to
>>define the sufficient number. But such a rule complicates the
>definition
>>of stopped and processing. For example, with this alternate definition
>of
>>stopped, a job can move from idle to processing without human
>intervention,
>>even though the Printer is stopped.
>>
>>
>>
>>Does the Model document need any futher clarification?
>>
>>Tom
>
>
>
>
>______________________________________________________
>Get Your Private, Free Email at http://www.hotmail.com
>
>