PMP Mail Archive: PMP> RE: Printer/Finisher MIB and IANA enu

PMP Mail Archive: PMP> RE: Printer/Finisher MIB and IANA enu

PMP> RE: Printer/Finisher MIB and IANA enumerations

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Tue Sep 17 2002 - 18:44:56 EDT

  • Next message: McDonald, Ira: "PMP> RE: Printer/Finisher MIB and IANA enumerations"

    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@ibr.cs.tu-bs.de]
    Sent: Monday, September 16, 2002 4:32 PM
    To: Ron.Bergman@Hitachi-hkis.com; bwijnen@lucent.com; dbh@enterasys.com;
    harryl@us.ibm.com; imcdonald@sharplabs.com; paf@cisco.com;
    ned.freed@mrochek.com; pmp@pwg.org; fin@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/>
    



    This archive was generated by hypermail 2b29 : Tue Sep 17 2002 - 18:47:22 EDT