* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Httpbis Status Pages

Hypertext Transfer Protocol (Active WG)
Art Area: Adam Roach, Alexey Melnikov, Ben Campbell | 2007-Oct-23 —  

2018-11-05 charter

Hypertext Transfer Protocol (httpbis)


 Current Status: Active

     Mark Nottingham <mnot@mnot.net>
     Patrick McManus <patrick.ducksong@gmail.com>
     Tommy Pauly <tpauly@apple.com>

 Applications and Real-Time Area Directors:
     Ben Campbell <ben@nostrum.com>
     Alexey Melnikov <aamelnikov@fastmail.fm>
     Adam Roach <adam@nostrum.com>

 Applications and Real-Time Area Advisor:
     Alexey Melnikov <aamelnikov@fastmail.fm>

 Tech Advisor:
     Allison Mankin <allison.mankin@gmail.com>

 Mailing Lists:
     General Discussion: ietf-http-wg@w3.org
     To Subscribe:       ietf-http-wg-request@w3.org
     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 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 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
  * 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, 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.  In particular, because something is in the initial
  document does not imply that there is consensus around the feature or how
  it is specified.  The deliverable of the WG is HTTP/2.0, and there is no
  consideration of preserving backwards compatibility with the initial starting

  As part of the HTTP/2.0 work, the following issues are explicitly called out for
  * 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

  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; any revisions to
    RFC 2818 will be done in the TLS working group.
  * 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
  * 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

  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 the HTTP/2.0 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
  Done     - Working Group Last Call for HTTP/1.1 Revision
  Done     - First WG draft of HTTP/2.0, based upon draft-mbelshe-httpbis-spdy-00
  Held / eliminated     - Working Group Last Call for HTTP Security Properties
  Done     - Submit HTTP/1.1 Revision to IESG for consideration as a Proposed Standard
  Done     - Working Group Last call for HTTP/2.0
  Done     - Submit HTTP/2.0 to IESG for consideration as a Proposed Standard
  Done     - Submit The Hypertext Transfer Protocol Status Code 308 to IESG for consideration as Internet Standard
  Done     - Submit HTTP Client-Initiated Content-Encoding to IESG for consideration as Proposed Standard
  Done     - Submit Tunnel Protocol for CONNECT to IESG for consideration as Proposed Standard
  Done     - Submit HTTP Authentication-Info and Proxy-Authentication-Info to IESG for consideration as Proposed Standard
  Done     - Submit HTTP Legally Restricted Status Code to IESG for consideration as a Proposed Standard
  Done     - Submit Alternative Services to IESG for consideration as a Proposed Standard
  Done     - Submit HTTP Opportunistic Security to IESG for consideration as Experimental
  Done     - Submit Character Encoding and Language for Parameters to IESG for consideration as Internet Standard
  May 2016 - Submit the Key HTTP Response Header Field for consideration as a Proposed Standard

All charter page changes, including changes to draft-list, rfc-list and milestones:

Generated from PyHt script /wg/httpbis/charters.pyht Latest update: 24 Oct 2012 16:51 GMT -