PMP Mail Archive: Re: PMP> hrMIB Extensions and Top25 Corrections

PMP Mail Archive: Re: PMP> hrMIB Extensions and Top25 Corrections

Re: PMP> hrMIB Extensions and Top25 Corrections

Harry Lewis (harryl@us.ibm.com)
Thu, 23 Oct 1997 10:16:21 -0400

Lloyd, these are very good questions (let me break them out...) and I
think the answers are encouraging.

>Is this an area that is broken in the Printer MIB?

DEFINITELY! The reliance of Host Resource MIB objects for printer statu=
s
has been the "Achilles heel" of the printer MIB from it's inception. We=

knew (and protested) this at the beginning, it was (twice) demonstrated=

to be the major thorn for interoperability. Our "Top 25" (alerts and
status) effort went a LONG way to patching things up but the additional=

hrPrinterDetectedErrorState bits were intended to finalize this process=

and have never (and will never) be accepted by the hrMIB.

>If yes, does this change fix the problem?

Not as well as if we had defined printer status ourselves, in the first=

place, but that's history. Defining prtDetectedErrors not only "fixes"
the problem quite well, within the existing context, but it also "frees=
"
the PWG/PMP from reliance on the hr MIB... something that was intended
to prevent redundancy in MIBs but which, in practice, has resulted in
more of a "log jam" in MIB progression.

>If we incorporate this change, will a host application developed
>against RFC 1759 still work correctly when run with a printer that
>has incorporated this change?

YES! Since prtDetectedErrors is a new OID, existing host applications
will simply operate as if constrained by the old definitions (and
confusion). The danger is that someone may have written a host applicat=
ion
and/or coded an agent to the interim "Top 25" definition... which is qu=
ite
possible. I am open to this objection as a valid concern. If this is so=
,
rather than drop the proposal, I'd like to entertain a "backwards
compatible" approach, for example defining
Input Tray Missing (Critical) - hrBit =3D noPaper; prBit =3D inputTrayM=
issing

Harry Lewis - IBM Printing Systems

---- Lloyd wrote----

pmp-owner@pwg.org on 10/23/97 05:52:42 AM
Please respond to pmp-owner@pwg.org @ internet
To: Harry Lewis/Boulder/IBM@ibmus
cc: pmp@pwg.org @ internet
Subject: Re: PMP> hrMIB Extensions and Top25 Corrections

Harry,

I would like to hear some feedback from people developing host printer
management applications that are using the Printer MIB. Over the past
month or so, we have had several host applications spring up that are
using the Printer MIB for managing printers. Is this an area that is
broken in the Printer MIB? If yes, does this change fix the problem?
If we incorporate this change, will a host application developed
against RFC 1759 still work correctly when run with a printer that
has incorporated this change?

Lloyd Young

---------- Original note ---------

harryl%us.ibm.com@interlock.lexmark.com
10/22/97 07:21 PM

To: pmp%pwg.org@interlock.lexmark.com
cc: (bcc: Lloyd Young)
bcc: Lloyd Young
Subject: PMP> hrMIB Extensions and Top25 Corrections

I recently made an observation regarding the mandated combination of
OFFLINE with SERVICE REQUESTED in the "Top 25" alert table definitions.=

I don't think my point came across too clearly (as there has been littl=
e
or no response). At the risk of being "lengthy", please let me attempt
to clarify and make a proposal.
BACKGROUND:
----------
1. RFC1759 utilizes a combination of status indications from the hrMIB,=

including hrDeviceStatus, hrPrinterStatus and
hrPrinterDetectedErrorState
to derive "Overall Printer Status" as defined in the table in sectio=
n
2.2.13.2 (March 1995 version).
2. Of all the "Overall Printer Status" definitions, only OFFLINE (and
moving offline) correspond directly with a specific
hrPrinterDetectedErrorState bit.
3. The semantic of OFFLINE has never been adequately defined in the
printer MIB. Some devices do not incorporate the concept of
ONLINE/OFFLINE.
4. In it's definition of the hrPrinterDetectedErrorState, the hrMIB
(unfortunately) mandates correlation between the bits and hrDeviceSt=
atus
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)
As such, there is no "No Paper Warning" as might occur when one tray=

of n linked is exhausted, or no "Service Requested Down" as might
result from a fuser overheating.
5. In conjunction with the development of the "Top 25" alerts, a
proposal was made to extend the hrPrinterDetectedErrorState bits
as follows

