RE: Moving forward with HTTP/2.0: proposed charter

Mark

Thanks for sending this out! Based on the discussion at the Vancouver meeting and on the mailing list I think there are four items that need explicitly to be clarified in the proposed charter:

1) Clarify the relationship to SPDY, especially the ongoing work on SPDY 3 and the upcoming 4. We don't want to get in a situation with dueling specifications so we have to be clear on there the WG and the SPDY community stand on this. My sense is that as the SPDY spec is used as a starting point we have to roll all new development in under HTTP/2.0 as otherwise we don't know where we stand.

2) Clarify the point made during the WG meeting in Vancouver that because something is in the starting point it doesn't mean that there is consensus around it. That is, there shouldn't be a perception that because something is in that we have to argue whether it should be taken out. It is just as much an argument as to whether something should say in.

3) Clarify that it is the intent of HTTP/2.0 to function as a functional replacement of HTTP/1.1, part 1. That is, it should be possible (in practical and realistic, not theoretical terms) to use HTTP/2.0 in the same scenarios where HTTP/1.1 (and HTTP/1.0) is used today. One group that is missing from the below is embedded systems in which HTTP has a huge role.

4) State that, while not part of the deliverables, given the focus on performance, the WG will continue work on performance evaluation so that we can determine whether something actually improves performance and by how much within the scenarios we are looking at.

I have appended comments to clarify these issue in the below text (look for text between $...$)

Thanks,

Henrik

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.

$Because something is in the initial document does not imply that there is consensus around the feature or how it is specified.$

$The outcome of this WG is HTTP/2.0, not SPDY. It is important that there is no confusion about the relationship between HTTP/2.0 and SPDY as we do not want to have dueling specifications in this area.$

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)

$Note that this doesn't mean that no other issues should be brought up. The discussion can and should cover the entire HTTP/2.0 spec$

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 be 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). 

$as well as embedded systems$

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.

$That is, in functional terms, one should consider the goal of this work to address parts of HTTP/1.1 part 1 in terms of how the HTTP protocol is mapped to message structures as well as to the underlying transport.$

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 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).

$While not a direct deliverable of the WG, given the focus on performance, it is critical that the WG evaluates how well the proposed features in HTTP/2.0 perform within a common set of scenarios. It is expected that the WG will take such data into consideration when discussing features.$

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 prioritize HTTP/1.1 work until it is complete.

Other HTTP-Related Work
-----------------------

The Working Group may define additional extensions to HTTP as work items, provided that:
* There is clear consensus to do so, and
* It does not, in the judgement of the Chair(s), interfere with the work  described above, and
* The Area Director(s) give consent, 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.


-----Original Message-----
From: Mark Nottingham [mailto:mnot@mnot.net] 
Sent: Friday, August 03, 2012 1:06 PM
To: ietf-http-wg@w3.org Group
Subject: Moving forward with HTTP/2.0: proposed charter

In the second Vancouver session, we discussed the proposals, expressions of interest in them, and the proposed charter text sent to the list earlier. 

The result of those discussions has been captured in the charter proposal below.

Please have a look and discuss, express your support or concern, and of course make proposals for any changes that you believe will be able to gain consensus. Barring serious problems, I'd like to get it to the ADs in the next week.

---8<---

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 be 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 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 prioritize HTTP/1.1 work until it is complete.

Other HTTP-Related Work
-----------------------

The Working Group may define additional extensions to HTTP as work items, provided that:
* There is clear consensus to do so, and
* It does not, in the judgement of the Chair(s), interfere with the work  described above, and
* The Area Director(s) give consent, 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
Aug 2012	Working Group Last Call for HTTP/1.1 Revision
Sep 2012	Working Group Last Call for HTTP Security Properties
Sep 2012	First WG draft of HTTP/2.0, based upon draft-mbelshe-httpbis-spdy-00
Oct 2012	Submit HTTP/1.1 Revision to IESG for consideration as a Proposed Standard
Oct 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
--->8---

Regards,

--
Mark Nottingham   Systems Architect, Cloud Standards and APIs
mark.nottingham@rackspace.com    http://www.mnot.net/

--
Mark Nottingham
http://www.mnot.net/

Received on Saturday, 4 August 2012 20:23:03 UTC