PMP Mail Archive: Re[2]: PMP> Alert table thoughts

PMP Mail Archive: Re[2]: PMP> Alert table thoughts

Re[2]: PMP> Alert table thoughts

Bill Wagner (
Fri, 4 Apr 1997 02:09:26 -0500


I suppose I do regret cutting the last day of interop testing.

1. Although I find Matt's proposal well expressed, and I agree that
it may be desirable to a continuously edit the alert table to ensure
that it fully expresses the current condition, I do not agree with
making the concise editing of the table mandatory. The table
management paragraph recognized that there must be some way to empty
events or else the table would fill up. It defined a simple protocol
(set of rules) to make room. Its intent was not to require that the
printer remove unary events the effect of which appears to have been
superseded by other unary events. I believe it unreasonable to mandate

2. I suggest that Jay is indulging in hyperbole in stating "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." Again, although it would be nice to have a complete
profile of the printer condition in the alert table, and higher end
units will want to stress the fact that they have such support, I do
not believe that it should be mandated. To Jay's objection that it
imposes a requirement on the management application to poll the
printer and keep a record of alert events that the printer may drop, I
suggest that it not be mandated that the management app keep this full
record either. If a printer manufacturer decides that a limited depth
alert table is appropriate for his product, that implementation is
still better than if there were no alert table.

In case I an unclear, I see insufficient justification for mandating
either the editing of alert table events so that only current
conditions are reflected, or for mandating that the alert table be
large enough to accommodate all possible, 'significant', contemporary

Bill Wagner, DPI

______________________________ Reply Separator _________________________________
Subject: Re: PMP> Alert table thoughts
Author: JK Martin <> at Internet
Date: 4/2/97 6:01 PM


Excellent proposal for the new text! No redundant unary alerts would
be very helpful for us (as software developers), not to mention printer

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,


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

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

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?