PMP Mail Archive: RE: PMP> Printer MIB v2 changes

RE: PMP> Printer MIB v2 changes

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Wed Mar 29 2000 - 17:10:53 EST

  • Next message: McDonald, Ira: "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 : Wed Mar 29 2000 - 17:17:06 EST