Lloyd,
Harry has raised some very good points and is now proposing some
very solid--and simple--changes to the new Printer MIB.
The short response from our corner is that we agree with Harry's
proposal 100%. The *long* response is probably more than anyone
wants to read on the mailing list right now. However, I'd like
to make these quick points:
1. It's high time we nailed the HR MIB-related questions once
and for all. Harry has been tastefully persistent in repeatedly
attempting to get the PMP to understand the gravity of the
problem and to get resolution. The PMP has always pushed the
situation to the side, saying something to the effect of
"Let's wait to hear from the IETF, etc..." We should NOT wait
any longer, particularly given the standards track problems
we're experiencing with other PWG standards efforts.
2. From a technical implementation viewpoint, making the changes
Harry is proposing should be seen by all developers as being
VERY, VERY SIMPLE to implement in a rapid fashion. The real
question is something like:
"How many implementations have already gone to market
that are based on Printer MIB II, but use the old HR MIB
cookie values as defined in the Top25 Condition list?"
While as an IETF working group we're not supposed to ask such
questions, the ever-pragmatic lot that represents the great bulk
of the PWG know better... We need to ask this question.
It would be nice to handle the final resolution of the HR MIB issues
and Harry's proposal over the mailing list, however I believe we
don't have the bandwidth to do it justice. At least not in the
remaining time we have to get the standard "done".
Unfortunately, there is no time slot currently allotted to the PMP
group at the Boulder meetings next week. Since I firmly believe
this topic needs serious face-to-face discussion time, I would like
to propose that the Thursday afternoon slot given to the SENSE
project be shortened to 2 hours, in which the PMP group would be
given the 2-hour slot right after lunch.
Perhaps the Boulder meetings can be the LAST TIME we have to address
the issues surrounding the integration of the HR MIB with the Printer
MIB.
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm at underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------
Harry Lewis wrote:
>> Lloyd, these are very good questions (let me break them out...) and I
> think the answers are encouraging.
>> >Is this an area that is broken in the Printer MIB?
>> DEFINITELY! The reliance of Host Resource MIB objects for printer status
> has been the "Achilles heel" of the printer MIB from it's inception. We
> knew (and protested) this at the beginning, it was (twice) demonstrated
> to be the major thorn for interoperability. Our "Top 25" (alerts and
> status) effort went a LONG way to patching things up but the additional
> hrPrinterDetectedErrorState bits were intended to finalize this process
> and have never (and will never) be accepted by the hrMIB.
>> >If yes, does this change fix the problem?
>> Not as well as if we had defined printer status ourselves, in the first
> place, but that's history. Defining prtDetectedErrors not only "fixes"
> the problem quite well, within the existing context, but it also "frees"
> the PWG/PMP from reliance on the hr MIB... something that was intended
> to prevent redundancy in MIBs but which, in practice, has resulted in
> more of a "log jam" in MIB progression.
>> >If we incorporate this change, will a host application developed
> >against RFC 1759 still work correctly when run with a printer that
> >has incorporated this change?
>> YES! Since prtDetectedErrors is a new OID, existing host applications
> will simply operate as if constrained by the old definitions (and
> confusion). The danger is that someone may have written a host application
> and/or coded an agent to the interim "Top 25" definition... which is quite
> possible. I am open to this objection as a valid concern. If this is so,
> rather than drop the proposal, I'd like to entertain a "backwards
> compatible" approach, for example defining
> Input Tray Missing (Critical) - hrBit = noPaper; prBit = inputTrayMissing
>> Harry Lewis - IBM Printing Systems
>> ---- Lloyd wrote----
>>pmp-owner at pwg.org on 10/23/97 05:52:42 AM
> Please respond to pmp-owner at pwg.org @ internet
> To: Harry Lewis/Boulder/IBM at ibmus> cc: pmp at pwg.org @ internet
> Subject: Re: PMP> hrMIB Extensions and Top25 Corrections
>> Harry,
>> I would like to hear some feedback from people developing host printer
> management applications that are using the Printer MIB. Over the past
> month or so, we have had several host applications spring up that are
> using the Printer MIB for managing printers. Is this an area that is
> broken in the Printer MIB? If yes, does this change fix the problem?
> If we incorporate this change, will a host application developed
> against RFC 1759 still work correctly when run with a printer that
> has incorporated this change?
>> Lloyd Young
>> ---------- Original note ---------
>> harryl%us.ibm.com at interlock.lexmark.com> 10/22/97 07:21 PM
>> To: pmp%pwg.org at interlock.lexmark.com> cc: (bcc: Lloyd Young)
> bcc: Lloyd Young
> Subject: PMP> hrMIB Extensions and Top25 Corrections
>> I recently made an observation regarding the mandated combination of
> OFFLINE with SERVICE REQUESTED in the "Top 25" alert table definitions.
> I don't think my point came across too clearly (as there has been little
> or no response). At the risk of being "lengthy", please let me attempt
> to clarify and make a proposal.
> BACKGROUND:
> ----------
> 1. RFC1759 utilizes a combination of status indications from the hrMIB,
> including hrDeviceStatus, hrPrinterStatus and
> hrPrinterDetectedErrorState
> to derive "Overall Printer Status" as defined in the table in section
> 2.2.13.2 (March 1995 version).
> 2. Of all the "Overall Printer Status" definitions, only OFFLINE (and
> moving offline) correspond directly with a specific
> hrPrinterDetectedErrorState bit.
> 3. The semantic of OFFLINE has never been adequately defined in the
> printer MIB. Some devices do not incorporate the concept of
> ONLINE/OFFLINE.
> 4. In it's definition of the hrPrinterDetectedErrorState, the hrMIB
> (unfortunately) mandates correlation between the bits and hrDeviceStatus
> Condition Bit # hrDeviceStatus
> 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)
> As such, there is no "No Paper Warning" as might occur when one tray
> of n linked is exhausted, or no "Service Requested Down" as might
> result from a fuser overheating.
> 5. In conjunction with the development of the "Top 25" alerts, a
> proposal was made to extend the hrPrinterDetectedErrorState bits
> as follows
>> Condition new hrBit Today's mapping
> --------- ------ ---------------
> inputTrayMissing 8 noPaper or lowPaper
> outputTrayMissing 9 Service Requested
> markerSupplyMissing 10 noToner
> outputNearFull 11 Service Requested
> outputFull 12 Service Requested
>> PROBLEM:
> -------
> 1. As it stands, the "Top 25" alerts resort to utilizing
> uninformative, inappropriate or ambiguous combinations of
> hrPrinterDetectedErrorState bits to overcome the constrained
> associations described in 4 (above) or compensate for the
> fact that proposal 5 (above) has received little or no
> consideration by the keepers of the hrMIB.
> 2. The areas in question are:
> row 5 - Initial Power Up - hrBit = offline
> row 9 - Input Tray Missing (Critical) - hrBit = noPaper
> row 11 - Output Tray Missing (Critical) - hrBit = serviceRequested +
> offline
> row 12 - Output Tray Full (Critical) - hrBit = serviceRequested +
> offline
> row 13 - Marker Supply Missing (Crit) - hrBit = noToner
> row 16 - Output Tray Almost Full (Warn) - hrBit = serviceRequested
> row 18 - Input Tray Missing (warning) - hrBit = lowPaper
> row 19 - Input Tray Empty (warning) - hrBit = lowPaper
> row 20 - Output Tray Missing (warn) - hrBit = serviceRequested
> row 21 - Output Tray Full (warn) - hrBit = serviceRequested
> 3. OF THESE, ROWS 5,11 AND 12 ARE THE MOST SIGNIFICANT IN TERMS OF
> MISLEADING INFORMATION, BECAUSE THEY MANDATE THE INDICATION OF
> OFFLINE, A PRIMARY "OVERALL PRINTER STATUS", WHEN THE PRINTER
> MAY NOT BE OFFLINE (AND, INDEED, SOME PRINTERS CANNOT GO OFFLINE).
> 4. Rows 9,13,16,18,19,20 and 21, are "less than informative".
>> PROPOSAL
> --------
> 1. Acknowledge that it is beyond our control to see that the hrMIB will
> ever be updated.
> 2. Define a new OID in prtGeneral
> -- "prtDetectedErrors" hrMIB extension object.
> --
> -- This object extends the octet string originally defined in the
> hrMIB (RFC1514) and is intended to operate in concert with the
> hrMIB object hrPrinterDetectedErrorState. See Appendix E -
> Overall Printer Status Table, for information on the use of
> this object in conjunction with printer conditions and alerts."
> --
> -- Future extension of printer state "bits" will occur in this, printer
> -- MIB OID, not in the hrMIB.
> prtDetectedErrors OBJECT-TYPE
> SYNTAX OCTET STRING
> ACCESS read-only
> STATUS mandatory
> DESCRIPTION
> "This object represents additional error conditions
> detected by the printer which were not included in
> the initial hrMIB definitions or
> hrPrinterDetectedErrorState. The error conditions
> are encoded as bits in an octet string, with the
> following definitions:
> Condition Bit # hrDeviceStatus
> inputTrayMissing 0 warning(3) or down(5)
> outputTrayMissing 1 warning(3) or down(5)
> markerSupplyMissing 2 warning(3) or down(5)
> outputNearFull 3 warning(3) or down(5)
> outputFull 4 warning(3) or down(5)
> inputTrayEmpty 5 warning(3) or down(5)
> Reserved 6 n/a
> Reserved 7 n/a
>> If multiple conditions are currently detected and
> the hrDeviceStatus would not otherwise be
> unknown(1) or testing(4), the hrDeviceStatus shall
> correspond to the worst state of those indicated,
> where down(5) is worse than warning(3) which is
> worse than running(2).
> Bits are numbered starting with the most
> significant bit of the first byte being bit 0, the
> least significant bit of the first byte being bit
> 7, the most significant bit of the second byte
> being bit 8, and so on. A one bit encodes that
> the condition was detected, while a zero bit
> encodes that the condition was not detected.
> This object is useful for alerting an operator to
> specific warning or error conditions that may
> occur, especially those requiring human
> intervention.
> ::= { prtGeneralEntry 20}
> 3. Correct the "Top 25" table as follows:
> row 5 - Initial Power Up - hrBit = (0x0)
> row 9 - Input Tray Missing (Critical) - hrBit = inputTrayMissing
> row 11 - Output Tray Missing (Critical) - hrBit = outputTrayMissing
> row 12 - Output Tray Full (Critical) - hrBit = outputFull
> row 13 - Marker Supply Missing (Crit) - hrBit = markerSupplyMissing
> row 16 - Output Tray Almost Full (Warn) - hrBit = outputNearFull
> row 18 - Input Tray Missing (warning) - hrBit = inputTrayMissing
> row 19 - Input Tray Empty (warning) - hrBit = inputTrayEmpty
> row 20 - Output Tray Missing (warn) - hrBit = outputTrayMissing
> row 21 - Output Tray Full (warn) - hrBit = outputFull
> 4. Define OFFLINE as follows and add this definition to the printer MIB
> "The OFFLINE state may be implemented differently on various devices
> and, indeed, some devices may not implement OFFLINE at all. In
> general, if a device has an OFFLINE state it MUST indicate, via
> hrPrinterDetectedErrorState bit (2) when this state has been entered