- From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
- Date: Tue, 06 May 2014 22:37:26 +1200
- To: K.Morgan@iaea.org, ynir.ietf@gmail.com
- Cc: C.Brunhuber@iaea.org, ietf-http-wg@w3.org
I'm the author of the original commentary on the consequences of HTTP 2 for embedded devices (or, in general, anything that isn't a web server or browser), which was written to explore how a move to HTTP 2 would potentially affect non-web-browser users. To respond to some specific points: >If HTTP/2 is inappropriate for a case where HTTP/1.1, that's a problem we >need to solve. This WG is chartered to define a new protocol version that can >*replace* HTTP/1.1. Combining the reply to this and other comments people have made about "let them eat HTTP 1.1" or "HTTP 2 isn't meant for this": HTTP 0.9 was designed to communicate web pages between web servers and web browsers. It ended up being used as a universal substrate for the Internet. HTTP 1.0 was designed to communicate web pages between web servers and web browsers. It ended up being used as a universal substrate for the Internet. HTTP 1.1 was designed to communicate web pages between web servers and web browsers. It ended up being used as a universal substrate for the Internet. You can probably see where this is going... So, no matter what the people designing HTTP 2.0 may want, it's going to end up as the universal substrate for the Internet. The only question is, will it be a clearly-defined, well-specified substrate, or a bunch of not-very- compatible vendor-specific hacks on the current 2.0 spec to try and trim it down to something that functions as a universal substrate? >Perhaps an update to BCP 56 (aka http://www.ietf.org/rfc/rfc3205.txt ) "On >the use of HTTP as a Substrate" and explicit warnings about the >inappropriateness of HTTP/2 for these other applications belongs in the HTTP2 >introduction. Yeah, because that approach has worked so well to date... >the pain I had with HPACK suggests it's a potential pain-point for a lot of >others as well. As the author of the original HPACK (see e.g. https://www.freshports.org/archivers/hpack.non-usa.only/), maybe it could be renamed so it doesn't give my original HPACK a bad name :-). Peter.
Received on Tuesday, 6 May 2014 10:38:02 UTC