- From: Eric J. Bowman <eric@bisonsystems.net>
- Date: Tue, 30 Nov 2010 06:24:25 -0700
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Greg Wilkins <gregw@webtide.com>, HTTP Working Group <ietf-http-wg@w3.org>, hybi <hybi@ietf.org>
Julian Reschke wrote: > > > > > 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. > It isn't clear to me whether a line should be drawn, merely that it's worth taking a moment to ponder the implications of not drawing one. > > - Uprade to TLS is already defined (although not really used), and > changes the message framing > I was wondering about that; I've never come across it in the wild, is there any data? > > - Things like SPDY and/or Waka will have binary headers, so will have > no on-the wire resemblance to HTTP messages > While adhering to the same architectural principles, primarily resource/ representation instantiation via media types. > > - I can easily imagine that HTTP/2.0 could add server-initiated > messages. > To which I can easily imagine a client responding. > > If these things qualify as HTTP/2.0 features, why not allow other > protocols to use same mechanism? > These things are all vaporspecs, right? So it isn't too late to think about some minimal guidelines for protocols desiring to use Upgrade, to keep port 80 manageable. Whatever family of protocols interoperate around the http: scheme should have *something* in common, i.e. using media types, as a basis for that interoperability being securable. -Eric
Received on Tuesday, 30 November 2010 13:24:57 UTC