November 10-12, 1998

1. Meeting Attendees

Maulik Desai	Auco
Katsuaki Sekiguchi	Canon
Lee Farrell	Canon Information Systems
Toru Niki	Canon Information Systems
Don Purpura	Canon Information Systems
Michael Yeung	Canon Information Systems
Ron Bergman	Dataproducts
Bill Wagner	DPI/NetSilicon
Greg LeClair	Epson
Amar Rajan	Genoa
Shivaun Albright	Hewlett-Packard
Brian Batchelder	Hewlett Packard
Ben Brezinski	Hewlett Packard
Laurie Lasslo	Hewlett Packard
Sandra Matts	Hewlett Packard
Harry Lewis	IBM
Henrik Holst	i-data
Pierre Landau	Ikon
Yuji Sasaki	Japan Computer Industry
Michael Wu	Kodak
Stuart Rowley	Kyocera
Don Wright	Lexmark
Paul Moore	Microsoft
Hugo Parra	Novell
Ben Chun	Samsung Electronics
Fumio Nagasaka	Seiko Epson
Atsushi Uchino	Seiko Epson
Bob Herriot	Sun
James Kempf	Sun
Chuck Adams	Tektronix
Tom Hastings	Xerox
Carl-Uno Manros*	Xerox
Rick Yardumian	Xerox
Pete Zehler	Xerox
Guenther Kapp	Xionics

On Tuesday, Carl Uno-Manros opened the IPP meeting and provided the agenda topics for the remainder of the day:

• Discuss IFax over IPP
• Review latest updated IPP drafts, including resolutions to any still unsettled issues
• Presentation of latest SLP drafts

Carl-Uno asked for someone to record the Minutes. Lee Farrell volunteered.

1. The Use of IPP as a Facsimile Service – IFax Over IPP (IFX)

The group referenced the Internet-Draft written by Richard Shockey. (This document is available at: "ftp://ftp.ietf.org/internet-drafts/draft-shockey-ipp2ifax-01.txt".) Richard attended the meeting via teleconference. The document discusses the possible use of the Internet Print Protocol as a facsimile service. According to Shockey, "IPP has most of the functional attributes necessary to be a successful real time facsimile service on the Internet with little or no modification to the core IPP v1.0 protocols." He points out that "IPP compliance with the legal and general custom and practice surrounding General Switched Telephone Network will require some modification to the behavior of IPP clients and the common usage of time/date stamping on IPP transactions and logs."

The group started by discussing the confirmation requirements for fax (Section 3.1.1). It was noted that IPP might not currently provide the transaction time-stamping characteristics that are necessary for facsimile. For existing fax communication, no time-stamp information is sent over the wire—it is recorded and logged locally on the client and the server.

The concept of identification exchange between the sender and recipient was raised. Currently, an exchange of this information is achieved during the negotiation phase with a CSID data set. Richard suggested that Vcard (ref: RFCs 2425 and 2426) could be considered as a method for achieving this information exchange.

There was a long discussion about the legal requirements for clearly marking the identification required on fax messages. Many opinions and ideas were expressed about the possibility of creating and/or providing cover sheets with the needed information. The group agreed that any "fax job" sent over IPP should have all necessary characteristics and/or its "fax cover sheet" embedded in its PDL.

Carl-Uno gave Richard several (minor) editorial corrections that should be applied to the document. Richard agreed to update the document with the suggested corrections.

Carl-Uno pointed out that the document incorrectly claims that IPP can modify a print job. Currently, this is not true. He also clarified that IPP supports Digest Authentication, which could be used to restrict access to the printer/fax service.

Carl-Uno told Richard that IPP currently does not support any facility for notification. However, the group is planning to include some method for this capability. At a minimum, it is expected that an e-mail notification message would be sent. Carl-Uno stressed that the notification method will not be limited to SMTP.

Finally, the group reviewed the suggested work items that are listed in Section 13 of the document. Most of the items were accepted and agreed to without modification.

Richard stated that he will attempt to revise and submit his Internet-Draft within the next week.

2. Notifications

Tom Hastings distributed a document on IPP Event Notifications and led a review of the proposal summary. (This document is available at: "ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notifications-very-short-980701.pdf".) Because of some confusion about previous agreements that had been reached, Tom also reviewed the Job Events and Printer Events that had been identified and suggested at earlier meetings. After a bit of debate about which events might be useful for IFX, Carl-Uno suggested that the list of proposed events should be sent to the IFax Working Group for their review and feedback. The same suggestion was made for the list of IPP attributes.

Undeterred by the late hour (and reduced participation), Tom continued by reviewing the list of Issues in the Notification document. The following agreements were reached:

• No, we do not want to allow the client to specify the format of the event report independent of the delivery method.
• It was suggested to add TAP (Touch-tone ASCII Protocol) for pager notification
• Yes, we should make "subscriptions" be a Job Description attribute.

