Lloyd,
Our client developers agree that the problem is a problem and is worth
fixing.
Thanks,
Tom
At 04:45 10/23/1997 PDT, lpyoung at lexmark.com wrote:
>>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 at interlock.lexmark.com>10/22/97 07:21 PM
>>>To: pmp%pwg.org at 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 little
>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 section
> 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 hrDeviceStatus
> 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 = offline
> row 9 - Input Tray Missing (Critical) - hrBit = noPaper
> row 11 - Output Tray Missing (Critical) - hrBit = serviceRequested +
>offline
> row 12 - Output Tray Full (Critical) - hrBit = serviceRequested +
>offline
> row 13 - Marker Supply Missing (Crit) - hrBit = noToner
> row 16 - Output Tray Almost Full (Warn) - hrBit = serviceRequested
> row 18 - Input Tray Missing (warning) - hrBit = lowPaper
> row 19 - Input Tray Empty (warning) - hrBit = lowPaper
> row 20 - Output Tray Missing (warn) - hrBit = serviceRequested
> row 21 - Output Tray Full (warn) - hrBit = 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, printer
> -- 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.
> ::= { prtGeneralEntry 20}
>3. Correct the "Top 25" table as follows:
> row 5 - Initial Power Up - hrBit = (0x0)
> row 9 - Input Tray Missing (Critical) - hrBit = inputTrayMissing
> row 11 - Output Tray Missing (Critical) - hrBit = outputTrayMissing
> row 12 - Output Tray Full (Critical) - hrBit = outputFull
> row 13 - Marker Supply Missing (Crit) - hrBit = markerSupplyMissing
> row 16 - Output Tray Almost Full (Warn) - hrBit = outputNearFull
> row 18 - Input Tray Missing (warning) - hrBit = inputTrayMissing
> row 19 - Input Tray Empty (warning) - hrBit = inputTrayEmpty
> row 20 - Output Tray Missing (warn) - hrBit = outputTrayMissing
> row 21 - Output Tray Full (warn) - hrBit = 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
>>>>>>