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

From: Chuck Adams <[email-masked]>
Date: Thu, 01 May 1997 08:33:26 -0700

Folks,

        I have posted the proposed Appendix wording for the
	the Top 25 minus 4 alerts document to the ftp site. See:

        ftp://pwg.org/pub/pwg/pmp/contributions/err4.doc
        ftp://pwg.org/pub/pwg/pmp/contributions/err4.pdf

	I believe this reflects all the changes requested
	in the Wednesday conference call.

Chuck Adams
Tektronix, Inc.

---

From: Bob Pentecost <[email-masked]>
Date: Thu, 1 May 1997 10:43:06 -0600

During the Tuesday phone conference, I offered some wording about a 
particular alert condition that is non-critical yet the printer stops due 
to an option being set in the printer. Here's the wording which can be 
added to Chuck's table if desired.

"When a non-critical condition occurs, the printer may choose to stop 
printing by going offline (e.g., when a toner low condition occurs, the 
printer might stop to notify the user); in which case there would be two 
alerts entered into the alert table, one for the error condition and one 
for the offline condition. The offline condition is considered to be the 
critical alert that is stopping printing. Putting the printer online 
without fixing the error condition causes the offline alert to be removed 
from the table, but the non-critical alert remains in the table until the 
error condition is fixed."

Bob

----------
From:  Chuck Adams[SMTP:[email-masked]]
Sent:  Thursday, May 01, 1997 9:33 AM
To:  [email-masked]
Subject:  PMP> Top 25 minus 4 conditions/alerts proposal

Folks,

Chuck Adams
Tektronix, Inc.

---

From: [email-masked] (Bill Wagner)
Date: Thu, 1 May 1997 14:08:01 -0400

The idea that "The printer (and only the printer) decides which alert 
     codes are critical versus non-critical." was an original premise, and 
     I have been confused by apparent recent attempts to "standardize" what 
     is critical. I would also say that the linkage of events (e.g., a 
     critical alert and off-line) is also printer specific, and there 
     should be no dictate here. And, referring to the 'off-line' question, 
     there are several other persistent implemenations of what off-line 
     means. It is one of those things that non-printer people think is 
     obvious, but has so many different implementations as to be 
     conceptually useless. 
     
     Jay, The 'pause/resume' approach (using a new name) is probablly 
     reasonable, but I wonder is the specific printer pause/resume 
     implemmetation you mention functioannly the same as the Windows 
     printer pause/resume function? Or are we creating more confusion?
     
     Bill Wagner

______________________________ Reply Separator _________________________________
Subject: RE: PMP> Top 25 minus 4 conditions/alerts proposal
Author:  JK Martin <[email-masked]> at Internet
Date:    5/1/97 1:11 PM

Bob,

Thanks for following up on this topic.  You know, though, after reading
your proposed text, it suddenly hit me that we may not have been properly
analyzing the scenario in the first place.

A quick review of the basic scenario for those not in the PMP telecon
during which this new topic was first discussed:

  Some printers can be configured such that a certain condition
  normally considered as a "warning" (such as "toner low") can
  be configured so as to stop the printer altogether, that is,
  the event results in a critical condition, not a warning.

Now (assuming the above picture is correct), if we step back back
and look at the words, in essence what we have is the interesting
situation where the printer can actually *map* a warning condition
to a critical condition.

As such, for this scenario, a "toner low" condition is not at all
a non-critical (ie, warning) condition, but rather a very real
critical condition.  There is nothing in the alert code tagged for
"toner low" that implies it is implicitly a non-critical alert, right?

If this is indeed true, then we don't have to worry about muddying up
the Top 25 Conditions table with a new situation in which a non-critical
alert is treated in some way as a critical alert.

Basic premise for everyone to agree upon (and maybe a useful bit of
clarifying text for the new Printer MIB draft):

  The printer (and only the printer) decides which alert codes are
  critical versus non-critical.

