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

Caruso, Angelo (Angelo.Caruso@usa.xerox.com)
Thu, 16 Apr 1998 07:46:09 PDT

I would argue that the same is true for the on-line/off-line bit in
hrPrinterDetectedErrorState. But it seems that most everyone has gone off
and reconciled their implementations against the Top 25 list, so I think we
are stuck with what we have defined there.

Thanks,
Angelo

-----Original Message-----
From: Ron Bergman [SMTP:rbergma@dpc.com]
Sent: Wednesday, April 15, 1998 7:35 PM
To: Tom Hastings
Cc: Ron Bergman; pmp@pwg.org
Subject: RE: PMP>Unavailable vs. Broken - review by April
17th

Tom,

The bit is currently meaningless, we should either admit this fact
and
recommend not using it or fix the problem. To keep it as is is
essentially the former.

Ron Bergman
Dataproducts Corp.

On Wed, 15 Apr 1998, Tom Hastings wrote:

> It looks like a number of products do set the broken bit as well
as the
> unavailable bit, so we shouldn't change the spec for the top 25
> out from under them.
>
> So I would think that we should add a note to application writers
> that the broken bit doesn't necessarily mean that the device is
broken.
>
> At 08:56 04/15/1998 PDT, Ron Bergman wrote:
> >Tom,
> >
> >The Dataproducts implementation conforms to the Top-25 alert
definitions
> >reporting "Unavailable because Broken".
> >
> >I would, however, prefer that the HR MIB and the Printer be
revised to
> >allow more flexibility in these conditions to allow the true
condition of
> >the printer to be reported.
>
> But if we make such a change, how is an application to know
whether a device
> that has set the broken bit is really broken or is one of the
existing
> devices that sets the broken bit because the top 25 says to set
the bit?
>
> Unfortunately, I don't think we can use the broken bit to mean
broken
> without impacting existing implementations.
>
> >
> > Ron Bergman
> > Dataproducts Corp.
> >
> >
> >
> >
>