Bill, Jay, Harry:
It sounds like I did an ok job making my point on all questions except
for #2, where I apparently really blew it. Let me take another hitch at
#2.
[Verbosity On]
I was asked to clarify (write up) a formal rule for removal of unary
alerts when redundant unary alerts are added to the alert table. The
difference between this and what is currently in the internet-draft is
that this would be done even when the table is not full. Below is a
draft of the clarification I will be proposing. It would be added just
below the 4th paragraph of section 2.2.13.4, Alert Table Management.
"Note that there should never be redundant unary alerts in
the alert table, where redundant is defined as two or more
alerts having the same prtAlertGroup, prtAlertGroupIndex,
prtAlertLocation, and prtAlertCode. If a second unary change
event of the same type occurs on the same subunit and
location, as an existing alert, the existing alert should
be removed from the alert table and the new one added. For
example if a media size change occurs on input subunit 1,
then some time later a second media size change occurs on
the same subunit, the origional alert would be removed and
a new one added. However, if the second media size change
occured on input subunit 2, both entries would appear in
the table unless the first had to be managed out due to
space constraints."
The only point I was trying to make was that the 4th paragraph of
section 2.2.13.4, seems to be trying to make the point that the problem
with unary alerts is that they will continue to be added to the alert
table until it is full at which point they will be managed out to make
room for new alerts. It gives the following 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."
It then goes on to explain:
"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."
Applying my clarification for removal of redundant unary alerts would
cause the current example to leave only one entry in the alert table.
Once again, It seemed to me that the point they were trying to make was
that if the example progressed, the table would eventually become full
of media change alerts. That is why I felt "[this] makes the example
not demonstrate waht [sic] it was intended to do."
The question then is, once you apply the new rule, what is a good
example of what would fill up the alert table?
By the way, I don't think I just pulled this proposed clarification/rule
out of my ..., well ya'know. I think this is what we came up with
during one of our discussions at the interop testing. Do others recall
this?
[Verbosity Off]
--Matt
Bill Wagner wrote:
> [Text deleted]
>> 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?
>> I find the paragraph in the draft useful, if a bit chatty. I
> am unsure about what is being clarified.
>> [Text Deleted]
--
Matt King Opinions are my own and
Staff Engineer are not necessarily
Lexmark International, Inc. those of Lexmark
emking at lexmark.com