Minutes of IPP Working Group Meeting
December 16-17, 1998
Meeting Attendees
|
Richard Shockey |
<consultant> |
|
Patrick Powell |
Astart |
|
Maulik Desai |
Auco |
|
Nick Webb |
Auco |
|
Katsuaki Sekiguchi |
Canon |
|
Lee Farrell |
Canon Information Systems |
|
Michael Yeung |
Canon Information Systems |
|
Ron Bergman |
Dataproducts |
|
Greg LeClair |
Epson |
|
Mike Moldovan |
Genoa |
|
Amar Rajan |
Genoa |
|
Brian Batchelder |
Hewlett Packard |
|
Michael Wu |
Kodak |
|
Stuart Rowley |
Kyocera |
|
Don Wright |
Lexmark |
|
Hugo Parra |
Novell |
|
Charles Kong |
Panasonic |
|
Eric Random |
Peerless |
|
Randy Turner |
Sharp |
|
Bob Herriot |
Sun |
|
Tom Hastings |
Xerox |
|
Carl-Uno Manros* |
Xerox |
|
Pete Zehler |
Xerox |
* IPP Chairman
Day 1
Carl Uno-Manros opened the IPP meeting and provided the suggested agenda topics:
Given that there is (still) no Secretary, Carl-Uno asked for someone to record the Minutes. Lee Farrell volunteered. However, because of his vacation schedule, he indicated that the Minutes might not be published until January.
Unfortunately, Carl-Uno was not feeling well. He excused himself from the meeting for the rest of the day.
Review Implementer’s Guide
Tom Hastings distributed the latest update to the Implementer’s Guide. (This document is available at: "ftp://ftp.pwg.org/pub/pwg/ipp/proposed-clarifications/ipp-implementers-guide-981206-rev.pdf".)
Tom led a review of the changes to the document. He explained the contents of Table 1, Summary of Operation Attributes. He pointed out that the words "Optional" and "Required" need to be qualified whether they apply to the Client or Server, for sending or support.
Tom then read many of the changes and additions within the document to the rest of the group. However, there were very few comments or discussions.
Line 1052, Section 2.3.1.1 – There was some discussion on the use and support of UTF-8. Evidently there is still some debate about the amount of effort involved in actually supporting the character set. Tom volunteered to raise the issue on the reflector for further discussion.
Line 1098 – The document should clarify what is meant by "closest version." Specifically, a more detailed description of the version negotiation process should be included.
Line 1286, Section 2.6.1 – It was suggested that the document should recommend implementations that support UTF-8 to also advertise that they support US-ASCII.
Line 1511 – Change the text to say, "A server is not required to send a response until after it has received the client’s entire request. (Hence, a client must not expect a response until after it has sent the entire request.) However, we recommend that the server return a response as soon as possible."
Attribute Extensions
Tom Hastings distributed three documents that describe additional extensions for the "finishings", "output-bin", "pages-per-minute", and "pages-per-minute-color" attributes. These documents are available at:
It is expected that each of these documents will be published and placed on Last Call after the editing changes identified below are completed.
Finishings
Tom explained that the ‘finishings’ document provides additional enum values for the attribute. The values are based on a coordinate system for the placement of finishing operations with respect to the corners and edges of a document. The coordinate system used is based on the ISO DPA standard, and is consistent with the Finisher MIB.
It was decided to re-consider the details of the ‘saddle-stitch-single’, ‘saddle-stitch-dual’, ‘fold’ and ‘trim’ values. These four values will be removed until further discussion on their usage reaches agreement.
Output-bin
This attribute permits the client to specify into which output bin a job is to be placed. Hugo Parra pointed out that if a printer has four bins, the idea of a "middle bin" might not be clear. Tom agreed that some values might not be meaningful for all printers. He explained that devices do not need to support all values.
Bob Herriot noted that the value of ‘private’ requires a late binding, and it is very different from all the other values in its associated support and validation. He suggested that we should remove it unless there is a strong reason for including it. No one was aware of an implementation that used the ‘private’ value—so the group decided to remove it.
Bob also requested that the document should include a better explanation to distinguish the meanings of stacker and mailbox.
Pages-per-minute and Pages-per-minute-color
These attributes permit the client to determine the nominal speed for black/white and color printing. The group decided that the minimum values should be 1, not 0.
Collection Attribute Syntax
Tom Hastings distributed a document describing a "collection." (This document is available at: "ftp://ftp.pwg.org/pub/pwg/ipp/new_COL/ipp-collection-attr-syntax-981215.pdf".) He led a review of the document, which proposes a definition of an optional attribute syntax for a set of unordered member attributes.
Tom reviewed the examples of collection usage in Appendix A. Don Wright suggested that throughout Section 2, the text that refers to ‘xxx’ and ‘yyy’ should be modified to include specific examples—to better illustrate the point being made.
Randy Turner asked if this document is considered for IPP v1.0 or "IPP-NV". Tom and Bob suggested that it would be submitted as an option for IPP v1.0, but should be considered for inclusion in IPP-NV. Randy suggested that the proposal should only be considered for IPP-NV. He is aware of other activities in the IETF (e.g. CONNEG) that might be very useful for achieving similar capabilities related to the collection proposal.
It was suggested that the proposal document should be forwarded to Graham Klyne of the CONNEG WG for his review. He is currently involved in defining a "feature algebra" for manipulating aggregations of feature sets.
Security
According to Carl-Uno, the individual responsible for TLS is now considering the use of HTTP-S. Carl-Uno suggested that we could develop an IPP-S security approach that would be easily mapped to the HTTP-S scheme. It was noted that the IESG has previously indicated that HTTP-S is not a good method. However, there is some belief that the Security WG might now be allowed to do so. (As usual, it is very difficult to predict what the IESG will decide.)
Carl-Uno suggested that we should develop a separate document on IPP security. He is anxious for someone to volunteer as an Editor. He thinks that the IPP group could work on IPP-S development in parallel with the Security group activity—rather than waiting for the IESG to decide on HTTP-S.
Randy Turner listed several possible security alternatives for consideration:
Randy believes that we will have trouble getting alternative 6 accepted within the IETF. Randy recommends that we should adopt alternative 2 and 3 (without the security parameter.) It was also suggested that alternative 4 should be used—to minimize risk of acceptance.
The group pressured Randy into volunteering to write up a proposal for dealing with the security issues for IPP.
IPP Scheme
There was no discussion on this topic.
Day 2
The Use of IPP as a Facsimile Service – IFax Over IPP (IFX)
Richard Shockey presented some slides that explained the concept of using IPP as an Internet Fax (IFax) service. These were the same slides that he presented at the IETF Plenary session to both the IPP and IFax WGs.
At a high level of abstraction, one could say that Fax is similar to remote printing. According to Richard, IPP meets the test of a facsimile service. (Refer to the IFax Goals document: draft-ietf-fax-goals-xx.txt.)
Richard noted that ITU T.38 is the only other real competition to IPP. He believes that there is a reasonable chance of IPP being adopted as an ITU standard. (At the IETF session, Herman Silbiger, ITU Chairman for Fax activity, seemed willing to consider this possibility.) However, IPP would first need to be an IETF Standard before it could be referenced by the ITU.
There was an exchange of opinions on the likelihood of whether a separate port assignment would be necessary for this service. Richard believes that it won’t be necessary. Most people agree that it would be preferable to use the same port as IPP. However, several individuals pointed out that Keith Moore—and the IESG—has surprised us in the past with his opinions regarding port separation.
The group agreed on the following recommendations for IFX action items:
Richard noted that there was much interest in the IFX concept at the IETF Plenary. Keith Moore (IETF Area Director) suggested that a separate IETF Working Group should be established for this effort. Toward that goal, Richard distributed a proposed Charter for a new WG. The proposed focus of the group would be to define necessary extensions to the IPP specification to provide conformance with the legal and general practice of Fax.
During the review of the proposed Charter, Richard stressed that the IFX WG would not propose any major revisions to the IPP specification, and no revisions to the IFax specifications.
Richard indicated that he would like to get consensus on the Charter as soon as possible. He will post the draft to the IPP reflector for final comments. He will then take it to the IFax WG for their review and acceptance. Hopefully, a draft Charter can be submitted to the IETF well in advance of the next Plenary Session—and a BOF meeting can be scheduled. It is Richard’s plan to get as much of the WG Documents written and agreed to before the BOF.
It was suggested that the set of IFX document deliverables should be changed to:
Richard volunteered to be the Chairman of an IFX WG. No one else objected. He also volunteered to work on the Goals and Requirements document, but he needs other people to work on the other documents.
IPP Bake-Off
Pete Zehler announced that Novell will be hosting the next IPP interoperability test "Bake-off" on March 9-12 in Orem, Utah. March 9 will mainly be used for setting up equipment. Part of March 12 will be used for "tear-down."
Fifteen companies have already shown interest in attending: Apple, Auco, Axis, Canon, Extended Systems, i-data, IBM, JCI, Lexmark, Microsoft, Novell, Ricoh, Sun, and Tektronix. Pete will distribute the list on the reflector.
Pete says that he will issue the test plan document by mid-January.
The group identified some equipment needs for the Bake-off:
Pete identified some items for (potential) inclusion in the Test Plan:
URL
enet@
security
designator
Do we want to rank the above items for priority? Pete will distribute the above list on the reflector and request feedback by the individual companies. He will then compile the results to generate a weighted average on the priorities.
Notifications
Tom Hastings distributed the latest update of a document on IPP Event Notifications and led a review of its contents. (This document is available at: "ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notifications-very-short-981210.pdf".)
The document describes an extension to the IPP v1.0 model that allows end users to subscribe to printing-related events as part of job submission. Tom explained that the proposed events are classified as either Job events or Device events. An event subscription identifies both the event(s) of interest and the delivery method(s) and address(es) to use in sending the event notification report. There are two basic types of event reports—human consumable and machine consumable.
As part of the review, Tom explained the Model for the Job and Device event notification.
It was suggested that the "ipp-tcp-socket" name should be renamed "ipp-tcp-notify" and "ipp-udp-datagram" should be renamed to "ipp-udp-notify".
There was some discussion about whether or not two ports should be assigned—one each for both the origin and the destination. However, there was no clear consensus reached on this issue.
Several other discussion topics resulted in a few suggested editorial changes. Tom will update the document accordingly.
IPP Meeting adjourned.