Condition new hrBit Today's mapping
--------- ------ ---------------
inputTrayMissing 8 noPaper or lowPaper
outputTrayMissing 9 Service Requested
markerSupplyMissing 10 noToner
outputNearFull 11 Service Requested
outputFull 12 Service Requested

PROBLEM:
-------
1. As it stands, the "Top 25" alerts resort to utilizing
uninformative, inappropriate or ambiguous combinations of
hrPrinterDetectedErrorState bits to overcome the constrained
associations described in 4 (above) or compensate for the
fact that proposal 5 (above) has received little or no
consideration by the keepers of the hrMIB.
2. The areas in question are:
row 5 - Initial Power Up - hrBit =3D offline
row 9 - Input Tray Missing (Critical) - hrBit =3D noPaper
row 11 - Output Tray Missing (Critical) - hrBit =3D serviceRequested=
+
offline
row 12 - Output Tray Full (Critical) - hrBit =3D serviceRequested=
+
offline
row 13 - Marker Supply Missing (Crit) - hrBit =3D noToner
row 16 - Output Tray Almost Full (Warn) - hrBit =3D serviceRequested=

row 18 - Input Tray Missing (warning) - hrBit =3D lowPaper
row 19 - Input Tray Empty (warning) - hrBit =3D lowPaper
row 20 - Output Tray Missing (warn) - hrBit =3D serviceRequested=

row 21 - Output Tray Full (warn) - hrBit =3D serviceRequested=

3. OF THESE, ROWS 5,11 AND 12 ARE THE MOST SIGNIFICANT IN TERMS OF
MISLEADING INFORMATION, BECAUSE THEY MANDATE THE INDICATION OF
OFFLINE, A PRIMARY "OVERALL PRINTER STATUS", WHEN THE PRINTER
MAY NOT BE OFFLINE (AND, INDEED, SOME PRINTERS CANNOT GO OFFLINE).
4. Rows 9,13,16,18,19,20 and 21, are "less than informative".

PROPOSAL
--------
1. Acknowledge that it is beyond our control to see that the hrMIB will=

ever be updated.
2. Define a new OID in prtGeneral
-- "prtDetectedErrors" hrMIB extension object.
--
-- This object extends the octet string originally defined in the
hrMIB (RFC1514) and is intended to operate in concert with the
hrMIB object hrPrinterDetectedErrorState. See Appendix E -
Overall Printer Status Table, for information on the use of
this object in conjunction with printer conditions and alerts."
--
-- Future extension of printer state "bits" will occur in this, printe=
r
-- MIB OID, not in the hrMIB.
prtDetectedErrors OBJECT-TYPE
SYNTAX OCTET STRING
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object represents additional error conditions
detected by the printer which were not included in
the initial hrMIB definitions or
hrPrinterDetectedErrorState. The error conditions
are encoded as bits in an octet string, with the
following definitions:
Condition Bit # hrDeviceStatus
inputTrayMissing 0 warning(3) or down(5)
outputTrayMissing 1 warning(3) or down(5)
markerSupplyMissing 2 warning(3) or down(5)
outputNearFull 3 warning(3) or down(5)
outputFull 4 warning(3) or down(5)
inputTrayEmpty 5 warning(3) or down(5)
Reserved 6 n/a
Reserved 7 n/a

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.
::=3D { prtGeneralEntry 20}
3. Correct the "Top 25" table as follows:
row 5 - Initial Power Up - hrBit =3D (0x0)
row 9 - Input Tray Missing (Critical) - hrBit =3D inputTrayMissing=

row 11 - Output Tray Missing (Critical) - hrBit =3D outputTrayMissin=
g
row 12 - Output Tray Full (Critical) - hrBit =3D outputFull
row 13 - Marker Supply Missing (Crit) - hrBit =3D markerSupplyMiss=
ing
row 16 - Output Tray Almost Full (Warn) - hrBit =3D outputNearFull
row 18 - Input Tray Missing (warning) - hrBit =3D inputTrayMissing=

row 19 - Input Tray Empty (warning) - hrBit =3D inputTrayEmpty
row 20 - Output Tray Missing (warn) - hrBit =3D outputTrayMissin=
g
row 21 - Output Tray Full (warn) - hrBit =3D outputFull
4. Define OFFLINE as follows and add this definition to the printer MIB=

"The OFFLINE state may be implemented differently on various devices=

and, indeed, some devices may not implement OFFLINE at all. In
general, if a device has an OFFLINE state it MUST indicate, via
hrPrinterDetectedErrorState bit (2) when this state has been entered=

=