Subject: User defined SETTINGS frame extensions

From: Daniel Sommermann <[email-masked]>
Date: Fri, 7 Feb 2014 12:23:42 -0800

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.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Fri, 7 Feb 2014 12:36:30 -0800

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 <[email-masked]> 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.
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 7 Feb 2014 23:56:04 +0200

On Fri, Feb 07, 2014 at 12:36:30PM -0800, William Chan (陈智昌) wrote:
> 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

---

From: Mike Bishop <[email-masked]>
Date: Fri, 7 Feb 2014 21:56:18 +0000

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: [email-masked] [mailto:[email-masked]] 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 <[email-masked]> 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.
>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Fri, 7 Feb 2014 13:58:33 -0800

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.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 7 Feb 2014 15:23:56 -0800

On 7 February 2014 13:58, William Chan (陈智昌) <[email-masked]> wrote:
> Unhandled SETTINGS MUST be ignored, though.

I'll note that there was subsequent discussion on this point that
concluded with what we have in the spec.  I know Roberto in particular
was sad at this conclusion, but I got the sense that this was another
case of "done > perfect".

I got the sense that there was a reasonably firm commitment to
preventing extension for frame types.  There might be frame types that
don't interact with the protocol state in any way, but most of the
functions those can, to a large extent at least, be fulfilled at
higher layers.

Forbidding setting extension is less popular, since there is arguably
less risk that settings could be used to break things.  At the same
time, it's hard to imagine something that couldn't be fulfilled
through other avenues.  I feel obliged to point out that we've started
to set the bar pretty high for adding new features, and this could be
conceived of as a new feature.  It would have to come with some fairly
strong justification.

---

From: Mike Bishop <[email-masked]>
Date: Fri, 7 Feb 2014 23:29:35 +0000

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:[email-masked]] 
Sent: Friday, February 7, 2014 1:56 PM
To: William Chan (陈智昌)
Cc: Daniel Sommermann; HTTP Working Group
Subject: Re: User defined SETTINGS frame extensions

> other extensibility, since people should just use a different ALPN 

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:

-Ilari