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