Editor's note: These minutes have not been edited. Minutes of the HTTP Working Group at the 35th IETF (Los Angeles, March 4-8, 1996). Reported by Ted Hardie (hardie@nasa.gov), revised by Larry Masinter (masinter@parc.xerox.com). The HTTP working group held two regular sessions, the first on March 5th and the second on March 7th; in addition, an extra meeting took place the afternoon of March 7th and is reported here. Larry Masinter chaired the sessions. The HTTP 1.0 specification has been taken up by the IESG, and the proposal to move it forward as an Informational RFC is expected to be processed at their next meeting. The group applauded Roy Fielding for his work in producing the specification. Jim Gettys will be taking over as primary editor of the HTTP 1.1 specification, continuing Roy Fielding's work and coordinating with others who will aid in the editing process (including Roy, Henrik Frystyk, and others.) The Area Directors approved Jim's selection as editor; as is expected of WG editors, Jim confirmed that he would act on behalf of the working and that he did not see his role at Digital or in the W3C as in conflict with his role as editor. One of the first items Jim will do is to decide on how best to split the HTTP/1.1 specification into separate documents. Most of the meeting was consisted of reports from the subgroups constituted at the Dallas IETF. This marks the formal end point of the subgroups. The members of the individual subgroups may continue to use those mailing lists to discuss issues, but further internet drafts from the subgroups are not expected. Caching: Jeff Mogul presented the status report of the caching subgroup. The group generally agreed on cache control headers for Expires, Age, and Cache-control; some differences remain on the exact syntax of the Cache-control headers related to object "freshness", but the subgroup did not see these as anything more than a stylistic disagreement. The subgroup also agreed on the need for a Warning header, and proposed a series in the 90 range; some disagreement on how to associate text with the different warnings remains and will have to be worked out on the list. The subgroup had also reached consensus on the need to distinguish between history buffers and caches; history buffers are meant to replay pages which have already been seen, as they were seen, and they should thus not be subject to the same directives as caches. The caching subgroup has reached general agreement on how caching should interact with the Location: header and the Vary: header, but it has not yet worked out the details. Still unresolved are: the general question of semantic transparency vs. performance in default behavior; the use (or re-use) of opaque validators; whether protocol elements were needed to control history buffers; what defaults should be set for caches in the absence of any expiration or age directives; and whether or how to cache PUTs and POSTs. In the course of discussion, the working group agreed to delay work on bulk validation of cached material to a release after HTTP 1.1. It was also agreed that we can currently allow for multiple warnings, but that the issue might need to be revisited if contradictory warnings were ever introduced (the current set includes no mutually exclusive statements). Discussion of Content-id: as validators also took place at the meeting, but no consensus emerged. Content Negotiation: Brian Behlendorf presented the status report of the content negotiation subgroup. The subgroup adopted a strategy that allows for both pre-emptive and reactive content negotiation and which will normally progress from pre-emptive to reactive if the pre-emptive is not immediately successful. As it is now, the draft proposes content negotiation on four axes: media-type, charset, language, and encoding. The subgroup had agreed that to prevent spoofing, all variants would have to be extensions of the original URL. Discussion at the meeting on this issue and on the issue of what to do when variant entities don't have URLs did not come to a resolution, and will have to be worked out on the list. >From the subgroup's point of view, Koen Holtmann's draft is ready for comments and implementation experience; some experimentation has occurred, but more experience on interoperation is needed. The content negotiation subgroup has not yet addressed feature set negotiation at the content-level; Koen has just submitted a draft on that, but it has not yet received much review. Harald Alvestrand expressed some misgivings about a draft which allowed for negotiation on only four axes and which did not have a mechanism for further extendibility. He felt that it might be possible to crate a more open framework which used the RFC process to declare dimensions for variability. The group agreed that adding extendibility to the draft would be considered. State Management: David Kristol gave the status report of the State Management subgroup. The group has adopted a variant of the Cookie proposal originally proposed by Netscape. A tighter syntax has been proposed as well as new hostname matching rules which help protect privacy by avoiding leakage of usage data across sites. Open issues for the group are: the response header for Set Cookie: ; whether spaces are allowed around the equals sign in attribute value pairs; default behavior of the Path attribute; the domain matching rules; and what to do when multiple matching cookies are available. On a larger level, interoperability between the older cookie format and the newer format may force the creation of a version number for the cookie headers, though every effort has been made to make the two very similar in usage. The working group came to the consensus that cookies were an optional part of the HTTP specification but that those who created cookies within the HTTP context should do so according to this document's specifications. The group also appeared to agree that this would be a separate document which advanced with the main HTTP 1.1 document (or document set), rather than being folded into the base document. Thursday session: HTTP MIB: A separate BOF considering a MIB for HTTP servers met at IETF this week. Carl Kalbfleisch reported on the meeting of HTTPMIB BOF. That group is interested in extending the work of the MADMAN group to create a standard way to monitor the health of a web server. Two draft mibs are already available. Further information is available at http://http-mib.onramp.net/ ; to join the mailing list, send mail to http-mib-request@onramp.net with "subscribe http-mib Your Name" in the body of the message. HOST Redux: John Klensin raised issues about the deployment of the Host: header field under constraints that appeared in the HTTP/1.1 draft. He presented an argument for changing the syntax of the base http methods so that all use fully qualified domain names and full URLs. This would provide a more elegant solution to the "vanity domain" problem which is currently consuming IP addresses than the proposed HOST command, which he believes might easily be misimplemented. The sesne of the meeting was that, while this was an elegant solution, it would break a large number of existing servers and the desire for interoperability with older implementations would force providers to keep associating vanity domains with unique IP addresses. As an implementation plan, the group will tighten the wording on HOST to make it clear that it is a MUST, and plan to make the shift after widespread deployment of HTTP 1.1. APPS/TSV: On Monday, there'd been an APP/TSV open meeting on the impact of the Web on the Net. Jim Gettys reviewed his presentation. The basic problem is a "tragedy of success". There are so many users of the web that congestion is becoming endemic on many links, especially those which are transatlantic or transpacific. The routing table caches are also being rendered useless by the relatively short packet trains of http. Possible long term solutions include multiplexing connections, a multicast transport layer, and extensive caching networks. Projections are for an eventual growth in the web of four orders of magnitude, so we need to address this problem as quickly as possible. Persistent connections should help to some degree, but there will remain potential fairness problems in allocating bandwidth. Web Transaction Security: Larry Masinter reported on the results of WTS working group meeting. The WTS working group will clarify the relationship of SHTTP and HTTP in their current draft, and then it will likely move forward as a proposed standard. This will put some constraints on what the HTTP 1.1 documents can say about security. As working group chair of HTTP, Larry feels that the work on security relatives to HTTP is taking place in WTS and encourages those interested in that area to work with both groups. Digest Authentication is a special case which will be finished in this working group; it should, subject to problems with the wording, be in HTTP 1.1. Persistent connections: Alex Hopmann presented the results of the persistent connection subgroup. The persistent connection subgroup took as its goals proxy support, simplicity, 1.0 compatibility, and fast deployment. The subgroup has come to consensus on the use of Connection: persist as header, along with Persist: (Keepalive: must also be sent to maintain 1.0 compatibility). These headers must be deleted by proxies; they apply only for one hop. If the next hop server replies with the same headers, it will then keep open the connection after sending its response. The client may pipeline requests and the server may pipeline responses. The server must, however, reply to requests in the order they were received. Discussion in the working group of marking entity boundaries came to the consensus that chunked transfer encoding would be required but not whether support for multi-part mime would be optional, required, or omitted. Further discussion on the list will be needed to clarify support level. Range retrieval: Ari Loutonen presented the changes to the Range-retrieval proposal; they are very few--only the if-valid and if-invalid sections have changed substantially. Discussion of how range retrieval interacted with caching concentrated on reducing the number of headers, with the conclusion that logic bags would not actually reduce the number of possible choices needed for completeness, even if those choices were squeezed into a smaller number of headers. Extensions: Rohit Khare reviewed the status of PEP, the Protocol Extension Protocol. He believes that the syntax for PEP is currently complete and ready for review by this group, but he does not believe that it is a critical path item for HTTP 1.1. The principal changes in PEP are the addition of scope and the deprecation of a central registration of protocols. PEP does require a minor version upgrade in HTTP, but only a minor version. Discussion presented a number of issues related to the association of related extension protocols (or version of extension protocols); no resolution was reached, however, and they will be continued in conversation with the authors. Demographics: Brian Behlendorf gave an introduction to the demographics work currently going on in the W3C; this work would set up a common logging format for proxies and develop methods for servers to interact with proxies to retrieve information on transactions they have handled. This system sees the proxies as acting on behalf of the server; John Klensin challenged this trust model by noting that historically proxies have acted on behalf of the user. Legal issues were also raised about both privacy and legality of storing cached material in the absence of an agreement; after polling the group, Larry Masinter declared demographics not on the critical path for 1.1, but within the scope of the group. Logistics: In a discussion on logistics led by Jim Gettys, the group established a timeline which would lead to a draft being sent to the IESG on May 1st. According to this timeline, a small group will conduct an immediate triage on issues which can, might, or cannot be resolved in time for a May 1st draft. This will be reviewed by the group and sent to the ADs; a feature list and a structure for the set of documents will be presented by March 18th. A draft will be ready for working group review by April 1st. Jim intends for the group to follow the issues list very closely, and asks that clarifying discussions be conducted off-list and then reported to the list. Concrete wording for suggested changes will be essential for this timeframe, and he encourages us to agree to defer quickly what cannot be resolved, so that we can accomplish what is needed immediately. Thursday afternoon: A smaller group met on Thursday afternoon to continue the discussion of logistics. The group reviewed a calendar and worked backward: We accepted that it was important to influence the next release of HTTP products from major vendors; we were given information that having a proposed standard by May 15 is important. No product can claim to 'comply' with the draft until the draft has been accepted by IESG as an action item by the IETF secretariat. Giving allowance for the web conference, and the possibility that the first draft might bounce, it seems important to submit the HTTP/1.1 draft to IESG by May 1. Working backward from that, this meant having a new draft ready by April 1. The calendar we came up with was: March 13 - Review issues March 15 - Feature list & structure of the document(s) set April 1 - Updated draft to W.G. April 2 - Start new issue list specifically on updated draft April 24- W.G. last call May 1 - IESG submission of 1.1 draft. The group then reviewed the issues list: http://www.w3.org/pub/WWW/Protocols/HTTP/Issues/http-wg.html and assigned owners to each item to shepherd the issue through and propose revised text.