RE: User defined SETTINGS frame extensions

Which was my original argument against it -- it doesn't scale well *for numerous arbitrary extensions you want to have adopted broadly at separate times*.  However, if you accept the model that "adopted broadly" ought to mean "brought to the IETF for inclusion in HTTP/_+1" then that's not a concern because you'll be testing with a defined set of extensions in a localized scope, and adding new functionality in chunks as HTTP/_+1 support.  Or you'll be using it privately with a controlled set of devices and servers, and you don't care about broad adoption.

-----Original Message-----
From: Ilari Liusvaara [mailto:ilari.liusvaara@elisanet.fi] 
Sent: Friday, February 7, 2014 1:56 PM
To: William Chan (陈智昌)
Cc: Daniel Sommermann; HTTP Working Group
Subject: Re: User defined SETTINGS frame extensions

On Fri, Feb 07, 2014 at 12:36:30PM -0800, William Chan (陈智昌) wrote:
>
> People discussed allowing this sort of extensibility at the Zurich 
> interim. I think it was fairly contentious but overall we decided to 
> disallow it. You're absolutely right that this kind of extensibility 
> could have value, but I think we killed it off like we killed off all 
> other extensibility, since people should just use a different ALPN 
> token.

How would extensions via ALPN scale? It seems to me that the negotiation scales very poorly (full exponential in independent case!) in number of available extensions.


As for extensions via SETTINGS, it might be that the the model is not useful enough for negotiating extensions.

Few example issues:
- How would other end NAK such extension?
- How would extensions needing two-way ACKs be supported?


-Ilari

Received on Friday, 7 February 2014 23:30:23 UTC