Since I am the "maintainer of picoquic" quoted in the zhangph's email,
let me provide a bit more context.
The generic behavior in parsing settings is to ignore anything that the
local implementation does not understand. RFC 9114 says that, and then
also says a bit later that some settings should not be just ignored, but
also ignored with prejudice. The prejudice applies to the 5 parameters
that are defined in HTTP2 but have no meaning in HTTP3, but as it is
written it would also apply to all new parameters that will be defined
for HTTP2 in the future but do not apply to HTTP3. That latter
requirement is, shall we say, not entirely realistic.
Coming back to the distinction between "ignore" and "ignore with
prejudice". The main reason for that requirement is to enforce that any
implementation that errs into reusing HTTP2 parameters for H3 will
encounter so many connection failures that it would have no choice but
to fix their code. It is a classic consequence of the "Postel was wrong"
argument: by providing stark consequences to any deviation of the
standard, we ensure that the standard remains pure.
We have a couple of similar prohibitions in RFC9000, and we generally
adopted a "MUST ignore, MAY yell" pattern. This is a practical solution,
because if enough implementations do the "MAY" part, the deviants will
still be whacked into compliance. At the same time, we let constrained
implementations decide whether they should add code to implement the
punishment. We also make sure that these implementations will not be
bothered by over-zealous protocol verifiers.
My position is that RFC 9114 should have adopted the "MUST ignore, MAY
yell" pattern, and that mandating all implementations to police this
kind of thing is overreach worthy of an errata.
As for protocol purity, I don't think that flogging these 5 specific
code points will have a big effect on the purity of the ecosystem.
Deviants have almost 2^62 potential codes to experiment with, blocking 5
of them is not likely to make a difference.
And as for picoquic, we just checked in a PR to fail the connection if
the settings include one of these five codes. Turns out that we already
had a switch statement listing the code points that should not be
expected, and returning an error for the 5 contentious values costed
just 8 lines of code...
-- Christian Huitema
On 6/10/2026 6:50 PM, Lucas Pardue wrote:
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.
