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