All,
Below are the more detailed minutes from the IPP WG Meeting in Minneapolis.
Many thanks to Lee Farrell for taking the notes and getting them ready for
distribution so quickly.
Carl-Uno
==================
IPP WG Minutes - March 17, 1999
=========================
Carl-Uno Manros led the meeting for the Internet Printing Protocol (IPP) WG
session. Around 30 people attended. Notes taken by Lee Farrell.
Agenda
· IPP Status - Where do we stand?
· Highlights from the IPP bake-off
· Presentation of IPP 1.1 documents
· Highlight differences between 1.0 and 1.1
· Open discussion
IPP Status
· The five draft documents that constitute IPP/1.0 have been accepted by the
IESG as Experimental. These five documents are currently in the RFC Editor's
queue for publication
· An IPP/1.0 Implementer's Guide document is currently out for IPP WG Last
Call
· Two new drafts have been produced for IPP/1.1. They are currently out for
IPP WG Last Call
Some objections have been raised on the mail list about finalizing IPP/1.1
"too quickly" before reasonable experience is gained on IPP/1.0. There is
especially some concern with regard to over 20 issues that came up at the
2nd bake-off. Tension exists between delaying too long before the first
standards track draft is issued and waiting for "sufficient stability" in
experience with 1.0 version implementations before issuing a second
specification.
Carl-Uno showed slides on the bake-off event. He explained the
infrastructure set-up and services.
Highlights from the IPP bake-off
· 24 vendors (Carl-Uno provided list)
· 11 IPP clients
· 27 IPP printers
· 297 possible combinations
· 296 "basic print" feature successful after 3 days (one hold-out due to ROM
implementation-couldn't modify code)
It was noted that "new faces" (i.e. never attended an IPP meeting) brought
successful implementations. This suggests that the IPP/1.0 specification is
clear enough for consistent interpretation.
Genoa is developing an IPP test suite that will be made available to the
open market.
Q: How many vendors demonstrated the ability to handle multiple concurrent
sessions?
A: It wasn't really one of the tests, but there was a wide spectrum of
capability present-including a OS/390 mainframe machine that could handle 20
simultaneous HTTP/IPP connections.
Carl-Uno brought with him and showed a palm-sized IPP Print Server device
implemented by i-data. It has 4 MB memory, and supports TCP/IP, HTTP, SNMP,
SMTP, and SSL3, with a web server, plus four print protocols, including IPP.
Presentation of IPP 1.1 documents
· IPP Protocol: Model and Semantics - draft-ietf-ipp-model-v11-00.txt
· IPP Protocol: Encoding and Transport - draft-ietf-ipp-protocol-v11-00.txt
Important Differences between IPPv1.0 and v1.1
· Six new optional Operations
· Introduction of the ipp:// scheme
· TLS replaces SSL3 ("should" support TLS)
New Operations (all optional)
· Printer Operations
* Pause-Printer
* Resume-Printer
* Purge-Jobs
· Job Operations
* Hold-Job
* Release-Job
* Restart-Job
Carl-Uno provided background comments on the group's reluctance to adopt the
IESG recommendation to implement ipp:// scheme. However, he points out that
several people have shown that the scheme is relatively simple to implement.
It was noted that http:// is used on the wire. The Client translates before
sending. Any URLs contained in the MIME message body are maintained as
ipp://.
ipp:// scheme:
· Synonym for http://
· Has its own default port--#631
· Easy to map from/to http:// scheme
· If client uses http://, server responds with http://
· If client uses ipp://, server responds with ipp://
Use of TLS vs. SSL3
· SSL3 uses special scheme https:// and special port #443
· TLS uses ipp:// scheme and same port as IPP-#631
· For SSL3, the IPP client has to start up with https:// and later switch to
http://
· For TLS, the IPP client starts up with http:// using the Upgrade header
Carl-Uno noted that he has heard rumors about "one little problem" with the
Upgrade header, but the details were not clear. There was speculation that
there might be a need for a registry of tokens and their meanings-to avoid
collisions.
He also noted that there is not a lot of TLS code "lying around" for general
use. He requested if anyone knows about SDK for TLS in Java-please notify
him; the IPP WG is interested.
There was some discussion about handling both TLS and SSL3. There was some
confusion about the correct interpretation regarding support of IPP/1.0 (and
SSL3) as part of IPP/1.1. Carl-Uno suggested that if people have any
suggestions for existing text on this issue, please send him comments. The
Last Call period on the current document set will be extended.
Discussion about IPP-to-IFax BOF activity (now "TCN Docs"). One person
reported that it is still not clear from the Area Director whether IPP is
the accepted mechanism for the goals of this group. He explained that "due
diligence" must be performed on clarifying the problem statement. There is a
perception that the current approach might be "a solution looking for a
problem."
Larry Masinter proposed that it's a small amount of work to merge both
document sets (IPP/1.0 and IPP/1.1) into one. He suggests that we could pull
the current experimental RFC documents from the Editor's queue, and include
in the IPP/1.1 documents an informational description of IPP/1.0.
Larry pointed out that the preface to Experimental RFCs includes warnings
that they are not standards-and should not be implemented.
Carl-Uno expressed his belief that many of the vendors that attended the
Bake-off would be upset about "pulling the IPP/1.0 RFCs." He pointed out
that there was strong desire to establish a document set to clearly define
the IPP/1.0 version.
A popular compromise was suggested: do both. Include the "merge" of IPP/1.0
description within the IPP/1.1 document set-and obsolete the IPP/10
Experimental RFCs once the combined IPP/10 and 1.1 version is published. A
benefit of this approach is that all relevant information would be available
in a single document set-rather than having two document sets that are
essentially the same.
Strong majority agreed that this was a good compromise approach. No one
voiced any objections.
Larry and John Wenn volunteered to propose text modifications to achieve the
merge. The proposed text will be issued for review by the IPP mailing list.
Issues to be addressed:
· How difficult is the actual modification of the documents?
· Is IPP/1.0 really a true subset of IPP/1.1?
· Can we (continue to) avoid the requirement that 1.1 Clients need to
support 1.0 Servers?
· "How to be compatible with existing 'pre-standard' (i.e. IPP/1.0)
implementations of IPP?"
Larry will analyze the effort to merge, and will issue a statement/proposal
to the reflector as appropriate.
Meeting adjourned.
Shortly after the meeting, the chair extended the Last Call period for the
IPP/1.1 documents and the IPP Implementer's Guide until April 30, 1999.
-----
Carl-Uno Manros
Principal Engineer - Xerox Architecture Center - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros at cp10.es.xerox.com