I suggest we hold this for update. This is not necessary (a MAY and MUST are not in conflict) and it complicates the section to mention NEW_TOKEN this way, but it's not outright wrong.
On Fri, Jun 12, 2026, at 04:06, [email protected] wrote: > The following errata report has been submitted for RFC9000, > "QUIC: A UDP-Based Multiplexed and Secure Transport" > > -------------------------------------- > You may review the report below and at: > https://errata.rfc-editor.org/eid9003/ > > -------------------------------------- > Type: Technical > Reported by: zhangph <[email protected]> > > Section 12.5 says: > > Original Text > ------------- > Note that it is not possible to send the following frames in 0-RTT > packets for various reasons: ACK, CRYPTO, HANDSHAKE_DONE, NEW_TOKEN, > PATH_RESPONSE, and RETIRE_CONNECTION_ID. A server MAY treat receipt > of these frames in 0-RTT packets as a connection error of type > PROTOCOL_VIOLATION. > > Corrected Text > -------------- > Note that it is not possible to send the following frames in 0-RTT > packets for various reasons: ACK, CRYPTO, HANDSHAKE_DONE, NEW_TOKEN, > PATH_RESPONSE, and RETIRE_CONNECTION_ID. A server MAY treat receipt > of these frames in 0-RTT packets as a connection error of type > PROTOCOL_VIOLATION. Note that receipt of a NEW_TOKEN frame is always > a connection error of type PROTOCOL_VIOLATION, as specified in > Section 19.7, and is not subject to the MAY above. > > Notes > ----- > Section 19.7 states unconditionally that "a server MUST treat receipt > of a NEW_TOKEN frame as a connection error of type PROTOCOL_VIOLATION", > because NEW_TOKEN is a server-to-client frame. Section 12.5 lists > NEW_TOKEN among the frames for which a server MAY treat receipt in > 0-RTT packets as a connection error. For the specific case of a server > receiving a NEW_TOKEN frame in a 0-RTT packet, the permissive MAY in > Section 12.5 reads as if it could override the unconditional MUST in > Section 19.7. While Section 19.7 (being specific to NEW_TOKEN) would > normally govern, the spec does not explicitly state this precedence, > leaving an apparent normative-strength overlap. This is submitted as > Editorial: the proposed note in Section 12.5 clarifies that Section > 19.7's MUST takes precedence for NEW_TOKEN in all packet number spaces, > removing the ambiguity. (No change to intended behavior is requested, > only clarification of the relationship between the two sections.) > > 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. > > -------------------------------------- > RFC9000 (draft-ietf-quic-transport) > -------------------------------------- > Title : QUIC: A UDP-Based Multiplexed and Secure Transport > Publication Date : May 2021 > Author(s) : J. Iyengar, Ed., M. Thomson, Ed. > Category : Proposed Standard > Source : quic (wit) > Stream : IETF > Verifying Party : IESG
