Excellent proposal for the new text! No redundant unary alerts would
be very helpful for us (as software developers), not to mention printer
vendors.
You ask:
> The question then is, once you apply the new rule, what is a good
> example of what would fill up the alert table?
I am *so* glad you asked...
Here's a serious example worth considering, using the fictitious printer
model "Charmin" (as in, well, you know) made by Cheapoid Printers Corp:
1. Printer is powered on: "powerUp (503)" alert inserted as the first
entry in the Alert Table.
2. Printer starts processing a print job, drawing paper from tray #1,
however, that tray is empty: "inputMediaSupplyEmpty (808)" alert
added to the Alert Table.
3. User comes along and pulls out tray #1 to fill it with paper:
"inputMediaTrayMissing (801)" alert must be added to the Alert Table,
but...
THE ALERT TABLE IS FULL !!!
Now, some of you might be thinking, "Come on, Jay, don't be silly!
No printer is going to have an Alert Table capable of only 2 entries!"
Wanna bet?
Before explaining this situation, let me say that I have provided Matt
with a plausible example of how an Alert Table can get filled up. Now
for the explanation...
One of the hot-n-heavy discussions during the last day of interop
testing in San Jose last December was the heated debate over whether
the Printer MIB should MANDATE that an implementation MUST support an
Alert Table size capable of storing the entire set of critical alerts
that could be *simultaneously* active at any given time in the
printer. (Sorry that was one sentence.)
During that debate, I argued that the Alert Table should *always*
provide a complete picture of all known problems currently existing in
the printer. By "problem" I mean "critical alert".
Those against such a mandate argued that too many resources would be
required for very low end printer models. Gail Songer then provided an
execellent analysis showing how few resources would actually be
required to implement this mandate. Opponents, however, weren't
convinced.
My position (as stated on this mailing list) was to the effect that if
the Alert Table was not mandated as maintaining the complete set of
existing critical alerts, then the Alert Table was useless and should
be removed.
After all, if our management application software can not trust the
Alert Table to state the complete problem set, WE CAN'T USE IT;
instead, we would merely poll each and every subcomponent's subunit
status object and derive the equivalent set of alerts.
RFC 1759 states:
"Agent implementors are encouraged to provide at least enough storage
space for the maximum number of critical alerts that could occur
simultaneously."
I would like to propose that the phrase "Agent implementors are encouraged
to" be changed to "An agent implementation must" in the above sentence.
What say ye? Shouldn't the Printer MIB mandate that an implementation
must be able to store all existing critical alerts in its Alert Table?
If not, then what good is the Alert Table?
...jay