Subject: Who is using experimental codepoints in HTTP/2?

From: "Martin Thomson" <[email-masked]>
Date: Mon, 24 May 2021 20:10:52 +1000

https://github.com/httpwg/http2-spec/pull/853 proposes that we do away with the "Experimental Use" ranges for frame types and settings.  The result would be that new registrations could use these values.

This brings things more in line with recent changes in how we've seen protocols, like TLS and QUIC, do codepoint allocation.  There, we've learned (as we learned with RFC 6648 for textual registries) that codepoints used for experiments don't change when the experiment is successful.

What we're seeing instead new allocations that take _random_ unassigned codepoints and experiment with them without much coordination.  Registration policies that are welcoming (no review process, just liberally applied approval) ensure that these are entered into registries early.  As the policies (except for frame types) are already quite open for HTTP/2, removing this "Experimental Use" rule should make it easier rather than harder to experiment ... and transition the experiment into mainstream usage.

Of course, if extending HTTP/2 is as bad as Ian Swett would have it, then no one is experimenting because they can't.  Even if that might render this change moot, it's probably still worth doing the right thing anyway.

The other part of this, which might be worthwhile (I'm undecided here) is whether adding provisional registration makes sense.  I haven't written that up, but if people really want that, then we can do that too.

Does anyone have any objection to making this change?

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 24 May 2021 15:05:51 +0000

--------
Martin Thomson writes:
> https://github.com/httpwg/http2-spec/pull/853 proposes that we do away with t
> he "Experimental Use" ranges for frame types and settings.  The result would 
> be that new registrations could use these values.

I doubt this will cause issues for H2, even with a 8-bit space.

But it does give me reason to pause if you want this to be the general
policy going forward ?

Either we have to size fields which index such "potentially unlimited"
registries generously to avoid any "X bits is enough for everybody"
embarrasment, which probably means >=32 bits or we have to serialize
them as variable length.

SNMP did the latter and that seems like a good call: The
`enterprise-numbers` IANA registry is now up to 57468, despite the
people advocating for 16 bit fields back then assuring us there
would be /no way/ for that to ever happen.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 25 May 2021 07:05:46 +1000

> would be /no way/ for that to ever happen.

QUIC has done the same also and that seems like the right call here.  2^62 values is enough that we are unlikely to see the space exhausted.

---

From: Cory Benfield <[email-masked]>
Date: Tue, 25 May 2021 07:13:12 +0100

> QUIC has done the same also and that seems like the right call here.  2^62 values is enough that we are unlikely to see the space exhausted.

We can throw this idea on the "only with new ALPN" pile with the others.