So... Does the BITS encoding match the encoding in the previous draft?
Where is the BITS encoding formally defined? I can't find it in RFC 1902.
Ron Bergman
Dataproducts Corp.
On Mon, 16 Nov 1998, Michael Kirkham wrote:
>> 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
> -----------------------------------------------------------------------
>>