Re: Large Frame Proposal

Will double-bleh do?

Nope? I thought not.

The proposal will work just fine so long as you don't get a pair of entites
on the path that do the stupid together.
Hopefully this isn't something that would happen today, but who knows.
With a smaller max frame size and continuations, you need implementations
that screwed up by more than just setting a single variable too big in
order to screw with latency.

So, how much do we want to empower folks to shoot themselves in the head in
order to deal with the 0.02% usecase?

-=R


On Wed, Jul 9, 2014 at 5:57 PM, Mark Nottingham <mnot@mnot.net> wrote:

>
> On 10 Jul 2014, at 10:54 am, Roberto Peon <grmocg@gmail.com> wrote:
>
> > If there is a single limit on framesize, then it would end up being
> large because the receiving party is unlikely to know how large the headers
> should be, and must set it to as large as they ever believe headers might
> be.
> > That negatively impacts reactivity.
> >
> > One could fix this by have separate headers vs data max frame size.
> > Then we'd need to figure out which one mapped to SETTINGS and other
> control frames.
> > Would it be a control-frame vs data-frame setting?
>
> That's the direction that greg et al have proposed, and it seems to have
> good support.
>
> > Bleh.
>
> I need a better reason than "bleh" to justify the decision to the IESG...
>
> Cheers,
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>
>
>