Re: Moving forward with HTTP/2.0: proposed charter

On Fri, Aug 3, 2012 at 1:06 PM, Mark Nottingham <mnot@mnot.net> wrote:

> [snip]
> * 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.
>

I want to just clarify that the proposed language does leave the room open
for potentially non-backwards compatible changes to be made within HTTP
2.0. Specifically, the way I read this, it should be possible for us to
tunnel a 1.1 message through a 2.0 request, as well as reasonably translate
a 2.0 message into a 1.1, but the charter also allows for the introduction
of mechanisms within 2.0 that do not necessarily translate directly into
1.1 so long as those are clearly spelled out within the specification (In
particular I'm thinking of things like the binary optimized header
encoding, UTF-8 support, etc). I see nothing in the draft spec language
that rules non-backwards compatible changes as being out of scope. If
that's correct, then I'm +1 on the revised charter.

- James


>
> 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/
>
>
>
>
>
>