Hi Juergen,
Thanks for your excellent feedback.
Your timing is perfect! Last week, Ron Bergman and I concluded that
all type 2 and type 3 textual conventions should be moved into such
a separate IANA-Printer-Types-MIB (like the HOST-RESOURCES-TYPES-MIB
in RFC 2790).
We plan to do this before the next draft - so we will wind up with
three SMIv2 source modules for Printer MIB:
1) Printer-MIB itself
2) IANA-Charset-MIB for the 'IANACharset' TC (improved name per
feedback from the IETF Charsets Registry mailing list)
3) IANA-Printer-Types-MIB for type2/type3 enums
Should we use all uppercase for the two IANA-maintained modules?
More recent IETF 'standards track' MIBs seem to do so.
We've also identified _one_ textual convention 'PrtAlertGroupTC'
which should be changed from type 1 (requires republication of
entire Printer MIB) to type 2 (IANA maintained). Because the
Finisher MIB had to add enums to this TC several years ago.
Else, any more new Finisher MIB object groups would require
republication of the Printer MIB (a mistake in our opinion).
We will also (per Bert Wijnen's request) insert the 'Prt'
suffix into our two recently added localized string TCs:
- 'PrtLocalizedDescriptionStringTC'
- 'PrtConsoleDescriptionStringTC'
(my mistake this wasn't done originally).
One textual convention 'PresentOnOff' we plan to leave with
the current (original RFC 1759) name and no 'Prt' prefix.
Because the Finisher MIB uses it (unmodified) already.
And a number of vendor private MIBs import it (I used it
in the Xerox enterprise MIB modules for years).
Should we fix the name (add 'Prt' prefix) of this last TC?
We will also fix every one of the problems that Bert Wijnen
identified in his recent 24-page email on 'difftool' output.
Cheers,
- Ira McDonald, co-editor of Printer MIB v2
High North Inc
-----Original Message-----
From: Juergen Schoenwaelder [mailto:schoenw at ibr.cs.tu-bs.de]
Sent: Monday, September 16, 2002 4:32 PM
To: Ron.Bergman at Hitachi-hkis.com; bwijnen at lucent.com; dbh at enterasys.com;
harryl at us.ibm.com; imcdonald at sharplabs.com; paf at cisco.com;
ned.freed at mrochek.com; pmp at pwg.org; fin at pwg.org
Subject: Printer/Finisher MIB and IANA enumerations
I have done some more work on my Printer-MIB implementation and I
stumbled over the type 1, 2 and 3 enumerations. Section 2.4.1 says:
: 2.4.1 Registering Additional Enumerated Values
:: This working group has defined several type of enumerations. These
: enumerations differ in the method employed to control the addition of
: new enumerations. Throughout this document, references to
: "enumeration (n)", where n can be 1, 2 or 3 can be found in the
: various tables. The definitions of these types of enumerations are:
:: enumeration (1) All the values are defined in the Printer MIB
: specification (RFC for the Printer MIB). Additional enumerated
: values require a new RFC.
:: enumeration (2) An initial set of values are defined in the
: Printer MIB specification. Additional enumerated values are
: registered after review by this working group. The initial
: versions of the MIB will contain the values registered so far.
: After the MIB is approved, additional values will be registered
: through IANA after approval by this working group.
:: enumeration (3) An initial set of values are defined in the
: Printer MIB specification. Additional enumerated values are
: registered without working group review. The initial versions of
: the MIB will contain the values registered so far. After the MIB
: is approved, additional values will be registered through IANA
: without approval by this working group.
So this sounds like all type 2 and type 3 enumerations are in fact
under IANA control. In fact, IANA already maintains an informal list
for the printer languages:
http://www.iana.org/assignments/printer-language-numbers
I think the right thing to do here is actually to handle the type 2
and type 3 enumerations in exactly the way you handle the charset
textual convention so that IANA can update a proper MIB module which
the printer/finisher MIB import.
In other words, I propose to move the type 2 TCs
PrtGeneralResetTC, PrtMarkerSuppliesTypeTC, prtGeneralReset
and the type 3 TCs
PrtCoverStatusTC, PrtChannelTypeTC, PrtInterpreterLangFamilyTC,
PrtInputTypeTC, PrtOutputTypeTC, PrtMarkerMarkTechTC,
PrtMediaPathTypeTC, PrtConsoleColorTC, PrtConsoleDisableTC,
PrtAlertTrainingLevelTC, PrtAlertCodeTC
into an IANA maintained module, e.g. the IANA-PRINTER-MIB. (I hope I
did not mis one.) This way, there is no cut&paste needed when updating
to the latest set of assigned values and IANA can use the SMIv2 module
identity macro to allow others to track changes.
/js
--
Juergen Schoenwaelder <http://www.informatik.uni-osnabrueck.de/schoenw/>