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
-----------------------------------------------------------------------