Does everyone agree with this?  If so, then (following Bob's text) when
the user "continues" the printer (ie, acknowledges the warning condition),
then shouldn't the printer remove *both* the Offline and critical alert
(describing the toner low condition), and add a new non-critical alert
to say that the condition still remains (but is no longer critical)?

Comments?

        ...jay

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------

----- Begin Included Message -----

>From [email-masked] Thu May  1 12:45 EDT 1997
From: Bob Pentecost <[email-masked]>
To: "[email-masked]" <[email-masked]>, "'Chuck Adams'" <[email-masked]>
Subject: RE: PMP> Top 25 minus 4 conditions/alerts proposal
Date: Thu, 1 May 1997 10:43:06 -0600
Encoding: 39 TEXT

Bob

----------

Folks,

Chuck Adams
Tektronix, Inc.

----- End Included Message -----

---

From: JK Martin <[email-masked]>
Date: Thu, 1 May 1997 15:05:41 -0400 (EDT)

Bill,

Your absence at the last PMP telecon was sorely missed (and noted by
the group, by the way), as we were hoping to get your input on these
issues.  Perhaps then you would have understood the issue a bit better.

>      is critical.

Bill, I have no idea what you're talking about here.  To my knowledge,
there have been so such efforts to "'standardize' what is critical".  If
anything I have posted makes you believe that, then I'm sorry to have
mislead you.  What makes you think such an attempt at standardization
is going on?

>      I would also say that the linkage of events (e.g., a 
>      should be no dictate here.

You should be proud that I carried that same "anti-mandate" position during
the telecon, but as I recall, it was never an issue in the first place, but
merely a clarification of the text proposed by Bob Pentecost.

The bottom line is:  if a given critical condition results in the printer
taking itself offline, then that's fine--it's a printer implementation
choice.  If it does, then it should add the Offline alert; however, adding
such an Offline alert is really quite separate from the addition of the
critical alert that caused the subsequent offline condition in the first
place.

>      And, referring to the 'off-line' question, 

You'll get no argument here.  It's a shame, really.  However, all I was
trying to do is put forth the functional concept of Pause/Resume (and
how useful it is) and to get the printer manufacturers to not tie that
functionality in with all other conditions that result in "Offline".
Thats all.

>      printer pause/resume function? Or are we creating more confusion?

(Rapid scurrying while Jay puts on his perennial UNIX hat...  ;-)

Umm, er, how exactly does "pause/resume" work in Windows?  That is,
what are the implementation ramifications involved?  (I would guess
that perhaps the printer driver simply stops sending data to the
printer...or is this a completely naive view?)

	...jay

---

From: Bob Pentecost <[email-masked]>
Date: Thu, 1 May 1997 13:26:12 -0600

Jay,

Here are my thoughts...

From:  JK Martin[SMTP:[email-masked]]
> Sent:  Thursday, May 01, 1997 7:11 AM
> To:  [email-masked]
> Cc:  [email-masked]

Correct.

> situation where the printer can actually *map* a warning condition

Actually, we have a situation where the printer has been told "stop 
printing when the toner goes low because the user doesn't want to take a 
chance on running out of toner." If the printer truly mapped the toner low 
to a critical alert, it would never print with a low toner condition.

> "toner low" that implies it is implicitly a non-critical alert, right?

Toner low is implicitly a non-critical alert because technically, the 
printer can still print with no degradation.

> alert is treated in some way as a critical alert.

We aren't muddying up the table. We are just explaining a case where a 
non-critical condition can cause a secondary critical condition. When the 
critical condition is fixed (the printer is put online), the original 
non-critical condition (toner low) remains.
>   critical versus non-critical.

I can agree to the above.

> to say that the condition still remains (but is no longer critical)?

If the printer does this, then it appears as if the toner low condition was 
fixed and then occurred again, when in reality the toner situation hasn't 
changed. Also, this causes the management application to handle yet another 
alert (three instead of two).

> Comments?

Just the above.

Bob Pentecost
HP

---

From: JK Martin <[email-masked]>
Date: Thu, 1 May 1997 16:10:58 -0400 (EDT)

Bill,

Sheesh, so sorry I mixed the wrong set of words here:

> Bill,
> 
> Your absence at the last PMP telecon was sorely missed...

Of course I meant to say that your *presence* was sorely missed...  8-}

	...jay

---

From: JK Martin <[email-masked]>
Date: Thu, 1 May 1997 16:06:35 -0400 (EDT)

Bob,

> to a critical alert, it would never print with a low toner condition.

Reading that last sentence, I'm not sure whether you're agreeing
or disagreeing with me.  If the printer "would never print with a
low toner condition", then this definitely represents a critical
(ie, show-stopping) situation, right?  (Are we agreeing here?  Or
am I missing a point?)

> printer can still print with no degradation.

Ah, here is where we definitely disagree.  (And I believe this might
be just what Bill Wagner was complaining about regarding the attempt
to "standardize" critical vs. non-critical conditions.)

See if you can agree with this series of premises and the resulting
conclusion:

  1. Any condition for which the printer ceases operation is described
     as being a "critical" alert.  (Conversely, a condition can NOT be
     described as a "critical" alert if the condition does NOT result
     in the printer stopping operations.)

  2. Alert codes do NOT have any associated semantics (implied or
     otherwise) regarding the severity level of the condition associated
     with the alert code.  In other words, there is absolutely no
     binding whatsoever between an "alert code" and the "severity level"
     for any given condition.

  Therefore, if the printer ceases operation (ie, stops printing) when
  a "toner low" condition is encountered, then the alert added to the
  Alert Table must be tagged with a severity level of "critical".

And, following Bill Wagner's relevant comments, whether the printer
chooses to take itself offline or not is completely up to the printer
manufacturer; however, if it does, then it must also add a separate
alert to the table with an alert code of "Offline" and a severity level
of "critical".

Do you agree with this?

> printer can still print with no degradation.

Until the printer runs *out* of toner, printing *can* continue; however,
at some point those sheets are going to start getting a bit dim, don't
you think?  ;-)

> non-critical condition (toner low) remains.

