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

Re: HTTbis spec size, was: Rechartering HTTPbis

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 28 Jan 2012 11:50:52 +0100
Message-ID: <4F23D30C.1040406@gmx.de>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
CC: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
On 2012-01-28 11:45, Poul-Henning Kamp wrote:
> In message<4F23CF65.6030605@gmx.de>, Julian Reschke writes:
>> I do agree that whatever is done better get the layering right. My
>> conclusion although is different: calling something HTTP/2.0 which
>> doesn't roughly address the same use cases would be totally confusing.
> As "totally confusing" as HTTP/1.1(bis) ?  :-)

I don't find it totally confusing.

> I don't think we have a choice in practice.
> Either we chop this monster into bites we can understand or chew,
> or we're wasting our time on a long interminable death-march towards
> IPv6 adoption.

We've been doing that; this is why we have 3 base documents and 4 
optional modules (your mileage wrt "base" and "optional" obviously varies).

> In terms of practical standards documents, a HTTP/2.0 RFC could
> have a section which simply point back into HTTP/1.1bis and say
> "Use these bits to interpret and understand the content+metadata
> parts".  If/when later, the content+metadata part gets cleaned up
> in dedicated RFCs, those RFC's will refer directly to the HTTP/2.0
> RFC, less that section.

Organization aside the question is whether things like methods, payload 
formats, and status codes are integral parts of HTTP/2.0. I think they are.

I *agree* with improving the layering, and maybe giving the transport 
layer a specific name, but "HTTP/2.0" it can't be.

Best regards, Julian
Received on Saturday, 28 January 2012 10:51:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:00 UTC