Ron,
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
MIB.
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.
Thanks,
Tom
-----Original Message-----
From: Ron Bergman [mailto:rbergma@hitachi-hkis.com]
Sent: Wednesday, March 22, 2000 08:43
To: 'pmp@pwg.org'; Harry Lewis
Cc: Tom Hastings; Ira McDonald; pmp@pwg.org; don@lexmark.com
Subject: PMP> JMP> RFC 2790 - Host Resources MIB v2 - Let's move Printer
MIB v2
Harry,
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.
Cheers,
- Ira McDonald, consulting architect at Sharp Labs America
High North Inc
-----Original Message-----
From: Ron Bergman [mailto:rbergma@hitachi-hkis.com]
Sent: Monday, January 03, 2000 08:41
To: Elvers, Mike
Cc: 'McDonald, Ira'; 'pmp@pwg.org'; 'jmp@pwg.org'; 'harryl@us.ibm.com';
'rbergman@hitachi-hkis.com'; 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
that
> existed in version 1 and the new definition in version 2. I have not
listed
> 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
the
> 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
is
> 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 =
3
> hostResourceMIBDeviceTable = 4 hostResourcesMIBDeviceTable =
4
>
> 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: mailto:mike.elvers@usa.xerox.com
>
> -----Original Message-----
> From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
> Sent: Tuesday, December 21, 1999 6:32 PM
> To: 'pmp@pwg.org'; 'jmp@pwg.org'; 'harryl@us.ibm.com';
> 'rbergman@hitachi-hkis.com'; 'hastings@cp10.es.xerox.com';
> 'Mike.Elvers@usa.xerox.com'; 'Joe.Filion@usa.xerox.com';
> 'pgloger@cp10.es.xerox.com'; 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 [mailto:Mike.Elvers@usa.xerox.com]
Sent: Friday, August 27, 1999 12:28
To: 'pmp@pwg.org'
Subject: PMP> TC definitions is Printer MIB II
PMP,
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
stations?
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:
prtConsoleDisable
prtMarkerAddressabilityUnit
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?
Thanks,
Mike
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 14:34:29 EST