BITS is encoded as OCTET STRING. They are not the same as the "Bit
String" ASN.1 type. Rather, they are a way of formalizing the naming of
and assignment of individual meaning to individual bits in an OCTET
STRING. It essentially accomplishes the same task as giving bits names in
the DESCRIPTION, but allows the names of bits to be used by management
applications in the same way that names to enumerations can be (ie., via a
compiled MIB file).
I don't mean to argue for or against the change to BITS -- just to
clarify. I don't think it should affect any code whatsoever given that it
is totally transparent on the wire. That is, assuming the bit assignments
are kept consistent in the change to BITS.
[Note, however, the latest draft I have 11-02-98, which uses the BITS
construct incorrectly: the bit names are still listed in the DESCRIPTION,
rather than externally a la enums. I haven't paid close enough attention
to know if there is a later draft.]
On Mon, 16 Nov 1998, Ron Bergman wrote:
> Bobby,
>> I am also opposed to this change. I cannot find an exact definition of
> BITS in SMIv2. But if it is the same as Bit String it is a very different
> syntax from the current HR MIB (RFC 1514). Since this breaks all current
> Printer MIB implementations, there cannot be any good reasons for this
> change.
>> Ron Bergman
> Dataproducts Corp.
>>> On Mon, 16 Nov 1998, Jay Martin wrote:
>> > Bobby,
> >
> > Sorry for not catching this change sooner. We've been
> > pretty swamped with voluminous drafts in the PWG over
> > the past couple of years. Hopefully you can understand
> > how such a change might have been missed.
> >
> > So, can you give us some kind of a response to our questions?
> >
> > ...jay
> >
> >
> > Bobby Krupczak wrote:
> > >
> > > Hi!
> > >
> > > >This is not good for me, either. Can anyone explain
> > > >why this was done? I can get behind this kind of change
> > > >if someone can clearly delineate the positive aspects of
> > > >using a Bit string as opposed to octetString.
> > >
> > > >Harry Lewis wrote:
> > > >>
> > > >> During discussion and review at the "MIB meeting" in Tucson (PWG), we noticed
> > > >> (for the first time) that hrPrinterDetectedErrorState syntax was changed from
> > > >> octetString to Bits!! I have determined that this will result in code changes
> > > >> for us. We are, therefore OPPOSED to this change! Can someone state the reason
> > > >> for this change? Is anyone adamantly opposed to leaving it as is?
> > >
> > > I love this response!!!! Ive been awaiting feedback from various
> > > printer working group people for 6 months and only now that its gone
> > > through 2 revisions and only now that Im working on the
> > > interoperability report for the IETF that anyone objects.
> > >
> > > Harry Lewis, in particular, should have made these comments much much
> > > earlier in the process.
> > >
> > > Bobby
> >
>>
-----------------------------------------------------------------------
--==--==- Michael Kirkham Senior Engineer InterWorking Labs, Inc.
==--==--= 4113 Scotts Valley Drive, Suite 200 Scotts Valley, CA 95066
--==--==- mikek at iwl.com +1 831 430 3610 +1 831 430 9144 Fax
-----------------------------------------------------------------------