- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Fri, 11 Jul 2014 15:37:26 -0700
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: Nicholas Hurley <hurley@todesschaf.org>, Greg Wilkins <gregw@intalio.com>, Jeff Pinner <jpinner@twitter.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 11 July 2014 14:53, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > If 256 bytes is enough for basic interop, we shouldn't require more. I find this reasonably convincing. Interoperability is what we are looking for here. Though I'll note that the arguments regarding cost of implementation are very much less convincing. Those devices, when presented with a peer that doesn't know their capabilities, will have to deal with 16k frames until their setting is seen. And I'm not sure that 16k is so hard for a constrained device to handle anyway. I keep hearing about what amazing things that even the most constrained hardware can handle (TLS stacks, node.js, etc...). So I'm disinclined to lend too much weight to arguments about limited capabilities. That said, if 256 is enough to get something working, then that's a good argument. An alternative approach would be to set the default and minimum to the same value. That has other benefits, like being able to completely ignore a setting from the other side. That seems pretty attractive.
Received on Friday, 11 July 2014 22:37:54 UTC