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

From: [email-masked]
Date: Mon, 24 Feb 1997 09:35:18 -0500

Model and Semantics Team,

  First, for personal reasons, I must leave our telecon today
  (2/24) at 4:30PM Central Time.  This is a situation I didn't
  foresee at our telecon on 2/21.  Hopefully, we can cut to
  the chase on printer-state and printer-state-reasons at
  4:00PM sharp Central Time so I can at least participate for
  30 minutes.

  Now, here are my comments on printer-state and
  printer-state-reasons based on version 1.3.1 of the spec and
  Tom's document "comments on printer-state and
  printer-state-reasons attributes" dated 2/19/97
  (printer-state-comments-tnh.pdf):

  1.  I agree with Tom's comments 1-6.

  2.  On comment 7, the attribute "printer-is-accepting-jobs"
      documented in the 1.3 spec already covers the condition
      described for "warning-not-accepting-jobs".

  3.  I agree with comment 8 in that each value for
      "printer-state-reasons" should have a "severityLevel", a
      "subunit" and a "reason".  I believe "traingLevel" is
      overkill for IPP 1.0.

  4.  I agree with "processing/idle" value for printer-state.

  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.

      I believe that Example 1 is the typical fan-out scenario
      in the PC LAN world.

  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
  discuss this proposal won't return to the office until 2/26
  so look for a proposal on 2/27 in time for our telecon on
  2/28.  If I determine that this proposal is too complex for
  IPP 1.0, then I'll state so and we can table this matter
  until IPP 2.0.

  Have a super day,

  Keith