Sure, I can follow your drift here.  However, after reading Gail Songer's
just-posted message on this thread, I think I must disagree with some of
the directions we set during the telecon regarding the usage of the
"Offline" alert.

Please read my response to Gail's message (coming out Real Soon Now).

> I can agree to the above.

Great.  Does anyone else out there in PMP-land disagree with this premise?

> alert (three instead of two).

Yes, I'll admit I fully see your point.  And Gail's message seems quite
related to this line of thinking, too.

I'll address this in the reply to Gail's message.

	...jay

PS:  We're really coming down the wire on nailing down the Printer MIB,
     and this issue is definitely part of that effort.  Other PMP folks
     are strongly encouraged to voice their opinions to the list so that
     we can quickly come to consensus.  It makes no difference to me if
     you agree or disagree with my statements, but rather that you state
     what you think is correct...and quickly, please.

PPS: Now, about not caring whether you disagree with me...  ;-)

---

From: Bob Pentecost <[email-masked]>
Date: Thu, 1 May 1997 16:09:22 -0600

Jay,

I think we are agreeing more than disagreeing. Read on...

> Sent:  Thursday, May 01, 1997 10:07 AM
> To:  [email-masked]
> Cc:  [email-masked]

I agree. If the printer says that toner low is a critical alert, then 
printing is halted.

>      in the printer stopping operations.)

I agree.

>      binding whatsoever between an "alert code" and the "severity level"

I agree.

>   Alert Table must be tagged with a severity level of "critical".

If the printer stops because the toner is low and it will not continue 
printing until the toner is no longer low, then the toner low alert should 
be tagged as critical.

I think the above summarizes my point. A problem that causes a critical 
alert must be fixed before printing can continue. I find it confusing to 
think of fixing a toner low condition by putting the printer back online.

> alert to the table with an alert code of "Offline" and a severity level

Yes.

> at some point those sheets are going to start getting a bit dim, don't

Are we talking about a world of perfect sensors and perfect toner 
distribution or what we must deal with today? :-)

HP printers give the toner low alert at a point where there is still enough 
toner to print with no degradation. Ideally, we would signal toner out on 
the last page before a degraded page is printed, but we can't do that. If 
another printer vendor wants to signal toner low when they start printing 
faded pages, so be it.

Maybe we have different interpretations of what 'toner low' means. To me, 
it is a warning that some number of sheets will still print normally. 
Another vendor may mean that from this point forward, sheets will be 
getting dim. For this second case, I can see posting the toner low alert as 
critical (actually, I think HP would call it 'toner out', but we can't 
detect that condition) but I'll let the decision for critical/non-critical 
be left up to the printer vendor. If a printer wants to allow printing 
faded images even when they know they are faded, that's up to the vendor 
(they can allow printing when the fuser is not working too, I don't really 
mind :-).

> Please read my response to Gail's message (coming out Real Soon Now).

I'm anxiously waiting!

Bob Pentecost
HP

---

From: JK Martin <[email-masked]>
Date: Thu, 1 May 1997 22:08:36 -0400 (EDT)

All,

I was originally going to address Gail's comments step-by-step, but
the more I got into it, the more I felt that what we really need
right now is to step back for a moment and address THE BIG PICTURE.

Warning.  This is a very long post, but hopefully it reads quickly.
Those involved with this issue are encouraged to take the time to read
this message, as it suggests we have made some mistakes in the last
PMP telecon.

Those not interested in this issue should press "Delete" now.

Regarding Gail's comments: I'm always in favor of developing a design
(or standard) such that ease-of-implementation is regarded as a
top-level goal.  To that end, I really can't argue with your excellent
discourse on how the a printer implementation may be impacted in this
situation.

However...I am seldom in favor of "robbing Peter to pay Paul",
particularly when I represent the "Peter" in this scenario!
(Uh oh, I may live to regret that statement...)

You see, you're approach certainly does make it easier for *you*,
but what about *me*, the poor mgmt app developer?

And here is precisely where the PMP group needs to step back and once
again ask that age-old question (you know, the one Tom Hastings
dislikes so much ;-), namely:

	What problem are we trying to solve here?

First, let me present our perspective, that is, from the the mgmt app
point of view.

Our product (PrintAlert) is designed to monitor an extremely wide
variety of network printers, where the primary function is to visually
notify the user (a systems administrator or operator) of problems that
arise in those network printers.

Our customers want us to tell them _what's wrong_ with the printer,
and not just that the printer _has a problem_ that must be addressed.

In other words, within the context of this specific "toner low"
scenario, the customer demands to see something like the following;
the color prefixes help to visualize the classic "traffic light"
metaphor:

	RED: "Printer XYZ has stopped due to a toner low condition!"

and *not* something like:

	RED: "Printer XYZ has a problem!"

Now, given Gail and Bob's position, if "toner low" stops the
printer--yet the specific alert describing "toner low" is tagged as a
non-critical alert--then we can only say something like:

	YELLOW: "Printer XYZ is low on toner"
	   RED: "Printer XYZ is offline!"

This is unacceptable to our customers, as they demand something like:

	RED: "Printer XYZ is now offline due to low toner!"

