Thank you Chuck for putting together this chart, and thank you Lloyd
for formatting it - I couldn't make heads or tails of it as included
in the original e-mail.
I have the following comments:
1. PrtSubUnitStatusTC Clarification
I think the Availability bit descriptions desparately need
clarification. What is the difference between Available and Busy vs.
Available and Active? What about Standby vs. Idle (is Standby only
for power save mode?) What is Unavailable and OnRequest for?
As one example of this needed clarification... In Chuck's table, for
the Normal or idle state, subunitstatus is listed as all idle. In our
implementation, there is a substantial difference between the
currently active paper source as opposed to additional, but not
currently selected, paper sources. Because of this difference, our
engineers used subunitstatus of 4, Avail and Active, for the currently
selected paper source, while using 0, Avail and Idle, for non-selected
paper sources. Similar logic was used on other subunit items as well.
I noticed also that Vendor 4 in the MIB walk similarly used Avail and
Active in most cases rather than Avail and Idle.
2. hrPrinterStatus when hrDeviceStatus is Down
In the table in almost all cases where hrDeviceStatus is Down, the
hrPrinterStatus is listed as Idle or Printing or Warmup. According to
the HR MIB for hrPrinterStatus:
"The current status of this printer device. When
in the idle(1), printing(2), or warmup(3) state,
the corresponding hrDeviceStatus should be
running(2) or warning(3). When in the unknown
state, the corresponding hrDeviceStatus should be
unknown(1)."
Therefore, when hrDeviceStatus is Down, hrPrinterStatus should be
Other or Unknown.
3. Cover/Door Open
Should all covers/doors be entered in the covers(6) group? This
question was brought up a while back by Micheal from IWL in relation
to the interop testing. When our printer has additional paper trays
attached and the door of the paper tray is opened, it is entered in
the input group rather than the covers group. Reading the description
of prtAlertGroup, I can understand why our engineers did it this way.
DESCRIPTION
"The type of sub-unit within the printer model that this alert
is related. Input, output, and markers are examples of
printer model groups, i.e., examples of types of sub-units.
Wherever possible, these enumerations match the
sub-identifier that identifies the relevant table in the
printmib."
I have trouble thinking of all covers as one subunit rather than as
components of the general printer or another subunit. If everyone
else agrees that any cover/door open should be entered into the cover
group, then we'll change our implementation. Does the description for
prtAlertGroup need clarification or were we just out in left field?
Stuart Rowley
Kyocera