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

Rechartering HTTPbis

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 24 Jan 2012 14:55:46 +1100
Message-Id: <4429D3C2-9696-4110-B5BE-60DFB8A3101F@mnot.net>
To: HTTP Working Group <ietf-http-wg@w3.org>

We're getting close to Working Group Last Call. There are about 10 or so outstanding design issues, and I'd like them to be closed by Paris as we're now past the four year mark (on a WG that was originally chartered for a year and a half).

When this effort was started we took great pains to make it clear that we weren't working on a new version of HTTP, because there wasn't implementer support to do so and we wanted to focus upon interoperability and security.

That's clearly changed in the intervening time; two major browsers have implemented SPDY, a non-textual serialisation of HTTP's semantics, and there are now several other implementations as well (full disclosure: including an experimental one in Python by yours truly). 

I've been talking to a number of folks -- including those implementing SPDY, as well as HTTP implementers and the W3C TAG -- about this recently. There seems to be broad agreement that the time is ripe to start work on a new version of HTTP in the IETF, and that it should happen in this Working Group.

Why here? This mailing list is the best approximation of the HTTP community; it has participation (or at least presence) from most implementations, including browsers, servers, intermediaries, CDNs, libraries, tools, etc. I firmly believe that as HTTP evolves, it needs to accommodate the entire community, not just the selected needs of a subset, so rather than creating a new WG or having a private collaboration, it should happen here. 

I've put together a charter proposal (see attached) that has us going to WGLC shortly (something that I want to see us do regardless), and starting work on HTTP/2.0. Note that it does NOT call out a starting point; rather, we'll start by asking for proposals, considering them and selecting one based upon the traditional IETF criteria of rough consensus and running code.

We'll then spend about a year refining that proposal to make sure it is a suitable evolution path for HTTP, while offering better performance, security and interoperability.

Please have a look and tell us your thoughts, indicate support, or express any concern you might have. I'm also happy to talk to you privately if preferable. If there's good support in the WG for doing this, I plan on taking it to the IESG before Paris, so that we can have two meeting slots; one to work on BIS issues (hopefully, WGLC ones), and one to discuss HTTP/2.0.


Hypertext Transfer Protocol Bis (httpbis)

 Last Modified: 2012-01-21

 Current Status: Active Working Group

     Mark Nottingham  <mnot@mnot.net>

 Applications Area Director(s):
     Pete Resnick  <presnick@qualcomm.com>
     Peter Saint-Andre  <stpeter@stpeter.im>

 Applications Area Advisor:
     Peter Saint-Andre  <stpeter@stpeter.im>

 Mailing Lists: 
     General Discussion:ietf-http-wg@w3.org
     To Subscribe:      ietf-http-wg-request@w3.org
         In Body:       subscribe
     Archive:           http://lists.w3.org/Archives/Public/ietf-http-wg/

Description 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 (HTTP/1.1) and move RFC 2817 to Historic status
* A document cataloguing the security properties of HTTP/1.1
* A document that specifies HTTP/2.0 an improved binding of HTTP's semantics
  to the underlying transport.


HTTP 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, 
* Fix editorial problems which have led to misunderstandings of the 
* 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 

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


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. The Working Group will leverage this to create new major version
of HTTP. Although work on this new version will begin in parallel with 
completion of work on HTTP/1.1, the Working Group will prioritize HTTP/1.1
work until it is complete.

Particular goals of this effort include:
* Significantly improved perceived performance for common use cases
  (e.g., browsers, mobile)
* More efficient use of network resources; in particular, reducing the
  need to use multiple TCP connections
* Ability to be deployed on today's Internet, using IPv4 and IPv6, in the
  presence of NATs
* Maintaining HTTP's ease of deployment
* Reflecting modern security requirements and practices

In documenting this protocol, the Working Group must:
* Meet the goals specified above
* Make it possible to pass through a HTTP/1.1 message with reasonable
  fidelity; i.e., to implement a gateway to or from HTTP/1.1
* consider the needs of a variety of HTTP implementers and users
  (such as "back-end" or "web api" uses of HTTP, servers and intermediaries)
* Address HTTP proxy and CDN infrastructure requirements

Changes to the existing semantics of HTTP are out of scope in order to
preserve the meaning of messages that might cross a 1.1 --> 2.0 --> 1.1
request chain. However, the effort may define new semantics to further the
goals above, along with suitable extensibility mechanisms for defining
additional semantics.

This work will be known as "HTTP/2.0", unless the Working Group
determines that this isn't suitable (e.g., for interoperability).

 Goals and Milestones:

   Done        First HTTP/1.1 Revision Internet Draft 

   Done        First HTTP Security Properties Internet Draft 

   Feb 2012    Working Group Last Call for HTTP/1.1 Revision 

   Feb 2012    Working Group Last Call for HTTP Security Properties 

   Apr 2012    Submit HTTP/1.1 Revision to IESG for consideration as a 
               Proposed Standard 

   Apr 2012    Submit HTTP Security Properties to IESG for consideration as 
               Informational RFC

   May 2012    First HTTP/2.0 Internet Draft

   May 2013    Request Last Call for HTTP/2.0

   Jul 2013    Submit HTTP/2.0 to IESG for consideration as a Proposed

Mark Nottingham
Received on Tuesday, 24 January 2012 03:56:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:56 UTC