PMP Mail Archive: RE: PMP> Printer MIB v2 changes - Xerox/Sh

PMP Mail Archive: RE: PMP> Printer MIB v2 changes - Xerox/Sh

RE: PMP> Printer MIB v2 changes - Xerox/Sharp response

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Fri Mar 31 2000 - 16:12:09 EST

  • Next message: Minh Tran: "PMP> "printing on demand""

    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