Of course, what they really, Really, REALLY want to see is something
like:

	RED: "Printer XYZ is now offline due to low toner!"
	     "You must press the `Continue' button on the front"
	     "panel to resume normal operation."

But I digress...  ;-)

The point here is this:  it seems we have backed ourselves into a more
complex situation whereby two (or more!) alerts are instrinsically tied
to each in terms of resolving the overall semantics of the problem
condition.

How can the mgmt app (using an algorithmic approach) know that the
non-critical "toner low" condition is intrinsically tied to the
critical "offline" alert?  Oh yeah, and what order are the two alerts
supposed to be inserted in the Alert Table?

This is NOT GOOD.  Unfortunately, it gets worse...

First, it should be noted that the "offline" alert itself is a new
addition to the MIB draft; this alert is not defined in RFC 1759.

I'm not sure we completely thought through the ramifications when
the group reached consensus on the issue of adding "offline" alerts
when any one of a large number of top conditions is encountered.

Recall that during the telecon we ran through Bob's great markup of
Chuck's latest "Top 25 Conditions" draft.  Right up front we discussed
the "offline" issues; here is the extract from Harry's minutes posted
to the list the same day as the telecon on April 29:

>  - Big discussion about how to define Offline. As usual, we did not
>    reach consensus on how to DEFINE off-line, but we did agree that
>    off-line should be treated as a separate condition. We decided
>    that an off-line alert table entry should reference GroupIndex 5
>    (the General Group) with subUnitIndex (-1).

The phrase "off-line should be treated as a separate condition" was in
reference to Bob's posted comments (4/29), which it was suggested that
a critical "offline" alert be added to the table whenever one of 16 (!)
different conditions were encountered (out of a total of 21 conditions
in the entire list).

For those printers that go offline at the drop of a hat, this means
we're going to deal with a BUNCH of "offline" alerts in the table.

And now we really have a mess...a potential total of 16 different
ways required to derive the actual condition.

How can a mgmt app deal with this binding problem of related alerts?

Another question:  How can a mgmt app detect when the printer has been
taken offline because a user pressed a front panel button?

Don't you think that customers will want to know the difference?

Yet how can the mgmt app really tell in an algorithmic manner?

Here's another scenario to consider:

Say the cover is opened and the printer (by design, or by configuration)
automatically goes offline; before closing the cover, the user first
presses the "Offline" button on the front panel.

Now, how many "offline" alerts should be in the alert table BEFORE
the door is closed versus AFTER it is closed?  Does the printer
remain offline after the door is closed, and remains that way until
the user presses a button to return the printer to an online state?

Again, how can we determine the difference so as to convey the
true nature of the condition in the printer?

This is now the problem we, the mgmt app developers, must face.
Hopefully the response from the PMP isn't something like:

	"You'll have to know the precise model to which you're
	 communicating, then use the proper mapping table.
	 You can determine the model by using the OID maintained
	 in the hrDeviceID variable...and hope that the variable
	 has been implemented by the vendor..."

	(Note: most vendors do not currently implement hrDeviceID,
	       at least not in the proper manner.)

Hardly a standard approach.  Should the mgmt app accept this burden?

Here's a proposal to fix that problem that results in the reversal
of consensus reached in the last telecon:

	If the printer automatically goes offline when one of
	the 16 defined top conditions is encountered, then the
	hrPrinterDetectedErrorState variable is set to "offline".
	In this case, no "offline" alert should be added to the
	Alert Table.

	When a condition occurs that causes the printer to automatically
	go offline, a critical alert is added to the Alert Table, and
	the alert code reflects the specific nature of the condition.

	The only time an "offline" alert is added to the Alert Table
	is when the printer is directed to go offline by management
	control, either remotely or locally, from the front panel.

The points to consider:

  - The MIB agent must already set hrPrinterDetectedErrorState; this
    rule does not change the definition in RFC 1759, so we should have
    no backward-compatibility problems.

  - We can now more accurately detect when the front panel is used
    to effect the offline condtion.

  - There will be times when certain conditions (eg, "toner low") must
    be treated as either critical or non-critical based on the current
    printer configuration, if the printer allows such configuration.
    (And several excellent models currently provide this feature.)

  - Bonus points:  The Alert Table remains smaller.

Now this last point should have a few folks interested...  ;-)

The issue this approach raises revolves around where we started on
this whole thread, namely:

	If the printer automatically goes offline due to a particular
	condition, then the alert added to the table should have a
	severity level indicating that it is a critical alert.

This means that "toner low" (and other) conditions must be intelligently
handled by some printer implementation.  And this situation is what I
believe Gail describes as something she prefers to avoid. (Same with Bob?)

Again, a fundamental assumption here is that the definition of "offline"
implies the printer has ceased its normal operations, which by definition,
is a "critical" problem.  (Note that some implementations use "offline"
to denote they are not currently accepting print requests, but printing
could be in progress with no problems present.)

So there it is.  Sorry for the length, but I wanted to ensure that
everyone saw the complete ramifications of this situation.

