IPP WG - IETF 50th Plenary Carl-Uno Manros led the Internet Printing Protocol (IPP) WG session. Around 20 people attended. He explained that because there was no meeting at the last Plenary, some of his presentation would span several months. Agenda: - Overview of all current IPP Internet-Drafts and where they are in the IETF process - Review and comments on IPP Internet-Drafts, currently in IPP WG Last Call - Report from the IPP interoperability testing event Autumn 2000 - Future plans for IPP 1. Document Status [IPP Project Time Line diagram] 1996: PWG Start 1997: IETF Start 1998: First bake-off 1999: IETF IPP/1.0, bake-off 2 2000: IETF IPP/1.1, bake-off 3 2001: IETF IPP/1.1 extensions 1999: RFCs 2565-69, 2639 - IETF Experimental: - Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol - Mapping between LPD and IPP Protocols - IPP/1.0: Model and Semantics - IPP/1.0: Encoding and Transport - IPP/1.0: Implementers Guide - Design Goals for an Internet Printing Protocol 2000: IETF Standards Track: - IPP/1.1: Model and Semantics - RFC 2911 - IPP/1.1: Encoding and Transport - RFC 2910 - IPP/1.1: Implementer's Guide [not Standards Track] - in IESG - IPP: Requirements for Job, Printer and Device Operations [not Standards Track] - in IESG - IPP: Job and Printer Set Operations - in IESG - IPP: The 'collection' attribute syntax - in IESG - IPP: Job and Printer Administrative Operations - in IESG - IPP: LDAP Schema for Printer Services - in IESG - IPP: Requirements for IPP Notifications [not Standards Track] - in IESG - IPP: Event Notification Specification - in IESG - IPP: Job Progress Attributes - in IESG - IPP: The 'mailto' Notification Delivery Method - in IESG - IPP: The INDP Notification Delivery Method and Protocol/1.0 - IPP: The 'ippget' Notification Delivery Method - in IESG Ned Freed commented that most documents have gone thru IESG. IANA is having some confusion about how to handle some of the registries. Ned will coordinate with IANA to determine next steps. He also indicated that "things are fine." Ned reported that Patrik Fältström is still working on the LDAP document-and he hopes that Patrik will finish his review soon. IETF drafts currently in Last Call - IPP URL Scheme - The 'indp' Delivery Method for Event Notifications and Protocol/1.0 - The 'ippget' Notification Delivery Method for Event Notifications - Printer Installation Extension - IPP URL Scheme - The 'indp' Delivery Method for Event Notifications and Protocol/1.0 - The 'ippget' Notification Delivery Method for Event Notifications - Printer Installation Extension Carl-Uno asked for any comments about the above drafts. Ned commented that a clear security section would be necessary. There were no other comments on the drafts. IPP Specifications that are PWG documents: - IPP: Override Attributes for Documents and Pages IEEE-ISTO 5010.4 - IPP: Production Printing - Set 1 IEEE-ISTO 5010.3 - IPP: 'finishings" attribute values extension IEEE-ISTO 5010.1 - IPP: 'output-bin" attribute extension IEEE-ISTO 5010.2 Carl-Uno mentioned that some of these documents also generate additional IANA registration needs. 2. Report from the IPP Interoperability Testing Event Autumn 2000 Fifteen printer vendors participated in the IPP bake-off. Four firewall and proxy server vendors participated: - 17 companies total - 9 IPP client side implementations - 16 IPP printer side implementations - 96% IPP/1.1 client/printer success rate for interworking - Firewalls and proxies worked fine - A few issues: * HTTP stack * IPP/1.0 and IPP/1.1 interworking Carl-Uno mentioned one problem experienced was that a 100 Continue was unexpectedly received. A few people, including Larry Masinter, agreed that no response should be sent until a request is received. 3. Market Activity with IPP Carl-Uno gave some status on IPP products. Canon, Ricoh, and Xerox have all introduced Multifunction products with IPP support. New IPP Products in Japan from the following companies: - Canon - printers, multifunction systems - Epson - printers, small print servers - Fuji Xerox - printers, multi-function systems - HP - small print servers, network cards - JCI - network cards - Minolta - printers - Ricoh - printers, multi-function systems Europe: - Axis, Sweden - I-data, Denmark - SEH Computertechnik, Germany New IPP products - Linux - Several vendors are now offering IPP Open Source code for Linux: * Easy Software Products - CUPS * Astart Technologies - LPRng * VA Linux - GNUlpr - Expect to see IPP code in most Linux distributions in 2001 New IPP products - Applications - Easy Software Products * IPP as transport for miniMAX international miniMax services competes with Kinko's and other printing shops * IPP as printing service in the US Department of Defense - From PrinterOn * IPP for PrinterOn Internet Printing Services among Seybold Editors' Hot Picks in San Francisco 2000 IPP impact in other printing standards - Universal Plug 'n' Play (UPnP) - Microsoft led consortium - Wireless Printing in Bluetooth - Telecom consortium - Job Definition Format (JDF) - CIP4 consortium on Production Printing - IPP Fax - Printer Working Group project - PPML - PODi (Print on Demand Initiative) consortium 4. Future plans for IPP Remaining Work in the IETF IPP WG: - Get the 4 WG Last Call drafts edited with any final comments and sent to the IESG - Make one more revision of the IPP/1.1 Implementer's Guide to incorporate resolutions to a few issues from the latest bake-off and send to IESG - Fix any issues brought up by the IESG or the RFC Editor - Finish some IANA registrations for document types, etc. Ned said that it is not necessary to create any RFCs for registering MIME types. It is especially easy if it is a vendor type. Carl-Uno suggested to Ned that when the remaining documents can successfully be pushed through the IESG, he believes that the IPP WG will be ready to close. 5. HTTP Authentication Scott Lawrence briefly referenced HTTP Authentication (RFC 2617) and Upgrading to TLS within HTTP/1.1 (RFC 2817). After reviewing past IPP e-mail on security, Scott wanted to clarify some HTTP Digest Authentication Misconceptions. Purposes of the Client Nonce (cnonce) - Prevent chosen-plaintext attack * Attacker spoofing server cannot choose all of the inputs to the authentication hash * Incidentally protects against sloppy nonce choices by server - Mutual authentication * The client can check the response digest to verify that the server also knew the shared secret Message Body Integrity Protection - NOT algorithm=MD5-sess * MD5-sess modifications shared secret usage to permit third party authentication services; has no effect on body integrity - qop=auth-int * Provides body integrity protection by incorporating body hash into authentication hash calculations * Note that you don't know the authentication status until the end Other - A server can challenge any time it wants to - For any reason it wants - How can a server distinguish protection domains? * Modify the realm name? Carl-Uno requested that Scott should send his comments to the IPP e-mail list, given that many of the IPP participants were not at the Plenary. Scott also mentioned that the HTTP reflector-although not very active-is still operating. He recommends that any HTTP questions should be directed to that list. 6. Fragmenting/Chunking XHTML/XML Carl-Uno raised a last topic on Fragmenting/Chunking XHTML/XML to help deal with receivers that have limited resources. He mentioned that a few groups have been struggling with this issue recently. Two Internet-Drafts will be published in the near future: - The MIME Multipart/Interleaved and application/chunk Content-types * draft-herriot-multipart-interleaved-00 - The MIME Application/BatchBeep Content-type * draft-herriot-application-batchbeep-00 Larry said that the problem really can't be solved-in general. He feels that neither of the above methods avoids the potential need to buffer at the receiver's end. If the receiver doesn't do the buffering, the sender must do the buffering at the receiver's request/control. Predicting the optimal buffering order is a very difficult effort-even if it is within a single page. The fundamental issue is not an encoding problem. It is related to the incremental rendering of a compound document by a device that cannot buffer all the components. This is very similar to the problem(s) being faced by mobile devices. Ned: Have you considered "pull" instead of "push"? Perhaps an IPP client could act as a server to pull the data when it is ready? There's nothing to stop you from having a reverse HTTP connection. If MIME types are used for this approach, it would be appropriate to identify them for limited use only. For example, these types would not be appropriate for web browser support. Larry referenced a W3C requirements document that discussed "packaging" components. It includes the concept of a manifest and several other features. He recommends examining this document as part of the effort to generate a possible solution. Carl-Uno indicated that the group will need to consider whether it makes sense to try to solve this as an "object" problem, or if it is more appropriate to examine as a communication problem. He also said that he does not think that he will be able to get travel authorization to attend the August IETF Plenary, but hopes to attend in December. Meeting adjourned.