Finisher MIB MInutes - Atlanta 9/19/97 Attendance: Ron Bergman - DataProducts Mabry Dozier - QMS Lee Farrell - Canon Tom Hastings - Xerox Scott Isaacson - Novell Rick Landau - Digital Equipment Harry Lewis - IBM Printing Systems Bob Pentecost - HP Yuyi Sacchi - Japan Computer Industry Bill Wagner - DPI/Osicom Lloyd Young - Lexmark Introduction: The 2nd meeting of the Finisher MIB working group of the PWG was held in Atlanta on Friday, 9/19 from appx 2 to 3pm. The following officers presided: - Chair - Harry Lewis - Editor - Ron Bergman - Secretary - Open (the FIN working group is seeking a reliable secretary) Scoping the Finisher MIB The primary goal for this meeting was to agree on the scope of the Finisher MIB project. Ron Bergman assembled a list of all Finisher MIB requirements which have been expressed, so far, and presented them in a single document. Requirements were derived from the Printer MIB, Jeff Rackowitz's e-mail, Harry Lewis's e-mail, DPA and the DMTF (LMO) Finisher MIF. By far, the majority of Finishing attributes appear to be covered by LMO. It appears the LMO Finisher MIF will make an excellent starting point for a PWG Finisher MIB. Although LMO has a "high-end" production finishing focus, it was developed in concert with the DMTF Printer MIF. The first approach to writing the Finisher MIB will be to convert the DMTF Finisher MIF to a MIB. We do not necessarily have the goal, however, to precisely align the MIF and MIB. Issues: The following issues were discussed and concluded as follows: - Should the Finisher MIB address "standalone" or detached Finishers? - No. The Finisher must interact directly with the printer via some signal interface. - Should the Finisher MIB really be a Pre/Post processing MIB. i.e. should it address Preprocessing as well as Finishing? - There are no known requirements to address Pre-Processing at the time. - Should the Finisher MIB be entirely passive (like the Job MIB) or should it allow some control via r/w attributes? - The Finisher MIB should behave more like the Printer MIB, covering Finisher status, events and configuration, including the management of default settings via r/w objects. - How should the Finisher MIB relate to the Printer MIB? - There are two options. A separate Finisher MIB which references the Printer MIB, or augmenting the Printer MIB, itself, with a new Finisher group. Review of RFC1759 shows that the later has been considered the most appropriate path since the initial development of the Printer MIB. - In the latest draft of the Printer MIB, the following was added to the alert textual conventions specifically with a Finisher MIB in mind: - PrtAlertGroupTC ::= TEXTUAL-CONVENTION -- This value is a type 1 enumeration for values in the -- range 1 to 29. -- Values of 30 and greater are type 2 enumerations and are -- for use in other MIBs that augment tables in the Printer -- MIB. Therefore, other MIBs may assign alert codes of 30 or -- higher to use the alert table from the Printer MIB without -- requiring revising and republishing this document. - Is it essential to associate Finishing capabilities with specific printer Output subUnits, or is it sufficient to associate Finishing functions with the printer as a whole. - Finishing capabilities must be associated with specific outputs. There are real examples of certain finishing operations available for some outputs and not others. - What if there is more than 1 finishing function or finisher associated with an Output. Is it necessary to define the cascade nature of multiple Finishers? - No. Each Finisher or function associated with an Output should be reflected, but the exact configuration or sequence of finishing operations will not be addressed. - LMO accommodates "Model/Manufacturer/SN" for Finisher Inputs and Outputs, mimicking the Printer MIB model. Would we limit this to just the overall Finisher? Eliminate it all together? - Undecided. General consensus seemed to lean toward limiting to overall Finisher, but this was not definitive. - In DMI, the Finisher Features table may be sparse, to address only the features present. Direct mapping to SNMP would require that every possible feature be present in the table even if only one function (i.e. Staple) were actually available. Thus, the structure of the SNMP MIB cannot be exactly the same as the MIF. - Do we need an IETF BOF? - In general, it seems the IETF is much less interested in placing MIBs on the standards track today than they were 4 years ago when we started the printer MIB, so, probably not. If the Finisher MIB extends the Printer MIB directly, however, a BOF could be required. - We need to clearly document what we are trying to accomplish with the Finisher MIB. Assignments Ron will work on MIB structure and Harry will draft the Purpose, Scope and Model documentation. Ron will post the Requirements list used in Atlanta. Anyone who thinks the overall list of Finishing attributes and functions is incomplete, excessive etc. should initiate e-mail discussion to that effect between now and the October meeting. Next Meeting The next meeting will be in Boulder, the last week of October Friday, October 31, in Boulder. Current level of the Finisher MIB draft will be reviewed. Any new requirements or adjustments in scope will be discussed.