Fwd: [new-work] WG Review: Hypertext Transfer Protocol Bis (httpbis)

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