PMP Mail Archive: PMP> prtDetectedError Proposal

PMP> prtDetectedError Proposal

lpyoung@lexmark.com
Wed, 5 Nov 1997 15:19:03 -0500

Given the fact that Harry has withdrawn his proposal of adding a new OID
to the Printer MIB to replace hrPrinterDetectedErrorState, I do not see any
reason for a PMP conference call to discuss this. With Harry's attached
proposal, we will continue down the path that was previously agreed to:
Get the HR MIB working group to extend hrPrinterDetectedErrorState.
Chris and I will present Harry's attached proposal to the new HR MIB
group for their acceptance.

Agreed?
Lloyd
------ Forwarded by Lloyd Young on 11/05/97 03:12 PM ------

harryl%us.ibm.com@interlock.lexmark.com
11/05/97 02:41 PM

To: pmp%pwg.org@interlock.lexmark.com
cc: (bcc: Lloyd Young)
bcc: Lloyd Young
Subject: PMP> prtDetectedError Proposal

First, let me reiterate that I feel the "Top 25" alerts are not in a
usable state of specification at this point due to ambiguity in the
area of hrPrinterDetectedErrorState. I had proposed additions to this
extensible byte coincident with creation of the "Top 25". These extensions
have not yet been accepted by the HR MIB. I recently proposed adding an
OID to the Printer MIB to extend these bits - freeing us from dependency
on the HR MIB in this area.
In light of the fact that, overall, the PWG is still trying to push
the Printer MIB to DRAFT status, I am willing to continue pursuing the
extension of HR MIB status bits rather than move this extension activity
into the Printer MIB. Should, for any reason, the IETF ultimately reject
the motion to grant DRAFT status to the Printer MIB, and should, at that
time, the HR MIB still resist extension of hrPrinterDetectedErrorState,
I will then STRONGLY re-introduce my proposal to extend these bits in the
Printer MIB. I suspect, if this comes about, there will be several other
areas of the Printer MIB we will want to clean up which would result in a
"Printer MIB-2" destined for PROPOSED status (like RFC1759).
I will restate (and extend) my proposed extensions to
hrPrinterDetectedErrorState, below.
Condition Bit # hrDeviceStatus
inputTrayMissing 8 warning(3) or down(5)
outputTrayMissing 9 warning(3) or down(5)
markerSupplyMissing 10 warning(3) or down(5)
outputNearFull 11 warning(3) or down(5)
outputFull 12 warning(3) or down(5)
* inputTrayEmpty 13 warning(3) or down(5)
Reserved for PWG 14 n/a
Reserved for PWG 15 n/a
I further propose that, in moving to DRAFT, the HR MIB, itself, remove
the stated correlation between hrPrinterDetectedErrorState bits and
hrDeviceStatus (Warning vs Down).
lowPaper 0 warning(3)
noPaper 1 down(5)
lowToner 2 warning(3)
noToner 3 down(5)
doorOpen 4 down(5)
jammed 5 down(5)
offline 6 down(5)
serviceRequested 7 warning(3)
I contend that this specification does not map accurately in all
cases to real printer implementations (for example, printers which are
offline but not down or are down with serviceRequested), and serves no
meaningful purpose.
* The hrPrinterDetectedErrorState pertains to the whole printer. Thus,
noPaper
means the whole printer is empty. inputTrayEmpty is distinguished from
noPaper
in that it means one or more trays are empty but not the whole printer.
Note that inputTrayEmpty (13) would probably not be needed if noPaper
(warning) were allowed.
Harry Lewis - IBM Printing Systems