INTERIM_MEETING_REPORT_ Reported by Don Wright/Lexmark and Joel Gyllenskog/Hewlett-Packard Minutes of the Printer MIB Working Group (PRINTMIB) An interim meeting of the PRINTMIB Working Group was held in SnowBird, Utah on 22 February 1994. Discussion Topics o Model - Component sets, objects - Two alert tables or one - Alerts summary or new information - Terminology o Multifunction ``printers'' o Medium size:ENUM or dimension o ``Interfaces'' connection or channel o MIF to MIB translation o When does a change take effect o Additional values for interpreter ENUM o IEEE 1284.2, 1284.3 o Editor o Margins on input o Simple-text o Media names o Schedule o Mapping media to inputs o Which objects are we importing from other MIBS - what about MIF o Operator console o Localization o Language codes o Bit fields for status Report on 1284.2, 1284.3 Larry Stein reported on the first meeting of the 1284.2 and 1284.3 study groups. o 1284.2 is the test, measurement and certification of the 1284 standard o 1284.3 is the extensions to 1284 (BIOS, etc.) Anyone interested in participating should contact Larry Stein at +1 805 726 4420 (voice) or +1 805 726 4438 (fax). The EPP/1284 BBS is +1 818 878 7618. 1 The next meeting of 1284.2/3 is scheduled for 18-19 April in San Diego at the Marina Marriott. Model A discussion was held on the various ``pictures'' of the printer models. Clarification is needed on which classes correspond to the entities in the model. o Disks will be managed in the HOST MIB space (Drawing omitted from TEXT file). o System controller objects are managed by the host MIB. o The DMTF Printer Component will have groups under it such as - Host - Printer Controller - Inputs o If the DMTF does not predefine a GROUP equivalent to the HOST MIB, this group will. o Discussion on Media Path Device by combining that with the Media Path and make Media Path a table. MaxSpeedPrintUnit, MaxSpeedTimeUnit and PhyMediaUnit would not be in the table. Result: We will have a single group combining Media Path and Media Path Device. This group could have a multiplicity of Media Paths, for example: Simplex Path, Long Edge Binding Duplex Path, Short Edge Binding Duplex Path. We will have a Default Path object. o Printer Control will become General Printer and includes a table of doors with their status. o Should CRITICAL ALERTS and NON-CRITICAL ALERTS be in a single table or separate? Result: One table which means the table must include a level of criticality: - CRITICAL & WARNING. o Should there be an INFORMATIONAL level alert? No. o Mike MacKay will make a recommendation as to the names of these two alert levels. o TRAPS will only be generated when a critical alert is added or removed from the table. o SUMMARY OF ALERT TABLE CONTENTS 2 - Components - Index (monotonically increasing, without reuse) Severity Level (Other, Unknown, Critical, Non-critical) Infoclass (Other, Unknown, Untrained, Trained, Field Service, Mgmt) Group (Input, Finisher, Marker, etc.) Group Index (Index into the Group Table ID/Top Level) Location (Manufacturer assigned) Alert Code Description (Vendor defined string) - ``Index,'' ``Infoclass,'' ``Location,'' ``Alert Code,'' and ``Description'' are not in the various groups only in the alert table. MIFs vs. MIBs o Discussion on the quality of the MIF to MIB translation o Limitations on character sets for MIBs o The MIF names are the MIB names with white space removed, special characters removed, etc. o A ``component'' to DMTF is a product, to IETF it is a device. Therefore Lotus 1-2-3 installed on a PC is a component to DMTF but not to the IETF. o The DMTF is building a set of standard parts, such as the Component ID group, and will place them on a server (DMTF.COM?) o Chris Thomas talked about some of the problems of mapping MIF/MIB due to the assumption by the DMTF that it is okay to duplicate objects in MIFs. The IETF wants everyone to use existing MIB objects rather than duplicate them. o Chris Thomas expressed his opinion on whether DMI will be implemented in the printer and accessed directly. No. o Joel Gyllenskog re-iterated our desire to leverage the HOST MIB Editor o Person needs to be an expert on MIFs and MIBs o No single person really exists o HP is willing to contract with Steve Waldbusser to have his assistance in developing the MIB o Intel will have a software developer's kit for the service layer for DOS and Windows 3.1 in May. They will license their code to system vendors. 3 o Novell has now committed to providing the service layer in their Novell DOS product. o NetManage will be shipping their product with DMI support in March o Each ``group'' editor will have a foil of objects, by group for tomorrow. Bit Fields for Status o Discussion on the need for the octet defined for each group that contains the status of that group. o An alert code was added for Interpreter to indicate ``Resource Unavailable'' o A trailing edge event does not cause an alert. If a ``Cover Open'' condition is the error then when the cover is closed a ``Cover Closed'' alert is not generated. If the error is caused by a ``Cover Closed'' condition, then a ``Cover Open'' is not reported when the condition is fixed. o The status field should indicate the ``state'' of the entity. Events which are not states should not be represented by this status field. o Vendors are required to report via alerts any critical errors o Vendors are to remove warnings from alert table if space is needed to insert new critical errors o Add a configuration change counter in the General Printer group. If the vendor wants to, an entry in the alert table can be added to provide more specific information about the configuration change. o Will need to add Marking Supplies Tables o Entity status which applies to all the rows of the various group is changed from an Octet to an ENUM: 1 = Other 2 = Unknown 3 = Ready/Available 4 = Critical State 5 = Warning State 6 = Both critical and warning state 7 = On Request 8 = Unavailable 9 = Busy/Temp Unavailable 4 Interfaces o Steve Zilles presented his thoughts on the Interfaces Group. o The IETF concept of interfaces does not match the realities of printers. o New Interfaces MIB is RFC 1573. o Steve recommends we develop a Channel Group which is more closely aligned with how printers get data. o Discussion on the objects to be included in this group - Object to set/read default page description language (In the absence of explicit job control, this object specifies where to send the data received on this channel) - Object to turn on/off a channel and/or interface - Object to set/read the current job control language - Object to contain current back channel syntax (optional object) * NPAP * PS * PCL o Discussion on distinguishing the back channel information format o The boundary between page description language and job control language is very fuzzy and is job related. Since we are not going to include jobs in this MIB we are going to leave this open. o Should we add an object to the interpreter group to indicate whether the interpreter can talk back? o The group should send a list of CONNECTIONS or SERVICES to Steve like: Serial, Parallel, LPD, PServer, AppleTalk PSP Multifunction Devices o Does the existing model accommodate a multifunction device? o We recognize that there are potential issues with the current model but we have decided to not address them. 5 Interpreter o Add simple-text (assumes ASCII) interpreter type o E-mail discussion on the need to provide a field which indicates whether the interpreter uses the back channel. When do Changes Take Effect o Vendor dependent - when the vendor ``darn well pleases'' o The change will be reported back, if asked, immediately whether the change has actually taken effect or not. Language Codes/Localization o Tom Hastings made a proposal of a means of the printer identifying the list of languages support by the printer. o Would be located in the General Printer Group. o Add two objects to the interpreter table to identify the default character sets for inbound and outbound data. o Tom will clean up the proposal and send out via e-mail for inclusion in the General Printer Group Operator Console o Andy Davidson presented a proposal on objects for the Operator Console. o Issues on: - Multiple people writing to the panel - Separate code page for each line of a display - What about alerts when the panel changes or a button is pressed? - Ability to read/write a line of the display - Is an alert/trap necessary when a button is pressed - Using a full remote op panel can provide a means to access parameters, etc. that are not in the MIB. 6 - Charlie Kimber will make a proposal of how to do a full remote operator panel o Andy will clean-up his proposal and distribute on the Network. Input/Output o prtInputTable Status changed from Octet to Enum(1) o prtInputTable MediaName and MediaSize are removed and a new group is created in the input component objects that augments the input table o the changes that Ron made to prtInput - TypeExtended are OK o Are we going to include media by enumeration or by dimension? Discuss by e-mail. o Harry will update the Tables. Future Meetings The next PRINTMIB meetings will be held during the Seattle IETF. The following meeting will be during the last week of April in New Orleans. Attendees Azmy Abouased Andy Davidson andyd@pogo.wv.tek.com Jack Demcak 72210.1121@compuserve.com Neal Fischer 71024.3344@compuserve.com Joel Gyllenskog jgyllens@hpbs907.boi.hp.com Thomas Hastings hastings@hannah.enet.dec.com Jeff Johnson jeffmj@microsoft.com Theodore Kearley theodore@qms.com Charles Kimber ckimber@dcp.com Peter Leunig Harry Lewis harryl@vnet.ibm.com Jay Martin jkm@underscore.com Michael Moore Ron Norton Noga Prat noga_prat@ccm.hf.intel.com Dave Roach 76247.3164@compuserve.com Larry Stein 71514.1057@compuserve.com Koji Tashiro koji@lpd.sj.nec.com Jody Terrill jodyt@tommy.extendsys.com 7 Michael Timperman mike@lexmark.com Randy Turner rturner@qms.com F. Don Wright don@lexmark.com Steve Zilles szilles@adobe.com 8