Subject: PMP> Re: Requested change to HR MIB

From: Steve Waldbusser <[email-masked]>
Date: Mon, 23 Aug 1999 12:53:03 -0700

This problem was solved a different way.

The new text (ini the current draft) clarifies that "The hrDeviceStatus column
shows the hrDeviceStatus which is typically appropriate when such an error
condition exists." In other words, there isn't a strict algorithmic
translation between errorState bits and deviceStatus. deviceStatus should be
set based on the operational status of the printer. errorState bits should be
set based on any detected errors. If the noPaper condition is set but the
printer is still able to run, this would be highly unusual, but OK. The
deviceStatus column just suggests the most likely condition.

Adding warning or down to all rows is less useful and actually provides less
flexibility than implementors might need.

Steve

> From: [email-masked]
>
> Please change the description of hrPrinterDetectedErrorState:
>
> Original Text
>              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)
>              inputTrayMissing      8        warning(3)
>              outputTrayMissing     9        warning(3)
>              markerSupplyMissing  10        warning(3)
>              outputNearFull       11        warning(3)
>              outputFull           12        warning(3)
>              inputTrayEmpty       13        warning(3)
>              overduePreventMaint  14        warning(3)
>
> Revised Text
>              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)
>
> Reason for change:
> The original text would seem to require all printers to respond
> identically in hrDeviceStatus on the same error condition. Reality
> is that different printers respond differently on the same error
> condition. What might be a warning in one printer may be a down
> condition in another printer. Even within a printer a single error
> condition might be a warning one time and a down condition another
> time. For example, several printers support the linking of multiple
> paper trays together to form one logical paper tray, when one of the
> linked trays runs out of paper the printer will start feeding paper
> from one of the other linked trays, the printer may report noPaper
> but it is a warning condition because paper is being fed from
> another tray.
>
> Lloyd
> ------------------------------------------------------------
> Lloyd Young
> Manager, Alliances and Complementary Project Development
> Consumer Printer Division         Lexmark International, Inc.
> Dept. C88M/Bldg. 005-1            740 New Circle Road NW
> email: [email-masked]        Lexington, KY 40550-0001
> Phone: (606) 232-5150             Fax: (630) 982-4032
>
> ----------------

---

From: [email-masked]
Date: Mon, 23 Aug 1999 16:10:52 -0700

I would like to second Harry's statements. The current wording looks
too much like a specification. I think this is best handled in
comments as information to developers. Implementations vary
too much to imply that this is anything more than a guide.

Tektronix, Inc.
Color Printing and Imaging Division
[email-masked]

> -----Original Message-----
> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Monday, August 23, 1999 3:26 PM
> To:	Steve Waldbusser
> Cc:	[email-masked]; [email-masked]
> Subject:	Re: PMP> Re: Requested change to HR MIB
> 
> 
> 
> Implementations had found a few cases where the fixed association between
> hrPrinterDetectedErrorState bits and hrDeviceStatus were inappropriate.
> The
> initial recommendation was to add warning or down for each bit. Later, we
> requested to just REMOVE the hrDeviceStatus column altogether since
> SPECIFICATION of an association was not feasible in all circumstances.
> 
> If the new wording is clear that these are LIKELY associations but not
> mandated,
> I guess that's ok too, but I'd rather see this as an example. I believe
> the
> current draft appears too much like a specification (that MUST be
> followed).
> 
> Harry Lewis
> IBM Printing Systems
> [email-masked]
> 
> 
> Steve Waldbusser <[email-masked]> on 08/23/99 01:53:03 PM
> 
> To:   [email-masked]
> cc:
> Subject:  PMP> Re: Requested change to HR MIB
> 
> 
> 
> 
> 
>

---

From: [email-masked]
Date: Wed, 25 Aug 1999 17:19:09 -0700

I like this new wording. 

Chuck Adams
Tektronix, Inc.

> From:	Steve Waldbusser [SMTP:[email-masked]]
> Sent:	Wednesday, August 25, 1999 5:05 PM
> To:	[email-masked]
> If we did this, the appropriate text would look like that below. Note that
> this
> also deletes the advice on setting hrDeviceStatus based on hrPrinterStatus
> values,
> which would also be problematic.
> 
> Steve
> 
> hrPrinterStatus OBJECT-TYPE
>     SYNTAX     INTEGER {
>                    other(1),
>                    unknown(2),
>                    idle(3),
>                    printing(4),
>                    warmup(5)
>                }
>     MAX-ACCESS read-only
>     STATUS     current
>     DESCRIPTION
>         "The current status of this printer device."
>     ::= { hrPrinterEntry 1 }
> 
> 
> hrPrinterDetectedErrorState OBJECT-TYPE
>     SYNTAX     OCTET STRING
>     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 #
> 
>              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
> 
>         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 }
> 
> 
> 
> [email-masked] wrote:
> 
> > Steve,
> > Another solution would be to delete the hrDeviceStatus column from
> > the description of hrPrinterDetectedErrorState. This column caused
> > alot of confusion in our interoperability testing and I am not sure
> > the clarifying text will solve the problem. It is also becoming
> > more common than not that a printer will keep running even with
> > "no paper". What was "typically appropriate" a year or so ago is
> > changing rapidly in the printer world.
> > Lloyd
> >
> > [email-masked] on 08/23/99 03:53:03 PM
> >
> > To:   [email-masked]
> > cc:    (bcc: Lloyd Young/Lex/Lexmark)