If somehow I'm being stupid here, please be kind.  But do please point
out the errors in this analysis as quickly as possible.  The MIB clock
is ticking...

	...jay

---

From: "Caruso,Angelo" <[email-masked]>
Date: Fri, 2 May 1997 07:27:05 PDT

I support Bill's position 100%. It's up to the implementation to decide 
 if a particular alert condition is critical or not. This may vary 
 depending on the current state of the device, the product complexity, 
 the target customer, etc. I also believe that linking any critical 
 alert condition to an offline condition is completely implementation 
 specific and should be optional.

Thanks,
Angelo
 
----------
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: Re[2]: PMP> Top 25 minus 4 conditions/alerts proposal
Date: Thursday, May 01, 1997 11:08AM

     
     Bill Wagner

---

From: "Caruso,Angelo" <[email-masked]>
Date: Fri, 2 May 1997 08:18:13 PDT

Jay,

I like your proposal (I'll repeat it here for those who did not read 

>	control, either remotely or locally, from the front panel.

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??? 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.

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. 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?

Thanks,
Angelo

---

From: [email-masked] (Bill Wagner)
Date: Fri, 2 May 1997 11:19:33 -0400

I was not part of the conference call, so I am not privy to the 
     considerations that resulted in the consensus that Jay wishes to 
     reverse. But, if one takes ignorance to allow objectivity,  to me 
     Jay's indicated alternative makes perfect sense.
     
     Despite the confusion in the precise meaning of 'off line', it 
     (almost) always results in the printer not printing subsequent print 
     jobs, so I see no difficulty in using it in the way suggested.
     
     I would also suggest that there has been enough last minute stuff here 
     to warrant a review at San Diego. Last minute changes have a way of 
     causing problems in the future.
     
     Bill  Wagner, Osicom/DPI

______________________________ Reply Separator _________________________________
Subject: Re: PMP> Top 25 minus 4 conditions/alerts proposal
Author:  JK Martin <[email-masked]> at Internet
Date:    5/1/97 10:08 PM

--------snip

------snip

---

From: Lloyd Young <[email-masked]>
Date: 2 May 97 11:26:04 EDT

I agree that Jay's write up makes a lot of sense and will add it to my list
of changes for the latest draft unless someone objects.

There are two problems with a review in San Diego:
1. I'll will not be there. This is a minor one though if the group wants
a review then I will find someone else to run the discussion.
2. According to the schedule, Randy will not have an updated draft ready
until Friday May 16th (the day the PWG meetings end).

Lloyd Young
Lexmark
------------------ Forwarded message ---------------------
To: 
cc: pmp%pwg.org @ interlock.lexmark.com @ SMTP (bcc: Lloyd Young)
From: bwagner%digprod.com @ interlock.lexmark.com (Bill Wagner) @ SMTP
Date: 05/02/97 11:19:33 AM
Subject: Re[2]: PMP> Top 25 minus 4 conditions/alerts proposal

     
     
     Bill  Wagner, Osicom/DPI

---

From: Harry Lewis <[email-masked]>
Date: Fri, 2 May 1997 11:30:50 -0400

Classification:

Well, I  certainly appreciate the rampant discussion on this topic and
apologize that I am playing catch-up with this thread. You've probably noticed,
I've been pre-occupied with topics of much greater consequence, like the color
of the LED ;-).

As best I can tell, much of the discussion focuses around the rather quirky
(with respect to the Printer MIB model) behavior of some toner low
implementations. We've run into the same situation. It's simply due to the lack
of an honest to goodness toner out sensor (let's face it... it must be pretty
DARK in there!). If you can only detect toner-low, what we do (and I think many
others too) is STOP printing on the first detection. Why? So the condition will
not go unnoticed! And, a person has to press a CONTINUE button to keep printing
(people do all kinds of other things, too, like shake the cartridge, tilt the
printer, curse the vendor, curse the secretary who didn't order enough new
toner...). Subsequently, the printer will continue to WARN of the toner low
condition, but, now, it's up to some poor sap some number of prints down the
road to suffer the readability consequences and finally take the ultimate
action (find another printer nearby that has toner!).

So... I really don't see how the OFFLINE discussion crept in here. You either
have a toner low critical or a toner low warning.

I probably have to read deeper into the thread than I have to grasp the entire
realm of this topic. I think our problems are exasperated by the fact (and I've
said this before) that we basically have THREE ways to reflect status - ALERTS,
MAGIC COOKIE and SUBUNIT STATUS. It's like moving parts... the more you have
the more likely something will break.

I agree with most of what Jay is saying in his long note. I disagree, however,
that subUnitOffline (22) is new. I mean, it didn't come in at Stardust. It's
probably been there a year, when Tom and I went through the generic exercise
with he PWG. We implement OFFLINE alert (but I don't have a thumb-nail
characterization or when or why). We also implement hrPrinterDetectedErrorState
offline. I kinda like what Jay is saying... 'only post OFFLINE alert if someone
explicitly SETS the unit OFFLINE'... but I'd have to investigate how that
matches our implementation. Also, this seems to conflict with the whole
movement to try and make your alert table big enough to contain ALL critical
alerts. What do we want, here? All criticials or selective criticals?

