- From: Yoav Nir <ynir.ietf@gmail.com>
- Date: Sun, 13 Jul 2014 15:38:28 +0300
- To: Mark Nottingham <mnot@mnot.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Jul 12, 2014, at 9:46 AM, Mark Nottingham <mnot@mnot.net> wrote: > There has been a lot of discussion over the last two weeks about various proposals to address a number of issues. While we're not at the point where we have consensus to accept any of them wholesale, I do think we can reduce the surface area of the discussion by declaring consensus on the less controversial parts. > > So: it appears that we have consensus to address issue #553 by: > > * Expanding the frame size field to 24 bits > * Reserving additional bits to align > * Adding a setting advertising the maximum frame size allowed by the recipient, with a default of 16K octets and a minimum of 256 octets > > This would address (only) <https://github.com/http2/http2-spec/issues/553>. > > Does anyone have a problem with that, or further comments? No problems for me, but at least some of the advocates for this change wanted separate settings for DATA vs HEADER frames (or more likely, DATA vs everything else). If that’s controversial, I think it’s fine to have a single setting now. I also agree with Roberto and Poul-Henning that alignment is not likely to matter much. I also don’t believe we need to reserve those bits for future extension of the length field. If we ever want to expand the frames beyond 16 MB, then it’s going to be a very different protocol (where we don’t care about interactivity) or a very different Internet (where sending a >16 MB buffer does not hurt interactivity), so it’s not likely that a protocol we make now will fit anyway. So IMO room for expanding the length field and alignment are not reasons to reserve bits. That said, leaving room for more flags may or may not be a worthy goal, so we might as well have it. Yoav
Received on Sunday, 13 July 2014 12:39:00 UTC