W3C home > Mailing lists > Public > ietf-http-ext@w3.org > January to March 1998

http-ext charter

From: Josh Cohen <joshco@microsoft.com>
Date: Mon, 2 Mar 1998 03:23:31 -0800
Message-ID: <8B57882C41A0D1118F7100805F9F68B50785B3@red-msg-45.dns.microsoft.com>
To: "'ietf-http-ext@w3.org'" <ietf-http-ext@w3.org>
Cc: "Harald (E-mail)" <Harald.Alvestrand@maxware.no>
Here is a draft charter for ext..

thoughts, comments?

I'd like to get this to our ADs as quickly as possible,
I beleive that we are ready to do work at the meeting so
I think we'd be better with a wg meeting instead of another

HTTP Extension Working Group

Suggested Name Abbreviations:
 "http-ext" [HTTP Extension] -or-
 "wevol" [Web Evolution]

	Josh Cohen <joshco@microsoft.com>

	Scott Lawrence <lawrence@agranat.com>

Area Director(s):
	Keith Moore <moore@cs.utk.edu>
	Harald Alvestrand <harald.alvestrand@maxware.no>

Area Advisor:
	Harald Alvestrand <harald.alvestrand@maxware.no>

Mailing List:
	General Discussion: ietf-http-ext@w3.org

	Subscription: ietf-http-ext-request@w3.org
	 ("subscribe" in the subject line)

	Archives: http://lists.w3.org/Archives/Public/ietf-http-ext/

Description of Working Group:

	As the World Wide Web has grown and become widespread, the use
of the Hypertext Transfer Protocol (HTTP) has become widespread as
well.  In particular, HTTP has become a popular transaction or
transport protocol to build on top of.  In ways similar to protocols
built upon TCP, HTTP has become quite popular at providing basic
services such as a framework for entity transport, authentication
(with Basic, Digest or other),encryption (with TLS or SSL),
Proxy/Firewall Boundary (PFB) transiting as well as caching and or

	With new protocols based on HTTP becoming increasingly
popular, it is important to attempt to lay a framework for using HTTP
as a common transport.  Most importantly, a clear mechanism is needed
for extension and higher level layer detection.  In addition, a set of
recommendations for using HTTP in a manner consistent with the
semantics and vision of the HTTP evolution group is desired to ensure
that new protocols built upon HTTP are to remain compatible and
functional as HTTP evolves.  Finally, along with an extension
mechanism, appropriate registries and or procedures are desired to
avoid conflicts and compatibility issues between new extensions,
higher level layered protocols and the HTTP evolution itself.

 Major Work Areas:

 HTTP Extension Mechanism:
  1) Create and submit a new standards track draft based on either or
a combination of OPTIONS and PEP.
  2) Create a registry for new HTTP headers and response codes
 HTTP Evolution and Extension recommendations
  1) Create an FYI document expressing recommendations or guidelines
for using HTTP as a transport layer in new protocols
  2) Continue work on selected functionality which was "undocked" from

Specific Work Items:
 HTTP Extension Mechanism:
  * Move the current PEP draft to experimental
  * Update and Submit draft-schulzrinne-http-status-00.txt

 HTTP Evolution and Extension recommendation FYI
  * Find consensus on new method vs. existing method tunneling
    Analyze semantics of how HTTP is used to cross firewalls.

  * Discuss issues expressed in FYI outline to find consensus on

  * Move forward with HTTP Mandatory specification


Mar 98		Move PEP to experimental
Mar 98		Find consensus on "POST" Method issue
Mar 98		Update and submit draft-schulzrinne-http-status-00.txt
Mar 98		Revised outline for recommendations FYI
Mar 98		First Draft of updated Extensions Mechanism Document


May 98		Revised Extensions Mechanism Document
		Submit as I-D
May 98		First draft of Recommendations FYI

Jun 98		Revised Recommendations FYI
		Submit as I-D

Jul 98		Revised Extensions Document
		Re-submit I-D revisions
Jul 98		Revised Recommendations FYI
		Re-submit I-D revisions

[ Chicago IETF Meeting ]

Aug 98		Last call Extensions Document
Aug 98		Last call recommendations FYI

Sep 98		Working group Closes


"Assignment of Status Codes for HTTP and HTTP-Derived Protocols"
	draft-schulzrinne-http-status-00.txt (existing)

"Don't go Postal, an argument against overloading the HTTP POST method"

"The Use of Post: A Response to <draft-cohen-http-postal-00.txt>"     

"PEP - an Extension Mechanism for HTTP"

"Specification of HTTP/1.1 OPTIONS messages"

Requests for Comments (RFCs):


Josh Cohen <josh@microsoft.com>
Program Manager IE - Networking Protocols 
Received on Monday, 2 March 1998 06:23:36 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 1 July 2021 15:49:07 UTC