Subject: PMP> Unavailable vs. Broken - review by April 17th

From: Harry Lewis <[email-masked]>
Date: Wed, 8 Apr 1998 16:56:06 -0400

The "Top-25" alert definitions specify subUnitStatus "Unavailable because
Broken" for

Jam
Cover/Door Open
Input Tray Missing
Output Tray Missing
Output Tray Full
Marker Supply Missing
Marker Supply Empty

During the PMP last call, Tom Hastings wrote

>We were wondering why we didn't use "Unavailable and OnRequest"
>...for something that requires human attention, but is not broken?

While we do not want to entirely resurface this discussion, we are giving
everyone until 4/17 to review their interpretations or implementations of the
Top-25 to see if there is major misunderstanding.

Please review with your product development teams and reply before Friday, 4/17.

Harry Lewis - IBM Printing Systems

---

From: Matt Young <[email-masked]>
Date: Thu, 16 Apr 1998 10:06:12 -0600

The current HP code returns "Unavailable and OnRequest" for all the
listed alerts except "Marker Supply Missing", which returns "Unavailable
because Broken".

I searched for a definition of what these status values are supposed to
mean and was not able to find any.  It certainly appears to make more
sense to return "OnRequest" because there are very few cases (at least
for HP printers) where these alerts are caused by errors that require
some type of repair.

--
Matt Young
([email-masked])  Hewlett-Packard Department LaserJet Division

---

From: Tom Hastings <[email-masked]>
Date: Thu, 16 Apr 1998 17:03:21 PDT

I have consulted at Xerox and we too would like to change our position
to changing the top 25 so that the broken bit is NOT set.

In fact, if we can do it as part of turning the Printer MIB into a draft
standard, we may solve the compatibility problem.  Implementations that
implement RFC 1759 generally set the broken bit (and don't mean that the
device is broken, necessarily).  Devices that implement the new draft
standard (RFC NNNN), set the broken bit only when the device is broken.

An application that works with both RFC 1759 and RFC NNNN can then handle
the broken bit being set differently between the two implementations
(after determining which RFC the device implements).

But if we publish the draft standard as it is and then change the
TOP25 to remove the broken bit from these events, we face serious 
problems with applications trying to do something with the broken bit:  
the applications can never be sure whether the broken bit has meaning or not.

Tom

---

From: Tom Hastings <[email-masked]>
Date: Thu, 16 Apr 1998 17:12:20 PDT

Here is a further suggestion on the broken bit from a Xerox participant:

I support the recommended change of not SETTING the 'broken'
bit whenever the device 'knows' that the condition to be resolved
depends ONLY upon 'normal human intervention...' and NOT in
need of 'extraordinary (service) intervention...'.  In other words, I
recommend  that the 'broken' bit(s) remain, but by definition that 
they are only SET when the device 'knows' (because of its 
intrinsic error handling capabilities) that 'something beyond
normal human intervention...' is required to resolve the problem
(eg: service rep, key operator, etc).  The 'broken' bit therefore
acts as a simple indicator of problem 'severity'.

I think this fits in with HP's approach as well, since they set the
broken bit for "Marker Supply Missing" which may be a more serious kind
of condition and require a more skilled person to fix.

Tom