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
At 13:57 03/11/1998 PST, Jay Martin wrote:
>Yes, of course, the user should see some sort of "device problem"
>when a job is spooled but the device is powered off. The point
>I was making was that the job submission itself should not fail.
>
> ...jay
>
>
>Adrian Hall wrote:
>>
>> This would depend. I can certainly see a couple of scenarios:
>>
>> 1. The Printer turned off is a part of a pool of
>> printers - the server should continue spooling
>> and simply use one of the other printers in
>> the pool.
>>
>> 2. The user wants the print-out semi-immediately -
>> in which case some sort of notification that
>> the printer is turned off.
>>
>> Both are valid for the same condition.
>>
>> --
>> Adrian Hall
>> Sr. Software Developer
>> Xionics Document Technologies, Inc.
>>
>> Jay Martin wrote:
>> >
>> > If the IPP server is a *spooling* server (eg, process(es) running
>> > on a general host system), then job submissions should not fail
>> > if the associated output device is powered off, IHMO.
>> >
>> > ...jay
>> >
>> > ----------------------------------------------------------------------
>> > -- JK Martin | Email: jkm@underscore.com --
>> > -- Underscore, Inc. | Voice: (603) 889-7000 --
>> > -- 41C Sagamore Park Road | Fax: (603) 889-2699 --
>> > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
>> > ----------------------------------------------------------------------
>> >
>> > Puru Bish wrote:
>> > >
>> > > I was looking into the different printer states defined in Model
>> > > document (page: 99 - 100). The document says
>> > >
>> > > "The following standard values are defined
>> > > '3' 'idle'
>> > > '4' 'processing'
>> > > '5' 'stopped' .. "
>> > >
>> > > I looked at the definition of 'stopped' state, and it says,
>> > > "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...."
>> > > There may be a situation when the actual output device is
>> > > powered off. In that case, should IPP server respond with
>> > > a state 'stopped'? If so, does that mean that IPP server
>> > > still accepts print-job request instead of sending an error like
>> > > "server-error-internal-error"?
>> > >
>> > > IMHO, if an output device is powered off, all IPP print job requests
>> > > should fail with the above-mentioned server error. Also,
>> > > the printer should have another state
>> > > '6' 'no-device'
>> > > to represent this condition.
>> > >
>> > > Any comments/suggestions?
>> > > PB
>> > >
>> > > ______________________________________________________
>> > > Get Your Private, Free Email at http://www.hotmail.com
>
>