Re: User defined SETTINGS frame extensions

That recollection of the discussion sounds right to me. FWIW, here's
what the minutes
(https://github.com/http2/wg_materials/blob/master/interim-14-01/minutes.md)
say:

"""
Issue 95 Extensibility

Hum was 50-50.

Decided against. Unhandled SETTINGS MUST be ignored, though.

On Fri, Feb 7, 2014 at 1:56 PM, Mike Bishop
<Michael.Bishop@microsoft.com> wrote:
> The general outcome of that discussion was that, if you want to add custom setting values or frame types to the base spec, you should define a corresponding ALPN string (e.g. "H2-FB") so you can be sure both parties know about and agree to use the extra values.  It's a higher bar and encourages fragmentation (which I don't like), but it gets rid of the need to negotiate what's supported or to restrict what those settings can do.
>
> -----Original Message-----
> From: willchan@google.com [mailto:willchan@google.com] On Behalf Of William Chan (???)
> Sent: Friday, February 7, 2014 12:37 PM
> To: Daniel Sommermann
> Cc: HTTP Working Group
> Subject: Re: User defined SETTINGS frame extensions
>
> http://http2.github.io/http2-spec/#SettingValues says: "An endpoint that receives a SETTINGS frame with any other setting identifier MUST treat this as a connection error (Section 5.4.1) of type PROTOCOL_ERROR."
>
> 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. I don't think there was a strong consensus at all, so you should push on this if you have strong feelings here.
>
> On Fri, Feb 7, 2014 at 12:23 PM, Daniel Sommermann <dcsommer@fb.com> wrote:
>> Right now, the HTTP/2 spec reserves higher numbers SETTINGS
>> identifiers for future revisions to the protocol. Would there be a
>> benefit to allowing users to register/reserve identifiers for their
>> own use? Or perhaps a weaker, more practical version of this: set
>> aside a range of high numbered identifiers (ala ephemeral ports) that
>> are reserved for internal use within controlled networks. It could be
>> useful to allow two internal HTTP/2 endpoints to exchange information
>> via SETTINGS that do not make sense for the internet at large.
>>
>

Received on Friday, 7 February 2014 21:59:01 UTC