- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 19 Sep 2012 13:03:32 -0700
- To: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
FYI; this is our re-charter to work on HTTP/2.0. Begin forwarded message: > From: IESG Secretary <iesg-secretary@ietf.org> > Subject: [new-work] WG Review: Hypertext Transfer Protocol Bis (httpbis) > Date: 18 September 2012 9:13:13 AM PDT > To: new-work@ietf.org > > The Hypertext Transfer Protocol Bis (httpbis) working group in the > Applications Area of the IETF is undergoing rechartering. The IESG has > not made any determination yet. The following draft charter was > submitted, and is provided for informational purposes only. Please send > your comments to the IESG mailing list (iesg at ietf.org) by 2012-09-25. > > Hypertext Transfer Protocol Bis (httpbis) > ------------------------------------------------ > Current Status: Active Working Group > > Chairs: > Mark Nottingham <mnot@pobox.com> > > Assigned Area Director: > Barry Leiba <barryleiba@computer.org> > > Mailing list > Address: ietf-http-wg@w3.org > To Subscribe: ietf-http-wg-request@w3.org > Archive: http://lists.w3.org/Archives/Public/ietf-http-wg/ > > Charter of Working Group: > > This Working Group is charged with maintaining and developing the "core" > specifications for HTTP. > > The Working Group's specification deliverables are: > * A document (or set of documents) that is suitable to supersede RFC 2616 > as > the definition of HTTP/1.1 and move RFC 2817 to Historic status > * A document cataloguing the security properties of HTTP/1.1 > * A document (or set of documents) that specifies HTTP/2.0, an improved > binding of HTTP's semantics to an underlying transport. > > HTTP/1.1 > -------- > > HTTP/1.1 is one of the most successful and widely-used protocols on the > Internet today. However, its specification has several editorial issues. > Additionally, after years of implementation and extension, several > ambiguities > have become evident, impairing interoperability and the ability to easily > implement and use HTTP. > > The working group will refine RFC2616 to: > * Incorporate errata and updates (e.g., references, IANA registries, > ABNF) > * Fix editorial problems which have led to misunderstandings of the > specification > * Clarify conformance requirements > * Remove known ambiguities where they affect interoperability > * Clarify existing methods of extensibility > * Remove or deprecate those features that are not widely implemented and > also unduly affect interoperability > * Where necessary, add implementation advice > * Document the security properties of HTTP and its associated mechanisms > (e.g., Basic and Digest authentication, cookies, TLS) for common > applications > > It will also incorporate the generic authentication framework from RFC > 2617, without obsoleting or updating that specification's definition of > the Basic and Digest schemes. > > Finally, it will incorporate relevant portions of RFC 2817 (in > particular, the CONNECT method and advice on the use of Upgrade), so > that that specification can be moved to Historic status. > > In doing so, it should consider: > * Implementer experience > * Demonstrated use of HTTP > * Impact on existing implementations and deployments > > HTTP/2.0 > -------- > > There is emerging implementation experience and interest in a protocol > that > retains the semantics of HTTP without the legacy of HTTP/1.x message > framing and syntax, which have been identified as hampering performance > and > encouraging misuse of the underlying transport. > > The Working Group will produce a specification of a new expression of > HTTP's > current semantics in ordered, bi-directional streams. As with HTTP/1.x, > the primary target transport is TCP, but it should be possible to use > other transports. > > Work will begin using draft-mbelshe-httpbis-spdy-00 as a starting point; > proposals are to be expressed in terms of changes to that document. Note > that > consensus is required both for changes to the document and anything that > remains in the document. > > As part of that work, the following issues are explicitly called out for > discussion: > * A negotiation mechanism that is capable of not only choosing between > HTTP/1.x and HTTP/2.x, but also for bindings of HTTP URLs to other > transports (for example). > * Header compression (which may encompass header encoding or > tokenisation) > * Server push (which may encompass pull or other techniques) > > It is expected that HTTP/2.0 will: > * Substantially and measurably improve end-user perceived latency in most > cases, over HTTP/1.1 using TCP. > * Address the "head of line blocking" problem in HTTP. > * Not require multiple connections to a server to enable parallelism, > thus > improving its use of TCP, especially regarding congestion control. > * Retain the semantics of HTTP/1.1, leveraging existing documentation > (see > above), including (but not limited to) HTTP methods, status codes, > URIs, and > where appropriate, header fields. > * Clearly define how HTTP/2.0 interacts with HTTP/1.x, especially in > intermediaries (both 2->1 and 1->2). > * Clearly identify any new extensibility points and policy for their > appropriate use. > > The resulting specification(s) are expected to meet these goals for > common > existing deployments of HTTP; in particular, Web browsing (desktop and > mobile), non-browsers ("HTTP APIs"), Web serving (at a variety of > scales), and > intermediation (by proxies, corporate firewalls, "reverse" proxies and > Content > Delivery Networks). Likewise, current and future semantic extensions to > HTTP/1.x (e.g., headers, methods, status codes, cache directives) should > be > supported in the new protocol. > > Note that this does not include uses of HTTP where non-specified > behaviours > are relied upon (e.g., connection state such as timeouts or client > affinity, > and "interception" proxies); these uses may or may not be enabled by the > final > product. > > Explicitly out-of-scope items include: > * Specifying the use of alternate transport-layer protocols. Note that it > > is expected that the Working Group will work with the TLS working group > to define how the protocol is used with the TLS Protocol. > * Specifying how the HTTP protocol is to be used or presented in a > specific > use case (e.g., in Web browsers). > > The Working Group will coordinate this item with: > * The TLS Working Group, regarding use of TLS. > * The Transport Area, regarding impact on and interaction with transport > protocols. > * The HYBI Working Group, regarding the possible future extension of > HTTP/2.0 > to carry WebSockets semantics. > > The Working Group will give priority to HTTP/1.1 work until that work is > complete. > > Other HTTP-Related Work > ----------------------- > > The Working Group may define additional extensions to HTTP as work items, > provided that: > * The Working Group Chairs judge that there is consensus to take on the > item > and believe that it will not interfere with the work described above, > and > * The Area Directors approve the addition and add corresponding > milestones. > > Additionally, the Working Group will not start work on any extensions > that > are specific to HTTP/2.0 until that work is completed. > > > Goals and Milestones > > Done First HTTP/1.1 Revision Internet Draft > Done First HTTP Security Properties Internet Draft > Done Call for Proposals for HTTP/2.0 > Sep 2012 Working Group Last Call for HTTP/1.1 Revision > Oct 2012 Working Group Last Call for HTTP Security Properties > Oct 2012 First WG draft of HTTP/2.0, based upon > draft-mbelshe-httpbis-spdy-00 > Nov 2012 Submit HTTP/1.1 Revision to IESG for consideration as a Proposed > Standard > Nov 2012 Submit HTTP Security Properties to IESG for consideration as > Informational RFC > Apr 2014 Working Group Last call for HTTP/2.0 > Nov 2014 Submit HTTP/2.0 to IESG for consideration as a Proposed Standard > > Milestones: > Done - First HTTP/1.1 Revision Internet Draft > Done - First HTTP Security Properties Internet Draft > Mar 2012 - Working Group Last Call for HTTP/1.1 Revision > Mar 2012 - Call for Proposals for HTTP/2.0 > Jun 2012 - Working Group Last Call for HTTP Security Properties > Jul 2012 - Submit HTTP/1.1 Revision to IESG for consideration as a > Proposed Standard > Jul 2012 - Submit HTTP Security Properties to IESG for consideration as > Informational RFC > Aug 2012 - Re-charter to work on HTTP/2.0 > _______________________________________________ > new-work mailing list > new-work@ietf.org > https://www.ietf.org/mailman/listinfo/new-work -- Mark Nottingham http://www.mnot.net/
Received on Wednesday, 19 September 2012 20:03:56 UTC