- From: Patrick McManus <mcmanus@ducksong.com>
- Date: Tue, 2 Sep 2014 17:25:31 -0400
- To: "Roy T. Fielding" <fielding@gbiv.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAOdDvNognsLEv_M0ngYz4jiNPWXXhyBPFRFLnthWeARG1t1zzQ@mail.gmail.com>
Hi Roy, On Fri, Aug 29, 2014 at 6:49 PM, Roy T. Fielding <fielding@gbiv.com> wrote: > This comment is in reference to section 4.1 of > > http://tools.ietf.org/id/draft-ietf-httpbis-http2-14.txt > > > 4.1. Frame Format > > > > All frames begin with a fixed 9-octet header followed by a variable- > > length payload. > [..] > > I think this has become a bit moth-eaten over time as the WG has > adjusted field lengths and perhaps added or removed a few. > That time was quite recent: from -13 to -14 as the consensus was to increase the payload length from 16 to 24 bits maintaining a requirement for a fixed 10 0 bits unless otherwise negotiated via settings. I was never a fan of that - if we were to decide that a concise 64 bits is necessary then I think we should revert that length field increase rather than giving up the type and flag space extensions may want to use. The extended length users could operate via extension. But before anyone gets too excited, overall I personally don't think the need to either align or pack the header into 64bits is very important given the rather unaligned nature of the payloads and so I don't favor reopening the issue. The 8 vs 9 byte header was part of the issue discussion already - as can be seen here http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/0706.html when a proposal reallocating 8 bits from stream ID instead of type and flags so I don't feel like this is unconsidered information when making that decision. -Patrick
Received on Tuesday, 2 September 2014 21:25:58 UTC