Subject: Re: PMP> hrMIB Extensions and Top25 Corrections

From: Harry Lewis <[email-masked]>
Date: 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 status
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 application
and/or coded an agent to the interim "Top 25" definition... which is quite
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 = noPaper; prBit = inputTrayMissing

Harry Lewis - IBM Printing Systems

---- Lloyd wrote----

[email-masked] on 10/23/97 05:52:42 AM
Please respond to [email-masked] @ internet
To: Harry Lewis/Boulder/IBM@ibmus
cc: [email-masked] @ 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 ---------

[email-masked]
10/22/97 07:21 PM

To:   [email-masked]
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

---

From: Jay Martin <[email-masked]>
Date: Fri, 24 Oct 1997 17:05:09 -0400

Lloyd,

Harry has raised some very good points and is now proposing some
very solid--and simple--changes to the new Printer MIB.

The short response from our corner is that we agree with Harry's
proposal 100%.  The *long* response is probably more than anyone
wants to read on the mailing list right now.  However, I'd like
to make these quick points:

  1. It's high time we nailed the HR MIB-related questions once
     and for all.  Harry has been tastefully persistent in repeatedly
     attempting to get the PMP to understand the gravity of the
     problem and to get resolution.  The PMP has always pushed the
     situation to the side, saying something to the effect of
     "Let's wait to hear from the IETF, etc..."  We should NOT wait
     any longer, particularly given the standards track problems
     we're experiencing with other PWG standards efforts.

  2. From a technical implementation viewpoint, making the changes
     Harry is proposing should be seen by all developers as being
     VERY, VERY SIMPLE to implement in a rapid fashion.  The real
     question is something like:

         "How many implementations have already gone to market
          that are based on Printer MIB II, but use the old HR MIB
          cookie values as defined in the Top25 Condition list?"

     While as an IETF working group we're not supposed to ask such
     questions, the ever-pragmatic lot that represents the great bulk
     of the PWG know better...  We need to ask this question.

It would be nice to handle the final resolution of the HR MIB issues
and Harry's proposal over the mailing list, however I believe we
don't have the bandwidth to do it justice.  At least not in the
remaining time we have to get the standard "done".

Unfortunately, there is no time slot currently allotted to the PMP
group at the Boulder meetings next week.  Since I firmly believe
this topic needs serious face-to-face discussion time, I would like
to propose that the Thursday afternoon slot given to the SENSE
project be shortened to 2 hours, in which the PMP group would be
given the 2-hour slot right after lunch.

Perhaps the Boulder meetings can be the LAST TIME we have to address
the issues surrounding the integration of the HR MIB with the Printer
MIB.

	...jay

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------