For some reason Matt is not able to post mail to the PMP
distribution list so I am posting this one on his behalf:
----------
Hi folks,
I was working on a long overdue clarification of unary ond binary alert
management and started coming up some questions that I wanted to bounce
off the group.
1) I was looking at the new definition of PrtAlertCodeTC, and noticed
some seemingly minor changes that it seems to me make significant
changes in printer implementation.
Examples:
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).
With coverOpened(3) (Opened, verb describing the leading edge action) it
is implied that it will be followed by a coverClosed(4).
If this is the case is coverOpen(ed) a binary alert and coverClosed a
unary one? Is this waht we want?
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.
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?
4) The term "unary" and "simple" seem to be used interchangibly without
relating the two. Should we change all to "unary"?
--Matt
--
Matt King Opinions are my own and
Staff Engineer are not necessarily
Lexmark International, Inc. those of Lexmark
emking at lexmark.com