NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 27-Oct-97
Chair(s):
Larry Masinter <masinter@parc.xerox.com>
Dave Raggett <dsr@w3.org>
Applications Area Director(s):
Keith Moore <moore@cs.utk.edu>
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
Applications Area Advisor:
Keith Moore <moore@cs.utk.edu>
Mailing Lists:
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
Description of Working Group:
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 WorldWide 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:
o improved efficiency, o extended operations, o extended negotiation, o richer metainformation, and o 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.
Background information
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 WorldWide 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.
Also 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:
Done |
|
Draft working group charter. Establish mailing list and archive. |
Done |
|
Review draft charter for discussion at the Chicago WWWF'94 conference. Invest an interim Chair for the working group. Determine writing assignments for first draft of HTTP/1.0 document. |
Done |
|
Publish an Internet-Draft on HTTP as reflected by current practice (HTTP/1.0) |
Done |
|
Meet at the San Jose IETF as a BOF. Review HTTP/1.0 Internet-Draft and decide whether it should be published as Informational, should be a candidate for further working group development, or should be allowed to expire. Determine writing assignments for first drafts of the HTTP/1.1 or HTTPng documents. Establish charter and submit to IESG |
Done |
|
Revise the Internet-Draft on HTTP/1.0 and, if desired, submit to the IESG for consideration under the category determined at San Jose IETF. |
Done |
|
Final review of HTTP/1.1 draft at the Danvers IETF. Revise HTTP/1.1 draft and submit to IESG for consideration as Proposed Standard. Review progress on HTTPng. |
Done |
|
Final review of HTTPng draft at the Dallas IETF. Revise HTTPng draft and submit to IESG for consideration as Proposed Standard. Retrospective look at the activities of the HTTP WG. |
Done |
|
Initial publication of HTTP/1.1 proposal from document editors. |
Done |
|
Publish Internet-Drafts on HTTP/1.0 |
Done |
|
Complete review of HTTP/1.1 proposal and pending I-Ds by subgroups: Persistent connections; cache-control and proxy behavior; content negotiation; authentication; state management; range retrievals; extension mechanisms; other new methods and header features. |
Apr 96 |
|
Submit HTTP/1.1 as Internet-Draft (editing team led by Jim Gettys). |
May 96 |
|
Submit HTTP/1.1 to IESG for consideration as a Proposed Standard. |
Jun 96 |
|
Review additional features for HTTP/1.2 |
Oct 96 |
|
Submit HTTP/1.2 to IESG for consideration as a Proposed Standard. |
Internet-Drafts:
· PEP - an Extension Mechanism for HTTP
· Transparent Content Negotiation in HTTP
· Feature Tag Registration Procedures
· HTTP Remote Variant Selection Algorithm -- RVSA/1.0
· Problem with HTTP/1.1 Warning header, and proposed fix
· The User Agent Hint Response Header
· HTTP State Management Mechanism
· HTTP Connection Management
· HTTP Trust Mechanism for State Management
· Scenarios for the Delivery of Negotiated Content
· HTTP/1.1 305 and 306 Response Codes
· Feature Tag Scenarios
· Specification of HTTP/1.1 OPTIONS messages
· An Extension to HTTP : Digest Access Authentication
· Format and Example of HTTP/1.1 Requirements Summary
· The Alternates Header Field
· Hypertext Transfer Protocol -- HTTP/1.1
· HTTP Authentication: Basic and Digest Access Authentication
Request For Comments:
RFC |
Status |
Title |
RFC1945 |
Hypertext Transfer Protocol -- HTTP/1.0 | |
RFC2069 |
PS |
An Extension to HTTP: Digest Access Authentication |
RFC2068 |
PS |
Hypertext Transfer Protocol -- HTTP/1.1 |
RFC2109 |
PS |
HTTP State Management Mechanism |
RFC2145 |
Use and interpretation of HTTP version numbers | |
RFC2227 |
PS |
Simple Hit-Metering and Usage-Limiting for HTTP |
Minutes of the Hypertext Transfer Protocol (HTTP) Working Group
Chair: Larry Masinter
Minutes were recorded by Jim Whitehead, Daniel Veillard and Rohit Khare, edited by Larry Masinter. These minutes combine the notes from Monday December 8 and Wednesday December 10.
Jim Gettys led a review of issues from the issue list. Most of these issues reflect edits that were already in draft-ietf-http-v11-spec-rev-01.txt but needed additional review.
New issue AUTH-INFO-SYNTAX: New issue, reviewed for the group, but no conclusion.
New issue DIGEST-PROBS: Reviewed briefly, but take to the list.
Henrik presented CONTENT-ENCODING and a proposed solution: add to accept-encoding "*" (meaning all encodings), "identity" (meaning no encoding), and q values (for yes and no). There are some proxy issues with respect to content-encoding and transfer encoding: a Content-Encoding can go through proxies, but a Transfer-Encoding cannot. Dropping q values would avoid 406 codes from existing HTTP/1.1 servers, but would not fix some current problems. After discussion on whether any clients will support this, and a proposal of a "Decline-Encodings" header, the preferred solution is to use the solution in the issues list. This will be discussed more on the mailing list.
Issue PUT-RANGE: Few people had reviewed the rev-01 draft. There was no implementation experience with this in the room ( Henrik claims that he might have implemented something similar, once). On Wednesday, we discussed that the use might be in a proxy which updates a byterange of its _cached_ copy at the same time it passes back to the origin. But 1)in WebDAV, many proxies may have partial views of the update changes. So, you'd have to recheck e-tags to update caches -- and redownload all that material. 2) more to the point, editing usually adds and removes material, which put-range does not do. This feature requires a robust version number to detect the feature; a server that did PUT but not byteranges would REPLACE the whole resource; thus it should be forbidden, not just discouraged. We agreed to leave PUT with byte-ranges out of HTTP/1.1 (discouraged or forbidden). The WebDAV group may propose a PATCH method to handle this capability instead.
Issue DIGEST_SYNTAX: was reviewed, but will be discussed on the list.
Issue PROTECTION-SPACE: People are happy with the current language, but current implementations don't behave as specified; the spec doesn't break any existing implementation. We'll go forward with the current language in rev-01.
Issue CONTRADICTION: The Proxy-Length change introduced an error. The proposal in rev-01 was accepted.
Issue IMS_INM_MISMATCH: The proposal in rev-01 was accepted.
Issue BYTERANGE_SYNTAX: This is a subtle problem; some implementors seem to want to be too smart. We need to specify that you should do the "dumb" thing, not the "smart" thing. The proposal in rev-01 was accepted.
Issue PROXY-REDIRECT: The functionality is desirable (e.g., for switching to a new protocol in the future, via use of proxies), but someone from needs to develop a draft to address this problem. Resolution: add note to spec. to deprecate 305, and note that it should not be implemented. Document security problem with this status code.
Issue RE-AUTHENTICATION-REQUESTED: Most current clients do not discard credentials when they receive a 4xx status code. Roy Fielding had suggested that an extra header should be used to inform the client to discard credentials. One problem with this approach is the server does not know if the client really has discarded credentials. Resolution: add a note to the security considerations indicating that this issue exists, but has not been addressed in the specification. This should not be in the Draft Standard 1.1 spec. Scott Lawrence may develop an Internet-Draft to address this issue outside of the Draft Standard.
Issue RANGE_WITH_CONTENTCODING: Should range requests apply before or after content coding? On Wednesday, we agreed to "last call" the resolution in rev-01.
Issue TRAILER_FIELDS: Discussion on why this is needed, and whether clients are likely to support this. On Wednesday, we agreed to "last call" the resolution in rev-01.
Issue HOST: Resolution in rev-01 is closed.
Issue RE-VERSION: (Wednesday) If you DON'T upgrade the request, you'll get a lower version answer for your cache -- a subsequent 1.1 request CAN'T be satisfied from a 1.0 cached response. 1.0 requests can be answered from 1.1 responses. Richer responses can always be used to answer simpler queries. Henry Sanders will post his remarks to the list, and then RE-VERSION will be closed.
New issue DIGEST-SCALING: (Wednesday)
RFC 2069 had one concern raised: Digest does not work well with proxies and not at all across multiple servers. Paul Leach will soon post to the list a small tweak which addresses both (and issue a new I-D?).
I. State Management
Dave Kristol reviewed State Management
Timeline:
December, 1995 [sic!] state management sub-group formed
April, 1996 first Internet Draft, http-state-mgmt-00
July, 1996 I-D submitted as prospective RFC, minor wording tweaks for IESG in Oct., Nov.
February, 1997 RFC 2109 issued
RFC 2109 Issues:
compatibility (interoperability): client behavior on unrecognized attributes
privacy - especially "unverifiable transactions" user
interface requirements - arising from support of privacy protection
RFC 2109 Follow-up, since February:
Compatibility (interoperability) - Define Set-Cookie2 response header
privacy and user interface requirements - temporarily delete contentious parts
Major Changes Since RFC 2109:
Set-Cookie -> Set-Cookie2
add CommentURL attribute
add Discard attribute
add Port attribute
fuss with Domain, domain matching
clarify behavior for unrecognized or duplicate attributes
State Management Progress Plan
current draft: http-state-man-mec-05 - "pure protocol" (more or less)
do Last Call on -05
restore privacy/user interface parts
discuss and seek consensus
reach Last Call
submit result to supersede RFC 2109
Where to look:
DMK's cookie page - http://portal.research.bell-labs.com/~dmk/cookie.html
Current draft (draft-ietf-http-state-man-mec-05.txt)
HTTP-WG mailing list - http://www.ics.uci.edu/pub/ietf/http/
http-state mailing list - http://www.bell-labs.com/mailing-lists/http-state
Following the slide presentation, there was discussion on the privacy considerations in the draft. Ted Hardie: In Comment-URL, the URL could potentially be a non-HTTP URL, and this issue needs to be addressed.
Dan Jaye presented some information on further work on trust labels.
State Management will proceed as an informal working group. There is no plan to form a formal IETF working group at this point. On Wednesday, it was reported that a small group of developers reviewed the outstanding issues with state management and found one technical and one political problem left. Technically, domain matching does not work with flat (intranet) domains where "foo." is an FQDN. The political issue is user notification of cookies from unverifiable transactions -- should people be tracked by an external source of inline images or applets or audio?
Extensions
Josh Cohen gave a presentation on OPTIONS and PEP:
Motivation - Extensibility
· Both OPTIONS and PEP were intended to provide more robust extensibility mechanisms for HTTP/1.1.
Extensibility of HTTP/1.1
· Clients can advertise some kinds of capabilities using Accept-*headers.
· Clients and Servers can prevent inappropriate caching by 1.1 Proxies using Vary and Cache-Control. This may result in cache misses that could have been hits, but can if used correctly prevent hits that should have been misses.
· Clients have _very_ limited ability to discover whether or not a Server implements a given extension. The response version number and the OPTIONS method are the only mechanisms available.
· No mechanisms for discovering which optional or extension headers are supported.
· No mechanisms for discovering which optional or extension headers are supported, or what definition of a given header is implemented.
· Discovery of Proxy capabilities by either Clients or Origin Servers is worse.
History
These issues have been discussed on the WG list since (at least) early 1995, insufficient consensus has been reached to incorporate stronger general purpose discovery mechanisms into the standard.
Issues Resolutions for Draft Standard
OPTIONS: Incorporate only the minimal definition (no defined body for OPTIONS response, only use the Allow header field).
PEP: Possibly proceed as an Experimental RFC, nothing in Draft Standard.
Futures
· Extensions to HTTP are being actively developed, both by and within IETF (UAhint, Safe, Content Negotiation, State Management, WebDAV, Hit Metering)
Guidelines for Extensions
HTTP-WG has learned (and relearned) about many problems inherent in each of the possible means of extending HTTP (new methods, new headers, new values or semantics in existing headers). Protocol mechanisms have not been defined to avoid or mitigate all of these possible pitfalls.
It would seem to be a good idea to develop an archival document (FYI, BCP?) to capture some of this knowledge as advise to others who will develop and attempt to deploy HTTP extensions. This will not be a work item of the HTTP working group.
After discussion Monday and Wednesday, a new working group (HTTP EXTEND) will be chartered. It is important to move forward on this because there are a large number of working groups that want to layer themselves on top of HTTP.
There is a need to develop a document that explains both the "dos" and the "don'ts" of extending HTTP. This document should start with the "don'ts" so they can be captured to prevent future bad practice.
The HTTP Extension group will develop PEP, the HTTP extension guidelines document, and the OPTIONS draft. The Extensions team reported a strawman charter for 1) producing an FYI document of guidance on adding features, headers, and methods to HTTP, 2) extending error response codes, 3) and simplifying PEP and OPTIONS into a reliable extension hook. It is NOT an HTTP/1.2 group. Josh Cohen and Scott Lawrence will chair and edit, respectively, an investigation into how-to-extend, not what-to-extend.
Other extensions were discussed, e.g., transactional HTTP. People forget about interaction with proxies in general; it should be explicitly considered.
The group will also take on Schulzrinne's extend error codes work. (JG thought arguments against on http-wg were really bogus.) A report on experience reading PEP: it was necessary to talk to Henrik to figure it out. A requirements document may be necessary and will be considered.
There is no formal requirement for a separate BOF, but the IESG may need to announce the working group.
Keith Moore asked for volunteers for a document to integrate TLS and HTTP. Rohit Khare volunteered.
III. Interoperable Implementations
To advance to Draft Standard, we need to document at least two independent, interoperable implementations of each feature. It isn't necessary that the features be in the same implementation, and the implementations need not be shipping products.
Tuesday night, a half-dozen client, server, and proxy developers sat down with the chair and editor to walk through the draft section by section. The main insight was that we'll need much more systematic support to document the hundreds of requirements in HTTP/1.1. Caching, in particular, seems to be the most fraught with difficulty. Scott Lawrence agreed to continue his (very useful) Thursday testing bees; and there was a survey of interest in face-to-face implementation bake-offs or conference calls.
IV. Web Privacy
User Services sponsored a BOF on Web Privacy. April Marine reported the broad support for investigating the nexus of trust issues around the Web. A detailed charter awaits debate, though, on web-priv@nasa.gov. A second BOF is projected for LA.
V. Content Negotiation
Recipient Feature Profile (nee content-negotiation), weaves together extensibility threads from HTTP, printing, fax, mail, and many other application layer protocols. Ted Hardie reported the conviction the group will set up a registry as quickly as possible. Then, it may tackle aggregation of features and a prototypical example of how to store profiles within LDAP, etc.
VI. HTTP-NG
W3C has been working on experiments for HTTP-NG, which had a BOF at 39th IETF and will surely be heard from in 1998.
VII. CONCLUSION
A poll ("Will there be an HTTP/1.2?") had a lot of responses, split 50-50. This was the last planned meeting of the HTTP working group. The group's chartered work is nearly complete, and no further meetings will be necessary. Additional work will happen in other groups or outside a formal working group. The mailing list will remain open. We're not really done: one estimate was that 20 more issues will be raised from the interoperability testing. But regardless, this was the LAST meeting. Scott Lawrence commits to continuing Thursday interoperability tests until such time as testing becomes uninteresting. The HTTP-WG mailing list will remain open indefinitely (or until Standard status two years from now).
None Received