Jay expressed the problems that he is having dealing with the various
implementation choices that printer MIB implementors have chosen for
generating traps when a user pulls out the tray. There are a number of
different event enums that implementors have chosen, such as:
configurationChanged(7), inputMediaTrayMissing(801),
inputMediaSizeChange(802), inputMediaWeightChange(803),
inputMediaTypeChange(804), inputMediaColorChange(805). For the draft
Printer MIB, we've even added more: subunitMissing(9) [which has the comment
tray, bin, etc has been removed], and subunitRemoved(26).
Either management applications have to deal with such diversity or we have
to tighten up conformance requirements.
In any case, application developers should read such "shopping list"
implementation choices and decide if they can live with implementations
being able to choose which ever they want. If you can live with that, then you
should speak up while we develop these MIB specifications. Be a devils
advocate on such lists of possible enums and imagine that implementors will
pick and chose, unless we write more stringent conformance requirements.
This admonition applies to the new Job Monitoring MIB particularly.
I haven't thought too hard about how I would implement a management
application using the Printer MIB events. But I would think that I would
design to expect
any possible event dealing with media and would have code that supports any
of them.
Comments?
Tom