Ron, All,
I have complied into this not what seems to be applicable to this discussion
of changes to hrPrinterDetectedErrorState.
The included references are:
1) An excerpt from RFC1902 (SMIv2) relating to the BITS construct.
2) An excerpt from RFC1906 (Transport Mappings) relating to the BITS
construct.
3) The definition of hrPrinterDetectedErrorState from RFC1514.
4) The definition of hrPrinterDetectedErrorState from the internet-draft.
The things that would break existing implementations are:
1) If base ASN.1 type changed.
2) If bit-field positions changed.
3) If bit-field definitions changed.
4) If restrictions on use of base type were broken.
As I see it, the proposed changed would not break existing implementations.
1) SNMPv2 transport mappings [rfc1906.txt], specifies that the BITS
construct is encoded as an OCTET-STRING which matches the
original definition of hrPrinterDetectedErrorState [rfc1514.txt].
2) SNMPv2 transport mappings [rfc1906.txt], specifies that Bit 0 is
defined to be the MSB of the first octet which matches the
original definition of hrPrinterDetectedErrorState [rfc1514.txt].
3) The new definition of hrPrinterDetectedErrorState [draft-krupczak-
hostmibv2-01.txt] defines bits 0-7 to have identical meaning as the
original definition of hrPrinterDetectedErrorState [rfc1514.txt].
4) The new definition of hrPrinterDetectedErrorState [draft-krupczak-
hostmibv2-01.txt] extends the length of the OCTET-STRING to 2. The
original definition of hrPrinterDetectedErrorState [rfc1514.txt]
placed on constraints on the length of the OCTET-STRING.
Matt King
Lexmark International
References:
[rfc1902.txt]
7.1.4. The BITS construct
The BITS construct represents an enumeration of named bits. This
collection is assigned non-negative, contiguous values, starting at
zero. Only those named-bits so enumerated may be present in a value.
(Thus, enumerations must be assigned to consecutive bits; however,
see Section 9 for refinements of an object with this syntax.)
Although there is no SMI-specified limitation on the number of
enumerations (and therefore on the length of a value), MIB designers
should realize that there may be implementation and interoperability
limitations for sizes in excess of 128 bits.
Finally, a label for a named-number enumeration must consist of one
or more letters or digits (no hyphens), up to a maximum of 64
characters, and the initial character must be a lower-case letter.
(However, labels longer than 32 characters are not recommended.)
[rfc1906.txt]
(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.
[rfc1514.txt]
hrPrinterDetectedErrorState OBJECT-TYPE
SYNTAX OCTET STRING
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object represents any error conditions
detected by the printer. The error conditions are
encoded as bits in an octet string, with the
following definitions:
Condition Bit # hrDeviceStatus
lowPaper 0 warning(3)
noPaper 1 down(5)
lowToner 2 warning(3)
noToner 3 down(5)
doorOpen 4 down(5)
jammed 5 down(5)
offline 6 down(5)
serviceRequested 7 warning(3)
If multiple conditions are currently detected and
the hrDeviceStatus would not otherwise be
unknown(1) or testing(4), the hrDeviceStatus shall
correspond to the worst state of those indicated,
where down(5) is worse than warning(3) which is
worse than running(2).
Bits are numbered starting with the most
significant bit of the first byte being bit 0, the
least significant bit of the first byte being bit
7, the most significant bit of the second byte
being bit 8, and so on. A one bit encodes that
the condition was detected, while a zero bit
encodes that the condition was not detected.
This object is useful for alerting an operator to
specific warning or error conditions that may
occur, especially those requiring human
intervention."
::= { hrPrinterEntry 2 }
[draft-krupczak-hostmibv2-01.txt]
hrPrinterDetectedErrorState OBJECT-TYPE
-- SYNTAX BITS (0..128) {
SYNTAX BITS {
lowPaper(0),
noPaper(1),
lowToner(2),
noToner(3),
doorOpen(4),
jammed(5),
offline(6),
serviceRequested(7),
inputTrayMissing(8),
outputTrayMissing(9),
markerSupplyMissing(10),
outputNearFull(11),
outputFull(12),
inputTrayEmpty(13),
overduePreventMaint(14)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object represents any error conditions
detected by the printer. The error conditions are
encoded as bits in an octet string, with the
following definitions:
Condition Bit # hrDeviceStatus
lowPaper 0 warning(3) or down(5)
noPaper 1 warning(3) or down(5)
lowToner 2 warning(3) or down(5)
noToner 3 warning(3) or down(5)
doorOpen 4 warning(3) or down(5)
jammed 5 warning(3) or down(5)
offline 6 warning(3) or down(5)
serviceRequested 7 warning(3) or down(5)
inputTrayMissing 8 warning(3) or down(5)
outputTrayMissing 9 warning(3) or down(5)
markerSupplyMissing 10 warning(3) or down(5)
outputNearFull 11 warning(3) or down(5)
outputFull 12 warning(3) or down(5)
inputTrayEmpty 13 warning(3) or down(5)
overduePreventMaint 14 warning(3) or down(5)
If multiple conditions are currently detected and
the hrDeviceStatus would not otherwise be
unknown(1) or testing(4), the hrDeviceStatus shall
correspond to the worst state of those indicated,
where down(5) is worse than warning(3) which is
worse than running(2).
Bits are numbered starting with the most
significant bit of the first byte being bit 0, the
least significant bit of the first byte being bit
7, the most significant bit of the second byte
being bit 8, and so on. A one bit encodes that
the condition was detected, while a zero bit
encodes that the condition was not detected.
This object is useful for alerting an operator to
specific warning or error conditions that may
occur, especially those requiring human
intervention.
Because error bits 8 through 14 can indicate a printer
that is still functioning, the corresponding
(recommended) printer hrDeviceStatus can be either
warning(3) or down(5).
New bits may be defined by standards-track MIB modules
but the maximum size of instances of this variable
should be 128 octets."
::= { hrPrinterEntry 2 }
On Tuesday, November 17, 1998 10:32 AM, Ron Bergman [SMTP:rbergma%dpc.com at interlock.lexmark.com] wrote:
> 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
> > -----------------------------------------------------------------------
> >
> >
>