PMP Mail Archive: PMP> Strong objection to Printer MIBv2 nam

PMP Mail Archive: PMP> Strong objection to Printer MIBv2 nam

PMP> Strong objection to Printer MIBv2 names that aren't the same as R FC 1759

From: Hastings, Tom N (
Date: Thu Mar 23 2000 - 14:28:39 EST

  • Next message: "PMP> Would you like to save 30% on your phone bills and..."


    I'm sorry that I have objected to the TC and enum name changes between
    Printer MIBv1 and v2 on the mailing list as you indicated in your mail note.
    I was letting our Xerox implementers do the objecting which they have done
    over the past six months (see attached) and before.

    Xerox implementers have been strongly objecting to the name changes for a
    long time. They break client and printer implementations of V1. Both
    client and server code has to be changed in order to compile with the new v2

    See last August mail attached and there is some that goes back two years.

    I think that some of us (including me) thought it was ok to change symbol
    names, since it didn't affect the over the wire protocol. However, such
    name changes do affect client and server code compiling with the MIB, which
    is standard implementation practice.

    Please change them back to agree with Printer MIB v1. Its fine to introduce
    TCs in V2 that didn't have TCs in V1, but don't change the names of any V1
    TCs. Same for enums.


    -----Original Message-----
    From: Ron Bergman []
    Sent: Wednesday, March 22, 2000 08:43
    To: ''; Harry Lewis
    Cc: Tom Hastings; Ira McDonald;;
    Subject: PMP> JMP> RFC 2790 - Host Resources MIB v2 - Let's move Printer
    MIB v2


    We are now in the "hot seat" to get this document completed!

    Other than a couple of editorial corrections, the only real
    open issue is the name changes. I have not received any
    response from Tom regarding the impact to Xerox, so I can
    only assume that this is not an issue. (We had one vote
    for and one vote against from Xerox.)

    Ira stated that Sharp was against the new names, but I have
    no statement that it actually breaks an implementation.
    Since the current MIB draft was completed over three years
    ago and the editor during the draft development was
    employed by Sharp, it it hard to believe that these changes
    would break an implementation by Sharp!

    I agree that the name changes should not have been made,
    especially the textual conventions. But I have revised
    my implementations and going back would break my code!
    Actually, if there was a strong consensus, I am willing
    to again change my code.

    I don't see any consensus, and for this issue to surface
    three years after the draft was completed, makes it seem
    more like a religious issue than a real technical problem.
    The weak response on this subject indicates that the
    majority of WPG members don't care.

    As chairman of this project, I am closing this issue. We
    must move forward and get this document published.

    As to incorporation of the Finisher MIB, this will surely
    cause a major problem with the IETF. We are going to
    have enough to worry about due to the changing Area
    Director. (My real concern with the Finisher MIB is the
    attribute mechanism and the negative response it received
    in the Job MIB.)

    When do you estimate the editing changes can be incorporated
    and the document submitted as an Internet-Draft? I can
    assist in any editing changes if necessary.

            Ron Bergman
            Hitachi Koki Imaging Solutions

    -- Original message from Ira
            Tue, 21 Mar 2000 14:58:42 -0800

    Hi folks,

    RFC 2790 - Host Resources MIB v2 (March 2000)
    - IETF Draft Standard status

    This was posted last week (14 March 2000) but got past
    me until it showed up in the RFC Index today.

    So now it's time to get on with Printer MIB v2.

    I urge that we fold the text of Finisher MIB into the
    Printer MIB v2 text (after all it completes the model
    in original Printer MIB, RFC 1759, March 1995) and
    NOT publish Finisher MIB as a separate RFC.

    I also urge that we press on as quickly as possible
    with publishing a definitive text for Printer MIB v2
    (with the approved additions from July 1999 for new
    generic alerts and 'chIPP' specification) and move it
    to PMP WG last call and send it onward for IESG last
    call. More than one vendor has already shipped a
    product with Printer MIB v2 new objects implemented.

    Remember that since the bar is now *very* high for
    advancement to Draft Standard, the Printer MIB v2
    MUST be published at Proposed Standard and convincing
    proof of interoperable implementations of EVERY object
    and object group must be presented to the IESG and
    publicly posted before we can request movement to
    Draft Standard status.

    - Ira McDonald, consulting architect at Sharp Labs America
      High North Inc

    -----Original Message-----
    From: Ron Bergman []
    Sent: Monday, January 03, 2000 08:41
    To: Elvers, Mike
    Cc: 'McDonald, Ira'; ''; ''; '';
    ''; Hastings, Tom N; Filion, Joseph L; Gloger,
    Paul; Whittle, Craig
    Subject: Re: PMP> RE: Final edits to Printer MIB v2 - fix broken names

    Happy New Year! Hope everyone had a very good holiday!

    (Now back to work)

    I need to know, ASAP, if these enum name changes really have
    an impact on anyone's system. So far there has been no response
    to Mike Elvers message.

    Now that the holidays are over, I would like to get the Printer MIB
    into a 'ready to go' stage, so that it can progress as soon as the HR
    MIB is approved. Please review this message and if any of these
    changes have an impact, please reply stating which items are a
    problem. No response is assumed to be a 'no problem" reply (but
    it would be nice if some 'no problem' replies were received ;-)

    The deadline is January 24th (3 weeks). No changes will be made
    to the MIB unless a reply is received to a specific item.

        Ron Bergman
        Hitachi Koki Imaging Solutions

    "Elvers, Mike" wrote:

    > I was finally able to complete the listing of enumeration changes between
    > version 1 and version 2 of the Printer MIB (RFC17659). Please see the
    > listed items below. I did this is textual mode for those of you who don't
    > have an appropriate email tool for handling attachments or enhanced text.
    > This list includes everything that is different between an enumeration
    > existed in version 1 and the new definition in version 2. I have not
    > new values or any unchanged old values. I have listed the object that
    > defines the enumeration for clarity.
    > I am providing this information so the people are aware of the extent of
    > changes that were made. I am not suggesting all of these should not be
    > made. In some cases, where spelling is the motivator, (as in the
    > PrtAlertGroupTC or PrtInterpreterLangFamilyTC values) I could see where
    > those kind of changes would be desirable. However, in the cases where it
    > simple a tense issue or where items were actually deleted, I would suggest
    > that these be reconsidered and thought given to if these are, in fact,
    > essential and necessary.
    > Printer MIB v1 Printer MIB v2
    > -------------- --------------
    > prtAlertCode PrtAlertCodeTC
    > coverOpen = 3 coverOpened = 3
    > interlockOpen = 5 interlockOpened = 5
    > configurationChange = 7 configurationChanged = 7
    > jam = 8 jammed = 8
    > powerUp = 503 poweredUp = 503
    > powerDown = 504 poweredDown = 504
    > inputMediaSizeChange = 802 inputMediaSizeChanged = 802
    > inputMediaWeightChange = 803 inputMediaWeightChanged = 803
    > inputMediaTypeChange = 804 inputMediaTypeChanged = 804
    > inputMediaColorChange = 805 inputMediaColorChanged = 805
    > interpreterMemoryIncrease = 1501 interpreterMemoryIncreased =
    > 1501
    > interpreterMemoryDecrease = 1502 interpreterMemoryDecreased =
    > 1502
    > prtAlertGroup PrtAlertGroupTC
    > hostResourceMIBStorageTable = 3 hostResourcesMIBStorageTable =
    > hostResourceMIBDeviceTable = 4 hostResourcesMIBDeviceTable =
    > prtAlertSeverityLevel PrtAlertSeverityLevelTC
    > critical = 3 criticalBinaryChangeEvent = 3
    > warning = 4 warningUnaryChangeEvent = 4
    > prtChannelType PrtChannelTypeTC
    > chDCERemoteProcCall = 22 <deleted>
    > chONCRemoteProcCall = 23 <deleted>
    > chOLE = 24 <deleted>
    > chNamedPipe = 25 <deleted>
    > chDPMF = 28 chPSM = 28
    > chDLLAPI = 29 <deleted>
    > chVxDAPI = 30 <deleted>
    > prtConsoleDisable prtConsoleDisable
    > enabled = 3 operatorConsoleEnabled = 3
    > disabled = 4 operatorConsoleDisabled = 4
    > prtCoverStatus PrtCoverStatusTC
    > doorOpen = 3 coverOpen = 3
    > doorClosed = 4 coverClosed = 4
    > prtInterpreterLangFamily PrtInterpreterLangFamilyTC
    > langImPress = 33 langimPress = 33
    > prtMarkerMarkTech PrtMarkerMarkTechTC
    > electroPhotographicLED = 3 electrophotographicLED = 3
    > electroPhotographicLaser = 4 electrophotographicLaser = 4
    > electroPhotographicOther = 5 electrophotographicOther = 5
    > impactMovingHeadDotMatrix9Pin = 6 impactMovingHeadDotMatrix9pin
    > 6
    > impactMovingHeadDotMatrix24Pin = 7 impactMovingHeadDotMatrix24pin
    > 7
    > prtMediaPathMaxSpeedPrintUnit PrtMediaPathMaxSpeedPrintUnitTC
    > feetPerhour = 16 feetPerHour = 16
    > prtOutputType PrtOutputTypeTC
    > mailbox = 6 mailBox = 6
    > subUnitStatus PrtSubUnitStatusTC
    > intendedStateIsOnLine 0 stateIsOnLine
    > 0
    > intendedStateIsOffLine 32 stateIsOffLine
    > 32
    > atIntendedState 0 currentlyAtIntendedState
    > 0
    > transitiioningToIntendedState 64 transitioningToIntendedState
    > 64
    > Mike
    > X
    > Mike Elvers
    > The Document Company Xerox
    > 200 Crosskeys Office Park
    > M/S 815-000
    > Fairport, New York 14450
    > Phone: 716-425-6449
    > Intelnet: 8*225-6449
    > Email:
    > -----Original Message-----
    > From: McDonald, Ira []
    > Sent: Tuesday, December 21, 1999 6:32 PM
    > To: ''; ''; '';
    > ''; '';
    > ''; '';
    > ''; McDonald, Ira; Whittle, Craig
    > Subject: Final edits to Printer MIB v2 - fix broken names
    > Hi Harry Lewis and PMP folks,
    > I've just learned from Ron Bergman (PMP chair) that the
    > IETF Host Resources MIB v2 is 'close' to moving forward
    > to IESG 'last call', after Steve Waldbusser's recent work.
    > BEFORE we send the final text of the Printer MIB v2 to the IESG,
    > I urge that we restore to original Printer MIB (RFC 1759) names:
    > 1) Several textual conventions originally from Printer MIB v1
    > (RFC 1759), which were renamed with a 'Prt...' prefix
    > - this breaks IMPORTS into other MIB modules;
    > 2) Several enumeration labels originally from Printer MIB v1
    > (RFC 1759), which were renamed, apparently for clarity
    > - this breaks open management stations and client tools.
    > UNLESS the above corrections are made, it is IMPOSSIBLE to build
    > a hybrid device or client software implementation, which conforms
    > simultaneously to both Printer MIB v1 and Printer MIB v2.
    > I don't have the detailed list here at the moment but Ron Bergman
    > (Hitachi/Koki) has encountered the renamed textual conventions
    > and Mike Elvers (Xerox) has encountered the renamed enumeration
    > labels - they CAN supply the short list of corrections to be
    > made.
    > If you are not an implementor, you may not realize how serious
    > the breakage is from these small name errors. If you are an
    > implementor, you've already had to hand-edit the Printer MIB v2
    > text in order to proceed with your own development. These are
    > NOT just hypothetical problems.
    > Cheers,
    > - Ira McDonald (outside consultant at Sharp Labs America)
    > High North Inc

    -----Original Message-----
    From: Elvers, Mike []
    Sent: Friday, August 27, 1999 12:28
    To: ''
    Subject: PMP> TC definitions is Printer MIB II


            I have been looking at the latest draft of the Printer MIB and I
    have observed that many existing enumeration values have had their names
    changed or have been deleted (without first having been deprecated). Does
    this not present a significant backward compatibility problem for management

            I have also noticed that the enumeration definitions have been
    removed from the object definitions and placed in their own TC defintions
    except for the following objects:


            Is there something special or unusual about these two that the
    enumeration values have not be extracted into a new TC type definitions and
    the objects defined with the TC definition?



    This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 14:34:29 EST