Re: Striving for Compromise (Consensus?)

Hi Jeff,

Thanks. Based on the discussion today, I'm open to this.

From where I sit, the only one that seems controversial is #4 - and we've already seen a proposed modification from Greg. 

Personally, I wonder if we can just ditch #4 and still have reasonable properties; an implementation that receives too many CONTINUATIONS can reset the stream and continue to process other streams, correct?

Let's talk it through. 

Cheers,


On 11 Jul 2014, at 5:32 pm, 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.
> 
> For implementors that know that they will never accept more than 64kb
> of headers, they don't have to implement CONTINUATION frames.
> 
> For implementors that are concerned about not receiving routing
> headers and having to buffer full frames, they will be the first
> things that show up and the rest of the headers can be proxied without
> any buffering.
> 
> For implementors that need to support headers > 64kb they can do so
> using CONTINUATION frames.
> 
> For implementors concerned about interleaving headers between multiple
> streams, that is now allowed because the reference set does not
> coincide with the end of the header block.
> 
> For implementors that are concerned with spec complexity, the entire
> notion of "header block fragments" is removed.
> 
> Thoughts?
> 

--
Mark Nottingham   https://www.mnot.net/

Received on Friday, 11 July 2014 08:04:18 UTC