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