End of the first day of IPP meeting.

1. IPP Project – Day 2

Carl-Uno Manros started the continuation of the IPP session by presenting the remaining agenda items:

• Report about Discussion with IESG
• IPP Scheme
• TLS Security
• NLO Discussion and Resolution
• SLP Presentation and Discussion
• Teleconference with Keith Moore (IETF Area Director)
• Resolve other MOD Issues
• Resolve PRO Issues
• Decide on Versions
• PWG Actions
• Objectives for next Bake-off
• Review Implementor’s Guide
• New Stuff

1. Report about Discussion with IESG

Carl-Uno reported that the Internet Engineering Steering Group (IESG) acknowledges that the PWG has developed their own IPP version 1.0. However, before they will endorse an IPP standard, they still require an IETF version that includes an IPP scheme (ipp://) and addresses security issues. They encourage the group to continue to develop the specification to gain IETF acceptance.

Currently, there is much frustration with the Transport Layer Security (TLS) WG activity that is occurring within the IETF. Keith Moore believes there will be continued delay in this area. He suggests that the IPP WG should remove the references to TLS from the specifications—and address the security issues in a separate document. By doing so, he thinks IESG approval of the other documents will occur more quickly.

2. IPP Scheme

Carl-Uno distributed a new document for the proposed IPP Scheme. The proposal has now had security parameters removed. Otherwise, it is very similar to previous scheme proposals.

[Carl-Uno noted that a recent proposal (discussed via e-mail) for an IPP scheme that is supported only by the Client side was not acceptable to the IESG.]

Paul Moore pointed out that in the past, the IPP scheme printer address has been touted as "the thing to put on your business card." However, he wanted to make sure everyone understands that an IPP v1.0 Client will not understand an IPP scheme address. He believes we should not do the "halfway solution" (accepting ipp:// in the client, but sending http:// over the wire) just to gain "fast" IETF acceptance. Instead, he thinks a "proper" solution should have ipp:// supported in all contexts.

Once again, the group engaged in a (very long) speculative discussion about how long it might take to get IETF approval for an IPP scheme.

A few people are concerned that if IETF approval occurs quickly (i.e. less than two months), then we would be faced with the undesirable situation of having two different (potentially non-interoperable) standards to choose from.

It was noted that there has not yet been a clear list of requirements published for the IPP Scheme. So, the group generated the following list:

• Produce an IETF-accepted standard
• Provides something that serves as an SLP v1 directory entry
• Must support SSL3

Carl-Uno then led a review of the IPP Scheme proposal. A comment was raised that we should remove the explicit references to HTTP/1.1 (instead, just refer to the RFC documents.)

A straw poll showed that several people are planning to support SSL3. This raised the concern about whether the IETF version of IPP could require backwards-compatibility to the PWG standard of IPPv1.0. What about support of HTTPS?

Later in the day, an updated version of the IPP Scheme document was distributed. Bob Herriot discussed the section in the document that discusses "Compatibility with IPP/1.0." He explained the contents of a table that shows the scheme returned for the "job-uri" and "job-printer-uri" job attributes for all operations—based on how the job was created. the table.

It was pointed out that the table incorrectly results in a change of a secure job to a non-secure job. Bob will need to modify the document.

[Another lively discussion ensued…]

After more frustration with the same familiar arguments about PWG vs. IETF interests, someone suggested that the group should prepare a list of questions and issues for discussion with Keith Moore during the teleconference tomorrow. The following items were identified:

1. Does Keith think that the Compatibility section is acceptable?
   Does he approve of our method for dealing with "mixing" both ipp:// and https://?
   How should we deal with it?
2. Can the IPP scheme wait for TLS, and have the IESG approve the existing document suite as is?
   [It was suggested that we ask the IESG to ratify the current document suite, and we will implement the next version—with the ipp:// scheme—when TLS is ready. Carl-Uno did not think this approach would be acceptable to the IESG.]
3. Does the IESG have any technical requirements justification for the ipp:// scheme?
4. How long will it take to get an RFC published if we adopt the IPP Scheme document as part of the specification?

It seems that a major issue is not whether an ipp:// scheme is a good idea, but how soon such a feature could/should be included in the specification.

1. TLS Security

Based on the advice from Keith Moore, Carl-Uno suggests that all material referencing TLS should be removed from the Encoding & Transport document. This will be done to the document that will serve as part of the PWG IPPv1.0 document suite.

There was no disagreement to this suggestion.

2. NLO Discussion and Resolution

The Natural Language Override (NLO) issue has been discussed via e-mail and teleconference over the last several weeks. (See the IPP Issues List, Questions #1.46-1.48. This document is available at: "ftp://ftp.pwg.org/pub/pwg/ipp/proposed-clarifications/ipp-issues-list-mod-1.7.pdf".) Different people have interpreted the current specification text differently. Apparently, every implementation might have to change to some degree. Unfortunately, at least one vendor has already shipped their product.

Several individuals are very concerned about making a change—purely for the sake of simplification—that will break existing implementations.

Pete Zehler suggested that the next version of IPP should deprecate the nameWithoutLanguage and the textWithoutLanguage attributes.

Tom Hastings led a review of the NLO Issues:

1. Require all ‘text’ and ‘name’ attributes to always use the ‘textWithLanguage’ and ‘nameWithLanguage’ attribute syntaxes
2. Delete the ‘textWithoutLanguage’ and ‘nameWithoutLanguage’ attribute syntaxes

1. No change to June drafts, i.e., keep both text/nameWithLanguage and text/nameWithoutLanguage forms
2. For each attribute that the client supports whose attribute syntax is ‘text’ or ‘name’, the client MUST accept and process both the WithoutLanguage and WithLanguage forms

1. Too Many Meetings?

A few people raised the concern that having both the December and January meetings is undesirable. They feel that there is not enough time between meetings to accomplish sufficient work.

A straw poll was taken to see how many people were in favor of eliminating the December meeting. Approximately 12 people of 24 present indicated a desire to eliminate the meeting. No clear consensus was reached.

Later, Don Wright quickly resolved the issue by saying it’s too late to cancel the contract with the hotel in San Diego. There will be a meeting in December.

2. SLP Presentation and Discussion

James Kempf of Sun gave a slide presentation about the Service Location Protocol (SLP.) The presentation slides will be posted on the ftp site. Some highlights of the presentation include:

• Clients find services by typed and desired attributes, rather than by name.
• SLP operates in the absence of a directory server.
• 3 kinds of service types:

1. protocol (e.g. service:ldap)
2. abstract (e.g. LSPv2 only)
3. URL scheme (e.g. service:printer:lpr://motels.eng.sun.com:4242/MPK15-214)

• Attributes consist of an LDAPv3-compatible tag and zero or more values

1. Four attribute types include Integer, Boolean, String, and Opaque

• Service requests consist of a service type, the scope in which the service should appear, and a query consisting of Boolean expressions comparing attributes and values
• There are different methods for service discovery

He then discussed some of the problems associated with LDAP.

The SLP group is currently in contact with the Desktop Management Task Force (DMTF) regarding their development of the Common Information Model (CIM). They are discussing the possibility of integrating SLP template definitions into the LDAP schema via CIM.

Service discovery is a small part of JINI, but it does not use SLP. An SLP/JINI bridge will allow JINI networks to access industry standard SLP-enabled devices.

Hewlett Packard’s latest network enabled printer line and WebJet administration product have SLP built in. Novell Netware 5.0 has integrated LDAP directory services with SLP as a replacement for their proprietary SAP protocol. Intel’s Wired for Management has adopted SLP.

More information can be obtained at: http://www.srvloc.org.

James said that he has not been closely involved with the details of the SLP Printer Template.

Some ideas were discussed about possible methods for dealing with IPP under SLP service advertising. No concrete proposals were suggested, and no conclusions were reached. Interested parties are encouraged to formalize a proposal for future consideration by the group.

1. Teleconference with Keith Moore (IETF Area Director)

Thursday morning, the group held a teleconference with Keith Moore. Prior to the call, Carl-Uno had sent him the following questions via e-mail:

Harry Lewis acted as spokesperson during the call with Keith Moore. He started the conversation by stating that the group believes that the ipp:// scheme and the support of security are both important issues—and they are very strongly connected. Harry indicated that we would like the IESG to ratify the existing IPPv1.0 document suite—with the understanding that we would incorporate both the scheme and security together in the future.

Keith was unclear why the ipp:// scheme was closely related to the support of security. Harry explained that by including the ipp:// scheme now, we will not be able to support SSL3. Keith said that it would be good to document what the PWG members are planning to implement, but it would be difficult to obtain IETF approval for standards track purposes. Both Keith and Harry agreed that a reasonable approach would be to submit the current document suite as an Informational RFC. They also agreed that the documents would include the usage of the separate port number for IPP.

The highlight summary of the agreement in terms of the Informational RFC documents is as follows:

• Use SSL3
• Include port number
• No ipp:// scheme
• No TLS

Additionally, the group will publish a document about the ipp:// scheme as an Internet-Draft. (This should set a positive direction for future work.)

To achieve the above highlights, the group will need to modify the existing text on Security to include the usage of SSL3. (This text exists in a previous version of the documents, and should be easy to insert before next week’s submission deadline.)

[Because of the agreement reached with Keith, the PWG realizes that it no longer needs to maintain a suite of documents as a separate standard from the IETF. For IPPv1.0, the group will use the Informational RFC documents.]

1. Resolve Other MOD Issues

Tom Hastings again referenced the IPP Issues List and addressed the remaining Issues.

1. Clarify that "multiple-operations-time-out" is a minimum, not a promise to close the job after exactly that much time.
2. Require the IPP Printer to clean up such jobs, not the client.
3. IPP Printer MUST support the OPTIONAL "multiple-operations-time-out" Printer Description attribute if it supports the Create-Job and Send-Document operations, i.e., if it supports multi-document jobs.
4. The system administrator can set the "multiple-operations-time-out" attribute to any value. He/she is not restricted to a one to four minute value. Instead, the one- to four-minute value will be the RECOMMENDED default value for this attribute.
5. Remove the discussion of fidelity.
6. Additional clarification text will be added.

1. ‘keyword’ values never match ‘name’ values.
2. Remove any statement about any other equivalencies, such as accent insensitivity or other character equivalencies, such as Unicode composed accented letters versus composite accented letters. [Put this in the Implementor’s Guide.]
3. ‘nameWithLanguage’ matches ‘nameWithoutLanguage’ if explicit natural language (NL) is the same as the implicit NL too.
4. Change from MAY to SHOULD that a NL without a country matches a NL with a country (i.e. the shorter length must be equivalent.) [Add a warning in Implementor’s Guide about comparing user names for submitting and canceling jobs.]
5. Separate namespaces for keyword and name.

1. Resolve PRO Issues

Several miscellaneous edits to the PRO document were discussed and approved. Many of the changes were made in real-time while being projected on a screen. [Details of the changes were not captured for the Minutes.] The modifications will be reflected in the November submission to the IETF.

2. Decide on Versions

The group agreed that all references to future versions of IPP (beyond v1.0) will use the term "IPP-NV" (for "next version".)

3. IETF Plenary Session

Almost none of the attendees plan to attend the IETF plenary session in December. Carl-Uno will be there to discuss the status and latest IPP progress with any individuals that do attend.

4. Objectives for the Next Interoperability Test ("Bake-off")

Pete Zehler mentioned that a second Bake-off has been tentatively discussed for February, but not yet finalized. He wonders if February is too soon. To help people evaluate what might be a reasonable timeframe, the following items were identified as possible things to include in the next Bake-off:

• Testing based on contents of Informational RFCs (to be published in November)
• Security

1. Digest
2. Basic
3. SSL

• NLO issue resolutions
• Firewalls/proxies
• Extended character set/localization

1. Japanese
2. European

• Optional operations/attributes

1. multi-doc
2. print_uri
3. set 1 extensions

• Contention resolution
• Test error conditions
• Range boundaries
• Chunking
• Larger jobs (> 1 page)
• Client testing
• "Real-world scenarios"

While listing the above items, the following objectives of the Bake-off were identified:

• Interoperability verification
• Identify issues for the Implementor’s Guide

The group agreed that having an outside firm developing test suites would useful. "We do not want to be developing test suites another year from now." However, no one was anxious to endorse a particular (test suite vendor) company over another.

Pete asked the group for a straw poll on the following alternatives:

• Bake-off in February
• Bake-off some time later <TBD>
• No second Bake-off

The group concluded that we should hold the next Bake-off in March. (This will probably cause the usual PWG IPP meeting that is scheduled that month to be canceled.) Don Wright pointed out that it would be better if it were scheduled at a different time to the PWG meeting in March. That way, people that want to attend the other PWG sessions in addition to the Bake-off could do so. Because the previous event was "tight" at three days, it was suggested that (at least) four days should be scheduled.

Pete volunteered to work on establishing a host for the Bake-off.

1. Proposals for IPP Extensions

Tom Hastings led a review of the document, "Additional Attributes and Attribute Values – Set 1." (This document is available at "ftp://ftp.pwg.org/pub/pwg/ipp/proposed-registrations/ipp-attrs-set1.pdf".)

The following agreements were reached:

• The security keywords will not be addressed until IPP-NV
• Tom will make a separate "Set 2" document for the "finishings" values of the Job Template attributes
• Tom will make a separate "Set 3" document for the "output-bin" values of the Job Template attributes
• No changes will be made to the Model document regarding these attributes

1. Review Implementor’s Guide

Carl-Uno noted that the Implementor’s Guide might not be submitted to the IETF immediately to become an RFC. The group agreed to keep it as an Internet-Draft for awhile. It was suggested that the IPP document suite should reference "the latest version of the Implementor’s Guide" as a work in progress.

Carl-Uno quickly reviewed the latest changes of the document, and they were (generally) approved by the group. A few additional changes were identified for the next update. It was suggested that the Chunking problems encountered should be discussed in the document. A clarification about implementing HTTP/1.1 vs. HTTP/1.0 will also be added.

IPP Meeting adjourned.