Harry Lewis seems to have hit the nail on the head with this
suggestion:
> A thought occured... while I'm in favor of a discussion and agenda topic
> to straighten out and document the 3 status snippets from existing MIBs
> another approach might be to take the bull by the horns and do what we
> felt we could not do initially and just define status in prtGeneral or
> in a seperate (new) group. At least we'd have this initial "failure"
> to back up our argument this time.
Yeah, I realize that we are once again suggesting the addition of MIB
objects when we're trying to "tie things up", however, Harry's suggestion
has real merit IMHO.
For one thing, we knew we had to support the three "magic decoder ring"
values in the HR MIB? Why? Because we were supposed to be "conformant"
with the design and intent of that particular MIB. (Now, why we had to
be integrated in the HR MIB in the first place is a valid question, but
let's not discuss that here.)
However, what we might have mistakenly assumed during the development
of RFC1759 is that the HR MIB values had to be the ONLY source for the
overall printer status.
I also recall, however, that a basic rule of "MIBology" is to not
replicate data values across various MIBs.
The question might boil down to whether adding a single, monolithic
MIB object breaks that fundamental rule. And, even if it does, is
it justified in our collective opinion (now backed up by some honest
to gosh interoperability experience)?
...jay