The meeting was called to order by Lloyd Young at 1:05 PM CST on
April 8th at the Peabody Hotel in Memphis, Tennessee.
The Printer MIB Working Group presently developing two printer
related MIBs. The first is the Printer MIB and the second is the
Job Monitoring MIB.
The Working Group Chairs are:
Chris Wellens firstname.lastname@example.org
Lloyd Young email@example.com
1. Review of the Printer MIB interoperability testing.
2. Report on status of the Job Monitoring MIB.
The Printer MIB is presently a Proposed Standard and the current
efforts are to advance to Draft Standard. One of the prime
requirements for advancement to Draft Standard is to demonstrate
interoperability. This test was performed in February 1997. A
brief report was presented by Lloyd Young as to the test methods
and results of these tests. A copy of Interoperability test
results was provided to all interested attendees.
1. Static variables were tested using the Castle Rock SNMPc
2. Dynamic variables used the Castle Rock SNMPc product for
3. Additional testing was performed using the InterWorking Labs
MIB Test Suite.
4. Application testing used:
Underscore's Print Alert
QUESTION: Why was Castle Rock's package used instead of OpenView
ANSWER: This package was recommend by several of the
participating vendors and Castle Rock provide free licenses for
The current schedule for completing the Printer MIB:
- Last comments must be submitted by May 2
- New Internet draft ready for Working Group review by May 16
- Final comments cutoff date is May 30
- Final draft submission to IESG by June 2
Job Monitoring MIB:
The current status of the MIB was presented by Tom Hastings. The
MIB has been simplified to a total of 13 objects, all of which
are mandatory. The emphasis is on a Client - Server - Printer
The MIB currently contains four groups / tables. No traps are
included in the MIB.
- The General group contains 5 objects
- The Job Id group contains 2 objects
- The Job State group contains 4 objects
- Attribute group contains 2 objects
QUESTION: Is this a Job MIB intended for servers in general or
just print servers?
ANSWER: The MIB is being designed for Printers but other
functions such as faxing could use the MIB with extensions.
QUESTION: The Job Monitoring MIB seems to be focusing on some of
the same areas as IPP. Is there any coordination between the two
ANSWER: Yes, the IPP and Job Monitoring programs are both being
developed by the same people. The Printer MIB, the Job
Monitoring MIB and Internet Printing Protocol projects are being
coordinated to insure that they are compatible.
There was an extended discussion on how the client creates the
Job Submission Id for the job. The MIB now specifies a Client
generated 32 octet Job Submission Id which is really only quasi
unique. The Working Group believes that defined methods for this
identification string result in an extremely low probability of
duplicate strings. There was some concern in the audience that a
100% guarantee of uniqueness must be assured.
Keith Moore expressed concern that SNMP should not be used for a
User application. The Working Group is aware that SNMP is not
the ideal solution for this problem. Long term IPP will provide
a significantly better solution. This is intended to be a
solution for current legacy systems.
QUESTION: If the client job can be sent to one of several
printers, how do I determine which printer received the job?
ANSWER: The Job MIB has two objects jmPhysicalDeviceName and
jmPhysicalDeviceIndex which specify which physical device received
QUESTION: How does the submission id get to the printer?
ANSWER: The job submission can be either a header or wrapper to
the job data or imbedded with the PDL of the job. The Working
Group believes that the method will be vendor specific and will
also be unique to the various hardware / software platforms that
Steve Zilles commented about the definition of the Attribute
Table attributes being Conditionally Mandatory. He was not sure
as to the meaning of Conditionally Mandatory in this case. The
MIB specification needs to fully define this meaning.
The meeting was closed by Tom Hastings at 3:00 PM CST.