I doubt I've helped the conversation a whole lot. You guys are about to strike
oil with this one you're so deep! I hope my observations about simply treating
toner low as critical or warning are useful (by the way... this was a topic I
brought up about 3 months ago... I thought it was resolved in the manner I've
described). I also recall previous attempts to actually define which alerts are
critical and which are warning and I, too, recall we abandoned this approach -
the right decision, I think.

So, I don't think we should expect (or desire) Printer Management Applications
like Jay's to work on hardcoded knowledge based of the hrDeviceID. Definitely
not the goal! But I don't think the Printer MIB facilitates... "Printer offline
because toner is low and also Inupt 1 open because blonde operator is changing
paper from green to purple..." ;-). I think the best we can do with what we've
got is to report (accurately) the collection of current conditions.

Harry Lewis - IBM Printing Systems

---------------------- Forwarded by Harry Lewis/Boulder/IBM on 05/02/97 08:24 AM
 ---------------------------

        [email-masked]
        05/01/97 08:13 PM

To: [email-masked]@internet
cc: [email-masked]@internet
Subject: Re: PMP> Top 25 minus 4 conditions/alerts proposal

All,

But I digress...  ;-)

The points to consider:

 ...jay

---

From: Bob Pentecost <[email-masked]>
Date: Fri, 2 May 1997 11:11:04 -0600

As the deadline for MIB updates and clarifications is today, I propose the 
following.

1) Put the table of ~25 Printer Conditions (as posted in err4.doc) in the 
Printer MIB document.

2) I withdraw my suggested wording.

It is apparent that we disagree on how it is best to present printer 
condition information to our customers. As such, it should be left up to 
the printer vendor to decide the best implementation for their customers. 
When a generic management app interprets the Alert Table it may show the 
user either of the following:
   RED: Printer offline
   YEL: Low toner
or
   RED: Low toner

To me the first says that the printer can be put back online to continue 
printing; the second says the printer must have toner added to continue 
printing. Let each vendor decide what is appropriate.

Bob Pentecost
HP

----------
From:  JK Martin[SMTP:[email-masked]]
Sent:  Thursday, May 01, 1997 4:09 PM
To:  [email-masked]
Cc:  [email-masked]
Subject:  Re: PMP> Top 25 minus 4 conditions/alerts proposal

All,

But I digress...  ;-)

The points to consider:

	...jay

---

From: Bob Pentecost <[email-masked]>
Date: Fri, 2 May 1997 11:14:11 -0600

I do not believe we have reached consensus on this. Therefore, it should 
not be added to the document.

I will be in San Diego to discuss this further, but I do not think we 
should delay the document for this matter. Perhaps there is an alternative 
way to clarify and publish it later.

Bob

----------
From:  Lloyd Young[SMTP:[email-masked]]
Sent:  Friday, May 02, 1997 9:26 AM
To:  pmp%pwg.org
Subject:  Re[2]: PMP> Top 25 minus 4 conditions/alerts proposal

Lloyd Young
Lexmark
------------------ Forwarded message ---------------------
To:
cc: pmp%pwg.org @ interlock.lexmark.com @ SMTP (bcc: Lloyd Young)
From: bwagner%digprod.com @ interlock.lexmark.com (Bill Wagner) @ SMTP
Date: 05/02/97 11:19:33 AM
Subject: Re[2]: PMP> Top 25 minus 4 conditions/alerts proposal

     Bill  Wagner, Osicom/DPI

---

From: JK Martin <[email-masked]>
Date: Fri, 2 May 1997 13:37:38 -0400 (EDT)

Harry,

> have a toner low critical or a toner low warning.

Because Gail and Bob were saying that toner low should always be
a non-critical alert, but that if the printer stops as a result
of that condition, then a critical "offline" alert should also be
added to the Alert Table.

Then the discussion moved on to the point where "offline" alerts were
being added for a large number of alert conditions.  Hence, the focus
on the ramifications of so many "offline" alerts, etc.

> the more likely something will break.

It I would submit that we have just reached the point of serious discord with
the Host Resources MIB status variables (aka, "magic cookie variables").

For example, the HR MIB is very clear (in its attempts to "describe" a
printer sub-object) that a "toner low" condition is a warning.  And yet,
now it appears that at least some of us agree that if a "toner low"
condition results in stopping the printer, then it should be a critical
alert and NOT a non-critical (warning) alert.

So, the Printer MIB now differs from the HR MIB...unless of course we
fool around with certain definitions of other HR status values, such
as "serviceRequested", etc.  I sincerely hope we do NOT go done that
rat-hole of a hack.

To fully resolve this situation, the PMP group is going to have to
wrestle with a fundamental issue raised at the interop event last
February:

	How to support both "simple" applications that only want to
	use a few simple variables to discern the printer's state
	(ie, using only the HR variables), and "full-featured"
	applications that attempt to do a more detailed job of
	presenting the complete picture of the printer's status?

