- From: James M Snell <jasnell@gmail.com>
- Date: Thu, 7 Feb 2013 15:42:38 -0800
- To: HTTP Working Group <ietf-http-wg@w3.org>
+1 .. the minimum data size was a bit strange to me as well. On Thu, Feb 7, 2013 at 3:39 PM, David Morris <dwm@xpasc.com> wrote: > > > On Thu, 7 Feb 2013, Martin Thomson wrote: > >> One potential concern with this is that the opaque id is too small. We >> haven't discussed this, but the current design relies on the fact that >> stream identifiers are not reused. A 16 bit id would lead to connections >> being rendered useless very quickly. Jeff mentioned that even at 31 bits, >> this happens too often anyway. >> >> That could mean that we need to consider other options anyway, but I >> thought the information useful to surface, regardless. > > I was concerned abut the 16bit Opaque ID as well, it seems small to me. > > I also noted a comment when this frame header was suggested that frame > data must be a minimum of 16 bits. I'm perhaps not yet aware of the > bigger picture, but I don't understand that constraint. But it is > a desire to maintain 64bit alignment, then just expand the ID and remove > the 16 bit minimum constraing. > >> On Feb 7, 2013 1:53 PM, "James M Snell" <jasnell@gmail.com> wrote: >> >> > On Wed, Feb 6, 2013 at 3:47 AM, Amos Jeffries <squid3@treenet.co.nz> >> > wrote: >> > [snip] >> > > >> > > The Frame format: >> > > >> > > 0 1 >> > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >> > > +-+-+-----------+---------------+ >> > > |F|C| type | | >> > > +-+-+-----------+ + >> > > | Frame Length (24) | >> > > +-------------------------------+ >> > > | opaque ID (16) | >> > > +-------------------------------+ >> > > | Frame Data (16...N) | >> > > +-------------------------------+ >> > > >> > >> > +1 ... I'm still unconvinced that control frames ought to be any >> > longer than 16-bit but this seems like a reasonable compromise and >> > workable format. >> > >> > - James >> > >> > >> >
Received on Thursday, 7 February 2013 23:43:25 UTC