Quick Status of the Printer Working Group Projects

The PWG has several subgroups working on projects and many additional topics of interest to consider. Wednesday, January 28 1998, in Maui, was the first meeting where a brief overview from the Chairman of each PWG project as well as limited discussion on any new topics was presented as a specific agenda item. The PWG intends to continue this process of high level project status and overview as long as it appears to be useful. Following are the minutes from this meeting.

Printer MIB Project

The Host Resources MIB working group of the IETF has finally reconvened in attempt to progress the HR MIB to Draft status. Recall that, because it cross references OIDs from the HR MIB, Printer MIB progression is thought to be limited by the status of the HR MIB. There is currently no projected completion date for HR MIB project. They will need to identify implementations, show interoperability etc. which implies they should be contacting the PMP folks. The recommendation from Lloyd and Chris (Chair and CO-Chair) is to solicit the IETF to accept the latest version of the Printer MIB with no further changes. This would result in the Printer MIB remaining in Proposed status, just like RFC1759 is today, and would place no further requirements on the HR MIB. The printer MIB would receive a new RFC number and RFC1759 would be edited to indicate that it has been superseded by the new RFC.

Harry Lewis objected on the basis of completely overlooking his proposal for extending hrPrinterDetectedErrorState bits which has been in limbo since the Stardust Labs interoperability test, waiting for some action on part of the HR MIB team. At the Boulder meeting, in October, Harry suggested adding an OID to the Printer MIB to accommodate the extension and break ties with the HR group. Later, in a December e-mail, Ron Bergman posted the idea of treating the hrPrinterDetectedErrorState bit definitions similar to enums and extending the definition in the Printer MIB without the need for a new OID. Printer MIB implementations could then make use of the new bits immediately and the HR MIB could pick them up whenever their document is updated.

Job MIB Project

The Job MIB sub-group of the PWG is preparing for release of two IETF Informational RFC's. One is the actual Job Monitoring MIB and the other is a set of Job Submission Protocol Mapping Recommendations for the Job MIB. The goal is to submit these documents to the IESG the first week of Feb 1998. Then, a 4 week IESG last call should insue. By early March, the Job MIB should be in official status.

There were 2 open issues going into the Maui meeting.

  1. PWG OID structure.
  2. Coordination with IPP - if IPP is delayed (mainly editorial issues).
PWG OID structure was resolved later in the PWG series of meetings (see minutes, below). Potential IPP delays are still unknown. Unless there are major changes, IPP and the Job MIB will remain well correlated. The next JMP meeting will open the topic of potential job notification using SNMP traps and/or other scenarios. JMP also needs to address interoperability testing.

Finisher MIB Project

The Finisher MIB is an extension of the Printer MIB which will allow remote configuration (SETs) and status monitoring of print finishing devices. There is a question about administrative functions possibly migrating away from SNMP and into IPP. At least, coordination with IPP is necessary. There is also question about SNMPv3 which adds multiple trap hosts and tighter security to SNMP. At this point, we are not mandating SNMPv3. The Finisher MIB project has made great progress in structuring a MIB which augments the Printer MIB. There will be an attempt to review definitions of Finishing attributes with actual finishing company representatives.

SENSE Notification Protocol

No status. Jay Martin (SENSE Chair) not present. It is unfortunate that we were unable to schedule a SENSE discussion in Maui because IPP is interested in considering SENSE as notification scheme. IPP may also want to look at SNMPv3 (recently published RFCs). It was noted that there are many notification protocols available today that may need to be investigated.

IPP - Internet Printing Protocol

An internal last call was established 2 weeks ago. Drafts were to go out early Jan to IESG for final review and processing. This was held up by the introduction of new ideas concerning the application of XML and new HTTP methods. IPP spent the rest of the Wednesday, in Maui, on this topic. See the IPP minutes at ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-0198.pdf for details.

Universal Print Driver

