The August PWG meeting was held in Toronto, Canada during the week of August 17th. A summary of the status and activities of various PWG subgroups was presented, Wednesday morning, and is reported below.

Next meeting...

September 28 - October 2

Savannah, Georgia

Accommodations T.B.D. (possibly make your own)


PWG officer elections took place per the new PWG process. The following officers were elected into a 2 year term.

Chairman - Don Wright - Lexmark

Vice Chairman - Harry Lewis - IBM

Secretary - Lee Farrell - Canon

The Savannah meeting will follow the standard agenda except there is a possibility that MIBs (Tuesday night) and UPD (typically Friday) will be swapped - stay tuned.

Monday/Tuesday - P1394

Tuesday evening - MIBs and MIB related (PMP, JMP, FIN) and Printer-Finisher Interface startup

Wednesday - PWG Plenary (morning), IPP (afternoon)

Thursday - Notification (morning), SDP (afternoon)

Friday - UPD (break by 3pm).

There is general overall concern about relinquishing copyright of PWG works to other standards organizations and sublet charters slowing the progress of Printing Industry standards. When the PWG drafted the Printer MIB, the IETF did not require or enforce a copyright notice. Now, with IPP, the work of the IPP project is considered property of the IETF because we are so chartered. There are circumstances wherein this is fine, but, in general, the PWG feels this type of arrangement can prevent us from controlling the standards we create and maintain.

The PWG process document is complete and now in effect. UPD is one of the first working groups to completely follow this process. They have observed that templates are needed for Charter, Requirements etc.

Printer/Finisher Interface BOF

This is a "budding" workgroup, spawned from Finisher vendor participation in the Finisher MIB project. The observation is that standardization of a physical, transport and command interface between the printer and in-line finisher would enable finisher vendors to focus on the expertise of bringing new devices and finishing features to market with less effort focused on customizing the printer interface. Also, printer vendors and customers would, ultimately, be provided with greater choice.

Toronto represented the first BOF to investigate formation of a PWG working group (PFI?). There was good discussion Tuesday evening, but few Finisher vendors were involved. DuploUSA intends to publish a strawman set of requirements and possibly a draft white paper on the 3 areas of focus - physical, transport and protocol/commands. It is their intent to post this to the FIN list 2 weeks prior to Savannah and try to gain a slot on the Savannah (and subsequent PWG) agenda. If this group forms, it will need a reflector, FTP folder and permanent agenda slot during 1999.

Printer MIB

There are questions about how to progress the Printer MIB from Proposed to Draft standard since there were several corrections made following the Stardust bakeoff. Some think an entirely new interoperability test is required. Others consider the current Printer MIB the result of interoperability testing and actual application experience which is of greater significance. Since progress within the IETF has been so slow, a proposal was adopted to resubmit the new Printer MIB as a Proposal rather than Draft. While there seems to be little reason that the Printer MIB should not be progressed to Draft status (in terms of support , stability and interoperability, what MIB is more eligible?)... this seems to be a way "around" the IETF roadblock. All parties present said they would be just as inclined to implement to a new Proposed standard as a Draft standard of the printer MIB - so what are we waiting for?


The Job MIB is a completed PWG standard which is highly correlated with the IPP print job attributes.

Tom Hastings introduced a proposal to enhance Job MIB accounting based on a subset of "activities". As is, the Job MIB may be used, today, for accounting of job attributes but some jobs may result in sub-processes such as COPY, SCAN or FAX. Tom's proposal refers to these sub-processes as "activities" and represents a straightforward approach to subsetting. Since the Job MIB has already been criticized for it's liberal use of optional attributes, an alternative approach, adding only one new attribute (jobParentID) was proposed in response to Tom's submission. Tom to investigate and modify proposal for Savannah.

Interest was expressed by several parties in conducting a Job MIB interoperability test within a 6 month time frame.


The P1394 group has defined a print transport, command set and config ROM for printing over 1394 serial. Interoperability testing of their specification is anticipated in the January time frame. Contact to participate. The config ROM architecture requires an Organization Unique ID (OUI). There is a proposal for the PWG to collect the $1000 fee from members, and subsequently own and manage the OUI. Contributing members will receive address blocks in the PWG OUI space. See posting to the PWG e-mail for further details.

Universal Printer Driver

UPD reviewed the charter, scope and direction. The ideal goal would be to create one set of printer description attributes for all major datastreams (raster and vector based). Sandra Matts (HP), is chair. The charter and a set of requirements are expected to be ratified in Savannah.

