NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.
Dave Raggett <dsr@w3.org>
Larry Masinter <masinter@parc.xerox.com>
Applications Area Director(s):
Keith Moore <moore+iesg@cs.utk.edu>
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
Keith Moore <moore+iesg@cs.utk.edu>
General Discussion:http-wg@cuckoo.hpl.hp.com
To Subscribe: http-wg-request@cuckoo.hpl.hp.com
In Body: subscribe http-wg Your Full Name
Archive: http://www.ics.uci.edu/pub/ietf/http/hypermail
Note: This working group is jointly chartered by the Applications Area and the Transport Services Area.
The HTTP Working Group will work on the specification of the Hypertext Transfer Protocol (HTTP). HTTP is a data access protocol currently run over TCP and is the basis of the World-Wide Web. The initial work will be to document existing practice and short-term extensions. Subsequent work will be to extend and revise the protocol. Directions that have already been mentioned include:
· Improved efficiency · Extended operations · Extended negotiation · Richer meta-information · Ties with security protocols.
Note: the HTTP working group will not address HTTP security extensions as these are expected to be the topic of another working group.
The initial specification of the HTTP protocol was kept in hypertext form and a snapshot circulated as an Internet draft between 11/93 and 5/94. A revision of the specification by Berners-Lee, Fielding and Frystyk Nielsen has been circulated as an Internet draft between 11/94 and 5/95. An overview of the state of the specifications and a repository of pointers to HTTP resources may be found at http://www.w3.org/hypertext/WWW/Protocols/Overview.html.
Once established, the working group will expand and complete that document to reflect HTTP/1.0 as it has been implemented by World-Wide Web clients and servers prior to November 1994. The resulting specification of HTTP/1.0 will be published for review as an Internet-Draft and, if deemed appropriate, will be submitted to the IESG for consideration as a Proposed Standard or Informational RFC.
In parallel with the above effort, the working group will consider enhancements/restrictions to the current practice in order to form a specification of the HTTP protocol suitable for eventual consideration as a proposed standard.
In addition, in parallel with the above efforts, the working group will engage in defining (or selecting from various definitions) a next-generation protocol for hypertext transfer (HTTPng).
A description of HTTP/1.0 as it is generally practiced currently on the Internet has been submitted to become an Informational RFC. The working group is considering enhancements/restrictions to the current practice in order to form a specification of the HTTP protocol suitable for eventual consideration as a proposed standard.
Goals and Milestones:
· PEP: an Extension Mechanism for HTTP
· Transparent Content Negotiation in HTTP
· Simple Hit-Metering and Usage-Limiting for HTTP
· Feature Tag Registration Procedures
· Use and interpretation of HTTP version numbers
· HTTP Remote Variant Selection Algorithm -- RVSA/1.0
· The User Agent Hint Response Header
· Problem with HTTP/1.1 Warning header, and proposed fix
· HTTP State Management Mechanism (Rev1)
· HTTP Connection Management
Request For Comments:
The group concentrated on closing outstanding issues. Jim Gettys led a review of the issues list (http://www.w3.org/pub/WWW/Protocols/HTTP/Issues/).
In the discussion, the following issues seemed to have sufficient consensus in the meeting that "last call" would be sent to the mailing list for each of them:
"Chunked encoding" clarification The caching issue raised by Dingle Accept-charset wildcarding Proxy authorization The FIN-WAIT2 issue Jeff Mogul's resolution for connection Impermissability of CRLF in a quoted string
Jeff Mogul's drafts on HTTP versions and proxy-revalidate will also go to last call in their current forms.
The following issues are resolved in principle, but require language to cover the needed editorial changes or clarifications:
· Content-Disposition will be added to the Appendix, as one of a group of common MIME headers about which implementers should be aware; Koen Holtman will draft the addition. · The draft by Gettys et al on who should close the connection represents valuable information and advice, but needs continued development. A new version is expected shortly. · Richard Gray will provide language on sending 100 series response codes with no date headers; Jim Gettys will then fold these into the main document. · Jeff Mogul will draft an explanation of how to cache resources containing a "?" in the context of HTTP 1.1. · Paul Leach will provide an examination of the use of byte-ranges with PUT, with the understanding that there is mild applause in the working group for eliminating the possibility of PUT with byte-ranges. · Ted Hardie will draft a missive on how to respond to a request for a range of bytes for a resource that contains none of the bytes in the range. · Roy Fielding's solution for how to define max-age for responses is accepted in principle, subject to minor wording changes to be worked out between Jeff Mogul and Roy. · Larry Masinter will author an implementation note on the desirability of including charsets in responses. · Paul Leach will pen a note on a proxy being able to serve a resource with a content-length when it receives that resource with chunked-encoding. · Scott Lawrence will provide a sentence or two that will cover the possibility of leading zeros in a content-length. · Koen Holtman will draft a clarification that a qvalue of 0.0 means "Don't send me this." · After consulting the language in use in RFC822, Koen Holtman will also draft an editorial correction on the use of LWS in headers like VIA. · Jeff Mogul will respond to syntactic changes proposed by Koen Holtman for the HTTP-warning draft; if appropriate, a new version of the draft will appear. · The Hit-metering draft will go last call after Jeff checks it for one last set of editorial revisions.Not all issues reached closure. For those that did not, particular individuals may have accepted responsibility for providing next steps. In all cases, however, input from others is solicited.
Josh Cohen will take responsibility for re-raising the issue of using an equality check for date if modified on the list.
While there is general agreement that 305 should be limited to use by origin servers, the proposal by Josh Cohen for 306 needs both concrete language and further discussion of the implications of a proxy-managed proxy redirect. Josh Cohen will provide a draft explaining Netscape's vision for 306.
The issue of how to handle age calculations remains contentious; Jim Gettys has suggested that a small group interested in the problem should get together and work out a solution. Those interested in being part of that group should volunteer on the list; implementers of proxy caches are particularly encouraged to share their experience. To help minimize this issue, Jim will draft language that strongly encourages proxies to run with synchronized clocks.
Jeff and Henrik raised the issue of inappropriate client behavior on receipt of a content-encoding that it does not understand. Henrik will draft a document proposal to fix the problem; since this touches on the difference between different content-header types, careful review of the proposal by the working group is needed.
Josh and Henrik will work off-line on the question of what a client should use in the HOST: header when it has a URL with a host part that is not a fully qualified domain name. Regardless of the outcome of that discussion, Paul Hoffman will draft language proposing that the client be allowed to chop the host part out of the URL and use that.
Discussion of the two proposals should consider in particular the difficulties faced by clients who would have to resolve hosts into fully-qualified domains and the difficulties faced by proxies without access to fqdns as identifiers.
Henry Sanders will check Microsoft's implementation of chunked encoding to ascertain whether the Digest Authentication headers can be placed in the chunked encoding trailer. If it does and there is no contrary implementation, the issue is closed; if it does not, the working group will need to examine the interoperability issues of allowing those headers in the trailer.
The question of sending a Retry-After with 503 and 3xx response codes has been tabled, pending Mr. Briscoe's providing a compelling reason for allowing the Retry-After.
Jeff and Henrik will write up a short draft on how to optimize returns on range requests by removing meta-data which is not needed to assure the client that the range returned is part of the correct resource.
Henry Sanders will review based on implementation experience at Microsoft.The issue raised by Koen Holtman regarding the asymmetry in matching rule for accept language in 14.4 produced a great deal of debate on the appropriate matching semantics. Dirk van Gulik will identify the appropriate ISO documents that indicate why matching semantics based on wildcards will not handle all cases. Since HTTP's use of language tags is derived from RFC 1766, changes needed in HTTP might, in fact, reflect changes needed in RFC 1766. Exactly how much of the matching algorithm belongs in the protocol is not clear, and further discussion will be needed on the mailing list.
Discussion of Koen Holtman's draft on Safe Post and Dave Morris' draft on UA-hint focused on two issues: whether safe post and history list manipulation belong in the same mechanism and which of the two proposals best handle the issue. No consensus emerged, but interest in this in certain user communities (banks, etc.) is high enough to warrant further work. Some indications were given that progress might be faster after splitting off the history list issue from the safe post issues required for i18n, but, again, no real consensus emerged.
Dan Connoly presented the new PEP draft. Three major issues were raised: PEP can be overkill for some small, lightweight extensions; the cost of discovering whether or not a server understands PEP and a particular extension can be significant; and the draft's language for how to handle these extensions through HTTP 1.0 proxies does not seem adequate. Koen Holtman suggests that the language in the hit-metering draft is a good model for how to handle PEP with 1.0 Proxies. Dan will look at that language and the other objections; a new draft is expected.
Koen Holtman presented a portion of the TCN drafts; time constraints did not allow the group to consider the full set. The base portion of TCN is now stable, and there are server side (Apache) and client side (Tango) implementations. Preliminary indications from Dirk's experience as a server implement are that this is a very successful mechanism for negotiation on things like image format, but that language and character set encoding need more implementation before they can be fully evaluated. Yaron Golan (not speaking officially for Microsoft) noted that he does not feel that TCN is rich enough for the applications he envisions; he feels that script-based solutions would be required for any meaningful content negotiation, and these solutions would both enable better server/author control and would shift the computational locus to the client. Scott Lawrence and Ted Hardie spoke in favor of the TCN framework, noting that it is richer and leaner than Accept headers while being fully interoperable. A counter-proposal by Mr. Briscoe will be sent to the list in the form of a paper. The chair ruled after discussion that the working group is not ready for last call on these drafts.
Dave Kristol presented his new Cookie draft and discussed, briefly, the controversy that has surrounded the subject. ("In the case of RFC 2109, it was a Request For Comments, and it got some.") Two classes of problems were raised: interoperability problems and objections to the default settings required by 2109. The interoperability problems are being addressed in the new draft. Those objecting have been invited to present alternative proposals. Dan Jaye, of Engage Technologies, has proposed one solution, but it requires a public key infrastructure that would delay deployment too long. His work and other solutions for resolving the tension between user privacy and traffic can go forward independently, but, based on Area Director input, we should not repeal what we have in favor of a technology which will take a year or more to put in place. Interested parties should note that the W3C is putting together a forum to address this issue.
The session closed with the Chair noting that the main work of the group should be progressing HTTP 1.1 from Proposed to Draft Standard and that he hopes to close the working group by the next IETF meeting in Munich. Other groups working on specific problems may be needed, but he believes we have reached a stage where they can operate independently.