W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: Straw-man for our next charter

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 27 Jul 2012 15:42:57 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <83281BFC-F40C-48B9-9C6D-1C78CE4E1AF9@mnot.net>
To: James M Snell <jasnell@gmail.com>

On 26/07/2012, at 12:13 AM, James M Snell <jasnell@gmail.com> wrote:

> On Wed, Jul 25, 2012 at 12:53 AM, Mark Nottingham <mnot@mnot.net> wrote:
> [snip]
> 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).
> [snip] 
> I do not believe new semantics should be entirely out of scope within the new charter. Particularly in that there are opportunities to..
> A) Utilize the transport more efficiently through the use of binary-encodings of header fields
> B) Improve internationalization support by requiring UTF-8 in character-based header values
> C) Improve intermediary support through the introduction of protocol-level routing tokens that can begin to replace the clumsy and hackish use of cookies
> D) Explore the possibility of in-stream encryption and integrity mechanisms such as my proposed SPDY KEY_NEGO frame.
> E) Provide for millisecond-level resolution within date headers, particularly Last-Modified and If-Modified-Since
> F) Require support for trailing headers
> And I'm sure there are others that simply aren't coming to mind at the moment. Yes, each possible change or addition to existing semantics would need to be carefully considered with backwards compatibility in mind, and we would need to carefully consider each individual change. 

Without going into the specific issues, I'm going to push back strongly on anything that changes the abstraction of HTTP, or that could be layered onto HTTP/1 and /2 as an extension.

We need to stay focused.

That said, note that there is an option in there to expand scope *cautiously* when we think it's worthwhile.


Mark Nottingham   http://www.mnot.net/
Received on Friday, 27 July 2012 05:43:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:03 UTC