Re: Striving for Compromise (Consensus?)

Well I thought we were close to consensus on the large frame proposal until
the reduction <24 bits.    If 24bits is so objectionable that we want to
continue circling on this one .....

So let's look at your alternative.

On 11 July 2014 17:32, Jeff Pinner <jpinner@twitter.com> wrote:

> How do people feel about the following compromise:
>
> 1) Increase frame size to 16-bits.
> 2) Remove reference set from HPACK allowing for "streaming" decoding.
> 3) Requiring that all ":"-headers appear first.
> 4) Only allowing CONTINUATION if the previous frame is 2^16-1 bytes.
> 5) Allowing interleaving of CONTINUATION frames with other frames.
>
>
I could almost live with that.   Problem is that can't fragment headers to
less than 64KB, which if I understand the current arguments against the
"Greg et al" is a must have.

So how about:

1) Increase frame size to 16-bits
1a) Add a settings for max_frame_size
2) Remove reference set from HPACK allowing for "streaming" decoding.
3) Requiring that all ":"-headers appear first.
4) Only allowing CONTINUATION if the previous frame is max_frame_size.
5) Allowing interleaving of CONTINUATION frames with other frames.
5b) The size of the HEADERS and CONTINUATION frames are removed from the
flow control window, but the they are never flow controlled.








-- 
Greg Wilkins <gregw@intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.