Subject: IPP> Printer state

From: "Puru Bish" <[email-masked]>
Date: Wed, 11 Mar 1998 13:04:45 PST

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: Jay Martin <[email-masked]>
Date: Wed, 11 Mar 1998 16:20:23 -0500

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

---

From: Adrian Hall <[email-masked]>
Date: Wed, 11 Mar 1998 16:38:30 -0500

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.

---

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

---

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