Paul Moorue reintroduced the idea of a Universal Printer Driver, this time, based on Microsoft's GPD (Generic Printer Description) printer driver syntax. This new driver technology for Windows uses a printer description file like the Postscript PPD but applies it to any raster printer (PCL etc). The result is one "universal" driver with many GPD files that enable the client build the right PDL for each printer. About 1000 printers are already described in this syntax on the NT5.0 Beta DDK. A GPD is about 30K bytes per printer.

The ASCII GPD file can express device options, limitations between features (ex. "don't allow envelopes unless AUX tray is installed" or "can't staple if media is transparency") and may be used to dynamically build the print driver UI. Settings can be grouped, for example, for the "fastest", or "highest quality". Currently, the GPD is static or manually updated. A future improvement could be to dynamically update the GPD from something like a Printer MIB database, preferable using IPP.

Microsoft is offering the syntax as a model for standardization, beyond the Windows platform. There was enough interest that an agenda item has been agreed to for the March meeting in Austin. People would like an opportunity to look at the spec prior to this meeting. Concern was expressed that, in general, job control should be migrated out of PDLs into the control of job submission languages or protocols (like IPP, PJL or the Adobe Job Ticket). Some participants were also concerned about loss of product differentiation if one Universal Print Driver were to become ubiquitous. Others wondered if it would be possible to structure the GPD in XML.

NC Printing

It was reported to the PWG that, on January 14th 1997, a meeting of the Network Computer Management Group (NCMG) took place to define the JAVA OS printing architecture. The meeting was Co-Chaired by Roger deBry (IBM) and Lloyd Young (Lexmark). Some goals the NCMG is addressing are

Roger and Lloyd participated in this meeting largely to assure coordination with IPP and other PWG efforts. The PWG needs to consider future coordination with the Open Group and whether print standards should evolve as Open Group standards should the Open Group look to the PWG to develop and manage the standards. Developing the standards within the PWG might lessen the concern of non-Open Group members of the PWG. Don Wright will post minutes of the NCMG meeting to the PWG.

IBIP

The US Postal Service had a meeting last Fall with print vendors to discuss this new method for distributing and franking postage. Most print vendors had a representative there. Not a lot of progress was made but several unforeseen issues were raised. The 1Q 1998 beta appears to have slipped to 1Q 1999. Lloyd Young (Lexmark) is coordinating the next meeting with the Postal Service and will keep the PWG informed.

OID Space

The Job MIB was rejected from the standards track by the IEGS but they recommended it be submitted as an informational RFC and gave the PWG an enterprise OID (2699) under which to register future developments. This raised an issue regarding how to structure the enterprise subtree. The options were

The basic arguments were to go flat because we are not that likely to extend the subtree and no change would be necessary to the current Job MIB OID definitions vs add some structure to plan for the future. The resolution was to add structure by functions, for example: 2699.1 = MIBs .1.1 = JMP MIB .1.2 = FIN MIB .1.3 = Printer MIB 2 2699.2 = Protocols (Examples only) .2.1 = IPP .2.1.1 = IPP Operations .2.1.2 = IPP Attributes 2699.1.1 is the only thing we will actually put into practice, initially with this new structure rippling the Job MIB OIDs.

Job MIB Traps

Initially, the Job MIB project rejected the idea of defining job traps for several reasons.

  1. We wanted to limit the scope and schedule for the project to an achievable level.
  2. We did not want to upset IETF and didn't think they would like the idea
  3. We thought SENSE might provide the job event notification solution.
In final analysis, several Job MIB prototypes or private SNMP based job management implementations have admitted to using private traps to enhance their solution. Now, we are proposing time on the agenda in Austin and, possibly, continuation of the JMP project, to investigate a standard job trap architecture. Job events which might be handled via traps are JobStart, JobComplete and JobError. We will schedule time on the Austin agenda to kickoff this discussion. It is recommended that any vendor who wants to consider sharing their approach have a presentation. Ron Bergman (Dataproducts, JMP Chair) will write up a charter addendum to JMP and publish via e-mail.