Subject: Re: IPP> Printer state

From: Jay Martin <[email-masked]>
Date: Wed, 11 Mar 1998 16:57:55 -0500

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:   [email-masked]          --
> > --  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

---

From: Tom Hastings <[email-masked]>
Date: Wed, 11 Mar 1998 17:55:01 PST

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