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

From: [email-masked]
Date: Fri, 28 Feb 1997 15:12:13 -0500

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" <[email-masked]>
   To: [email-masked], [email-masked]
   Keith,

   You wrote:

   >>> <[email-masked]> 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.
   >>> <[email-masked]> 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:

   >>> <[email-masked]> 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
     ....
   >>> <[email-masked]> 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 <<<<