IPP> Withdrawn - IPP MIB

IPP> Withdrawn - IPP MIB

IPP> Withdrawn - IPP MIB

Ira Mcdonald imcdonal at sdsp.mc.xerox.com
Thu Oct 7 10:38:53 EDT 1999

Hi folks,

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

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

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.

- Ira McDonald
  High North

More information about the Ipp mailing list