Re: Frame Length Restrictions

On Mon, Apr 21, 2014 at 9:03 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

>
> Not so.
>
> Rather than 8 bytes of overhead every 2^14-1 bytes, you have 8 bytes
> of overhead every 2^14-9 (or 8, which is be sufficient).  If that's a
> problem, then any sort of framing overhead is a problem.
>

I don't think I follow. Are you saying that the overhead of always
splitting frames is negligible so it's ok to always split frames in order
to not have a discontinuity in padding?

That seems to be saying that implementations that don't always split frames
could have an issue but they should just "do the right thing" instead of
forcing it by calling out the restriction in the protocol itself.

If that is the argument (and I'm not saying it is) then it seems antithesis
to restricting the frame length in the first place. Arguably
implementations that care about responsiveness should "do the right thing"
and restrict the data payloads instead of having the protocol force them to
do so at the expense of applications that either do not multiplex or do not
care about interactivity.