Subject: IPP> MOD - Comments on printer-state and printer-state-reasons -Reply

From: "Scott A. Isaacson" <[email-masked]>
Date: Thu, 27 Feb 1997 10:30:01 -0700

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.

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

Scott