--------------6283761BAB82683BB594ED4E
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Received: from teil.soft.net by teil.soft.net via ESMTP (940816.SGI.8.6.9/940406.SGI)
id KAA10995; Mon, 6 Dec 1999 10:10:32 +0530
Message-ID: <384B3E5A.B80A4786@teil.soft.net>
Date: Mon, 06 Dec 1999 10:10:58 +0530
From: Sharathchandra B Inamdar <sbinamdar>
Organization: Tata Elxsi Ltd.
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: sandeep kamat <sandeep>, Venkatesh <venky>
Subject: Resume-Printer Operation Ambiguity
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mozilla-Status2: 00000000
Dear Sandeep/Venkatesh,
See if this gives a clear understanding of our issue. Please change it
if necessary and put it onto the IPP mailing list at the earliest.
Thanks and Regards,
Sharath.
10:05 AM. 06-Dec-1999.
Bangalore.
-----------------------------------------------------------------------------------
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 ?
- 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,
-----------------------------------------------------------------------------------
*****************************************
Sharathchandra B Inamdar
Networking - D&D
Tata Elxsi Ltd. Bangalore.
Phone:
(Off): +91-80-8410220/21/22 (Ext : 416)
(Res): +91-80-3423117
Fax : +91-80-8410219
Email: sbinamdar@teil.soft.net
*****************************************
--------------6283761BAB82683BB594ED4E--