The point of these specific reserved identifiers is that they are understood by recipients. The sections that are cited clearly describe what it means to understand and process these.
I appreciate that this sort of thing can trip people up. Those specific codepoints are described as not being used. I'm split between holding this for document update and rejecting it. If this were an erratum to hold, then I'd suggest that the replacement text instead include a new sentence: Endpoints MUST understand and process all setting identifiers in this document according to their definitions. But that's a bit of a non-statement, because we already have MUST-strength requirements attached to each and you don't get to pick and choose what parts of the document you comply with[*]. [*] Well, I guess people do, but they assume an interoperability hazard by doing so. Those "MUST"s all exist for good reasons. On Thu, Jun 11, 2026, at 04:19, [email protected] wrote: > The following errata report has been submitted for RFC9114, > "HTTP/3" > > -------------------------------------- > You may review the report below and at: > https://errata.rfc-editor.org/eid8999/ > > -------------------------------------- > Type: Technical > Reported by: zhangph <[email protected]> > > Section 7.2.4 says: > > Original Text > ------------- > An implementation MUST ignore any parameter with an identifier it does > not understand. > > Corrected Text > -------------- > An implementation MUST ignore any parameter with an identifier it does > not understand, except for reserved setting identifiers as specified in > Section 7.2.4.1. > > Notes > ----- > Section 7.2.4 states that a receiver MUST ignore any SETTINGS parameter > with an identifier it does not understand. However, Section 7.2.4.1 > states that reserved setting identifiers (0x00, 0x02-0x05, which were > defined in HTTP/2 but have no corresponding HTTP/3 setting) MUST NOT be > sent, and their receipt MUST be treated as a connection error of type > H3_SETTINGS_ERROR. > > These two rules contradict each other for reserved identifiers: the > general rule says "ignore", but the specific rule says "treat as > connection error". A receiver that does not understand a reserved > identifier would follow the general rule and ignore it, when it should > actually treat it as a connection error. > > The suggested fix adds an exception clause to the general rule, making > it clear that the reserved identifier handling in Section 7.2.4.1 takes > precedence. > > Instructions: > ------------- > This erratum is currently posted as "Reported". Please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > will log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC9114 (draft-ietf-quic-http) > -------------------------------------- > Title : HTTP/3 > Publication Date : June 2022 > Author(s) : M. Bishop, Ed. > Category : Proposed Standard > Source : quic (wit) > Stream : IETF > Verifying Party : IESG
