WG Review: Hypertext Transfer Protocol Bis (httpbis)

The IESG <iesg-secretary@ietf.org> Tue, 18 September 2012 16:10 UTC

Return-Path: <iesg-secretary@ietf.org>
X-Original-To: ietf-announce@ietfa.amsl.com
Delivered-To: ietf-announce@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 30CBD21F8564 for <ietf-announce@ietfa.amsl.com>; Tue, 18 Sep 2012 09:10:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.541
X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id XEJ3w3OLUS9k for <ietf-announce@ietfa.amsl.com>; Tue, 18 Sep 2012 09:10:31 -0700 (PDT)
Received: from ietfa.amsl.com (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 31E2021F873A for <ietf-announce@ietf.org>; Tue, 18 Sep 2012 09:10:31 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: WG Review: Hypertext Transfer Protocol Bis (httpbis)
X-Test-IDTracker: no
X-IETF-IDTracker: 4.34
Message-ID: <20120918161031.26180.80210.idtracker@ietfa.amsl.com>
Date: Tue, 18 Sep 2012 09:10:31 -0700
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-announce>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Sep 2012 16:10:32 -0000

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

  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
  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
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
retains the semantics of HTTP without the legacy of HTTP/1.x message
framing and syntax, which have been identified as hampering performance
encouraging misuse of the underlying transport.

The Working Group will produce a specification of a new expression of
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
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
* 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
* 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,
  improving its use of TCP, especially regarding congestion control.
* Retain the semantics of HTTP/1.1, leveraging existing documentation
  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
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
Delivery Networks). Likewise, current and future semantic extensions to
HTTP/1.x (e.g., headers, methods, status codes, cache directives) should
supported in the new protocol.

Note that this does not include uses of HTTP where non-specified
are relied upon (e.g., connection state such as timeouts or client
and "interception" proxies); these uses may or may not be enabled by the

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
  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
  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
  and believe that it will not interfere with the work described above,
* The Area Directors approve the addition and add corresponding

Additionally, the Working Group will not start work on any extensions
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
Nov 2012	Submit HTTP/1.1 Revision to IESG for consideration as a Proposed
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

  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