> So... I really don't see how the OFFLINE discussion crept in here. You either
> have a toner low critical or a toner low warning.
Because Gail and Bob were saying that toner low should always be
a non-critical alert, but that if the printer stops as a result
of that condition, then a critical "offline" alert should also be
added to the Alert Table.
Then the discussion moved on to the point where "offline" alerts were
being added for a large number of alert conditions. Hence, the focus
on the ramifications of so many "offline" alerts, etc.
> I probably have to read deeper into the thread than I have to grasp the entire
> realm of this topic. I think our problems are exasperated by the fact (and I've
> said this before) that we basically have THREE ways to reflect status - ALERTS,
> MAGIC COOKIE and SUBUNIT STATUS. It's like moving parts... the more you have
> the more likely something will break.
It I would submit that we have just reached the point of serious discord with
the Host Resources MIB status variables (aka, "magic cookie variables").
For example, the HR MIB is very clear (in its attempts to "describe" a
printer sub-object) that a "toner low" condition is a warning. And yet,
now it appears that at least some of us agree that if a "toner low"
condition results in stopping the printer, then it should be a critical
alert and NOT a non-critical (warning) alert.
So, the Printer MIB now differs from the HR MIB...unless of course we
fool around with certain definitions of other HR status values, such
as "serviceRequested", etc. I sincerely hope we do NOT go done that
rat-hole of a hack.
To fully resolve this situation, the PMP group is going to have to
wrestle with a fundamental issue raised at the interop event last
February:
How to support both "simple" applications that only want to
use a few simple variables to discern the printer's state
(ie, using only the HR variables), and "full-featured"
applications that attempt to do a more detailed job of
presenting the complete picture of the printer's status?
I maintain that we have now come to the crossroads where we must decide
whether to retain a conforming relationship with the HR status values,
or do the RIGHT THING and say what must be said in the Alert Table.
The primary scenario driving this decision:
If "toner low" stops the printer, then a CRITICAL "toner low"
alert is added to the Alert Table; however, following the HR
rules, a "toner low" WARNING is indicated in the HR variable
prtPrinterDetectedErrorState.
Does everyone agree we have a problem here?
> I agree with most of what Jay is saying in his long note. I disagree, however,
> that subUnitOffline (22) is new. I mean, it didn't come in at Stardust. It's
> probably been there a year, when Tom and I went through the generic exercise
> with he PWG.
Yes, the valid enum value "subUnitOffline(22)" is old, but the "offline"
alert code is new.
> We implement OFFLINE alert (but I don't have a thumb-nail
> characterization or when or why).
Yes, IBM and other vendors have had to implement an "other" (ie, not
specifically defined) alert code for "offline", since RFC 1759 did not
include one. Hard to imagine we missed that one in the first place!
> We also implement hrPrinterDetectedErrorState
> offline. I kinda like what Jay is saying... 'only post OFFLINE alert if someone
> explicitly SETS the unit OFFLINE'... but I'd have to investigate how that
> matches our implementation. Also, this seems to conflict with the whole
> movement to try and make your alert table big enough to contain ALL critical
> alerts. What do we want, here? All criticials or selective criticals?
Sheesh, Harry, don't get me going on THAT one, please. You led the effort
to refrain from mandating a minimum-sized Alert Table (in which I proposed
that all outstanding critical alerts must be represented). Since my
proposal was not accepted, then how you decide which alerts should always
be in your products' Alert Tables is entirely up to you.
As a result, it should come as no surprise that Underscore (a printer mgmt
app vendor) strongly recommends to its customers that they only purchase
those printers with comprehensive support for the Printer MIB Alert Table.
And to us, comprehensive support means that all known problems are
fully represented in the Alert Table at all times.
...jay