Re: Straw-man for our next charter

Hi Amos,

On 25/07/2012, at 10:02 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:
>> Work will begin using XXX as a starting point; all proposals are to be expressed
>> in terms of changes to the that document.
> 
> I just think I'll throw a spanner in the general direction of the works here....
> 
> How realistic is it to expect the HTTPbis 1.1 draft documents fill that role? At least we can guarantee that modifications to adjust them for 2.0 specifics will not loose or add any features unintentionally that could affect HTTP/1.1 compatibility.

I'm not sure what your concern is here... 


> 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.
> 
> "measureably ... perceived" does not stack up.
> Surely we can aim for actual measurable efficiency rather than just perceived.
> 
> Possibly also improvement over *optimized* 1.1 would be a good aim.

Yes; there's some interesting discussion to be had here, I imagine.


>> 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).
> 
> +1. Although I predict that having multiplexing on the table will bring up the need for new hop-by-hop features on 2.0 connections. Specifically flow control features.


Yes, and I think that's OK; what I want to avoid (and we can work on language around this) is making material changes to the abstraction that HTTP presents to applications; i.e., necessitating changes in HTTP APIs. Of course, abstractions are leaky (e.g., optimisations around connections leak through), and we can't prevent that.

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

Received on Friday, 27 July 2012 05:28:00 UTC