RE: Striving for Compromise (Consensus?)

On Friday,11 July 2014 09:32, jpinner@twitter.com wrote:

> How do people feel about the following compromise:

-1
It eliminates both purposes of the 'Greg et al' proposal:
  a) Eliminate the CONTINUATION ugliness (complexity, processing, etc.), and
  b) add bits & settings for tuning frame lengths.


> 1) Increase frame size to 16-bits.

I don't know how this could be claimed as a good idea without also having the SETTINGS_HEADER_SIZE & SETTINGS_FRAME_SIZE setting.  Roberto, Patrick, etc. have repeatedly said that 16K is the 'optimal' frame size for multiplexing on today's networks.  Moving to 16 bits without a setting means everybody will use 64K.  Remember, in the 'Greg et al' proposal the default frame size is still 16K (actually it's literally one better - it's 16K instead of 16K-1!).

It's also terribly short-sighted to not have any space for expansion.  At the very least you should keep 1 reserved bit so you can do the ugly "jumbo frame" hack later when you figure out you want bigger frame sizes.


> 2) Remove reference set from HPACK allowing for "streaming" decoding.

This is a good idea.


> 3) Requiring that all ":"-headers appear first.

This is also a good idea.


> 4) Only allowing CONTINUATION if the previous frame is 2^16-1 bytes.

See Roberto's thread "Fragmentation for headers: why jumbo != continuation" [1] for reasons why he thinks this is a bad idea.


> 5) Allowing interleaving of CONTINUATION frames with other frames.

Admittedly better than the status quo, but still not entirely clear why this is necessary. i.e. why not 1*HEADERS instead?


[1] http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/0687.html


This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

Received on Friday, 11 July 2014 09:42:29 UTC