Re: Design Issue: Frame Size Items

[Roberto Peon <[e-mail]>]

since a frame != the payload of a frame, I think the answer shouldn't be in
question.
A frame includes the framing and overhead bytes, and (regardless of how it
may have been done in the past) the frame-size field either corresponds to
this entity, or needs to be renamed.
-=R


On Tue, May 7, 2013 at 11:07 AM, Martin Thomson <[e-mail]>wrote:

> On 7 May 2013 08:19, James M Snell <[e-mail]> wrote:
> > 1. There is an existing ed note in the draft indicating that we
> > currently do not have any way of specifying the maximum frame size.
> > There are several possibilities:
> >
> >   a. We decide we don't need to report a maximum frame size.
>
> This has been discussed.  The problem is that you have to then FIX the
> maximum frame size and require that all implementations support that
> size.  No one can decide on a goldilocks number: 4096, 8192, 16384,
> 32768 or 65536 have all been variously proposed.  Others want to add
> extra bits to the length field to open up other options (i.e.,
> petabytes).
>
> >   b. We introduce a MAX_FRAME_SIZE setting for the SETTINGS frame.
>
> This introduces another "known state" issue (see Gabriel's issues).
> You have to have a default (see above), and then a robust way to
> change.
>
> >   c. We add a headers block to the RST_FRAME and GOAWAY frames ;-) ..
>
> I'm not following you.
>
> >   I think I prefer option (a) but (b) works too.
> >
> > 2. In the current draft we say that all implementations MUST be
> > capable of supporting frames up to 8192 octets in length. We don't
> > say, however, whether that size includes the 8-byte header or is that
> > just payload octets?
>
> That's a simple fix.  Toss a coin.  ;)
>
>