Re: Rechartering HTTPbis

Just my 2c.

It will be an enormous amount of work to come up with a HTTP/2.0

What's the point of doing all that work if it will only be a minor 
incremental change to 1.1, shackled to 1.1 semantics?

I think at this stage it's too soon to decide that we shouldn't change 
semantics.  This is incompatible with a desire to implement many of the 
new features, or improve protocol efficiency.

I think we have a great forum of the right people to come up with 
something better, if maybe we spend a bit of time taking a step back.

What is it we are here for?  What is the web for?  What job does 
HTTP/1.1 currently do, and how might that job be done better?

A minor incremental change could be 1.2.  Many of the things that have 
been discussed as potential desirous paths for the web simply will never 
happen if we restrict ourselves to semantic compatibility at this stage, 
without even looking into the possibility that the web could / should be 
built on something that maybe works completely differently to current HTTP.

Cheers

Adrien


On 24/01/2012 5:52 p.m., Mark Nottingham wrote:
> Thanks, James.
>
> Pretty much everyone I've spoken to about this has raised the same concern. I agree it's going to be a tightrope walk, but I think there's a healthy amount of concern about this in the community, which will help guide development.
>
> Cheers,
>
>
> On 24/01/2012, at 3:50 PM, James Snell wrote:
>
>> +1... would love to see that work move forward within this group. I do
>> have concerns about keeping the scope focused, however. Even tho the
>> door would be opened to the possibility of new features being
>> introduced, there is obvious danger in opening those doors too wide. I
>> strongly feel that things such as the introduction of new request
>> methods and new header fields, unless there is clear and irrefutable
>> evidence of their general utility within the core of the spec, should
>> continue to be pursued as they are today -- within separate I-D's as
>> extensions to the core protocol. The charter should make it absolutely
>> clear that the goal is an incremental evolution of HTTP/1.1 rather
>> than an opportunity for radical changes.
>>
>> On Mon, Jan 23, 2012 at 7:55 PM, Mark Nottingham<mnot@mnot.net>  wrote:
>>> Everyone,
>>>
>>> We're getting close to Working Group Last Call. There are about 10 or so outstanding design issues, and I'd like them to be closed by Paris as we're now past the four year mark (on a WG that was originally chartered for a year and a half).
>>>
>>> When this effort was started we took great pains to make it clear that we weren't working on a new version of HTTP, because there wasn't implementer support to do so and we wanted to focus upon interoperability and security.
>>>
>>> That's clearly changed in the intervening time; two major browsers have implemented SPDY, a non-textual serialisation of HTTP's semantics, and there are now several other implementations as well (full disclosure: including an experimental one in Python by yours truly).
>>>
>>> I've been talking to a number of folks -- including those implementing SPDY, as well as HTTP implementers and the W3C TAG -- about this recently. There seems to be broad agreement that the time is ripe to start work on a new version of HTTP in the IETF, and that it should happen in this Working Group.
>>>
>>> Why here? This mailing list is the best approximation of the HTTP community; it has participation (or at least presence) from most implementations, including browsers, servers, intermediaries, CDNs, libraries, tools, etc. I firmly believe that as HTTP evolves, it needs to accommodate the entire community, not just the selected needs of a subset, so rather than creating a new WG or having a private collaboration, it should happen here.
>>>
>>> I've put together a charter proposal (see attached) that has us going to WGLC shortly (something that I want to see us do regardless), and starting work on HTTP/2.0. Note that it does NOT call out a starting point; rather, we'll start by asking for proposals, considering them and selecting one based upon the traditional IETF criteria of rough consensus and running code.
>>>
>>> We'll then spend about a year refining that proposal to make sure it is a suitable evolution path for HTTP, while offering better performance, security and interoperability.
>>>
>>> Please have a look and tell us your thoughts, indicate support, or express any concern you might have. I'm also happy to talk to you privately if preferable. If there's good support in the WG for doing this, I plan on taking it to the IESG before Paris, so that we can have two meeting slots; one to work on BIS issues (hopefully, WGLC ones), and one to discuss HTTP/2.0.
>>>
>>> Regards,
>>>
>>>
>>>
>>>
>>> --
>>> Mark Nottingham
>>> http://www.mnot.net/
>>>
>>>
>>>
>>>
>>>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 is released! - http://www.wingate.com/getlatest/

Received on Tuesday, 24 January 2012 05:05:23 UTC