- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sat, 28 Jan 2012 11:50:52 +0100
- 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