PMP Mail Archive: Re: PMP> Unavailable vs. Broken - review by April 17th

PMP Mail Archive: Re: PMP> Unavailable vs. Broken - review by April 17th

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

Tom Hastings (
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.


At 09:06 04/16/1998 PDT, Matt Young wrote:
>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.
>Harry Lewis wrote:
>> 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
>Matt Young
>( Hewlett-Packard Department LaserJet Division