NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.
Chair(s):
Larry Masinter <masinter@parc.xerox.com>
Dave Raggett <dsr@w3.org>
Applications Area Director(s):
Keith Moore <moore+iesg@cs.utk.edu>
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
Applications Area Advisor:
Keith Moore <moore+iesg@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 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 which have already been mentioned include:
· Improved efficiency,
· Extended operations,
· Extended negotiation,
· Richer metainformation, and
· 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 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.
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
· Simple Hit-Metering and Usage-Limiting for HTTP
· Feature Tag Registration Procedures
· 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
· HTTP Trust Mechanism for State Management (Rev 1)
· Scenarios for the Delivery of Negotiated Content using HTTP
· 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
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 | |
Minutes of the HTTP Working Group
Reported by: Koen Holtman, Martin Durst and Chantelle Cooper.
Edited by: Larry Masinter, based on minutes
I. Monday, August 11
The group focused on the issues in the issue list: http://www.w3.org/pub/WWW/Protocols/HTTP/Issues/ Numbers in [brackets] are the issue number in the issue list.
The 08 version of http/1.1 draft did not appear in the internet drafts directory before the meeting; the Internet Drafts editor had problems processing last minute submissions.
[1] 301-302, [2] VERSION, [3] RE-VERSION were discussed Monday, but see notes on Tuesday session.
[4] REDIRECTS
(How many redirects required?) We discussed the issue of the limit on the number of redirects that a server can expect a client to implement. Proposal: this belonged in an application profile (of HTTP, HTML, etc.) and not in the HTTP spec, which should have mandatory (SHOULD, MUST) redirects removed and replaced with an implementation note.
[5] LINK_HEADER
There seems to be a conflict between HTML and HTTP regarding the interpretation of Link header. Resolution: Remove the Link header from the main HTTP/1.1 spec. Dan Connolly will submit a Draft to align HTTP and HTML definitions of this header. The draft may proceed on standards track independently.
[6] CONTENT-ENCODING
The room seemed to be happy with the proposed resolution; also, it seems to be consistent with Apache and MSIE implementations.
[7] CACHING-CGI
We got into this state because some origin servers might have counted on the (simple optimization) that proxies (usually) didn't cache URLs with queries or /cgi/ in them. But this was never part of the specification. We concluded that the new text in the -08 revision (requiring caches to treat responses as uncacheable based on some patterns in the request URL) should not stay as a requirement. Jim Gettys will revert the requirements for treating responses as uncacheable to those in the 2068 RFC. He may rework the new URL pattern text into an implementation note.
[8] WARNINGS
Klaus Weide sent comments to the mailing list which should be responded to. There are several issues that are left to be resolved.
[10] OPTIONS
(See notes discussion on Tuesday)
[11] DATE-IF-MODIFIED, [12] 403VS404: these were declared 'editorial', see next draft for proposed wording.
[13] PUT-RANGE
We discussed whether we should deal with this issue at all, or merely forbid PUT with a byte range in HTTP/1.1. Proposed resolution: warn that using PUT with byte ranges is dangerous and not compatible with 1.0 or servers that don't accept-ranges. The WEBDAV group worked on this, but seem to have decided that it was too complex. Paul Leach will submit a proposal soon; the WG will wait and see how complex Paul's proposal might be.
[14] HOST
Jim Gettys will draft proposed text, to the effect ("Proxy can add, but not rewrite")
[15] AGE-CALCULATION
This issue has been debated at length. Jeff Mogul will submit an internet draft countering the position on this issue taken in Roy Fielding's draft. Once we have two drafts, we will evaluate them and decide.
[16] RE-AUTHENTICATION-REQUESTED
Should there be a revalidation request code? This needs mailing list discussion. It's marked as 'drafting'.
[17] SAFE [18] UAHINT
Given the current status, Keith Moore's suggested these be released as Experimental RFCs. Larry Masinter will initiate this.
[19] AUTH-CHUNKED
The proposed fix is in draft 08 and ready for last call.
[20] REQUIRE-DIGEST
There needs to be some way to require that Digest authentication be used. The draft has been issued and is ready for last call; John Franks had comments that need to be responded to.
[21] PROXY-REDIRECT
There was a lot of discussion about security and privacy issues, and the 08 draft does not address these issues. In particular, the scope restrictions in 305 processing are not restrictive enough, and alternative scoping rules are needed. There may be a privacy concern with respect to redirection of client requests to other servers without informing or asking the user for consent. There's a security difficulty with a permanent redirection to a proxy without user recognition or consent.
Yaron Goland had doubts about defining the 306 functionality inside HTTP; formats different from the Set-Proxy header format may be more appropriate as a means of reconfiguring client caches. It was decided to continue this discussion outside the meeting.
[25] PROXY-LENGTH
The content-length additions to the 08 draft caused some self-contradictions. Koen Holtman will send a message about this to the mailing list.
[34] QUOTED-BACK ([32] COMMENT)
A compatibility note seemed to be missing from the 08 draft. Jim Gettys will add this note, with appropriate cross-referencing.
[204] DISPOSITION RFC 1806
Keith Moore's Content-Disposition document, which is currently in the RFC pipeline, doesn't mention the HTTP usage or syntax. Larry Masinter and Keith will put together a paragraph to be added to the C-D draft, either before or after it goes to RFC.
[59] CLOSE
(Who should close the connection?) Jim Gettys promised a revised internet draft soon.
[201] REQUIREMENTS (Need table of requirements like RFC 1122 and 1123.) We discussed creating the index of HTTP requirements. The requirements table can also serve as a checklist to document independent implementations for each HTTP/1.1 feature.
We discussed having a 'HTTP/1.1 interoperability test' event, as a means of documenting compliance and getting implementor feedback about remaining problems. There was a lot of interest. Quentin Clark offered to help organize this, in order to be able to report on the results of interoperability by the Dec 97 IETF.
[**] Basic/Digest
There was some confusion about the status of Basic & Digest authentication in the -08 draft. The goal is to keep "HTTP/1.1" as two documents, one on the main protocol and a separate draft on "authentication," but that both would be required for compliance with HTTP/1.1.
II. Tuesday, August 12
CONTENT NEGOTIATION
Koen Holtman gave an overview of the current Transparent CN drafts (draft-ietf-http-negotiation-03.txt, draft-ietf-http-rvsa-v10-02.txt), and the history, goals, and test implementations.
Jim Gettys noted that the "Alternates" header might progress faster outside of the rest of TCN. We decided to split draft-ietf-http-negotiation-03.txt into two drafts, one with the Alternates header which might move to Proposed Standard while the rest of TCN can move to Experimental status.
We discussed the feature registration drafts (draft-ietf-http-feature-reg-02.txt, draft-ietf-http-feature-scenarios-01.txt). It has wide applicability and should go to BCP. Some questions, such as "should features be URLs?" and "are the types used the right ones?" may need further examination.
Ted Hardie and Graham Klyne will expand the current draft-ietf-http-negotiate-scenario-01.txt into a more general requirement and scenarios document that will cover other cases of feature and capability negotiation; it will likely become an Informational RFC.
There is interest in forming a 'negotiation subgroup', which may continue working independent of HTTP-WG.
[2] VERSION [3] RE-VERSION (Version number returned by servers)
There was an offline discussion Monday afternoon, reported on Tuesday.
RFC 2145 might need clarification of the result of the interactions between CGI scripts, proxies, servers; old CGI scripts working with new servers.
The entity (or "message payload") version number should supercede the server's version number. The HTTP versioning requirements in RFC2145 will probably not cause problems for proxies. Some language should be added to the 1.1 spec to make it more clear what proxies should do, and what they cannot be expected to do, when upgrading and downgrading responses between 1.1 and 1.0. It was suggested that a proxy's cache entries be upgraded to the highest version of the client request & server response, as a solution to the ambiguity of labeling cache entries.
[1] 301-302 (Problems with redirecting requests.) Josh Cohen reported on the conclusions of an offline discussion. 302's historical use has not been changed by most servers and scriptwriters to the new definition in RFC 2068.
The text in the -08 draft should be changed, either by
reverse the meanings of 302 & 303, or
Deprecate 302 and add 307
The consensus of the meeting was to take path (a). The issue will be raised on the mailing list.
[**] PEP discussion
Discussion of Henrik's new draft of 14 July centered around the question of how much complexity is needed for a) querying about the availability of protocol extensions, and b) negotiating on and detecting the use of protocol extensions.
Yaron Goland said that the current PEP spec was so complex that he feared that lots of people would only implement subsets, with the subset implementations ending up being incompatible with each other.
Some alternatives to PEP were discussed:
· The proposed OPTIONS mechanism
· The old Mandatory header field mechanism
· An IANA-based header field name registry
OPTIONS is not a subset of PEP capabilities, and isn't intended to be.
It was the general feeling that something simpler than PEP might well be sufficient for meeting the HTTP protocol extension needs of the internet community, but that the WG did not have sufficient data to know for sure. Jim Gettys asserted that most potential users of PEP were not in contact with the HTTP-WG.
Some people reported that the JEPI initiative, which was planning to use PEP, is basically "dead." Someone from the RTSP group reported that they had implemented a subset of PEP, and that it could be possible that the RTSP needs would also be satisfied by OPTIONS or the Mandatory header.
Jim Gettys said that he felt that header clashes due to independently developed protocol extension were a real potential problem, and that the http-wg ought to address this problem in some way, either with PEP or with something else. Koen Holtman remarked that the current and previous PEP drafts caused their own header clash problems because they basically allocated all remaining header field names for potential use by PEP, and that this would have to be fixed if work on PEP were to be continued.
Keith Moore remarked that, from a distance, it looked to him as if PEP was a solution in search of a problem, and that PEP review might be out of scope for HTTP-WG.
[10] OPTIONS
Josh Cohen reported on his motivation for proposing the OPTIONS mechanism: he discovered that he needed it when specifying the proxy redirect mechanisms. He felt an urgent need for a mandatory HTTP/1.1 extensions discovery mechanism, and that it should be bundled with the main HTTP/1.1 spec. Josh wanted to keep the mechanism very simple, so that quick progress could be made, and feared that having a general registration mechanism in addition to the `RFC=' and `HDR=' vocabulary in the current options draft would slow things down too much.
Does the current draft really addresses the necessary option/extension discovery scenarios? For example, what if a server does not implement some SHOULDs in an RFC? Which SHOULDs are ignored? Yaron Goland noted that WEBDAV defined three levels of compliance, so that the `RFC=' mechanism in the current options draft would not be sufficient for WEBDAV discovery needs.
Larry Masinter (not speaking as the chair) noted that OPTIONS defined yet another name space, and that the namespace of options could probably use the proposed feature tag registry, and asked the working group to consider whether this was desirable. For that matter, the namespace could be shared with PEP extensions.
Koen Holtman cautioned against rushing out a mechanism too quickly, without careful consideration of all details.
We agreed to finish work on OPTIONS quickly, and consider it as part of the HTTP/1.1 spec or as a separate draft.
[***] Query Internationalization
Martin Durst briefly reviewed the issues in internationalization of web form submission, and the possible solutions, as recorded in his recent internet drafts. This issue goes beyond HTTP, but the proposed solution involves a negotiation mechanism based on a HTTP header (Query-UTF-8).
Those interested should discuss this issue on the www-international@w3.org mailing list.
[***] Status codes sharing
Johnathan Rosenberg was going to present draft-schulzrinne-http...but was missing from the room; we wound up not discussing the issue.
[***] State Management
[--] Cookie Comment/CommentURL
The working group mailing list seemed to have been filled with discussion of the Comment-URL feature.
Larry Masinter gave his (personal) views on the comment and commentURL mechanisms. While it is a very good thing for service authors to inform users about the cookie-related privacy policies of the site, the comment and commentURL mechanisms are not the appropriate mechanisms to convey this information, and that these mechanisms should be removed from the draft. There was some agreement on removing comment and commentURLs from the audience.
Koen Holtman said that, lacking a concrete proposal for an alternative means of conveying the information, he did not mind if comment and commentURLs stayed in.
[--] Set-Cookie2
There's some concern that discussion of the technical protocol in RFC 2109 was being held up due to concern about the privacy considerations and provisions in it. The objection to RFC 2109 is that it does not reflect current practice. Yaron Goland asserted that the changes in 2109 from Netscape's first cookie spec are not wanted and will not be implemented.
Larry Masinter suggested separating the draft into two parts, although releasing them simultaneously. One part would discuss the protocol, and the other draft would discuss the privacy considerations.
Dan Jaye reported on his recent revision of the trust-state draft. He said he would mail draft-ietf-jaye-trust-state-01.txt to the list soon (an attempt to mail it before the meeting failed). Dan Jaye and Yaron Goland asserted that implementers wanted to use PICS-based cookie labeling as a privacy technology, and not the proposals in the state management draft. Yaron Goland said that, in his opinion, the effort on revising the Set-Cookie2 based state management draft should be stopped. In stead, the http-wg should concentrate on writing a standard that documents the current Cookie header practice, limiting itself to security issues. In his opinion, the http-wg should not try to decide on privacy mechanisms, but instead document whatever privacy mechanisms the browser implementers would end up using.
It was noted that Cookies, as used in practice, present a security issue since they are used for authentication, and might represent passwords in the clear.
[**] WG SCHEDULE & MILESTONES
Larry Masinter led a discussion of the WG schedule. The goal is to move HTTP/1.1 to draft standard in November 1997. The content negotiation work should also be completed in November 1997. It was suggested that we could complete work on every document outside of the main non-HTTP/1.1 working items (for example TCN, state management) before the next IETF meeting in December. Closing the WG at or before the December 1997 IETF meeting is not realistic. Ongoing implementation efforts and planned interoperability tests may lead to additional HTTP/1.1 issues, and it is unlikely that the http-wg will be able to close all these issues before December.
Current schedule:
07/97: Hit metering to Proposed
08/97: additional drafts
09/97: additional drafts
11/97: HTTP/1.1 -> Draft Standard
Content negotiation drafts -> Experimental
The working group meeting ended with an announcement of the HTTP-NG requirements BOF on Thursday.
None Received