Hi, Speaking as an individual with no hats, I think the current text is fine as is.
A recipient that implements RFC 9114 understands the setting _identifiers_ that RFC 9114 defines. Reserving an identifier is still a definition, the language for them is clear. It an implementation doesn't fo that, then it doesn't implements the RFC IMO. In other words, there should be code that says "this setting code point is not valid for HTTP/3 because this RFC says so and I'll close the connection". In practical terms, ignoring the setting, while not strictly to the letter of the law, is probably just fine. Some folks chose to let protocol violations slide. Beating them over the head with RFC text probably won't change their mind. IMHO reject the errata On Wed, Jun 10, 2026, at 19: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 > >
