Editor's Note: These minutes have not been edited. Printer MIB Working Group IETF Meeting Minutes 4/8/97 Reported by: Ron Bergman 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 chrisw@iwl.com Lloyd Young lpyoung@lexmark.com PLANNED AGENDA: 1. Review of the Printer MIB interoperability testing. 2. Report on status of the Job Monitoring MIB. Printer 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 product. 2. Dynamic variables used the Castle Rock SNMPc product for Alerts. 3. Additional testing was performed using the InterWorking Labs MIB Test Suite. 4. Application testing used: IBM's NetCube Underscore's Print Alert QUESTION: Why was Castle Rock's package used instead of OpenView or others? ANSWER: This package was recommend by several of the participating vendors and Castle Rock provide free licenses for the test. 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 configuration. 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 projects? 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 the job. 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 are supported. 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.