Minutes of IPP Working Group Meeting

November 10-12, 1998


  1. Meeting Attendees

Maulik Desai


Katsuaki Sekiguchi


Lee Farrell

Canon Information Systems

Toru Niki

Canon Information Systems

Don Purpura

Canon Information Systems

Michael Yeung

Canon Information Systems

Ron Bergman


Bill Wagner


Greg LeClair


Amar Rajan


Shivaun Albright


Brian Batchelder

Hewlett Packard

Ben Brezinski

Hewlett Packard

Laurie Lasslo

Hewlett Packard

Sandra Matts

Hewlett Packard

Harry Lewis


Henrik Holst


Pierre Landau


Yuji Sasaki

Japan Computer Industry

Michael Wu


Stuart Rowley


Don Wright


Paul Moore


Hugo Parra


Ben Chun

Samsung Electronics

Fumio Nagasaka

Seiko Epson

Atsushi Uchino

Seiko Epson

Bob Herriot


James Kempf


Chuck Adams


Tom Hastings


Carl-Uno Manros*


Rick Yardumian


Pete Zehler


Guenther Kapp


* IPP Chairman

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

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)
  2. 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.

  3. 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:

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:

  1. Report about Discussion with IESG
  2. 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.

  3. 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:

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
  2. 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.

  3. 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.46 NLO 2 of 4 (clarification that NLO MAY be used redundantly):

Sender MAY supply an attribute NLO in a request or response even when it isn’t needed, i.e., be able to supply the ‘textWithLanguage’ or ‘nameWithLanguage’ with the same natural language as in the supplied "attributes-natural-language" operation attribute.

The group agreed to this.

Shivaun Albright explained that the HP implementation will not accept anything with a nameWithLanguage attribute, because they only support (implicitly) US English. They will consider this an error, and will return an error code.

1.47 NLO 3 of 4 (vote to simplify Get-Jobs):

Delete the paragraph from Section Get-Jobs response that allows the IPP object to return the job’s "attribute-natural-language" as the first job attribute if it is different from the value being returned as the Get-Jobs response "attribute-natural-language" operation attribute, i.e., get rid of job-level NLO in Get-Jobs response

MOTION: Agree with the above paragraph.

VOTE: Motion passed.


1.48a NLO 4 of 4 (vote to always use ‘textWithLanguage’ and ‘nameWithLanguage’ NLO mechanism):

    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.48b NLO 4 of 4 (vote to always use ‘textWithLanguage’ and ‘nameWithLanguage’ NLO mechanism):

    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

MOTION: Agree with 1.48b, and add text in the Implementor’s Guide for the pros and cons of using textWithLanguage and textWithoutLanguage as a sender. Also add a warning that you might send in one format and receive a different format in the response.

VOTE: Motion passed.

  1. Too Many Meetings?
  2. 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.

  3. 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:

    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)
    1. Four attribute types include Integer, Boolean, String, and Opaque

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:


Questions for Phone Conference on Thursday:

We have run into some question marks relating to Channel Security for IPP:

1) Several current IPP implementations will support SSL3 over https:// scheme. Can we mix ipp:// scheme with https:// for practical purposes?

2) Please check draft above to se if you like our thinking on how https://

scheme works for backwards compatibility. Do you agree to our solution?

3) Considering the potentially unsuitable mix between ipp:// scheme and https:// scheme, should we wait to introduce the ipp:// scheme until we can combine it with TLS, which does not require a scheme on it's own. (However, we would still need to interwork with SSL3 implementations).

Other questions:

4) Do you agree with the backwards compatibility rules for inter-working with existing implementations?

5) The WG members would like to hear directly from you the justification for using the ipp:// scheme (again).

6) If we reach agreement on the ipp:// scheme issue, when could we expect a decision from the IESG on the IPP Proposed Standards documents?


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:

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.19 Revisited – What error to return when an unsupported charset is requested?
The group agreed to return "attributes charset", probably with "charset configured". It was noted that this interacts with bad version and unsupported operation. The clarifying text will be placed in the Implementor’s Guide—not in the Model document.

1.28 – What MUST an IPP object do if Create-Job never gets an Add-Document or Send-Document with ‘last-document’ set to ‘true’?

    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.33 and 1.34 – Equality between different syntaxes?
These rules only apply to the ‘name’ attribute syntax, not ‘text’:

    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.

[Additional clarification text will be added.]

Later in the afternoon, Tom Hastings proposed some text to explain the concept of an "associated natural-language" (ANL). This explanation is intended to help clarify the rules for determining a "match" for certain attributes. The group reviewed, modified, and agreed to a final explanation that will be added to the document.

1.53 – Should we make document-format-supported REQUIRED for directories?

The group reviewed a list of attributes and decided if each one should be REQUIRED or RECOMMENDED. Tom will modify the Model document to reflect the decisions, and will add text saying that the information is useful for template writers and printer implementors that register in Directories.

1.54 – Can’t put one staple through multiple documents that start on new sheets.

Add a new value to 4.2.4 multiple-document-handling:

‘single-document-forced-new-sheet’: same as ‘single-document’, except that the Printer object MUST force the document data in each document instance to place the first impression on a new media sheet. This allows multiple documents to be stapled together with a single staple where each document starts on a new sheet, i.e., staple each job copy.

  1. Resolve PRO Issues
  2. 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.

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

  5. IETF Plenary Session
  6. 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.

  7. 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:

    1. Digest
    2. Basic
    3. SSL
    1. Japanese
    2. European
    1. multi-doc
    2. print_uri
    3. set 1 extensions

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

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:

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.

ACTION: Pete Zehler will finalize the Bake-off plans and present them at the January meeting. Test scripts should be ready by mid-February.

  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:

  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.