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@novell.com>
To: Keith_Carter@aussmtp.austin.ibm.com, ipp@pwg.org
Keith,
You wrote:
>>> <Keith_Carter@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@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@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@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 <<<<