CURRENT MEETING REPORT Minutes of the HyperText Transfer Protocol Working Group (HTTP) Reported by Phill Hallam-Baker, W3 Consortium, and Rohit Khare, W3 Consortium The meeting was held as two sessions, one in the morning and one in the evening. Minutes for the morning session were taken by Phill Hallam- Baker and those for the evening session by Rohit Khare. Session 1 Larry Masinter has become co-chair of the Working Group along with Dave Raggett. Roy Fielding presented the status and plans of the Working Group. A discussion resulted from his presentation. HTTP/1.0 was proposed as Best Current Practice but was rejected by the IESG because it didn't describe people's view of what was Ôbest,Õ and thus it was deemed an inappropriate status. Roy described his proposal that HTTP 1.1 be 'fast track' and that HTTP 1.2 contain the extension mechanism and those bits that didn't make HTTP 1.1. He explained that he wrote things into the HTTP 1.1 specification even though they might be controversial because it was easier to take things out than to add them to the specification. After some back and forth about a variety of options, the desire for a stable core, and so on, the discussion led to the proposal that HTTP/1.0 be re-written as an Informational RFC describing current practice. 'Current practice,' however, does not mean that we should document all 50 versions of content negotiation as practices. Instead, we should merely use the core of the 1.0 document as it stands for the parts that are specified, and note that other features are not implemented consistently. Some other points raised included: o 1.0 is actually not any simpler than 1.1. 1.0, however, does ignore proxies and gateways; o all current clients/servers/proxies claim HTTP/1.0 in their headers. If we were to create a 'best current practice' document for HTTP/1.0, there becomes something for clients/servers proxies to conform to, but then there is no way for an agent to tell whether it is talking to a peer that claims conformance; o the 1.0 specification has been useful as it is because it is stable and consistent despite the fact that it is incomplete: and, o it is a bad idea to make something a standards track document and then obsolete it immediately. 1.0 should not be a proposed standard; 1.1 should be. Dave Kristol discussed his draft, draft-kristol-http-state-info-01.txt. Dave presented the following ideas: o To support state full sessions in a stateless protocol such an idea is similar to netscape cookies). Examples include shopping basket, subscription library system (for this remembers what has been looked at); and, o define new header State-info that carries state information between user agent and origin server. Requirements: o Cache friendly o simple to implement o simple to use o can be deployed quickly o downward compatibility o reliable o protect privacy o support complex dialogues o enough cache control possible o minimal risks when used with non conforming caches Dave went through the proposal. There is some belief that this may 'compete' with the Netscape 'cookies' method, but that is claimed not to be sufficiently documented. Comments during the meeting inluded: The privacy concern is not that the site that initiated the session might know things about the user, but that other non-related sites might be able to find out things about your sessions. (Larry Masinter) The security concern of allowing server to store data on the clients disk should be addressed explicitly. (Ed: this was a subtle point) (Phill Hallam-Baker) There is an issue with regard to servers with multiple CGI services which do not wish to share state information. (Alex Hopman) This is a server implementation issue. (Dave Kristol) Rohit Khare gave an overview of his PEP proposal, draft-khare-http- pep-00.txt. 1. History "Motivation; Existing Practice of Adding Headers; Extension/Negotiation experience in other IETF work areas" 2. How "extensions" work o feature present o "Modes activated by mere presence of a header: e.g. keep-alive, etc." o reprocess body o "Filter message through program with : e.g. encryption" 3. PEP features o naming o "Packaging a standard into a single name; a la ESMTP" o addressing o "Explaining which HTTP agents need to act on extensions; a la Ipv6 option faulting and scoping" o negotiation o "Advertising which extensions (at which settings) HTTP agents will accept; lessons from TELNET Option Negotiation" o processing o "Order-of-application; reuse of Content-Encoding header to form pipe" 4. Directions o "W3C is developing this for security, payments application; PEP will be HTTP 1.2; May form the basis for integrating work of HTTP sub-working-groups" Comments: The trend in the IETF has been to strict versions something that people can read on the back of a box. Once an extension list is in a protocol we have a checklist. We have never handled a transition from an extensions mechanism to a real verb well. PEP should consider migration to real verb properly. (John Klensin, speaking personally and not as A.D.) Typically the view is that an extension mechanism allows negotiation of optional features. A different view is to say we want to move from here to this one place, and that the negotiation mechanism allows movement of a functional core to a new base. This is Dave's view of the ESMTP work. Negotiation for combinatorial choices does not seem to work but as a migration strategy it does. (Dave Crocker) Don Eastlake described his Internet Draft, draft-eastlake-internet- payment-00.txt He has reviewed the problem of doing payments on the Internet. What is needed is a mechanism for specifying payment systems so that once there is an idea of prices it can be decided what type of system is most effective. He noted that there is no attempt to constrain the payments system. This draft allows a payment or receipt to be put into the header and allows for payments to be made over the Internet using a common framework. The current plan is to recast in terms of PEP. Larry Masinter noted that in order to complete reliable payments you need real (ACID) transactions. HTTP, however, does not seem to have any transaction mechanisms; e.g., you do not have the ability to find out where an aborted transaction has been placed. We might expect to provide a transaction mechanism on top of HTTP to permit this to be used. Don Eastlake noted that we should expect such matters to be handled by a payment system rather than an http layer, e.g. server allows interogation of server to find out where transaction has gone. Some lightweight payment systems will not provide such guarantees. Don attempted to restrict the draft to just messages and receipts. Dave Kristol expressed reservations about costs being embedded in documents and URLs. We deferred further discussion to the Internet Payment BOF. Alex Hopman was scheduled to discuss draft-ietf-http-ses-ext-00.txt. However, half of that internet-draft is now in HTTP/1.1. Ari Luotonen said only a few words about draft-luotonen-ssl-tunneling- 00.txt. It's been out for half a year. The Working Group did not come to any conclusions on this issue. We then talked about draft-luotonen-http-url-byterange-00.txt. This draft inspired the work in the HTTP/1.1 draft on ranges. The URL-method for byte ranges will be abandoned, although it may go through an interim release by Adobe/Netscape. The core HTTP/1.1 draft need not specify this if the methods and additions can be done in a separate document and linked to 1.1 by reference; this is still an option. One motivation for this feature was partial retrieval of PDF files. However, PDF as currently defined in application/pdf does not have binary offsets or byte ranges. Apparently this is a feature of a new version of to-be-released PDF. John Klensin pointed out that the byte range protocol should look at checkpoint and restart experience. It was likely that the real problem is that the document wants to be returned by parts, and that we need to devise a way inside the document format to refer to parts and use that for references. Roy Fielding then began a discussion of the HTTP 1.1 draft. Comments in the first section included: He thought that caching was meant to be a transparent optimisation technique. Nice simple semantics of http is being interfered with by the clutter of discussing this intermediary optimisation. The problem is that there are lots of different types of caches and hence different types of optimisation between server and intermediaries. We are describing cache control headers in terms of operational effect rather than semantic differentiation; this does not anticipate future cache techniques. (Larry Masinter) In response, Roy noted that these were just the header names, and the semantics were described that way. Someone suggested putting content negotation outside in a separate draft. Session 2 Simon Spero discussed HTTP-NG. HTTP-NG is the first protocol endorsed by Dogbert. "Resist and you will be shot." (Scott Adams cartooned a Dogbert on the HTTP-NG draft.) His presentation was a shortened version of the one to be presented at the WWW4 Conference in Boston. The primary modifications have been: Split the document into Architecture and Basics documents. The basic purpose is: negotiation, meta-information, and control. Highlights: o Uses SCP to multiplex sessions. o Transition strategies using DNS CNAME to indicate NG support. o Not a superset of HTTP/1.x o Just forwarding HTTP1.0 through ng encoding reduces packet count by 50 and speed by 180% o negotiation and profiles. Dictionaries on either side constitute shared state, and profiles are predefined dictionaries of preferences. Dictionary structure patterns can be reused in different exchanges. o Security Key exchange o reinventing several secrecy nd signature mechanisms o Get put and metainformation o HTTP/1.x metainfo + US MARC records. o can request metainfo for included or linked objects. o speculative sending of data can be enabled, experiments can reduce latency to 1/5th After various discussions, the chairs presented the results of their dinner planning session: o The HTTP/1.0 draft will be revised to become an 'informational RFC' which describes common current practice. Paul Hoffman (maintainer of the list of HTTP servers and their features) will help. This is primarily an editorial task, although additional material may be added to list features that are widely but inconsistently implemented (e.g., accept: headers). o The HTTP/1.1 draft will be reviewed independently by separate sub- groups. The sub-groups are chartered to review the HTTP/1.1 draft for text related to their issue, and propose changes to the HTTP/1.1 draft that consist of either wording changes, or movement of major chunks of HTTP/1.1 to separate documents, as appropriate. The issues are: o Persistent connections (this contains all of the 1.1 proposals for keep- alive, and maintaining connections to avoid TCP startup costs.) Alex Hoppman, Simon Spero, Mike Cowlishaw, Andy Norman, Scott Powers, Brian Swetlund volunteered. o Cache-control and proxy behavior-Ari Luotonen, David Morris, Jim Gettys volunteered. o Content negotiation-Larry Masinter, Simon Spero volunteered. o Authentication-Phill Hallam-Baker, Alex Hopman, John Marchinoi, Stefek Zaba, Scott Powers volunteered. (This issue must be coordinated with WTS working group drafts.) o State management-Dave Kristol, Rohit Khare, Scott Powers volunteered. o Range retrievals-Stephen Zilles, Ari Luotonen volunteered. o Extension mechanisms-Paul Hoffman, Rohit Khare, Daniel LaLiberte, Simon Spero, Phill Hallam-Baker volunteered. o other new methods and header features (no list of volunteers for this was gathered) o Subgroups should conclude their work by Jan 96, in time to publish their conclusions (or lack thereof) to the rest of the WG by February 96, so that new internet draft(s) for HTTP/1.1 will be ready in March 96 and ready for Proposed Standard RFC status by June 96. o Subgroups should document meetings, progress, etc. and are encouraged to meet regularly, by conference, phone, etc. o Any proposed HTTP/1.1 features not in HTTP/1.0 for which there is no consensus will revert to HTTP/1.0 status in 1.1 and be considered for inclusion in HTTP/1.2. Alex wondered where 'logic bags' fit, and Larry suggested it should be handled by the cache control/proxy group.