IPP> MOD - COMMENTS ON PRINTER-STATE AND PRINTER-STATE-REASONS

IPP> MOD - COMMENTS ON PRINTER-STATE AND PRINTER-STATE-REASONS

IPP> MOD - COMMENTS ON PRINTER-STATE AND PRINTER-STATE-REASONS

Keith_Carter at aussmtp.austin.ibm.com Keith_Carter at aussmtp.austin.ibm.com
Fri Feb 28 15:12:13 EST 1997


  Scott,


  Thanks for your response.  My response noted as KC>> below.


  Keith


   Date: Thu, 27 Feb 1997 10:30:01 -0700
   From: "Scott A. Isaacson" <Scott_Isaacson at novell.com>
   To: Keith_Carter at aussmtp.austin.ibm.com, ipp at pwg.org
   Keith,


   You wrote:


   >>> <Keith_Carter at aussmtp.austin.ibm.com> 02/24/97 07:35am >>>
     5.  In my opinion, a Printer should inform an IPP
         application of "printer-state-reason" for each output
         device connected to the Printer.  Here are 2 examples.


         Example 1.  A Printer supports 3 network-attached
         printers NETPRT1-3 connected to a print server using
         network ports NETPORT1-3 respectively.  NETPRT1 has a
         paper jam, NETPRT2 has run out of paper in its input
         tray and NETPRT3 is idle.  "printer-state" is "mixed".
         "printer-state-reasons" are "NETPORT1:critical-jammed,
         NETPORT2:critical-input-tray-empty, NETPORT3:idle".
         With this approach, an IPP application that sees a
         "printer-state" of "mixed" can read the state of each
         output device.  The application may: display the state
         of each device to the end-user (who may be the
         operator); display the most critical error(s) that
         require action; make a decision to submit a job if at
         least one of the devices is "idle" or "processing"; or
         display "printer-state-as-text" (i.e. rely on the
         Printer's summary of its printer state).


         Example 2.  PRT, IPP1 and IPP2 represent URLs for
         Printers.  A Printer, PRT, uses 2 Printers IPP1-2 as its
         output devices.  IPP1 and IPP2 each support multiple
         output devices.  One of the devices in IPP1 has a paper
         jam and the other device is idle.  One of the devices in
         IPP2 is idle and ther other is processing jobs.
         For PRT, "printer-state" is "mixed".  For PRT,
         "printer-state-reasons" are "IPP1:mixed,
         IPP2:idle/processing".  An application may: display the




         state reasons from PRT for IPP1-2 (i.e. "mixed" and
         "processing/idle"); display "printer-state-as-text"
         from PRT; or issue a Get-Attributes operation on IPP1
         and process the printer-state and printer-state-reasons
         as described in Example 1.
   >>> <Keith_Carter at aussmtp.austin.ibm.com> 02/24/97 07:35am >>>


   We had some disucussion about this in the Monday call after you left.
   We have decided to leave the syntax of this attribute as just STRING
   without defining the syntax within the string.  We also decided to remove
   the state value "mixed" or "printing/idle".    These just add complexity and
   confusion to the end user without real added value.  However, since
   printer-state-reasons is just a string, then a given implementation could
   do as you are suggesting below, and show the state, etc of connected
   output devices.  Since those output devices are not necessarily modeled
   as IPP printers, it is not guaranteed that their state values will be the
   same the the standard values for an IPP printer.


  KC>>  Ok.


   You also write the following:


   >>> <Keith_Carter at aussmtp.austin.ibm.com> 02/24/97 07:35am >>>
     The current model for IPP 1.0 requires an end-user to either
     submit a Job to a Printer to receive notifications of
     printer state events or to poll a Printer for its state
     using the Get-Attributes or Get-Jobs operation.  I am
     working on a proposed extension to the model so end-users
     can receive real time printer events without polling or
     submitting jobs to a Printer.  A person with whom I must
     ....
   >>> <Keith_Carter at aussmtp.austin.ibm.com> 02/24/97 07:35am >>>


   We all realize the importance of an event delivery mechanism, but we
   have backed away from trying to define one an PART of IPP.  I would be
   happy to review what you might propose, but I would be careful, as you
   have already suggested, that it is way beyond the scope of IPP 1.0


  KC>>  After thinking about how to do this, I agree that we should
  KC>>  postpone this capability until after IPP 1.0.


   Scott


  >>>> DO NOT REPLY TO THIS NOTE <<<<



More information about the Ipp mailing list