Straw-man for our next charter

Next week in Vancouver, we'll discuss both the candidate proposals for HTTP/2.0 and whether we should re-charter to begin that work, confirming consensus on the list afterwards. 

Assuming we do choose one, we'll also need to discuss the charter itself. To facilitate that, I've pasted a straw-man of what such a charter might look like below.

Please familiarise yourself with it. We can discuss on-list beforehand, of course, but please realise that we need to do this step-by-step, so don't get too far ahead of the conversation. 

Note -- this currently JUST covers the protocol discussion, not the authentication half; I've omitted it because there are a few different ways that work might end up, and it's going to need discussion before we can write even straw-man charter text.

Cheers,

---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 XXX as a starting point; all proposals are to be expressed
in terms of changes to the that document.

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.
* Not require multiple connections to a server to enable parallelism.
* Require no more configuration or tuning than current HTTP deployments; 
   preferably, less.
* 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), Web serving (at a variety of scales), and intermediation (by proxies,
corporate firewalls, "reverse" proxies and Content Delivery Networks).

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 protocols. Note that it
  is expected that the Working Group will define how the protocol is used
  with the TLS protocol.
* Specifying new semantics for HTTP (whether specific to HTTP/2 or not). 
  However, the Working Group may request a re-charter to start work on such
  items (during or after work on HTTP/2.0), provided there is consensus to
  do so, and it does not interfere with work on the "core" (both HTTP/1.x and
  HTTP/2.0).
    
The Working Group will prioritize HTTP/1.1 work until it is complete.


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 Security Properties
Sep 2012	Working Group Last Call for HTTP/1.1 Revision
Sep 2012	First WG draft of HTTP/2.0, based upon XXX
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
Dec 2013	Working Group Last call for HTTP/2.0
Apr 2014	Submit HTTP/2.0 to IESG for consideration as a Proposed Standard
--->8---


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

Received on Wednesday, 25 July 2012 07:54:27 UTC