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 (lpyoung at lexmark.com.)
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 (pmp at pwg.org) 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.