Hope you don't mind my posting your message and my reply to the PMP list.
I've also copied the SENSE discussion list, as
> I have been in Death Valley for a few days, and out of email contact.... in
> reading your response to Gail on a different subject, you mentioned that
> your PrintAlert product is intended to monitor network printers. You had
> also mentioned that you were doing some sort of testing for a large
> customer of all the printers. So, I am wondering if you tried setting up
> the IBM, the DataProducts, and the Lexmark printers to send traps to your
> PrintAlert software, and what the results were? We know that Tektronix,
> Kyocera, and Xerox do not send traps. We know that HP is doing it a
> proprietary way. So, did you find interoperability with the remaining
> three?
Good questions, Chris. The following does not give you the kind of answer
you were looking for, but should give you some food for thought in this area.
First, to parrot the SNMP designers, "Traps are Bad." However, in our
case, the reasons traps are bad are different than that stated by the
SNMP designers. We believe SNMP traps are "Bad" because they are ill-
defined, and not because they add excessive network traffic.
Our PrintAlert product has nothing to do with traps. Why? Because our
product must be able to come and go at any time. The lack of standards
for trap registration force us to use other means.
PrintAlert is based on SENSE (another PWG project). The backend agents
(called "Publishers") talk to the target network printers, then post the
equivalent of traps (with *far* more information than Printer MIB traps,
I might add) to the SENSE server. Applications (called "Subscribers")
interested in MIB-like data (called "Publications") can contact the server
and get that data, even if the associated Publisher is not currently running;
as a result, a SENSE server can provide "disconnected service" for
entity-related information.
Subscriber applications interested in trap-like stuff contact the server
and "subscribe" to one or more "Editions" defined for a given Publication.
(An "Edition" is an abstraction used to define an arbitrary event stream.)
When an Edition Publisher discovers a relevant event has occured for the
associated Publication, the Publisher posts an Edition Event to the server;
the server then sends copies of the event to all current Subscribers.
SENSE also provides one other critical operational feature not defined for
SNMP traps: reliable delivery. Even though the SENSE protocol uses UDP
(as does SNMP), the SENSE server resends event messages to a Subscriber
until the Subscriber acknowledges receipt of the event (or until a defined
timeout has occurred or a maximum retry count has been exceeded).
Hope this brings you up to speed on how our Printer MIB-related management
application uses the Printer MIB, and how it does nothing whatsoever with
SNMP traps.
...jay
PS: By the way, it would be quite trivial to provide the ability to serve
up Printer MIB traps to an arbitrary number of management apps using
the SENSE technology. This would allow a management app to be "mostly"
SNMP-based, but use a "side channel" to a SENSE server to reliably
collect traps from a target printer.
----------------------------------------------------------------------
-- 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 --
----------------------------------------------------------------------