I maintain that we have now come to the crossroads where we must decide
whether to retain a conforming relationship with the HR status values,
or do the RIGHT THING and say what must be said in the Alert Table.

The primary scenario driving this decision:

	If "toner low" stops the printer, then a CRITICAL "toner low"
	alert is added to the Alert Table; however, following the HR
	rules, a "toner low" WARNING is indicated in the HR variable
	prtPrinterDetectedErrorState.

Does everyone agree we have a problem here?

> with he PWG.

Yes, the valid enum value "subUnitOffline(22)" is old, but the "offline"
alert code is new.

> We implement OFFLINE alert (but I don't have a thumb-nail
> characterization or when or why).

Yes, IBM and other vendors have had to implement an "other" (ie, not
specifically defined) alert code for "offline", since RFC 1759 did not
include one.  Hard to imagine we missed that one in the first place!

> We also implement hrPrinterDetectedErrorState

Sheesh, Harry, don't get me going on THAT one, please.  You led the effort
to refrain from mandating a minimum-sized Alert Table (in which I proposed
that all outstanding critical alerts must be represented).  Since my
proposal was not accepted, then how you decide which alerts should always
be in your products' Alert Tables is entirely up to you.

As a result, it should come as no surprise that Underscore (a printer mgmt
app vendor) strongly recommends to its customers that they only purchase
those printers with comprehensive support for the Printer MIB Alert Table.

And to us, comprehensive support means that all known problems are
fully represented in the Alert Table at all times.

	...jay

---

From: JK Martin <[email-masked]>
Date: Fri, 2 May 1997 13:53:42 -0400 (EDT)

Lloyd,

There is clear support for both sides of this issue, so would it
be possible for the PMP to conduct a list-based "vote" to see how
close we are to consensus (either way)?

This would help ease some of the time availability problems we're
starting to see with the San Diego schedules.

	...jay

----- Begin Included Message -----

>From [email-masked] Fri May  2 13:17 EDT 1997
From: Bob Pentecost <[email-masked]>
To: "pmp%pwg.org" <[email-masked]>, "'Lloyd Young'" <[email-masked]>
Subject: RE: Re[2]: PMP> Top 25 minus 4 conditions/alerts proposal
Date: Fri, 2 May 1997 11:14:11 -0600
Encoding: 50 TEXT

Bob

----------

Lloyd Young
Lexmark
------------------ Forwarded message ---------------------
To:
cc: pmp%pwg.org @ interlock.lexmark.com @ SMTP (bcc: Lloyd Young)
From: bwagner%digprod.com @ interlock.lexmark.com (Bill Wagner) @ SMTP
Date: 05/02/97 11:19:33 AM
Subject: Re[2]: PMP> Top 25 minus 4 conditions/alerts proposal

     Bill  Wagner, Osicom/DPI

----- End Included Message -----

---

From: JK Martin <[email-masked]>
Date: Fri, 2 May 1997 14:02:03 -0400 (EDT)

Bob,

> 2) I withdraw my suggested wording.

Hold on a minute.  You also made some excellent contributions regarding
other aspects of the document that did not involve the "offline" issue.
I certainly hope we retain those, don't you?  (Besides, Chuck has probably
already made the changes...  ;-)

And thanks for making me realize that I did not follow up (in my message)

> printing. Let each vendor decide what is appropriate.

Based on my proposal, here is the scenario:

 1. Toner goes low, printer goes offline.  User sees this display from
    the management app:

	RED: Printer has stopped due to low toner

 2. User goes to printer, presses "Continue" (or whatever).  User now
    sees this display from the mgmt app:

	YELLOW: Printer is low on toner

That is, once "Continue" is invoked, the RED (critical) alert is removed
from the table, and is replaced with a YELLOW (non-critical, warning) alert.

You say:

> Let each vendor decide what is appropriate.

Ok, so we don't agree here.  We need to vote on this as quickly as possible.

	...jay

---

From: JK Martin <[email-masked]>
Date: 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.

>  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 

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

>  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 

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

---

From: [email-masked]
Date: 02 May 97 16:53:08 EDT

Jay,
     
snip...

>I maintain that we have now come to the crossroads where we must 
>decide whether to retain a conforming relationship with the HR status 
>values, or do the RIGHT THING and say what must be said in the Alert 
>Table.

     
>Does everyone agree we have a problem here?

snip...

I agree that there is a problem, but I don't think it is in the relationship 
between the Alert Table and the HR Mib.  It is in the HR Mib itself!  The HR Mib
says that when hrPrinterDetectedErrorState is Low Toner then hrDeviceStatus 
should be Warning.  A printer implementation which conflicts with this HR Mib 
edict must find a way to resolve that conflict regardless of the Alert Table.  
It is unthinkable for the AlertTable entry to lie about the printer state to 
match values in the HR Mib.  

