As a result of the interpretability meeting and a couple of the
teleconferences, I had 4 to-do's on my plate. Well, I just got around
to taking care of these (better late than ever -- right?). I know that
there is some controversy about some of these, however I thought it best
to post them and let everyone take shots at them.
Ready.... Aim.... Fire!
The items:
1. Clarification of Unary and Binary event management.
2. Clarification that hrDeviceStatus should not be used to
indicate installation status of options.
3. Clarification of prtChannelCurrentJobCntlLangIndex
and prtChannelDefaultPageDescLangIndex by defining zero to
mean does not have one.
4. Clarification of what should cause prtGeneralConfigChanges to
be incremented.
My proposals:
-------------------------------------------------------------------
1. Clarification of Unary and Binary event management.
a) The following paragraph should be inserted after paragraph 4 of
section 2.2.13.4.
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 original alert would be removed and a new
one added. However, if the second media size change
occurred on input subunit 2, both entries would appear
in the table unless the first had to be managed out due
to space constraints.
b) In the list of rules after paragraph 5 of section 2.2.13.4, first
rule refers to "simple" alerts. I believe this reference should be
changed to "unary".
c) The following paragraph should be inserted before the last paragraph
of the section.
In the event that a binary alert must be managed out of
the alert table; when space allows, if the condition still
exists, the alert should be re-added to the alert table
even if there was no subsequent transition into the
associated state. The new entry will not have the same
index as the original.
-------------------------------------------------------------------
2. Clarification that hrDeviceStatus should not be used to
indicate installation status of options.
Upon further thought, I feel that the MIB is clear enough on this point
and that there is no need for clarification. As far as I know, Lexmark
was the only company that misused hrDeviceStatus, and I think that was a
matter of laziness rather than misunderstanding.
-------------------------------------------------------------------
3. Clarification of prtChannelCurrentJobCntlLangIndex
and prtChannelDefaultPageDescLangIndex by defining zero to
mean does not have one.
a) The description of prtChannelCurrentJobCntlLangIndex refers to the
"Control Language Interpreter". Should this be "Job Control Language
Interpreter"?
b) Replace the last sentence of the prtChannelCurrentJobCntlLangIndex
description, "Must be 1 or greater", with "A value of zero indicates
that there is no current Control Language Interpreter for this channel".
c) Replace the last sentence of the prtChannelDefaultPageDescLangIndex
description, "Must be 1 or greater", with "A value of zero indicates
that there is no default Page Description Language Interpreter for this
channel".
-------------------------------------------------------------------
4. Clarification of what should cause prtGeneralConfigChanges to
be incremented.
a) In the first sentence of the prtGeneralConfigChanges description,
replace "media size" with "any media attributes".
b) Replace the third paragraph of the prtGeneralConfigChanges
description with the following.
The following are examples of actions that would cause the
prtGeneralConfigChanges to be incremented: Adding an output
bin, changing the media in a sensing input tray, changing the
value of prtInputMediaType via SNMP.
c) As it is difficult to write rules that make it obvious which actions
should cause prtGeneralConfigChanges, I propose the following appendix.
What is as important as what I put in the list, is what I left out. If
we decide to include this appendix, it warrants close review.
Appendix X - Actions that constitute a configuration change
Not all changes within the printer are configures to be
configuration changes, and as such increment
prtGeneralConfigChanges. Below is a list of actions that
should cause prtGeneralConfigChanges to be incremented.
1) An action that results in a row being added to or removed
from the prtStorageRefTable, prtDeviceRefTable,
prtInputTable, prtOutputTable, prtMarkerTable,
prtMarkerSuppliesTable, prtMarkerColorantTable,
prtMediaPathTable, prtChannelTable, prtInterpreterTable,
prtConsoleDisplayBufferTable, or prtConsoleLightTable.
2) An action that results in a change to
prtInputMediaDimFeedDirChosen, prtInputMediaDimXFeedDirChosen,
prtInputMaxCapacity, prtInputMediaName, prtInputName,
prtInputSecurity, prtInputMediaWeight, prtInputMediaType,
prtInputMediaColor, prtInputMediaFormParts,
prtInputMediaLoadTimeout, or prtInputNextIndex.
3) An action that results in a change to prtOutputMaxCapacity,
prtOutputName, prtOutputSecurity, prtOutputMaxDimFeedDir,
prtOutputMaxDimXFeedDir, prtOutputMinDimFeedDir,
prtOutputMinDimXFeedDir, prtOutputStackingOrder,
prtOutputPageDeliveryOrientation, prtOutputBursting,
prtOutputDecollating, prtOutputPageCollated, or
prtOutputOffsetStacking.
4) An action that results in a change to
prtMarkerSuppliesMaxCapacity.
5) An action that results in a change to
prtChannelCurrentJobCntlLangIndex,
prtChannelDefaultPageDescLangIndex, prtChannelState,
or prtChannelIfIndex.
6) An action that results in a change to
prtInterpreterDefaultOrientation,
prtInterpreterDefaultCharSetIn,
prtInterpreterDefaultCharSetOut.
-- The End --
Matt
-- Matt King Opinions are my own and Staff Engineer are not necessarily Lexmark International, Inc. those of Lexmark emking@lexmark.com