Thanks for the added context. I asked Claude Opus 4.5 to survey open source implementations of HTTP/3. I have not verified the full results for all surveyed. Take with pinch of salt. But can speak authoritative for Cloudflare quiche as a maintainer.
7 implementations reject 5 reserved codepoints (0x0, 0x2-0x5) - Cloudflare quiche, aioquic, hyperium/h3, haproxy, haskell http3, eclipse jetty, cowlib/cowboy 9 implementations reject 4 reserved codepoints (0x2-0x5). They all fail to reject 0x0. HTTP/2 itself reserves 0x0 for no use, see IANA. nghttp3, lsquic, msquic (.net), neqo, Google quiche, netty, ocaml-quic, libhttp.zig, quiver 9 implementations ignore these reserved settings. quic-go, proxygen, picoquic, nginx, xquic, flupke/kwik, h2o/quicly, ATS, deno I'd summarise this as an inconsistent application of the intent of RFC 9114. However, I don't think the fault lies solely on the RFC 9114 shoulders nor implementations. IANA has a reserved value for HTTP/2's 0x0, which cites RFC 9113 but there doesnt seem to be anything there. RFC 7540 seems quiet on 0x0 too. RFC 9114 explicirly reserves 0x0, it also has a section discussing H2 settings - A.3 - 0x0 is not mentioned there. So we are in a bit of an awkward situation that likely warrants deeper thinking than a spot fix in just one RFC. Cheers Lucas On Thu, Jun 11, 2026, at 01:38, zhangph wrote: >> Thank you both for the detailed analysis. >> >> >> >> I'd like to present a concrete example of the ambiguity in practice. The >> maintainer of picoquic (a widely-deployed HTTP/3 implementation) encountered >> exactly this issue when reviewing a bug report about reserved setting >> identifiers: >> >> >> >> https://github.com/private-octopus/picoquic/issues/2126 >> >> >> >> In response to the report, the project maintainer wrote: >> >> >> >> "The spec also says that 'An implementation MUST ignore any parameter with >> an identifier it does not understand.' Picoquic does not understand these >> parameters, so it ignores them." >> >> >> >> "The requirement to break the connection is probably a bug in RFC 9114, that >> should be fixed in its next revision." >> >> >> >> In other words, an experienced implementer of this RFC read the general rule >> in Section 7.2.4 ("MUST ignore unknown") and concluded that it applies to >> reserved identifiers — and further concluded that the specific requirement >> in Section 7.2.4.1 is itself the error. This is precisely the ambiguity I am >> highlighting. >> >> >> >> I agree this erratum may not warrant a technical correction. But I believe >> this real-world evidence supports Hold for Document Update — the current >> wording has led at least one prominent implementer to a reasonable but >> incorrect reading of the document. >>
