Peter Zehler
XEROX
Xerox Architecture Center
Email: Peter.Zehler@usa.xerox.com
Voice: (716) 265-8755
FAX: (716) 265-8792
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 139-05A
Webster NY, 14580-9701
-----Original Message-----
From: Venkatesh [mailto:venky@teil.soft.net]
Sent: Monday, December 06, 1999 11:28 PM
To: ipp@pwg.org
Subject: IPP> Issue with RESUME PRINTER OPERATION
Hello All,
I am unable to interpret the exact implementation of the
"Resume-Printer" operation from the RFC description. Here is what the
RFC has to say about the "Resume-Printer Operation",
"This operation allows a client to resume the Printer object scheduling
jobs on all its devices. The Printer object MUST remove the 'paused'
and 'moving-to-paused' values from the Printer object's "printer-state-
reasons" attribute, if present. If there are no other reasons to keep a
device paused (such as media-jam), the IPP Printer transitions itself to
the 'processing' or 'idle' states, depending on whether there are jobs
to be processed or not, respectively, and the device(s) resume
processing jobs."
The various questions this leaves un-answered are,
(1) Is the responsibility of the "Resume-Printer" operation limited to
changing the Printer objects 'printer-state-reasons' or does it have any
bearing on the 'Printer-state' also ?
PJZ> "resume-printer" does have a responsibility to change the printer
PJZ> state. Keep in mind that there may be other reasons for a printer's
PJZ> state besides someone issuing a 'pause-printer'. These other
PJZ> conditions may prevent the printer from transitioning to 'idle' or
PJZ> 'processing'.
- What this means is, according to the RFC description, the
"Resume-printer" operation must change the 'printer-state-reason' to
some thing other than 'Paused' and 'moving-to-paused' and it may or may
not result in the Printer transitioning itself to the 'processing' or
'idle' states, depending on the actual physical device status (and
offcourse depending on whether any jobs are queued-up for the printer or
not !). If, in case, the IPP printer is unable to change its state due
to some problem with the actual printer device (say, it is shut down or
there is a media-jam as indicated in the RFC), what should be the result
of the "Resume-printer" operation ? Should it still change the
'printer-state-reasons' and return success or should it fail ?
PJZ> The 'resume-printer' operation must clear the 'paused' or
PJZ> 'moving-to-paused' 'printer-state-message'. The operation must
PJZ> return a 'successful-ok' status code
If it
succeeds after changing the 'printer-state-reasons', what should be the
value of 'Printer-state' and who should take care of the
'Printer-state' later on ?
PJZ> The 'printer-state 'will change to one of three states
PJZ> 'idle' - no additional jobs and no error conditions present
PJZ> 'processing' - job available and no error conditions present
PJZ> current state (i.e. no change) an error condition is present
PJZ> (e.g. media jam)
PJZ> In the third case the 'printer-state-reason' will be cleared by
PJZ> automata when it detects the error condition no longer exists.
PJZ> The 'printer-state' will move to 'idle' or 'processing' when
PJZ> conditions permit. (i.e. no more error conditions)
I request any one who has implemented this or has a better understanding
of this operation to help me resolve this issue.
Thanks and Regards,