IPP - Internet Printing Protocol

IPP is holding it's breath until the IETF meeting in Chicago the last week of August. Although the IEGS feedback is considered incomplete, the IPP working group has responded to everything heretofore requested by the IESG including a default port and a new IPP scheme. A security scheme on the URL, devised by Xerox, was not reviewed as it is not our understanding that the IESG is seeking ad-hoc security devices. There is debate and dissension regarding the degree to which the IETF requirements will be embraced. For instance, IETF recommendations were modified to indicate that the IPP scheme SHOULD be adopted rather than SHALL. It is unclear whether everyone understands the significance of a separate default port (631 - i.e. is it mandatory that every IPP printer ship with the default port enabled). These issues are expected to be clarified at the IETF meeting in Chicago. If the IETF accepts the PWG drafts at the meeting in Chicago with little or no change, the PWG will have been successful in achieving a standards track project with the IETF. If we exit Chicago with another laundry list of requirements or undefined closure, the IPP group will consider the June 30 drafts a completed PWG specification and standard.

Interoperability testing of the June 30 drafts will be hosted by Microsoft the week before Savannah. The Savannah IPP meeting will be used to discuss the "bakeoff" results. The interoperability test will be attended only by those with prototypes to test, test tools to offer or those recording the event for the PWG. The test will not be a "public" or "press" event but, rather, is intended to uncover any misunderstandings that might have occurred from interpretation of the specifications. Each registered IPP test team will be provided (by Microsoft) with 3 Ethernet 10Based-T drops. These are intended to support one client, one printer and one network traffic analyzer. Further details are available on the IPP reflector, FTP and WEB sites.

Work continues on an IPP Implementors guide, offering concrete advice to implementers. Entries were reviewed with an attempt to resolve any issues that were present. This effort is ongoing. One of the major, unresolved issues, to date, is that of HTTP1.1 and it's requirement to support chunking. While it is clear that HTTP1.1 implementations are required to accepted chunked encoded data (but not necessarily to emit chunking), there are, evidently, some off-the-shelf web servers that claim HTTP1.1 compliance but do not handle chunked data. This will make for interesting interoperability testing.

Microsoft has proposed several new optional IPP operations. These were reviewed and , for the most part, accepted as straight forward except for the notion of and distinction between Restart and Reprocess. There is need for a great deal more clarification regarding the effects of these operations on accounting. There was tentative agreement to keep Restart (not Reprocess) and to use JobStateReasons (Hold and Pending) to distinguish accounting methods. See IPP minutes for complete details. While IPP operations like PAUSE and PURGE appear straightforward, they bring IPP out of the end-user arena and squarely into administration which requires close examination of the span of control of IPP, itself. For example, if the operation IPP-PAUSE-PRINTER were invoked, what effect would we expect on the server or device with respect to other print protocols like LPR? In an actual print device, IPP will likely be only one of many supported print protocols. Will it become the overriding administration and control vehicle? For the proposed IPP- PURGE-JOBs operation, should all jobs be purged (even those submitted via other protocols)? Tentative answer - Yes. Should the "accounting history log" be erased? Tentative answer... no and this is outside the scope of IPP, currently. Xerox also proposed 2 additional Admin operations (Accept and Reject jobs).

There is work going on to investigate IPP/IFAX mapping and the IETF is interested. Such a mapping would facilitate implementations that want to support both PRINT and FAX but do not necessarily want to implement legacy versions of either. Ron Bergman provided a first pass evaluation which shed light on several addressing, resolution and compression issues. More work needs to be done in this area.

The IPP proposal for MIB access was not discussed in great detail. This topic will be focused on when SDP is discussed.

Server-to-Device Protocol

This topic was postponed pending final status of IPPv1. The topic will be discussed in Savannah.


This topic was not discussed in great detail.. As a follow-on to IPP and a link to the SDP project, this topic is somewhat on hold until the status of IPP is determined. There was a short discussion about an IETF draft on the Internet Standard Event Notification scheme that tries to make use of the "beeper network" as a notification model. Further investigation is necessary to determine how appropriate this might be for IPP which will encompass device and print activity notifications. Notifications are expected to be re-engaged in Savannah.

Finisher MIB

The base Finisher MIB is complete and has exited PWG "last call". The Finisher MIB attributers will partially form the basis for the new proposal working group investigating a printer-finisher standard interface.