On the IPP Telecon yesterday, I explained that after my conversation
with Ron Bergman earlier this week I wish to withdraw the IPP Trap
MIB entirely and develop a MUCH simpler idea:
1) All IPP Printer events are mapped (the mapping is good) to
existing or new enumerations of 'prtAlertCode' and
delivered (for SNMP) via the Alert trap in the Printer MIB.
2) All IPP Job events are mapped to a (to be defined) extension
to the PWG Job Monitoring MIB that defines one job trap
(with optional bindings for the job-completed and job-progress
events).
I hope to write this up in the next week. The document
'IPP Notifications over SNMP' becomes almost entirely
a set of mapping tables (e.g., 'printer-config-changed'
maps to 'configurationChange' in the Printer MIB),
with one page for the proposed addition to the PWG
Job Monitoring MIB for traps.
Please recall that traps were left out of the PWG Job Mon MIB
because we had no widespread, standard way to do trap
registration and I argued (probably incorrectly) that
the SNMPv3 method (Notification MIB and Target MIB table
entries are required for a single subscription) was too
heavyweight.
But the SNMPv3 stuff is remaining stable. And IPP itself
will have excellent subscription BY JOB in-band. So now
adding a job trap to the PWG Job Mon MIB makes sense.
Harry Lewis raised this whole question yesterday. There
seemed reasonable concensus that the subscription issue
is no longer a serious problem.
Cheers,
- Ira McDonald
High North