Great! I missed that disassociation but have now confirmed it.
I wonder if we couldn't convince Steve to simply add one enum to
hrDeivceStatus (Standby). I think his main objection was the proposal to
also add "Offline" to the hrPrinterStatus since there is already an
offline bit in hrPrinterDetected... I know time and position in the
process is another major concern. But it's just an enum!
Harry Lewis
IBM Printing Systems
Ron Bergman <rbergma at hitachi-hkis.com>
11/18/99 09:21 AM
To: Harry Lewis/Boulder/IBM at IBMUS
cc: jkm at underscore.com, Ron Bergman <rbergma at dpc.com>,
Jeff.Rackowitz at intermec.com, pmp at pwg.org, don at lexmark.com,
bwagner at digprod.com
Subject: Re: PMP> Re: Long-standing HR MIB recommendations
from Printer MIB
Harry,
One point of clarification, the latest HR MIB draft...
http://search.ietf.org/internet-drafts/draft-ops-hostmib-01.txt
...has removed the association with hrDeviceStatus. So the only issue of
contention is the new enum for hrDeviceStatus (standby) and two new
enums for hrPrinterStatus (offline and notApplicable).
I totally agree that adding these enums should not be a major change.
However, Steve Waldbusser did not agree and stated that these new
enums would cause a major reset of the HR MIB. We should accept
Steve's position and, if we all agree that these enums are essential to
include, work on adding them without changing the HR MIB.
Ron Bergman
Hitachi Koki Imaging Solutions
harryl at us.ibm.com wrote:
> Thanks to Ron, Jay and Bill for your responses to the issue. First, let
me
> clarify, for Jay, that the new hrPrinterDetectedErrorState bits DID make
> it into the updated HR MIB which is going for the final holy blessing.
The
> "paragraph" in question, which Jeff Rackowitz so kindly pointed out,
> related to new hrDevice and hrPrinter states that we determined would
make
> the MIB more useful (as I recall) following the StarDust bakeoff (anyone
> recall how many candles should be on the cake for THAT anniversary?!).
The
> key recommendation was to add STANDBY to the list of possible hrDevice
> states because, if you look at our mocked up decoder table, standby is
> less than distinguished, currently, yet we call it out as an
"interesting"
> state.
>> I may tend to want to flog myself for allowing the HR MIB to reach this
> point without having "pushed" this issue, but then I'm tempered by my
> recollection of the way we "tip-toed" around the whole issue ('we're
> trying to progress here... so we can't afford to make very many
changes...
> it might rock the boat). Never mind the boat had it's bow stuck in the
> side of Antarctica.
>> So, I agree with Jay regarding the "hrBits"... and I'm glad they made it
> in (although they still have this redundant right hand column that
> associated each bit with either Warning or Down hrDevice status which I
> initially proposed but followed up with the request to just ELIMINATE
any
> implied mandatory relationship (this way, if we DID add hrDevice =
> Standby, hrBits and Standby would be allowed.
>> Bill expresses the sentiment that a change at this point may not receive
> much response anyway. To the extent that I believe the new
> hrPrinterDetectedErrorState bits are more useful additions than hrDevice
=
> Standby, I tend to agree.
>> Ron points out that we may be able to "patch" the situation in the
Printer
> MIB and I'm willing to consider this.
>> If you look at it galactically, adding an enum to the HR MIB should be
> like swatting a fly... but it does seem to feel more like trying to land
> on Pluto.
>> Thanks, again, for all your support.
>> Harry Lewis
> IBM Printing Systems