Hi Harry,
This is an OFFICIAL response from the Xerox open management
community and my best judgment of the position of the Sharp
open management community. The Xerox open management folks
discussed these changes yesterday, Thursday (30 March 2000),
during their weekly telecon.
Your proposed rollbacks of some of the Printer MIB v2 enum
name changes and TC name changes are all acceptable and
reasonable.
Mike Elvers (Xerox) asked me to remind you that he pointed
out about 18 months ago that while most of the enumerations
in Printer MIB v2 were declared in textual conventions, a
few objects STILL don't have textual conventions (that is,
the enumerations are defined in-line in the OBJECT-TYPE
macros). Mike thinks this inconsistency is bad. I agree.
If we're bothering to make textual conventions, we should
make them all once-and-for-all, so that doing so in the
future does NOT block the advancement of the Printer MIB
on the Internet 'standards track'.
IMPORTANT - Before the Printer MIB v2 can be advanced from
Proposed Standard (where it MUST first be published by IETF
rules, because new objects were defined and enumerations
added), we need a Printer MIB v2 Bakeoff which shows at
least two clients and two devices which IMPLEMENT EVERY
OBJECT (including in all optional groups). For the last
two years, the IETF has been completely inflexible about
this requirement, so let's start planning...OK?
Cheers,
- Ira McDonald, consulting architect at Xerox and Sharp
High North Inc
-----Original Message-----
From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
Sent: Wednesday, March 29, 2000 2:11 PM
To: 'harryl@us.ibm.com'; pmp@pwg.org
Cc: rbergma@hitachi-hkis.com; mike.elvers@usa.xerox.com;
'imcdonal@sdsp.mc.xerox.com'
Subject: RE: PMP> Printer MIB v2 changes
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@us.ibm.com [mailto:harryl@us.ibm.com]
Sent: Tuesday, March 28, 2000 9:30 PM
To: pmp@pwg.org
Cc: rbergma@hitachi-hkis.com; mike.elvers@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
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 16:18:22 EST