[For consideration this week at your PWG monthly meeting in Alaska -
now aligned with the latest IPP Notifications Model of 11 August 1999 -
but w/out 'job-complete' and 'job-progress' extra attribute bindings.]
For IPP Notifications over UDP (via SNMPv1, SNMPv2, or SNMPv3), I've
revised the *very* small IPP MIB and posted it on the PWG server at:
This MIB contains the following SNMP object groups:
Printer - 11 columnar objects (including 5 counters)
(Mandatory) (language, name, state, state reasons, state message)
Printer URI - 3 columnar objects (URI, authentication, security)
(Mandatory) (models 'printer-uri-supported', etc., in flat tables)
Event - 12 leaf objects
(Conditionally (printer/URI indices, trigger event, job bindings)
Mandatory) - 2 SNMP traps w/ a few optional bindings
This MIB compiles without errors or warnings with Epilogue Emissary 7.0
and includes MODULE-COMPLIANCE and OBJECT-GROUP macros (conformance).
This MIB follows the 'Draft Standard' SNMPv3 MIBs (RFC 2571-2575) and
conveys all text in the 'UTF-8' charset (ISO 10646 / Unicode in a stream
encoding that is file-system and legacy programming language safe) via
the textual convention 'SnmpAdminString' (imported from RFC 2571, the
SNMP Framework MIB), since all IPP clients and printers MUST support
This MIB supports fast IPP Printer discovery via SNMP (simply broadcast
an SNMP GetNext for 'ippPrinterName' to find all supporting systems).
Because the (mandatory) Printer group contains five basic counters
(connections, requests, errors, warnings, notifications) as well as the
printer name, state, and state reasons, this MIB arguably satisfies the
'appropriate technology' criteria for IPP Printer network management
(w/out introducing the WWW Services MIB, RFC 2594, or other overkill).
- Ira McDonald
High North Inc
PS - [switch on PWG parochial mindset]
Also note, since IETF IPP and PWG Job Monitoring MIB are fully aligned,
the job-level trap in this small IPP MIB constitutes a clean job-level
trap augmentation for the PWG Job Monitoring MIB.