- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 30 Nov 2010 12:03:47 +0100
- To: "Eric J. Bowman" <eric@bisonsystems.net>
- CC: Greg Wilkins <gregw@webtide.com>, HTTP Working Group <ietf-http-wg@w3.org>, hybi <hybi@ietf.org>
On 30.11.2010 02:29, Eric J. Bowman wrote: > Julian Reschke wrote: >> >>> >>> My suggested fixes to 9.8, based on the notion that HTTP 1.0, 1.1 >>> and 2.0, and PTTH 1.0, are not "incompatible" protocols: >>> ... >> >> Not convinced. >> >> If the protocol is compatible, you don't need "Upgrade" in the first >> place. >> > > Two issues here. One, is whether Upgrade should be a general-purpose > protocol tunneling mechanism vs. an HTTP-specific versioning mechanism. > Two, is how to change the wording. There are probably specific terms > which describe exactly what I'm getting at, in languages other than > English (you Germans probably have an absurdly-long compound word that > captures exactly what I'm trying to say :-). :-) >> So, HTTP/2.0 *will* need upgrade, if you start the conversation using >> HTTP 1.*. >> > > Of course. I'm not arguing against Upgrade as a versioning mechanism > for HTTP and HTTP-ish protocols. I can't imagine that HTTP 2.0 would > abandon the request/response or resource/representation paradigms, > which I'm suggesting be a requirement for protocols bound to port 80. > ... It's not clear to me where you want to draw the line. - Uprade to TLS is already defined (although not really used), and changes the message framing - Things like SPDY and/or Waka will have binary headers, so will have no on-the wire resemblance to HTTP messages - I can easily imagine that HTTP/2.0 could add server-initiated messages. If these things qualify as HTTP/2.0 features, why not allow other protocols to use same mechanism? Best regard, Julian
Received on Tuesday, 30 November 2010 11:04:25 UTC