1 Internet Printing Protocol July 8-9, 1998 2 Attendees David Pond Apple Lee Farrell Canon Information Systems Ron Bergman Data Products Shivaun Albright Hewlett Packard Brian Batchelder Hewlett Packard Alan Berkema Hewlett Packard Sandra Matts Hewlett Packard Ken Oakeson Hewlett Packard Kris Schoff Hewlett Packard Harry Lewis IBM Yuji Sasaki Japan Computer Industry Stuart Rowley Kyocera Don Wright Lexmark Paul Moore Microsoft Hugo Parra Novell William Wagner Osicom Charles Quan Kong Panasonic Atsushi Uchino Seiko Epson Randy Turner Sharp Anthony Fung ST Microelectronics Tom Hastings Xerox Carl-Uno Manros Xerox Xavier Riley Xerox Rick Yardumian Xerox Pete Zehler Xerox 3 Administrivia Don Wright provided details for the next PWG meeting: - August 17-21 - Toronto Marriott at Eaton Centre - 525 Bay Street - Toronto, Ontario, Canada M5G 2L2 - $175CN (about $120 US) - Deadline is July 24, 1998 Future PWG meeting schedules will have the following structure: - MIB meetings on Tuesday evenings (if needed) - PWG Plenary on Wednesday mornings - IPP meetings on Wednesday afternoon and Thursday morning - SDP meetings on Thursday afternoon - UPD meetings on Friday The PWG meeting calendar for 1999 will be discussed at the next meeting in Toronto. A first draft of dates and locations will be generated for review and evaluation. Carl Uno-Manros opened the IPP meeting. He presented the meeting goals and proposed agenda topics: ? Discuss Keith Moore’s (IETF Area Director) comments on IPP draft documents ? Reactivate us on the registration of Printer MIB document types as MIME types ? Microsoft’s proposal to register IPP extra operations ? Discuss plans for IPP interoperability testing ? Agenda for August IETF Plenary ? Discuss Implementor’s Guide activities for IPP ? Discuss a question from the IFAX group: Would the IPP group be prepared to write a mapping document for IPP to IFAX? ? MIB access over IPP ? IPP Notifications Carl-Uno noted that it is unlikely that we will be able to address all the above topics. The first item is the most important (and will probably occupy most—if not all—of the meeting.) 4 IESG Obstacles on IPP drafts It was suggested that the PWG group needs to consider their position on the IPP standards independently of the IETF views and opinions. It was noted that the PWG members seem to have reached agreement— only the IETF/IESG has any objections to the latest draft documents. One person raised the question about whether the group would consider moving forward with the IPP standard without IETF support. “What does it take to determine when the IPP v1.0 effort will be completed?” Someone voiced his frustration with the IETF and strongly suggested that the PWG group split from IETF control. [A lively discussion ensued, accompanied by a free flow of ideas and opinions.] During the discussion, Randy Turner said that he has received a private e-mail that suggests there will be another objection to the IPP documents with regard to security. He was not willing to provide more details. He believes that there might be a minimal security requirement that may be raised. Shivaun Albright pointed out that the IETF has provided useful technical guidance. She is concerned about the possible negative press that would result from the PWG splitting from the IETF. The group is very concerned that the IETF process (and possible additional objections by the IESG) may delay the process much more. Carl-Uno believes that the IESG will formally review the documents in the next three weeks. As a result of that meeting, he believes that they will provide a complete list of the outstanding problems. "Why can’t we just get to the stage of Proposed (Draft) Standard, and choose to implement them as written?" (And not wait for total agreement from the IETF/IESG.) How about if we just put the word SHOULD for including the ipp:// scheme in the specification, and agree not to implement it? Carl-Uno suggested that people should write to Keith Moore and explain that they have implemented the current set of documents. Perhaps this will help to persuade him (and the IESG) to accept the documents as is. Three alternatives were identified: ? split with the IETF ? wait for the full IETF process ? implement what we have now, and wait for the process to continue—decide later to change if necessary An attempt was made to obtain a consensus opinion on which decision the group wants to follow. Although a formal vote was not taken, it seemed that several people feel that we should still abide by the IETF/IESG decisions. The group agreed that no one should implement the ipp:// scheme until agreement has been reached within the IETF. The group then decided to spend the afternoon drafting a response to Keith Moore. It was suggested that we develop a document that includes the requested changes from Keith Moore, but also explains why the PWG members disagree with them. 5 IPP Scheme Carl-Uno provided a summary of what he understands that Keith Moore requires for the use of the ipp scheme. Whenever a URL is viewed or used by a user, it should be "ipp://" to refer to a printer. Also, the ipp scheme should be used for the MIME content type. However, Carl-Uno believes that we can use http:// when communicating to the server. The group reviewed a proposal from Randy Turner that was sent to the e-mail list on June 16. Various changes were suggested and will be included in an updated proposal response to Keith Moore. There were several comments speculating on exactly what Keith Moore believes. (Unfortunately, he was not present to explain his position.) An e-mail excerpt from Keith Moore was referenced to help clarify his position: There was much concern about the apparent contradiction of requiring that servers support "a full IPP URL" even though no client implementation is allowed to use them. There was repeated discussion about whether this is a reasonable concern. Two individuals strongly suggested that this requirement should be removed. As a compromise, it was left as a SHOULD instead of a MUST. 6 IPP Scheme in the Body Keith Moore also says that any URL in the body content that references an IPP Printer should use the ipp:// scheme. 7 Security What happens for translating ipp:// to http:// if security is desired? How does the new scheme for ipp indicate security? How will a process determine if an IPP URL should be mapped to http:// or https://? If it is mandated that ipp:// is used, how can an IPP Printer indicate that it should be contacted using https://? No clear conclusion was reached for any of these issues. Randy said that the IETF would be very happy if IPP included SASL. Carl-Uno said that if we did, it would further delay things by a few months. [More heated exchange of opinions.] --- "Cooling-off" break --- Paul Moore summarized an informal conversation that was held during the break: Several people feel that a "half-way, pseudo-scheme compromise" (as currently considered in the modified proposal) will encounter many problems as we dig deeper into the details. We really need to choose to use a "pure" ipp:// scheme or a "pure" http:// scheme - not the proposed "compound" scheme. By convincing the IESG that a compound scheme is not practical, the group believes that the IESG will agree to using http:// rather than forcing us to start all over and develop a completely new scheme. The group again agreed that we should continue to develop a document that addresses the requested changes from Keith Moore, but also explains why the PWG members believe it will not work. The group believes that this approach will be useful to prove that we did our "due diligence" in attempting to meet the suggestions from Keith Moore. However, after serious consideration, the group has found that the suggestions do not produce a viable solution for achieving the protocol. The group generated a list of several problems with the proposal (included at the end of the modified proposal - see below.) 8 Proposal Update - continued The next day, the group participated in a review of some modifications to the proposal that Randy had made the night before. There was much debate about Randy’s proposal for including a security parameter in a URL scheme. Several attendees were concerned that the IESG would not accept a parameterized URL scheme. No one was aware of any precedent for this concept, and a few people suggested that defining such a parameterized scheme should be done outside the IPP WG. Additional modifications to the proposal resulted in the following document: IPP Working Group Analysis of Proposed IPP URL Scheme ---------------------------------------------------------------------- Introduction The IETF Applications Area Director has proposed that the IPP working group consider creating a new URL scheme, "ipp:", to reference IPP objects, as defined in the IPP Model Document. The IPP working group has created a usage model of how a potential IPP URL would be used, if implemented and deployed. This usage model is included in this document analysis, for completeness. A subsequent analysis of the usage model for this new scheme has exposed some critical issues and concerns that the IPP working group has with the proposed "ipp:" scheme. Considering the impact of these issues, the working group feels that the integration of a new URL scheme into the IPP model and protocol specifications is not feasible at this time. Usage Model for "ipp" Scheme ----------------------------------------------------------------------- In its current definition, IPP uses HTTP 1.1 as a transport protocol, and hence uses the existing "http:" URL scheme, in which URL path names and MIME types are used to multiplex and demultiplex IPP from the HTTP protocol data stream. The conventional model for the introduction of a new protocol scheme assumes that the URL scheme maps directly to an application protocol, network transport protocol and default transport "port number". Typically, this transport protocol includes a multiplexing/demultiplexing capability based on the idea of a port number (e.g., TCP, UDP). The working group considered using the "ipp:" URL scheme using the conventional model, but the current HTTP infrastructure (existing HTTP 1.1 servers and proxies) does not understand "ipp:" URLs, and would not reliably transport HTTP messages containing headers that reference "ipp:" URLs. We finally considered a "compound" URL scheme, wherein a translation from "ipp:" to "http:" URL schemes is performed. The syntax for the new IPP scheme is identical to the existing "http" scheme except for the scheme name itself. The similarity is maintained to ease the IPP-to-HTTP translation burden: ipp://host[:port]/ Associated with this new IPP scheme is an IANA-assigned TCP port number, 631, which is the default port number used by clients to contact IPP servers that are represented by IPP URLs. The IPP scheme implies all of the same protocol semantics as that of the HTTP scheme, except that, by default, the port number used by clients to connect to the server is port 631. The semantics for clients configured for proxy access is different as described below. The implementation impact of using the new scheme on the existing specifications is divided into two key areas: HTTP headers and the application/ipp MIME body part. ------------------------------------------------------ HTTP Header Usage ------------------------------------------------------ When an IPP client obtains an IPP URL, the interpretation (translation) of this URL by the client can take one of two forms, depending upon whether the client is configured to use an HTTP 1.1 proxy server. IPP Client Configured with no proxy server ------------------------------------------------------ When an IPP client (no proxy configured) obtains an "ipp:" URL such as "ipp://myhost.com/myprinter/myqueue", it MUST open an TCP connection to port 631 on myhost.com, with the following example headers: POST /myprinter/myqueue HTTP/1.1 Host: myhost.com:631 Content-type: application/ipp Transfer-Encoding: chunked ... IPP Client Configured for Proxy Service ------------------------------------------------------ When an IPP client that uses a proxy named "myproxy.com" obtains the URL "ipp://myhost.com/myprinter/myqueue", it MUST open a TCP connection to myproxy.com with the following example headers: POST http://myhost.com:631/myprinter/myqueue HTTP/1.1 Host: myproxy.com:8080 Content-type: application/ipp Transfer-Encoding: chunked ... Existing proxies will not understand IPP URLs, so the RequestURI MUST use the HTTP form of the URL. After proxy processing, the proxy would connect to the IPP origin server with headers that are the same as the "no-proxy" example above. IPP/HTTP Server Implications ------------------------------------------------------------------- Existing HTTP 1.1 clients (and IPP clients) will only contact IPP origin servers using a requestURI specified in #1 below. However, RFC 2068 states that HTTP 1.1 servers MUST accept "full" URLs as well, so IPP servers MUST also be able to accept a requestURI as specified in #2 as well. Also, IPP servers SHOULD be able to accept a full requestURI as specified in #3 below. Servers MUST interpret all of the forms below as equivalent. 1. A "abs_path" URL (e.g., /myprinter/myqueue) 2. A full HTTP URL (e.g http://myhost.com:631/myprinter/myqueue) 3. A full IPP URL (e.g., ipp://myhost.com/myprinter/myqueue) NOTE: Example #3 is included to support the possible future deployment of IPP services that utilize full IPP requestURIs. Currently, this specification does not allow clients to generate full IPP requestURIs. In all forms of "ipp" URL translation, if an explicit port number is specified then this port number MUST be used by the clients and proxies to initiate connections to IPP/HTTP origin servers. ------------------------------------------------- application/ipp MIME body ------------------------------------------------- Printer and job URI attributes in the protocol MUST utilize the "ipp" scheme. The application/ipp body part contains the following URI components that are affected: job attributes - job-uri job-printer-uri printer attributes - printer-uri-supported operation attributes - job-uri printer-uri Other URI attributes in the protocol can contain any number of different URL schemes, e.g., document-uri, printer-more-info, and are not affected by the "ipp" scheme. ------------------------------------------------------------------- Summary Conclusions ------------------------------------------------------------------- The IPP working group has serious concerns regarding integrating a new "ipp:" URL into our specifications. The following issues have been raised with regards to usage of the "ipp:" scheme. 1. There is currently no defined way for a single "ipp:" URL to indicate whether or not a particular IPP server offers "secure" connections. Throughout the IPP model document, numerous assumptions are made with regards to our usage of the "http:" URL to reference IPP objects, chief among these assumptions is that IPP clients treat URL syntax beyond the "host" part of an HTTP URL as opaque. The IPP working group feels that any specification for security parameters within URL syntax should be a "standard" solution and not specifically a "one-off" or one-time only solution for IPP. The effort required to put together a group or effort to accomplish this is out-of-scope for our current charter. 2. There is no straightforward way to configure HTTP client proxy capability for "proxying" IPP. Currently, there are specific proxy configuration options for HTTP clients, such as FTP, GOPHER, HTTP, WAIS, etc. There is no option for proxying "ipp:" URLs and this deficiency could lead to confusion for the end user. Also, to correctly configure a proxy service for IPP, the user will have to "know" that IPP actually uses HTTP, and that for IPP proxy service the user must configure an HTTP proxy. 3. Similar to the end-user configuration problem in #2 above, there is currently no proxy configuration option for IPP proxy in existing proxy server software. IPP will be a "special case" wherein the administrator will have to know the special relationship between IPP URLs and HTTP URLs. 4. Future use of the "ipp" scheme is compromised by using the new "ipp" scheme in the translated form implied by the proposed "ipp:" scheme. The IPP working group would like to reserve use of the "ipp" scheme for a pure IPP client/server protocol implementation in the future (one that does not require utilization of an existing HTTP infrastructure). In this environment, it seems appropriate to attach the "ipp" URL to this future protocol, rather than the initial IPP protocol that is just carried in a MIME type within HTTP. For example, in a future implementation of an IPP scheme that does not utilize HTTP, existing IPP clients would still attempt to translate the "ipp:" scheme into an "http:" scheme, and would do so incorrectly, since the future "ipp:" scheme protocol might not use HTTP as a transport. 5. The proposal introduces "compound" spoofing by using an "ipp:" scheme and transparently translating it to an "http:" scheme An initial concern was the fact that there was no way to tell that IPP was actually being used by looking at an HTTP URL. However, publishing and using only IPP URLs to the user and administrator community might hide the fact that IPP is actually using HTTP. 6. Compound schemes is a new idea and not well understood in its' ramifications. In the current IANA registry for URL schemes, there are no examples that indicate that scheme "translation" to another scheme is required. 7. All applications that include URI/URL recognition features will have to be updated to include support for the new "ipp:" URL. 8. Existing network infrastructure tools and utilities would need to be modified in order to understand the "special" relationship between IPP and HTTP URLs. The working group considers IPP printing an "HTTP application", and therefore the usage of an "ipp:" URL scheme must maintain a special relationship with "http:" URLs. The definition of such a "compound" URL scheme, wherein an "ipp:" scheme is layered or translated to an "http:" scheme, is somewhat unusual, and the impact of such a definition on the protocol design and deployment is not generally well understood. This analysis document has identified a partial list of issues regarding the integration of the new "ipp:" scheme. It is anticipated that other unforeseen issues exist, since this technique has not been prototyped. If the usage model described herein were adopted, these issues raised in this analysis pose a significant negative impact on the implementation and deployment of current IPP specifications, as well as potential interoperability with future revisions of the protocol. This document will be forwarded to the IESG. 9 Interoperability Testing Pete Zehler announced that 13 companies (of 35 companies contacted) have said they are willing to make an announcement about their current status with regard IPP development. The other companies either have not responded, or prefer to keep their status private. Connectivity issues and bugs in implementations seem to be the major activity being addressed in the pair- wise testing that is currently occurring. More testing has occurred, but the participants continue to guard their activity results. Pete believes that an interoperability “bake-off” might be achievable some time in September, or later in the year. A major concern is having sufficient test tools to support such an effort. It was suggested that a poll should be taken to see which vendors are ready (or would be willing) to participate in an interoperability test within the next several weeks. Xerox, IBM, Microsoft, and Lexmark all said that they are willing and able to participate in a bake-off on September 15. Pete will send out a list of company status and contact points. He will also send out a request for additional participants for a September 15 bake-off. All implementations will be based on the June 30 specification documents. It was estimated that the bake-off would last three days. 10 IETF Plenary Meeting Agenda Carl-Uno asked what should be planned for the IPP session during the next IETF Plenary in August. After a short discussion, the following topics were suggested: ? Status review ? Implementation progress ? Discussion of open issues based on IESG feedback 11 Implementers Guide Several participants agreed that we should document clarifications and “lessons learned” from IPP implementation efforts. Carl-Uno volunteered to collect material for this document. He also said that he would update the FAQ document. 12 A Mapping Document for IPP to IFAX Carl-Uno asked if anyone would be willing to write a mapping document from IPP to IFAX. One suggestion was that Larry Masinter (who made the request) should provide more information on what he envisions. Harry Lewis said that he would be interested in talking with Larry about this. IPP Meeting adjourned 10/5/98 Page 10 of 10