Hi Harry,
Your reasoning looks sound in principle (for instance,
correcting spelling errors seems appropriate).
Your note will be addressed tomorrow (Thursday) at the
regular Xerox open management community telecon. Some
detailed feedback should be available after that.
Of course any symbol (textual convention or enum label)
that changes from RFC 1759 (even for sound reasons)
breaks somebody's existing code (because they have to
modify the code and recompile). It also breaks the
national language message catalogs in some products
(because the key string changes, where the enum was
converted back to a label, which is commonly the case).
I'll be glad to work with you on the edits (and on the
verification that the result compiles cleanly on more
than one SMIv2 capable MIB compiler). By the way, when
testing yourself, remember that both the RFC 144x and
RFC 190x series of SMIv2 specs are OBSOLETE. The current
specs are RFC 2578/2579/2580 (April 1999).
Please avoid the temptation to 'fix' LAST-UPDATED clause
of the MODULE-IDENTITY macro at the beginning of the MIB
to use extended UTC time - there are no commercial MIB
compilers in existence that correctly parse four-digit
years in extended UTC time (another year 2000 bug...).
Cheers,
- Ira McDonald, consulting architect at Xerox and Sharp
-----Original Message-----
From: harryl at us.ibm.com [mailto:harryl at us.ibm.com]
Sent: Tuesday, March 28, 2000 9:30 PM
To: pmp at pwg.org
Cc: rbergma at hitachi-hkis.com; mike.elvers at usa.xerox.com
Subject: PMP> Printer MIB v2 changes
Of the list of enumeration changes that have been debated going from v1 to
v2... here are the ones I agree make sense to "change back" (stated in
their v1 format).
The following are alert coded
coverOpen
interlockOpen
configuratoinChange
jam
powerUp
powerDown
inputMediaSizeChange
inputMediaTypeChange
inputMediaColorChange
interpreterMemoryIncrease
interpreterMemoryDecrease
The following are alert severities
critical
warning
The following is subUnitStatus
atIntendedState
All the other changes appeared to me to have a good purpose. Either they
corrected a misspelled word or resolved some conflict that had been
debated. A good example of this is the change in prtConsoleDisabled enums
from enabled/disabled to operatorConsoleEnabled/operatorConsoleDisabled.
Remember the debate about "enabling the disable"? I do ;-(.
I have already changed the above and am preparing to issue a new draft of
the Printer MIB. Now is the time to comment if you object or have further
observations. I think Mike was first to point out the folly of some of
these changes and my interpretation was that Mike was just asking for some
prudent reservation... I believe the collection, above, represents that.
I need some help on the change of things like prtChannelType to
PrtChannelTypeTC. This type of change occurs a lot and Mike seems to be
suggesting it was unnecessary but it would appear to me to be correcting
an original syntactical oversight.
Harry Lewis
IBM Printing Systems