So how can the conflict in the HR Mib be resolved?  Simple monitoring 
applications which look at the HR Mib variables use a traffic light metaphor.  
Thus, hrDeviceStatus is MUCH MORE IMPORTANT than hrPrinterDetectedErrorState.  
To me it seems clear that if I had a printer implementation that went down in a 
low toner condition, I would, 
1) report the situation accurately in the Alert Table, 
2) set hrDeviceStatus to Down, and 
3) set hrPrinterDetectedErrorState to Unknown.  
This gives my printer implementation the best chance of being reported 
accurately with both simple and sophisticated monitoring applications.  Note 
that the simple monitoring application error report is not complete, i.e. some 
unknown error, but at least it is accurate, i.e. the printer is down.  This is 
vastly superior to reporting that the printer has low toner and is not down, 
which is more informative but is incorrect.

I believe that any condition can be reported adequately for both simple and 
sophisticated applications using this priority scheme. 

Does this view conflict with the Top 25 table?  I don't think so.  I view a 
Toner Low condition which is Critical as a condition which is not defined by our
Top 25 table.

Stuart Rowley
Kyocera Electronics

---

From: Harry Lewis <[email-masked]>
Date: Mon, 5 May 1997 13:59:12 -0400

I agree with Jay that there is a mismatch between a critical toner low event
and the hrMIB toner low definition and I thank Stuart stating it so eloquently:

>between the Alert Table and the HR Mib. It is in the HR Mib itself! The HR
>Mib says that when hrPrinterDetectedErrorState is Low Toner then
>hrDeviceStatus should be Warning. A printer implementation which conflicts
>with this HR Mib edict must find a way to resolve that conflict regardless of
>the Alert Table.It is unthinkable for the AlertTable entry to lie about the
>printer state to match values in the HR Mib.

I can't believe the PRINTER WORKING GROUP PRINTER MIB PROJECT is going
through such contortion on this topic just because the hrMIB does not
recognize the very real situation of toner low criticals! I think
Stuart's recommendation is the best way to address this problem short of
grabbing the hrMIB by the horns (I thought Chris was going to help us
look at changing the hrMIB ala my proposed prtDetectedErrorState bits?).

---------------------- Forwarded by Harry Lewis/Boulder/IBM on 05/05/97 11:41 AM
 ---------------------------

        [email-masked]
        05/02/97 03:00 PM

To: [email-masked]@internet
cc: [email-masked]@internet
Subject: Re[2]: PMP> Top 25 minus 4 conditions/alerts proposal

Jay,

snip...

snip...

Stuart Rowley
Kyocera Electronics

---

From: Bob Pentecost <[email-masked]>
Date: Mon, 5 May 1997 13:29:14 -0600

Jay,

> Sent:  Friday, May 02, 1997 8:02 AM
> To:  [email-masked]
> Cc:  [email-masked]

Chuck made the changes from my review of the Top 25 Conditions and 
incorporated them in "err4.doc" which he posted. What I'm willing to drop 
is my wording about adding a critical offline to a warning alert condition 
(my first 5/1 email that started this mailstorm).

> from the table, and is replaced with a YELLOW (non-critical, warning) 
alert.

How does the user (or your software) know that in this case printing can be 
resumed by pressing 'Continue' (or whatever)? What makes this critical 
alert different from others?

Bob

---

From: JK Martin <[email-masked]>
Date: Mon, 5 May 1997 15:58:59 -0400 (EDT)

Bob,

> alert different from others?

Sorry if you misunderstood my scenario steps above.

The scenarios assumes that the printer has a way to continue operations
upon some sort of human intervention (eg, pressing a "Continue" button
on the front panel, as some models are currently implemented).  Of course,
if the printer can NOT continue in any way, then the scenario stops at
the first step above.

What makes this critical alert different than others?  As a critial alert,
absolutely nothing.  The key point here is that we now have a particular
alert condition ("toner low") that can be either a critical or non-critical
alert, depending on the precise state of the printer at any given time.

That's new for us, right?  Until now, a vendor would pretty much fix the
severity level for any given alert code, at least from what we've seen in
our testing.

	...jay

---

From: Harry Lewis <[email-masked]>
Date: Mon, 5 May 1997 18:53:55 -0400

Well, it might be "new"...

> ...jay

...but we're already dealt with a similar case - the linked input tray.
We asked ourselves what to do if a tray runs empty but that tray forms
part of a larger "logical" linked tray. We said, in this case, there
should be a subUnitEmpty WARNING. If the tray were not linked, and
the printer was calling for paper from this tray, there would be a
subUnitEmpty CRITICAL.

I know Bob P. was trying to provide a clarification regarding the (very
real) toner low (critical) vs. toner low (continue) situation... I
really appreciate that. And I suspect Bob introduced the notion of
focusing on OFF-LINE to try and "get around" the "broken" hrMIB. I
appreciate that, too. But, having gone this far down the road with this
topic, I think we'd be better off separating off-line from the discussion
and just decide to treat alerts that stop the printer as critical and
alerts that don't as warnings. As Stuart noted, we need to preserve the
alert table's integrity and not succumb to inherited hrMIB deficiencies.
I don't think anyone, even the designers of the hrMIB, would want, or
expect their MIB to prevent the printer MIB from reflecting reality.