PMP Mail Archive: Re: PMP> Top 25 minus 4 conditions/alerts proposal

PMP Mail Archive: Re: PMP> Top 25 minus 4 conditions/alerts proposal

Re: PMP> Top 25 minus 4 conditions/alerts proposal

JK Martin (jkm@underscore.com)
Fri, 2 May 1997 14:16:30 -0400 (EDT)

Angelo,

> I like your proposal

Thanks. Looks like we'll need a serious group vote, though, to reach
consensus on this issue.

> Also, for the record, I think forcing the printer "off-line" when
> critical alerts occur is uneccessary and annoying to users. Why should
> I have to remember to press a button after I add paper, clear a jam or
> add toner???

It's not a bug. It's a feature.

Seriously, we rather like the feature, for all the reasons Bob and Harry
have stated thus far. Hopefully no one in PMP-land thinks that we are
against this kind of functionality...unless, of course, the printer does
not let the user configure it so that it auto-continues upon those
conditions. (We haven't seen one of those yet, though. Knock on wood.)

> By the way, my definition of off-line is that the device
> will not accept new jobs from any channel, but will complete any job
> already in process.

I fully understand your thinking. However, you are bucking the trend
with your definition. Most printers stop printing when they are offline.

> Regarding Gail's earlier posting about the low toner bit being only a
> warning, the description of hrPrinterDetectedErrorState basically
> dictates that low toner can only be a warning. Obviously this is
> inconsistent with existing implementations.

Exactly. And, as I mentioned in a different posting, the PMP may very
well be at the point where we necessarily must part ways with at least
some parts of the Host Resources MIB.

That is, the PWG should "deprecate" certain definitions in the HR MIB.
And after all, the HR MIB is only at the "Proposed" stage.

> And, what about alerts
> which have no defined bits? It's seems logical to use the generic
> "serviceRequested" bit. But, again the description dictates that this
> can only be a warning. So, I propose that the Printer MIB, section
> 2.2.13.2, should state that the table in the description for
> hrPrinterDetectedErrorState is inconsistent with existing
> implementations and that the value of hrDeviceStatus for a given bit
> in hrPrinterDetectedErrorState is implementation specific. What do you think?

I think you're on the right track, Angelo. However, I truly believe
we need to do something more than add a few sentences in our new draft.

My personal feeling is that we deprecate the use of the HR MIB variable
prtPrinterDetectedErrorState altogether.

However, this will raise the issue I stated in another message regarding
the need to satisfy "simple" mgmt apps, since the Printer MIB does not
provide a few "simple" status variables that allow a simple app to quickly
derive reasonable status.

And why didn't we? Because we were told we had to use the HR MIB values,
since they were already defined. (Seemed logical at the time.)

Now, after several years of experience, we've learned otherwise. The
question is, are we going to do the right thing? Or just keep hacking
the semantics of special bit definitions (such as "serviceRequested")?

...jay