Classification:
Prologue:
Epilogue: Harry Lewis - IBM Printing Systems
Matt, I'll try to help with your questions:
>Value RFC1759 internet-draft
>------- ----------------------- -------------------
>3 coverOpen coverOpened
>When it was coverOpen(3) (Open, adj. describing state of cover), it made
>sense to put one alert in the alert table when it opened and remove it
>when it closed. I never did understand why there was a coverClosed(4).
I think this is just an editorial slip. I think it still makes sense
to remove the cover event from the table on the trailing edge. I'm
not positive, but coverClosed may have been an attempt to address
the situation where closing a cover actually caused the event printer
to stop.
>2) In the internet-draft, the section that talks about the alert table
>has a paragraph that talks about unary alerts (included for reference).
>The paragraph gives an example of a unary alert then goes on to talk
>about not knowing when to remove unary alerts from the table. The
>clarification I am adding talks about multiple unary alerts of the same
>type on the same subunit replacing each other. This makes the example
>not demonstrate waht it was intended to do. What do you guys think?
>Quote talking about unary alerts from internet-draft section 2.2.13.4.
> Unfortunately, there are some events that are not binary
> changes. This other category of event, the unary change
> event, is illustrated by the configuration change event.
> With this kind of event the state of the machine has changed,
> but to a state which is (often) just as valid as the state
> that was left and from which no return is necessary. For
> example, an operator may change the paper that is in the
> primary input source from letter to legal. At some time
> in the future the paper may be changed back to letter, but
> it might be changed to executive instead. This is where
> the problem occurs. It is not obvious how long to keep simple
> change event entries in the Alert Table. If they were never
> removed, the Alert Table would continue to grow indefinitely.
I'm working without a copy of the MIB in front of me but I recall
the premise that unary alerts would remain in the Alert Table until
managed out by subsequent unary or binary events. This sounds too
simple, I know... what am I missing?
>3) The title of section 2.2.13.3 is "Alert Tables". The title of
>section 2.2.13.4 is "Alert Table Management". Both sections talk about
>a single table. Any idea why the plurality?
I think it's just a typo.
>4) The term "unary" and "simple" seem to be used interchangibly without
>relating the two. Should we change all to "unary"?
At one time we migrated terminology from simple to unary thinking
unary was more the corollary to binary as opposed to (what? Simple and
Complex?). Regardless, I suspect some of the old terminology remains
and should be corrected.
Harry Lewis - IBM Printing Systems