- From: Simpson, Robby (GE Energy Management) <robby.simpson@ge.com>
- Date: Mon, 4 Aug 2014 19:46:57 +0000
- To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
I would very much like to see HTTP/2 be useful in constrained devices / embedded applications. I believe it to be unfortunate that there is currently a position to bifurcate the "human web" and the "machine web" (e.g., HTTP/1.1 vs. CoAP). In my read of -14, I believe (without having yet implemented) that HTTP/2 is very close to being quite useful to the constrained devices / IoT world. Here are a few concerns: In 4.2, "All implementations MUST be capable of receiving and minimally processing frames up to 2^14 octets in length, plus the 9 octet frame header (Section 4.1)." We could go back and forth on the term "minimally processing," but a lot of constrained devices are going to have difficulty buffering frames this large. Is there a reason we can not lower or remove this requirement? In 5.2.1, "The initial value for the flow control window is 65,535 bytes for both new streams and the overall connection." Once again, I believe constrained devices will have difficulty here. I realize that for this case, a new setting can be negotiated, but this could potentially occur after data have been sent (resulting in a negative window size). Ideally, we could also have this be <= to the minimum maximum frame size (2^14). It would also be helpful to try and maintain byte and/or word alignment in headers. Finally, I have not yet studied HPACK, but I do applaud the move away from deflate. deflate has terrible memory requirements for constrained devices. For reference, RFC 7228 has some definitions on "constrained devices." I would think ~10 KB RAM and ~100 KB flash would be the most constrained target. In addition to discussion on the above, I welcome any thoughts on HTTP/2 and constrained devices. - Robby Robby Simpson, PhD System Architect GE Digital Energy
Received on Monday, 4 August 2014 19:47:24 UTC