NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 23-Jul-98
Chair(s):
Larry Masinter <masinter@parc.xerox.com>
Applications Area Director(s):
Keith Moore <moore@cs.utk.edu>
Patrik Faltstrom <paf@swip.net>
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 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:
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 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
· HTTP State Management Mechanism
· HTTP Trust Mechanism for State Management
· Format and Example of HTTP/1.1 Requirements Summary
· 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 |
RFC2295 |
E |
Transparent Content Negotiation in HTTP |
RFC2296 |
E |
HTTP Remote Variant Selection Algorithm -- RVSA/1.0 |
RFC2310 |
E |
The Safe Response Header Field |
Minutes for the HTTP working group; Larry Masinter, Chair
42nd IETF. Monday August 25, 1998
Reported by Ted Hardie (hardie@nasa.gov) and
Larry Masinter; please send any corrections or additions ASAP.
This (really!) was the last meeting of the HTTP working group at IETF. The intent is
to have final drafts submitted to internet-drafts, and forward to the ADs for Last Call,
by the end of this week.
Agenda:
- Implementation reports
- Main draft: report on final issues
- Authentication draft: report on final issues
- closing the working group
Implementation Reports:
Jim Gettys led a review of the status of implementation reports on the base specification.
To be fully satisfied, he believes the group should put forward two interoperable
implementations each for client and server and should ideally put forward two proxies
as well except for the case where proxy behavior is no different than other parties.
Current implementation reports lack adequate testing of entity tags, transport encoding,
and trailers. One set of reports from a firewall proxy have been removed from those
indicate because it functioned largely as a tunnel; we now need one additional report
from a proxy implementing DELETE.
For digest we have one fully tested client and one fully tested server. Some of the newer
features related to 3rd party authentication are not yet available in any tested server. No
proxy implementations are yet available. The latest draft changes one of the hashes, so
current implementations will need to fix that and re-test.
At present the group believes that proxy authentication using Digest requires no special
handling, so that we will try to move forward to IESG with the implementation reports
that we currently have.
Independent of the "implementation reports", the chair raised the question of whether
there might still be a face to face event, to insure interoperability in the context of
complex interactions. Yaron Goland of Microsoft suggested (and Josh Cohen later
confirmed) that the offer to host such an event still stood. A co-event with ApacheCON
or some similar event was also suggested. Coordination on such an event is continuing
with; some of the participation can be remote, although proxy testing seems to require
more interaction. Please contact Josh Cohen <joshco@microsoft.com> for arrangements.
Main HTTP Draft: Jim Gettys
Jim listed a number of editorial changes related to RFC2119 use of MUST/MAY/
SHOULD; the new draft will move all normative language out of notes, for the sake
of clarity. He also reviewed and the working group accepted language around the NO-
TRANSFORM flag.
After discussion of the merits of allowing Content-MD5 and Digest Authentication
headers to appear in trailers when a message is chunked, the group decided to adopt
Roy Fielding's proposal, which states that Servers should not send essential headers
in the trailer when the Via headers indicate a 1.0 proxy may be part of the chain; the
group will also include language from Paul Leach which indicates ways in which an
upstream 1.1 proxy might assist a 1.0 proxy in handling very large chunked responses
using these trailers.
The working group discussed a proposal to create a method registry for HTTP methods,
but decided that related work implied a larger scope than could be adopted by the group
at this time. The group working on HTTP-EXT has a current proposal on this topic, and
it will be the basis for further discussion and that group will be the forum for further
discussion.
The working group reconsidered the 416 header briefly; there is an existing
implementation of 2068's advice on out-of-bound ranges which conflicts with the advice
in 416. After discussion which reiterated previous positions, the chair ruled that the
group had come to rough consensus on this matter and the issue would remain closed.
In response to a question on the use of Upgrade by Carl-Uno Manros, the group noted
that it does not see any need for changes to the current specification to allow UPGRADE
to work with TLS; it does require a specification of a token for this use. Rohit Khare
has written a draft to this end and it will be passed by the TLS working group before
being sent to the IESG as an individual submission.
Jim Gettys offered to try to finish the main draft by 8/27, so that it could be completed
before the end of this IETF meeting.
Authentication draft: Scott Lawrence
A small editorial change is needed to the current draft to improve the language related
to Digest-URI. The URI is a component of the authentication hash, but because of
proxy transformation, the received request-URI and the Digest-URI may differ. It is
the server's responsibility to ensure that the two refer to the same resource, and the
language will be tightened to make that clear.
An editorial change related to the scope of damage related to snooped passwords is
needed; the changes will be based on the language sent to the list.
Scott Lawrence and Paul Leach offered to submit a revised draft of the Authentication
draft by 8/27, so that it could be submitted before the end of this IETF.
- Closing the working group
The chair went through the steps needed to close the working group:
1) Submit final drafts
2) Submit implementation reports
3) Send document to A-D for review
4) IETF Last Call
5) IESG review
6) RFC Editor publication
These elements might be pipelined to finish more quickly; the most serious element
for quick conclusion are the implementation reports, which, of course, depend on
implementation testing of the few remaining insufficiently tested features; if this can
happen in the next week, we can send the documents to the A-D for review and IETF
Last Call, which will likely be simultaneous. Given the wide review that has already
occurred in the working group, it is likely that the IESG review will not be lengthy.
The working group will close after (5), which is likely as soon as 2-3 months from
now, and certainly before the next IETF meeting.
The working group mailing list will remain open after the close of the working group.
At the close of the meeting, Keith Moore solicited feedback on the IESG draft
describing layering other protocols on top of HTTP, draft-iesg-using-http-00.txt.
Feedback should go to the IESG or discuss@apps.ietf.org.
None received.