Subject: PMP> Re: printer MIB - RFC 1759 - comments and questions.

From: Don Wright <[email-masked]>
Date: 19 Mar 97 8:05:52 EST

Thanks for your interest in the printer MIB.  There is an active 
group working on an update to the MIB.  The issues you bring
up have been discussed within the group (in many cases forever.)
The chair of the group is Lloyd Young ([email-masked].)

I would suggest you check out the Printer Working Group's WEB
page at www.pwg.org.  There are several project pages available, 
instructions on how to subscribe to the mailing lists as well as 
a hyperlinked copy of the more recent mail.  There is also an
ftp server at ftp.pwg.org with contains the latest draft of the MIB:

ftp://ftp.pwg.org/pub/pwg/pmp/drafts/pmib_031897.txt

I am forwarding this note to the mailing list ([email-masked]) and
I am sure you will get plenty of responses.

Don

To: Don Wright, hastings%cp10.es.xeros.com @ interlock.lexmark.com @ SMTP, 
jgyllens%hpdmd48.boi.hp.com @ interlock.lexmark.com @ SMTP, 
rlsmith%nb.ppd.ti.com @ interlock.lexmark.com @ SMTP, szilles%mv.us.adobe.com @ 
interlock.lexmark.com @ SMTP
cc: david%munnari.OZ.AU @ interlock.lexmark.com @ SMTP, djenkins%hbmuk.com @ 
interlock.lexmark.com @ SMTP, psmartt%ozemail.com.au @ interlock.lexmark.com @ 
SMTP 
From: peters%pacsemi.oz.au @ interlock.lexmark.com (peter smartt) @ SMTP
Date: 03/19/97 04:53:34 PM
Subject: printer MIB - RFC 1759 - comments and questions.

Ron, Don, Tom, Stephen, Joel,

Let me introduce myself.  My name is Peter Smartt, and I am a consulting 
software engineer for Pacific
Semiconductor P/L, a firm of laser printer controller designers and software 
integrators based in Sydney,
Australia.  I am currently working on an SNMP implementation, and I have been 
using RFC 1759 as a guide.
I have a number of comments and questions I would like to raise concerning RFC 
1759 and the printer MIB.

1) What is the current status of the printer MIB?  The copy I have is now 2 
years old, and I would like
to know if there is a newer version around, or if there is likely to be one in 
the near future. Also is
it likely to become an experimental MIB or is it already a "real" MIB?

2) I am unclear about some aspects of the definition of Sub-unit Status. What 
is the difference between
Active and Busy ?  What state would be used to describe a sub-unit that is 
unavailable because another
sub-unit of the same type is active (or should that be busy). For instance, 
what is the state of an input
paper tray while another paper tray is being printed from, or a serial port 
while another serial port is
receiving data.  Also many sub-units seem by nature very hard to categorise 
according to the definition
of sub-unit status (data channels being a prime example - what are they when 
they have full input
buffers), or how does sub-unit status describe whether they have timed out? 
(Another problem with data
channels is that by sending a get request, the SNMP is immediately activating 
(or busying ???) the
channel that gets the message, and standby-ing (or idling or unknown-ing) all 
the other channels.)

With most sub-units, I have also taken the approach that the status of the 
whole printer is commonly
part of the status of the sub-unit (for instance, if the printer has a paper 
jam or is off-line, then
most of its sub-units would be unavailable and would carry the same alerts as 
the whole printer), so I
check the whole printer first, then just add in the results of a check of the 
sub-unit. Is this OK??

On reflection, would it be better to drop sub-unit status and define a separate 
status enumeration that
makes more sense to each sub-unit?

3) I note that the group seemed to have problems with the concept of "simple 
alerts" and how long they
should persist for. Eventually it opted for removing them on a rotating basis.  
With respect, I feel the
concept itself is flawed; that is why it was difficult to conceive an 
implementation.

I don't believe it should be necessary to post an alert because of an event 
such as a change of paper
size (or any other "simple alert").  It should be sufficient if the SNMP 
management application regularly
poles the printer for paper size (or whatever else it wants to know). This 
should be no more arduous than
poling for simple alerts.  This would also greatly simplify the implementation 
of the alert table.

4) Two major printer components seemed to be absent from the MIB. These include 
a) a Buttons group (which
would be similar to console lights except that it would have more information 
on the combinations of short
and long presses, and multiple simultaneous button presses).  There might be 
justification for issuing a
non-critical alert, or in some cases a trap, if a button is pressed. At least 
this would allow an operator
or system manager to know that someone was at the printer. Possibly a long (125 
character) verbal
description of each button should also be allowed for. b) A storage table 
showing how much SRAM is
installed, whether the printer has a hard disk and how big it is, NVRAM, flash 
etc. A simple table of
(enumerated) storage type, capacity and (optionally) percentage full should be 
sufficient.  I note that
there is provision for a system resources table, but there is no detail given.

5) Is there really a need to have a media path group? I have worked for a 
number of laser printer
manufacturers, and many have managed fine, and the code has worked fine, 
without using the concept of
a media path. It is easy to specify the requirements of a print job (in terms 
of input source, output
source, orientation, paper size, duplexing mode) without resorting to this 
media path concept. If a
manufacturer has built his code around the concept, then that's fine, but I 
don't see why it needs to
be included as part of the MIB, or why the SNMP manager would be interested in 
it. (I an pleased that the
MIB is only concerned with duplexing mode, and sets default paper source and 
destination separately).

6) Most of my other comments are matters of detail.

prtGeneralConfigChanges - I can't see the purpose (or role model) of this 
object, and there would be
problems in implementing it to persevere across power cycles. Most non-volatile 
storage devices (such as
ZRAM) only have a limited number of writes, and implementing this object to 
cause NVRAM to be written
every time a paper tray was removed could easily cause this limit to be reached.

prtInputType - I feel there should be an enumerated type for an envelope 
feeder. This is quite a common
input source, and is only covered by "other" at the moment.

prtMarkerSuppliesLevel - Most print engines can detect "Toner Low" or "No 
Toner", but can't measure the
number of tenthsOfGrams of toner present. The MIB specification makes no 
provision for differentiating
TonerLow from any of the other states, even though it is quite an important 
state to know about. I am
not sure what I should return if the "Toner Low" state has been detected.

prtConsoleOnTime and prtConsoleOffTime - On many printers, leds can be directed 
to flash slowly or
quickly or not at all, depending on the overall state of the printer (or some 
component). Although
the answer to this request is clearly not world-shattering, I think some 
implementation guidance is
still needed.

prtConsoleDisable - some printers may not permit the console to be disabled. Is 
it acceptable to not
implement this object, or to implement it so that issuing a "disable" set 
request has no effect, or
returns an error ?

prtChannelType - seems to have a lot of obscure channels, while missing some 
very common ones (like
TCP_IP, token-ring, SNA, quic, Wang etc.).

If I have any more comments as I continue the implementation I will mail you 
again.

Thank you for your trouble. If I should be consulting other sources I would be 
pleased if you could
refer me to them. Otherwise I look forward to hearing from you.

Regards

Peter Smartt.