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
