I'd like to suggest that if anyone out there intends to respond to Peter's
questions, then please raise your hand now (via a posting to the PMP list)
to state your intentions. Otherwise, a lot of wasted time will be incurred
if more than one person spends the time to answer one or more of his
questions.
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm@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 --
----------------------------------------------------------------------
----- Begin Included Message -----
To: peter smartt <peters@pacsemi.oz.au>
Cc: "hastings%cp10.es.xeros.com" <hastings@cp10.es.xeros.com>,
"jgyllens%hpdmd48.boi.hp.com"
<jgyllens@hpdmd48.boi.hp.com>,
"rlsmith%nb.ppd.ti.com"
<rlsmith@nb.ppd.ti.com>,
"szilles%mv.us.adobe.com"
<szilles@mv.us.adobe.com>,
"david%munnari.OZ.AU"
<david@munnari.OZ.AU>,
"djenkins%hbmuk.com"
<djenkins@hbmuk.com>,
"psmartt%ozemail.com.au"
<psmartt@ozemail.com.au>,
"pmp%pwg.org"
<pmp@pwg.org>
From: Don Wright <don@lexmark.com>
Date: 19 Mar 97 8:05:52 EST
Subject: PMP> Re: printer MIB - RFC 1759 - comments and questions.
Mime-Version: 1.0
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@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@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.
----- End Included Message -----