> So... Does the BITS encoding match the encoding in the previous draft?
Since the syntax definition is incomplete, I think this remains to be
defined. [Using BITS as a syntax doesn't accomplish anything if you don't
formally name the bits; but it should be possible to do so such that you
get an identical encoding on the wire.]
> Where is the BITS encoding formally defined? I can't find it in RFC 1902.
Only its usage in the SMI for defining objects with the BITS type is
defined in RFC 1902. Procedural information (ie., the ASN.1 Encoding
used) is in RFC 1904 (Transport Mappings). Section 8 says..
(3) When encoding an object whose syntax is described using the BITS
construct, the value is encoded as an OCTET STRING, in which all
the named bits in (the definition of) the bitstring, commencing
with the first bit and proceeding to the last bit, are placed in
bits 8 to 1 of the first octet, followed by bits 8 to 1 of each
subsequent octet in turn, followed by as many bits as are needed of
the final subsequent octet, commencing with bit 8. Remaining bits,
if any, of the final octet are set to zero on generation and
ignored on receipt.
[There's several other sections in there as well.. Suggest a search on
BITS in RFC 1904. For a usage example, see RFC 2021.]
>
> 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@iwl.com +1 831 430 3610 +1 831 430 9144 Fax
> > -----------------------------------------------------------------------
> >
> >
>
>
-----------------------------------------------------------------------
--==--==- Michael Kirkham Senior Engineer InterWorking Labs, Inc.
==--==--= 4113 Scotts Valley Drive, Suite 200 Scotts Valley, CA 95066
--==--==- mikek@iwl.com +1 831 430 3610 +1 831 430 9144 Fax
-----------------------------------------------------------------------