The requested operation cannot be served over HTTP/3.  The peer should retry over HTTP/1.1. <del> Error codes of the format "0x1f * N + 0x21" for integer values of N are reserved to exercise the requirement that unknown error codes be treated as equivalent to H3_NO_ERROR (extensions).  Implementations SHOULD select an error code from this space with some probability when they would have sent H3_NO_ERROR. </del> <ins> Error codes of the format "0x1f * N + 0x21" for non-negative integer values of N are reserved to exercise the requirement that unknown error codes be treated as equivalent to H3_NO_ERROR (extensions). Implementations SHOULD select an error code from this space with some probability when they would have sent H3_NO_ERROR. </ins> 9.


The entries in iana-frame-table are registered by this document. <del> Additionally, each code of the format "0x1f * N + 0x21" for integer values of N (that is, "0x21", "0x40", ..., through </del> <ins> Additionally, each code of the format "0x1f * N + 0x21" for non- negative integer values of N (that is, "0x21", "0x40", ..., through </ins> "0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA. 11.2.2.


The entries in iana-setting-table are registered by this document. <del> Additionally, each code of the format "0x1f * N + 0x21" for integer values of N (that is, "0x21", "0x40", ..., through </del> <ins> Additionally, each code of the format "0x1f * N + 0x21" for non- negative integer values of N (that is, "0x21", "0x40", ..., through </ins> "0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA. 11.2.3.


The entries in the iana-error-table are registered by this document. <del> Additionally, each code of the format "0x1f * N + 0x21" for integer values of N (that is, "0x21", "0x40", ..., through </del> <ins> Additionally, each code of the format "0x1f * N + 0x21" for non- negative integer values of N (that is, "0x21", "0x40", ..., through </ins> "0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA. 11.2.4.


The entries in the following table are registered by this document. <del> Additionally, each code of the format "0x1f * N + 0x21" for integer values of N (that is, "0x21", "0x40", ..., through </del> <ins> Additionally, each code of the format "0x1f * N + 0x21" for non- negative integer values of N (that is, "0x21", "0x40", ..., through </ins> "0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA. 12.  References


If TLS experiences an error, it generates an appropriate alert as defined in Section 6 of TLS13. <del> A TLS alert is turned into a QUIC connection error by converting the one-byte alert description into a QUIC error code.  The alert </del> <ins> A TLS alert is converted into a QUIC connection error.  The alert </ins> description is added to 0x100 to produce a QUIC error code from the range reserved for CRYPTO_ERROR.  The resulting value is sent in a QUIC CONNECTION_CLOSE frame of type 0x1c.


The alert level of all TLS alerts is "fatal"; a TLS stack MUST NOT generate alerts at the "warning" level. <ins> QUIC permits the use of a generic code in place of a specific error code; see Section 11 of QUIC-TRANSPORT.  For TLS alerts, this includes replacing any alert with a generic alert, such as handshake_failure (0x128 in QUIC).  Endpoints MAY use a generic error code to avoid possibly exposing confidential information. </ins> 4.11. After QUIC moves to a new encryption level, packet protection keys


Key updates MUST be initiated before usage limits on packet protection keys are exceeded.  For the cipher suites mentioned in <del> this document, the limits in Section 5.5 of TLS13 apply.  Other cipher suites MUST define usage limits in order to be used with QUIC. </del> <ins> this document, the limits in Section 5.5 of TLS13 apply.  TLS13 does not specify a limit for AEAD_AES_128_CCM, but the analysis in ccm- bounds shows that a limit of 2^23 packets can be used to obtain the same confidentiality protection as the limits specified in TLS. The usage limits defined in TLS 1.3 exist for protection against attacks on confidentiality and apply to successful applications of AEAD protection.  The integrity protections in authenticated encryption also depend on limiting the number of attempts to forge packets.  TLS achieves this by closing connections after any record fails an authentication check.  In comparison, QUIC ignores any packet that cannot be authenticated, allowing multiple forgery attempts. Endpoints MUST count the number of received packets that fail authentication for each set of keys.  If the number of packets that fail authentication with the same key exceeds a limit that is specific to the AEAD in use, the endpoint MUST stop using those keys. Endpoints MUST initiate a key update before reaching this limit.  If a key update is not possible, the endpoint MUST immediately close the connection.  Applying a limit reduces the probability that an attacker is able to successfully forge a packet; see AEBounds and ROBUST. Due to the way that header protection protects the Key Phase, packets that are discarded are likely to have an even distribution of both Key Phase values.  This means that packets that fail authentication will often use the packet protection keys from the next key phase.  It is therefore necessary to also track the number of packets that fail authentication with the next set of packet protection keys.  To avoid exhaustion of both sets of keys, it might be necessary to initiate two key updates in succession. For AEAD_AES_128_GCM, AEAD_AES_256_GCM, and AEAD_CHACHA20_POLY1305, the limit on the number of packets that fail authentication is 2^36. Note that the analysis in AEBounds supports a higher limit for the AEAD_AES_128_GCM and AEAD_AES_256_GCM, but this specification recommends a lower limit.  For AEAD_AES_128_CCM, the limit on the number of packets that fail authentication is 2^23.5; see ccm-bounds. These limits were originally calculated using assumptions about the limits on TLS record size.  The maximum size of a TLS record is 2^14 bytes.  In comparison, QUIC packets can be up to 2^16 bytes.  However, it is expected that QUIC packets will generally be smaller than TLS records.  Where packets might be larger than 2^14 bytes in length, smaller limits might be needed. Any TLS cipher suite that is specified for use with QUIC MUST define limits on the use of the associated AEAD function that preserves margins for confidentiality and integrity.  That is, limits MUST be specified for the number of packets that can be authenticated and for the number packets that can fail authentication.  Providing a reference to any analysis upon which values are based - and any assumptions used in that analysis - allows limits to be adapted to varying usage conditions. </ins> 6.7.


protocol negotiation.  TLS uses Application Layer Protocol Negotiation (ALPN) ALPN to select an application protocol.  Unless another mechanism is used for agreeing on an application protocol, <del> endpoints MUST use ALPN for this purpose.  When using ALPN, endpoints MUST immediately close a connection (see Section 10.3 in QUIC- TRANSPORT) if an application protocol is not negotiated with a no_application_protocol TLS alert (QUIC error code 0x178, see tls- errors).  While ALPN only specifies that servers use this alert, QUIC clients MUST also use it to terminate a connection when ALPN negotiation fails. </del> <ins> endpoints MUST use ALPN for this purpose. When using ALPN, endpoints MUST immediately close a connection (see Section 10.3 of QUIC-TRANSPORT) with a no_application_protocol TLS alert (QUIC error code 0x178; see tls-errors) if an application protocol is not negotiated.  While ALPN only specifies that servers use this alert, QUIC clients MUST use error 0x178 to terminate a connection when ALPN negotiation fails. </ins> An application protocol MAY restrict the QUIC versions that it can operate over.  Servers MUST select an application protocol compatible


Including transport parameters in the TLS handshake provides integrity protection for these values. <del> The "extension_data" field of the quic_transport_parameters extension </del> <ins> The extension_data field of the quic_transport_parameters extension </ins> contains a value that is defined by the version of QUIC that is in use.


output of AEAD_AES_128_GCM AEAD used with the following inputs: The secret key, K, is 128 bits equal to <del> 0x4d32ecdb2a2133c841e4043df27d4430. </del> <ins> 0xccce187ed09a09d05728155a6cb96be1. </ins> <del> The nonce, N, is 96 bits equal to 0x4d1611d05513a552c587d575. </del> <ins> The nonce, N, is 96 bits equal to 0xe54930f97f2136f0530a8c1c. </ins> The plaintext, P, is empty.


The secret key and the nonce are values derived by calling HKDF- Expand-Label using <del> 0x656e61e336ae9417f7f0edd8d78d461e2aa7084aba7a14c1e9f726d55709169a as </del> <ins> 0x8b0d37eb8535022ebc8d76a207d80df22646ec06dc809642c30a8baa2baaff4c as </ins> the secret, with labels being "quic key" and "quic iv" (protection- keys).


The payload of an Initial packet includes a CRYPTO frame (or frames) containing a cryptographic handshake message, ACK frames, or both. <del> PING, PADDING, and CONNECTION_CLOSE frames are also permitted.  An endpoint that receives an Initial packet containing other frames can either discard the packet as spurious or treat it as a connection error. </del> <ins> PING, PADDING, and CONNECTION_CLOSE frames of type 0x1c are also permitted.  An endpoint that receives an Initial packet containing other frames can either discard the packet as spurious or treat it as a connection error. </ins> The first packet sent by a client always includes a CRYPTO frame that contains the start or all of the first cryptographic handshake


The payload of this packet contains CRYPTO frames and could contain PING, PADDING, or ACK frames.  Handshake packets MAY contain <del> CONNECTION_CLOSE frames.  Endpoints MUST treat receipt of Handshake packets with other frames as a connection error. </del> <ins> CONNECTION_CLOSE frames of type 0x1c.  Endpoints MUST treat receipt of Handshake packets with other frames as a connection error. </ins> Like Initial packets (see discard-initial), data in CRYPTO frames for Handshake packets is discarded - and no longer retransmitted - when


Indicates that x is repeated zero or more times (and that each instance is length E) <ins> This document uses network byte order (that is, big endian) values. Fields are placed starting from the high-order bits of each byte. </ins> fig-ex-format shows an example structure: 5.


A QUIC packet with a long header has the high bit of the first byte set to 1.  All other bits in that byte are version specific. <del> The next four bytes include a 32-bit Version field (see version). </del> <ins> The next four bytes include a 32-bit Version field.  Versions are described in version. </ins> The next byte contains the length in bytes of the Destination <del> Connection ID (see connection-id) field that follows it.  This length is encoded as an 8-bit unsigned integer.  The Destination Connection ID field follows the DCID Length field and is between 0 and 255 bytes in length. </del> <ins> Connection ID field that follows it.  This length is encoded as an 8-bit unsigned integer.  The Destination Connection ID field follows the Destination Connection ID Length field and is between 0 and 255 bytes in length.  Connection IDs are described in connection-id. </ins> The next byte contains the length in bytes of the Source Connection ID field that follows it.  This length is encoded as a 8-bit unsigned <del> integer.  The Source Connection ID field follows the SCID Length field and is between 0 and 255 bytes in length. </del> <ins> integer.  The Source Connection ID field follows the Source Connection ID Length field and is between 0 and 255 bytes in length. </ins> The remainder of the packet contains version-specific content.


A QUIC packet with a short header includes a Destination Connection ID immediately following the first byte.  The short header does not include the Connection ID Lengths, Source Connection ID, or Version <del> fields.  The length of the Destination Connection ID is not specified </del> <ins> fields.  The length of the Destination Connection ID is not encoded </ins> in packets with a short header and is not constrained by this specification.


The primary function of a connection ID is to ensure that changes in addressing at lower protocol layers (UDP, IP, and below) don't cause <del> packets for a QUIC connection to be delivered to the wrong endpoint. The connection ID is used by endpoints and the intermediaries that support them to ensure that each QUIC packet can be delivered to the correct instance of an endpoint.  At the endpoint, the connection ID is used to identify which QUIC connection the packet is intended for. </del> <ins> packets for a QUIC connection to be delivered to the wrong QUIC endpoint.  The connection ID is used by endpoints and the intermediaries that support them to ensure that each QUIC packet can be delivered to the correct instance of an endpoint.  At the endpoint, the connection ID is used to identify which QUIC connection the packet is intended for. </ins> The connection ID is chosen by each endpoint using version-specific methods.  Packets for the same QUIC connection might use different


Indicates that x is repeated zero or more times (and that each instance is length E) <ins> This document uses network byte order (that is, big endian) values. Fields are placed starting from the high-order bits of each byte. </ins> By convention, individual fields reference a complex field by using the name of the complex field.


packet protection keys for Initial packets. The client populates the Source Connection ID field with a value of <del> its choosing and sets the SCID Length field to indicate the length. </del> <ins> its choosing and sets the Source Connection ID Length field to indicate the length. </ins> The first flight of 0-RTT packets use the same Destination Connection ID and Source Connection ID values as the client's first Initial


If a zero-length connection ID is selected, the corresponding transport parameter is included with a zero-length value. <del> fig-auth-cid shows the connection IDs that are used in a complete </del> <ins> fig-auth-cid shows the connection IDs (with DCID=Destination Connection ID, SCID=Source Connection ID) that are used in a complete </ins> handshake.  The exchange of Initial packets is shown, plus the later exchange of 1-RTT packets that includes the connection ID established during the handshake.


SHOULD be able to read longer connection IDs from other QUIC versions in order to properly form a version negotiation packet. <del> The Destination Connection ID field follows the DCID Length field and is between 0 and 20 bytes in length. negotiating-connection- ids describes the use of this field in more detail. </del> <ins> The Destination Connection ID field follows the Destination Connection ID Length field and is between 0 and 20 bytes in length.  negotiating-connection-ids describes the use of this field in more detail. </ins> The byte following the Destination Connection ID contains the length in bytes of the Source Connection ID field that follows it.


IDs from other QUIC versions in order to properly form a version negotiation packet. <del> The Source Connection ID field follows the SCID Length field and is between 0 and 20 bytes in length. negotiating-connection-ids describes the use of this field in more detail. </del> <ins> The Source Connection ID field follows the Source Connection ID Length field and is between 0 and 20 bytes in length. negotiating- connection-ids describes the use of this field in more detail. </ins> In this version of QUIC, the following packet types with the long header are defined:


The Initial packet contains a long header as well as the Length and Packet Number fields.  The first byte contains the Reserved and <del> Packet Number Length bits.  Between the SCID and Length fields, there are two additional fields specific to the Initial packet. </del> <ins> Packet Number Length bits.  Between the Source Connection ID and Length fields, there are two additional fields specific to the Initial packet. </ins> A variable-length integer specifying the length of the Token field, in bytes.  This value is zero if no token is present.


transport parameter; see termination.  However, state in middleboxes might time out earlier than that.  Though REQ-5 in RFC4787 recommends a 2 minute timeout interval, experience shows that sending packets <del> every 15 to 30 seconds is necessary to prevent the majority of middleboxes from losing state for UDP flows. </del> <ins> every 30 seconds is necessary to prevent the majority of middleboxes from losing state for UDP flows GATEWAY. </ins> 10.3.


After a client receives a Retry packet, 0-RTT packets are likely to have been lost or discarded by the server.  A client SHOULD attempt to resend data in 0-RTT packets after it sends a new Initial packet. <del> A client MUST NOT reset the packet number it uses for 0-RTT packets, since the keys used to protect 0-RTT packets will not change as a result of responding to a Retry packet.  Sending packets with the same packet number in that case is likely to compromise the packet protection for all 0-RTT packets because the same key and nonce could be used to protect different content. </del> <ins> New packet numbers MUST be used for any new packets that are sent; as described in retry-continue, reusing packet numbers could compromise packet protection. </ins> A client only receives acknowledgments for its 0-RTT packets once the handshake is complete.  Consequently, a server might expect 0-RTT


response to receiving a Retry. A client MUST NOT reset the packet number for any packet number space <del> after processing a Retry packet; packet-0rtt contains more information on this. </del> <ins> after processing a Retry packet.  In particular, 0-RTT packets contain confidential information that will most likely be retransmitted on receiving a Retry packet.  The keys used to protect these new 0-RTT packets will not change as a result of responding to a Retry packet.  However, the data sent in these packets could be different than what was sent earlier.  Sending these new packets with the same packet number is likely to compromise the packet protection for those packets because the same key and nonce could be used to protect different content. </ins> A server acknowledges the use of a Retry packet for a connection using the retry_source_connection_id transport parameter; see


12.1. All QUIC packets except Version Negotiation packets use authenticated <del> encryption with additional data (AEAD) RFC5116 to provide </del> <ins> encryption with associated data (AEAD) RFC5116 to provide </ins> confidentiality and integrity protection.  Retry packets use AEAD to provide integrity protection.  Details of packet protection are found in QUIC-TLS; this section includes an overview of the process.


Authenticated and encrypted header and payload <del> QUIC uses UDP as a substrate to avoid requiring changes to legacy client operating systems and middleboxes.  QUIC authenticates all of its headers and encrypts most of the data it exchanges, including its signaling, to avoid incurring a dependency on middleboxes. </del> <ins> QUIC establishes a connection, which is a stateful interaction between a client and server.  The primary purpose of a connection is to support the structured exchange of data by an application protocol. Streams are means by which an application protocol exchanges information.  Streams are ordered sequences of bytes.  Two types of stream can be created: bidirectional streams, which allow both endpoints to send data; and unidirectional streams, which allow a single endpoint to send.  A credit-based scheme is used to limit stream creation and to bound the amount of data that can be sent. The QUIC handshake combines negotiation of cryptographic and transport parameters.  The handshake is structured to permit the exchange of application data as soon as possible.  This includes an option for clients to send data immediately (0-RTT), which might require prior communication to enable. QUIC connections are not strictly bound to a single network path. Connection migration uses connection identifiers to allow connections to transfer to a new network path. Frames are used in QUIC to communicate between endpoints.  One or more frames are assembled into packets.  QUIC authenticates all packets and encrypts as much as is practical.  QUIC packets are carried in UDP datagrams to better facilitate deployment in existing systems and networks. Once established, multiple options are provided for connection termination.  Applications can manage a graceful shutdown, endpoints can negotiate a timeout period, errors can cause immediate connection teardown, and a stateless mechanism provides for termination of connections after one endpoint has lost state. </ins> 1.1.


5. <del> QUIC's connection establishment combines version negotiation with the cryptographic and transport handshakes to reduce connection establishment latency, as described in handshake.  During connection establishment, each side validates the peer's address, as described in address-validation.  Once established, a connection may migrate to a different IP or port at either endpoint as described in migration. Finally, a connection may be terminated by either endpoint, as described in termination. </del> <ins> A QUIC connection is shared state between a client and a server. Each connection starts with a handshake phase, during which the two endpoints establish a shared secret using the cryptographic handshake protocol QUIC-TLS and negotiate the application protocol.  The handshake (handshake) confirms that both endpoints are willing to communicate (validate-handshake) and establishes parameters for the connection (transport-parameters). An application protocol can use the connection during the handshake phase with some limitations.  0-RTT allows application data to be sent by a client before receiving a response from the server. However, 0-RTT provides no protection against replay attacks; see Section 9.2 of QUIC-TLS.  A server can also send application data to a client before it receives the final cryptographic handshake messages that allow it to confirm the identity and liveness of the client.  These capabilities allow an application protocol to offer the option of trading some security guarantees for reduced latency. The use of connection IDs (connection-id) allows connections to migrate to a new network path, both as a direct choice of an endpoint and when forced by a change in a middlebox.  migration describes mitigations for the security and privacy issues associated with migration. For connections that are no longer needed or desired, there are several ways for a client and server to terminate a connection (termination). </ins> 5.1.


5.3. <del> A QUIC connection is a stateful interaction between a client and server, the primary purpose of which is to support the exchange of data by an application protocol.  Streams (streams) are the primary means by which an application protocol exchanges information. Each connection starts with a handshake phase, during which client and server establish a shared secret using the cryptographic handshake protocol QUIC-TLS and negotiate the application protocol. The handshake (handshake) confirms that both endpoints are willing to communicate (validate-handshake) and establishes parameters for the connection (transport-parameters). An application protocol can also operate in a limited fashion during the handshake phase.  0-RTT allows application data to be sent by a client before receiving any response from the server.  However, 0-RTT lacks certain key security guarantees.  In particular, there is no protection against replay attacks in 0-RTT; see QUIC-TLS. Separately, a server can also send application data to a client before it receives the final cryptographic handshake messages that allow it to confirm the identity and liveness of the client.  These capabilities allow an application protocol to offer the option to trade some security guarantees for reduced latency. The use of connection IDs (connection-id) allows connections to migrate to a new network path, both as a direct choice of an endpoint and when forced by a change in a middlebox.  migration describes mitigations for the security and privacy issues associated with migration. For connections that are no longer needed or desired, there are several ways for a client and server to terminate a connection (termination). 5.4. </del> There are certain operations that an application MUST be able to perform when interacting with the QUIC transport.  This document does not specify an API, but any implementation of this version of QUIC


ordered delivery of cryptographic handshake data start from zero in each packet number space. <ins> fig-hs shows a simplied handshake and the exchange of packets and frames that are used to advance the handshake.  Exchange of application data during the handshake is enabled where possible, shown with a '*'.  Once completed, endpoints are able to exchange application data. </ins> Endpoints MUST explicitly negotiate an application protocol.  This avoids situations where there is a disagreement about the protocol that is in use.


A stateless reset uses an entire UDP datagram, starting with the first two bits of the packet header.  The remainder of the first byte <del> and an arbitrary number of bytes following it that are set to unpredictable values.  The last 16 bytes of the datagram contain a Stateless Reset Token. </del> <ins> and an arbitrary number of bytes following it that are set to values that SHOULD be indistinguishable from random.  The last 16 bytes of the datagram contain a Stateless Reset Token. </ins> To entities other than its intended recipient, a stateless reset will appear to be a packet with a short header.  For the stateless reset


This 8-byte field contains arbitrary data. <del> A PATH_CHALLENGE frame containing 8 bytes that are hard to guess is sufficient to ensure that it is easier to receive the packet than it is to guess the value correctly. </del> <ins> Including 64 bits of entropy in a PATH_CHALLENGE frame ensures that it is easier to receive the packet than it is to guess the value correctly. </ins> The recipient of this frame MUST generate a PATH_RESPONSE frame (frame-path-response) containing the same Data.


Any received 0-RTT data that the server responds to might be due to a replay attack. <del> Therefore, the server's use of 1-RTT keys MUST be limited to sending data before the handshake is complete.  A server MUST NOT process </del> <ins> Therefore, the server's use of 1-RTT keys before the handshake is complete is limited to sending data.  A server MUST NOT process </ins> incoming 1-RTT protected packets before the TLS handshake is complete.  Because sending acknowledgments indicates that all frames in a packet have been processed, a server cannot send acknowledgments


receiving a TLS ClientHello.  The server MAY retain these packets for later decryption in anticipation of receiving a ClientHello. <ins> A client generally receives 1-RTT keys at the same time as the handshake completes.  Even if it has 1-RTT secrets, a client MUST NOT process incoming 1-RTT protected packets before the TLS handshake is complete. </ins> 5.8. Retry packets (see the Retry Packet section of QUIC-TRANSPORT) carry


Invalid packets without packet protection, such as Initial, Retry, or Version Negotiation, MAY be discarded.  An endpoint MUST generate a <del> connection error if it commits changes to state before discovering an error. </del> <ins> connection error if processing of the contents of these packets prior to discovering an error resulted in changes to the state of a connection that cannot be reverted. </ins> 5.2.1.


On the other hand, reducing the frequency of packets that carry only acknowledgements reduces packet transmission and processing cost at <del> both endpoints.  It can also improve connection throughput on severely asymmetric links; see Section 3 of RFC3449. </del> <ins> both endpoints.  It can improve connection throughput on severely asymmetric links and reduce the volume of acknowledgment traffic using return path capacity; see Section 3 of RFC3449. </ins> A receiver SHOULD send an ACK frame after receiving at least two ack- eliciting packets.  This recommendation is general in nature and


constants-of-interest) for a new path, but the delay SHOULD NOT be considered an RTT sample. <del> Prior to handshake completion, when few to none RTT samples have been generated, it is possible that the probe timer expiration is due to an incorrect RTT estimate at the client.  To allow the client to improve its RTT estimate, the new packet that it sends MUST be ack- eliciting. </del> Initial packets and Handshake packets could be never acknowledged, but they are removed from bytes in flight when the Initial and Handshake keys are discarded, as described below in discarding-


6.2.4. When a PTO timer expires, a sender MUST send at least one ack- <del> eliciting packet in the packet number space as a probe, unless there is no data available to send.  An endpoint MAY send up to two full- sized datagrams containing ack-eliciting packets, to avoid an expensive consecutive PTO expiration due to a single lost datagram or transmit data from multiple packet number spaces.  All probe packets sent on a PTO MUST be ack-eliciting. </del> <ins> eliciting packet in the packet number space as a probe.  An endpoint MAY send up to two full-sized datagrams containing ack-eliciting packets, to avoid an expensive consecutive PTO expiration due to a single lost datagram or transmit data from multiple packet number spaces.  All probe packets sent on a PTO MUST be ack-eliciting. </ins> In addition to sending data in the packet number space for which the timer expired, the sender SHOULD send ack-eliciting packets from


5.2. <del> min_rtt is the minimum RTT observed for a given network path. min_rtt is set to the latest_rtt on the first RTT sample, and to the lesser of min_rtt and latest_rtt on subsequent samples.  In this document, min_rtt is used by loss detection to reject implausibly small rtt samples. </del> <ins> min_rtt is the sender's estimate of the minimum RTT observed for a given network path.  In this document, min_rtt is used by loss detection to reject implausibly small rtt samples. min_rtt MUST be set to the latest_rtt on the first RTT sample. min_rtt MUST be set to the lesser of min_rtt and latest_rtt (latest- rtt) on all other samples. </ins> An endpoint uses only locally observed times in computing the min_rtt and does not adjust for acknowledgment delays reported by the peer.


The RTT for a network path may change over time.  If a path's actual RTT decreases, the min_rtt will adapt immediately on the first low <del> sample.  If the path's actual RTT increases, the min_rtt will not adapt to it, allowing future RTT samples that are smaller than the new RTT to be included in smoothed_rtt. </del> <ins> sample.  If the path's actual RTT increases however, the min_rtt will not adapt to it, allowing future RTT samples that are smaller than the new RTT to be included in smoothed_rtt. Endpoints SHOULD set the min_rtt to the newest RTT sample after persistent congestion is established.  This is to allow a connection to reset its estimate of min_rtt and smoothed_rtt (smoothed-rtt) after a disruptive network event, and because it is possible that an increase in path delay resulted in persistent congestion being incorrectly declared. Endpoints MAY re-establish the min_rtt at other times in the connection, such as when traffic volume is low and an acknowledgement is received with a low acknowledgement delay.  Implementations SHOULD NOT refresh the min_rtt value too often, since the actual minimum RTT of the path is not frequently observable. </ins> 5.3.


with a value greater than 2^60, this would allow a maximum stream ID that cannot be expressed as a variable-length integer; see integer- encoding.  If either is received, the connection MUST be closed <del> immediately with a connection error of type STREAM_LIMIT_ERROR; see </del> <ins> immediately with a connection error of type FRAME_ENCODING_ERROR; see </ins> immediate-close. Endpoints MUST NOT exceed the limit set by their peer.  An endpoint


address validation by sending a Retry packet (packet-retry) containing a token.  This token MUST be repeated by the client in all Initial packets it sends for that connection after it receives the <del> Retry packet.  In response to processing an Initial containing a token, a server can either abort the connection or permit it to proceed. </del> <ins> Retry packet. In response to processing an Initial containing a token that was provided in a Retry packet, a server cannot send another Retry packet; it can only refuse the connection or permit it to proceed. </ins> As long as it is not possible for an attacker to generate a valid token for its own address (see token-integrity) and the client is


To avoid excessively small idle timeout periods, endpoints MUST increase the idle timeout period to be at least three times the current Probe Timeout (PTO).  This allows for multiple PTOs to <del> expire, and therefore multiple probes to be sent in the event of loss, prior to idle timeout. </del> <ins> expire, and therefore multiple probes to be sent and lost, prior to idle timeout. </ins> 10.1.1.


MAX_STREAMS frames; see frame-max-streams.  Separate limits apply to unidirectional and bidirectional streams. <del> If a max_streams transport parameter or MAX_STREAMS frame is received with a value greater than 2^60, this would allow a maximum stream ID that cannot be expressed as a variable-length integer; see integer- encoding.  If either is received, the connection MUST be closed immediately with a connection error of type FRAME_ENCODING_ERROR; see immediate-close. </del> <ins> If a max_streams transport parameter or a MAX_STREAMS frame is received with a value greater than 2^60, this would allow a maximum stream ID that cannot be expressed as a variable-length integer; see integer-encoding.  If either is received, the connection MUST be closed immediately with a connection error of type TRANSPORT_PARAMETER_ERROR if the offending value was received in a transport parameter or of type FRAME_ENCODING_ERROR if it was received in a frame; see immediate-close. </ins> Endpoints MUST NOT exceed the limit set by their peer.  An endpoint that receives a frame with a stream ID exceeding the limit it has


Clients SHOULD send a CANCEL_PUSH frame upon receipt of a PUSH_PROMISE frame carrying a request that is not cacheable, is not known to be safe, that indicates the presence of a request body, or <del> for which it does not consider the server authoritative. </del> <ins> for which it does not consider the server authoritative.  Any corresponding responses MUST NOT be used or cached. </ins> Each pushed response is associated with one or more client requests. The push is associated with the request stream on which the


served out of cache, overriding the actual representation that the authoritative tenant provides. <del> Pushed responses for which an origin server is not authoritative (see connection-reuse) MUST NOT be used or cached. </del> <ins> Clients are required to reject pushed responses for which an origin server is not authoritative; see server-push. </ins> 10.5.


21.6. <del> An adversarial sender might intentionally send fragments of stream data in an attempt to cause disproportionate receive buffer memory commitment and/or creation of a large and inefficient data structure. </del> <ins> An adversarial sender might intentionally not send portions of the stream data, causing the receiver to commit resources for the unsent data.  This could cause a disproportionate receive buffer memory commitment and/or the creation of a large and inefficient data structure at the receiver. </ins> An adversarial receiver might intentionally not acknowledge packets containing stream data in an attempt to force the sender to store the


Using a value for "N" that is small, but at least 1 (for example, 1.25) ensures that variations in round-trip time do not result in <del> under-utilization of the congestion window.  Values of 'N' larger than 1 ultimately result in sending packets as acknowledgments are received rather than when timers fire, provided the congestion window is fully utilized and acknowledgments arrive at regular intervals. </del> <ins> under-utilization of the congestion window. </ins> Practical considerations, such as packetization, scheduling delays, and computational efficiency, can cause a sender to deviate from this


If a path has been validated to support ECN (RFC3168, RFC8311), QUIC treats a Congestion Experienced (CE) codepoint in the IP header as a signal of congestion.  This document specifies an endpoint's response <del> when its peer receives packets with the ECN-CE codepoint. </del> <ins> when the peer-reported ECN-CE count increases; see Section 13.4.2 of QUIC-TRANSPORT. </ins> 7.2.


the congestion window. The minimum congestion window is the smallest value the congestion <del> window can decrease to as a response to loss, ECN-CE, or persistent congestion.  The RECOMMENDED value is 2 * max_datagram_size. </del> <ins> window can decrease to as a response to loss, increase in the peer- reported ECN-CE count, or persistent congestion.  The RECOMMENDED value is 2 * max_datagram_size. </ins> 7.3.


increased in either slow start or congestion avoidance.  This can happen due to insufficient application data or flow control limits. <del> A sender MAY use the pipeACK method described in Section 4.3 of </del> <ins> A sender can use the pipeACK method described in Section 4.3 of </ins> RFC7661 to determine if the congestion window is sufficiently utilized.


cause a sender to increase their send rate.  This increase could result in congestion and loss. <del> A sender MAY attempt to detect suppression of reports by marking occasional packets that they send with ECN-CE.  If a packet sent with ECN-CE is not reported as having been CE marked when the packet is acknowledged, then the sender SHOULD disable ECN for that path. </del> <ins> A sender can detect suppression of reports by marking occasional packets that it sends with an ECN-CE marking.  If a packet sent with an ECN-CE marking is not reported as having been CE marked when the packet is acknowledged, then the sender can disable ECN for that path by not setting ECT codepoints in subsequent packets sent on that path RFC3168. </ins> Reporting additional ECN-CE markings will cause a sender to reduce their sending rate, which is similar in effect to advertising reduced


packetization defines models for the transmission, retransmission, and acknowledgement of data, and <del> packet-size specifies rules for managing the size of packets. </del> <ins> datagram-size specifies rules for managing the size of datagrams carrying QUIC packets. </ins> Finally, encoding details of QUIC protocol elements are described in:


14. <del> The QUIC packet size includes the QUIC header and protected payload, but not the UDP or IP headers. </del> <ins> A UDP datagram can include one or more QUIC packets.  The datagram size refers to the total UDP payload size of a single UDP datagram carrying QUIC packets.  The datagram size includes one or more QUIC packet headers and protected payloads, but not the UDP or IP headers. The maximum datagram size is defined as the largest size of UDP payload that can be sent across a network path using a single UDP datagram. </ins> QUIC depends upon a minimum IP packet size of at least 1280 bytes. This is the IPv6 minimum size (IPv6) and is also supported by most <del> modern IPv4 networks.  Assuming the minimum IP header size, this results in a QUIC maximum packet size of 1232 bytes for IPv6 and 1252 bytes for IPv4. </del> <ins> modern IPv4 networks.  Assuming the minimum IP header size of 40 bytes for IPv6 and 20 bytes for IPv4 and a UDP header size of 8 bytes, this results in a maximum datagram size of 1232 bytes for IPv6 and 1252 bytes for IPv4. The maximum datagram size MUST be at least 1200 bytes. </ins> <del> The QUIC maximum packet size is the largest size of QUIC packet that can be sent across a network path using a single packet.  Any maximum packet size larger than 1200 bytes can be discovered using Path Maximum Transmission Unit Discovery (PMTUD; see pmtud) or Datagram Packetization Layer PMTU Discovery (DPLPMTUD; see dplpmtud). </del> <ins> Any maximum datagram size larger than 1200 bytes can be discovered using Path Maximum Transmission Unit Discovery (PMTUD; see pmtud) or Datagram Packetization Layer PMTU Discovery (DPLPMTUD; see dplpmtud). </ins> Enforcement of the max_udp_payload_size transport parameter (transport-parameter-definitions) might act as an additional limit on <del> the maximum packet size.  A sender can avoid exceeding this limit, </del> <ins> the maximum datagram size.  A sender can avoid exceeding this limit, </ins> once the value is known.  However, prior to learning the value of the transport parameter, endpoints risk datagrams being lost if they send <del> packets larger than the smallest allowed maximum packet size of 1200 bytes. </del> <ins> datagrams larger than the smallest allowed maximum datagram size of 1200 bytes. </ins> UDP datagrams MUST NOT be fragmented at the IP layer.  In IPv4 (IPv4), the DF bit MUST be set if possible, to prevent fragmentation


14.1. A client MUST expand the payload of all UDP datagrams carrying <del> Initial packets to at least the smallest allowed maximum packet size (1200 bytes) by adding PADDING frames to the Initial packet or by coalescing the Initial packet; see packet-coalesce.  Sending a UDP </del> <ins> Initial packets to at least the smallest allowed maximum datagram size (1200 bytes) by adding PADDING frames to the Initial packet or by coalescing the Initial packet; see packet-coalesce.  Sending a UDP </ins> datagram of this size ensures that the network path from the client to the server supports a reasonable Path Maximum Transmission Unit (PMTU).  This also helps reduce the amplitude of amplification


that it chooses. A server MUST discard an Initial packet that is carried in a UDP <del> datagram with a payload that is less than the smallest allowed maximum packet size of 1200 bytes.  A server MAY also immediately </del> <ins> datagram with a payload that is smaller than the smallest allowed maximum datagram size of 1200 bytes.  A server MAY also immediately </ins> close the connection by sending a CONNECTION_CLOSE frame with an error code of PROTOCOL_VIOLATION; see immediate-close-hs.


The Path Maximum Transmission Unit (PMTU) is the maximum size of the entire IP packet including the IP header, UDP header, and UDP <del> payload.  The UDP payload includes the QUIC packet header, protected payload, and any authentication fields.  The PMTU can depend on path characteristics, and can therefore change over time.  The largest UDP payload an endpoint sends at any given time is referred to as the endpoint's maximum packet size. </del> <ins> payload.  The UDP payload includes one or more QUIC packet headers and protected payloads.  The PMTU can depend on path characteristics, and can therefore change over time.  The largest UDP payload an endpoint sends at any given time is referred to as the endpoint's maximum datagram size. </ins> An endpoint SHOULD use DPLPMTUD (dplpmtud) or PMTUD (pmtud) to determine whether the path to a destination will support a desired <del> maximum packet size without fragmentation.  In the absence of these mechanisms, QUIC endpoints SHOULD NOT send IP packets larger than the smallest allowed maximum packet size. </del> <ins> maximum datagram size without fragmentation.  In the absence of these mechanisms, QUIC endpoints SHOULD NOT send datagrams larger than the smallest allowed maximum datagram size. </ins> <del> Both DPLPMTUD and PMTUD send IP packets that are larger than the current maximum packet size, referred to as PMTU probes.  All QUIC </del> <ins> Both DPLPMTUD and PMTUD send datagrams that are larger than the current maximum datagram size, referred to as PMTU probes.  All QUIC </ins> packets that are not sent in a PMTU probe SHOULD be sized to fit <del> within the maximum packet size to avoid the packet being fragmented or dropped (RFC8085). </del> <ins> within the maximum datagram size to avoid the datagram being fragmented or dropped (RFC8085). </ins> If a QUIC endpoint determines that the PMTU between any pair of local and remote IP addresses has fallen below the smallest allowed maximum <del> packet size of 1200 bytes, it MUST immediately cease sending QUIC </del> <ins> datagram size of 1200 bytes, it MUST immediately cease sending QUIC </ins> packets, except for those in PMTU probes or those containing CONNECTION_CLOSE frames, on the affected path.  An endpoint MAY terminate the connection if an alternative path cannot be found. Each pair of local and remote addresses could have a different PMTU. QUIC implementations that implement any kind of PMTU discovery <del> therefore SHOULD maintain a maximum packet size for each combination of local and remote IP addresses. </del> <ins> therefore SHOULD maintain a maximum datagram size for each combination of local and remote IP addresses. </ins> A QUIC implementation MAY be more conservative in computing the <del> maximum packet size to allow for unknown tunnel overheads or IP </del> <ins> maximum datagram size to allow for unknown tunnel overheads or IP </ins> header options/extensions. 14.2.1. Path Maximum Transmission Unit Discovery (PMTUD; RFC1191, RFC8201) relies on reception of ICMP messages (e.g., IPv6 Packet Too Big <del> messages) that indicate when a packet is dropped because it is larger than the local router MTU.  DPLPMTUD can also optionally use these messages.  This use of ICMP messages is potentially vulnerable to off-path attacks that successfully guess the addresses used on the </del> <ins> messages) that indicate when an IP packet is dropped because it is larger than the local router MTU.  DPLPMTUD can also optionally use these messages.  This use of ICMP messages is potentially vulnerable to off-path attacks that successfully guess the addresses used on the </ins> path and reduce the PMTU to a bandwidth-inefficient value. An endpoint MUST ignore an ICMP message that claims the PMTU has <del> decreased below the minimum QUIC packet size. </del> <ins> decreased below QUIC's smallest allowed maximum datagram size. </ins> The requirements for generating ICMP (RFC1812, RFC4443) state that the quoted packet should contain as much of the original packet as


validation. An endpoint MUST NOT increase PMTU based on ICMP messages; see <del> Section 3, clause 6 of DPLPMTUD.  Any reduction in the QUIC maximum packet size in response to ICMP messages MAY be provisional until </del> <ins> Section 3, clause 6 of DPLPMTUD.  Any reduction in QUIC's maximum datagram size in response to ICMP messages MAY be provisional until </ins> QUIC's loss detection algorithm determines that the quoted packet has actually been lost.


PADDING frame implement "Probing using padding data", as defined in Section 4.1 of DPLPMTUD. <del> Endpoints SHOULD set the initial value of BASE_PMTU (see Section 5.1 of DPLPMTUD) to be consistent with the minimum QUIC packet size.  The MIN_PLPMTU is the same as the BASE_PMTU. </del> <ins> Endpoints SHOULD set the initial value of BASE_PLPMTU (Section 5.1 of DPLPMTUD) to be consistent with QUIC's smallest allowed maximum datagram size.  The MIN_PLPMTU is the same as the BASE_PLPMTU. </ins> <del> QUIC endpoints implementing DPLPMTUD maintain a maximum packet size (DPLPMTUD MPS) for each combination of local and remote IP addresses. </del> <ins> QUIC endpoints implementing DPLPMTUD maintain a DPLPMTUD Maximum Packet Size (MPS, Section 4.4 of DPLPMTUD) for each combination of local and remote IP addresses.  This corresponds to the maximum datagram size. </ins> 14.3.1. From the perspective of DPLPMTUD, QUIC is an acknowledged <del> packetization layer (PL).  A sender can therefore enter the DPLPMTUD BASE state when the QUIC connection handshake has been completed. </del> <ins> Packetization Layer (PL).  A QUIC sender can therefore enter the DPLPMTUD BASE state (Section 5.2 of DPLPMTUD) when the QUIC connection handshake has been completed. </ins> 14.3.2. <del> QUIC provides an acknowledged PL, therefore a sender does not implement the DPLPMTUD CONFIRMATION_TIMER while in the SEARCH_COMPLETE state; see Section 5.2 of DPLPMTUD. </del> <ins> QUIC is an acknowledged PL, therefore a QUIC sender does not implement a DPLPMTUD CONFIRMATION_TIMER while in the SEARCH_COMPLETE state; see Section 5.2 of DPLPMTUD. </ins> 14.3.3.


PMTU probes are ack-eliciting packets. Endpoints could limit the content of PMTU probes to PING and PADDING <del> frames as packets that are larger than the current maximum packet size are more likely to be dropped by the network.  Loss of a QUIC packet that is carried in a PMTU probe is therefore not a reliable indication of congestion and SHOULD NOT trigger a congestion control reaction; see Section 3, Bullet 7 of DPLPMTUD.  However, PMTU probes consume congestion window, which could delay subsequent transmission by an application. </del> <ins> frames, since packets that are larger than the current maximum datagram size are more likely to be dropped by the network.  Loss of a QUIC packet that is carried in a PMTU probe is therefore not a reliable indication of congestion and SHOULD NOT trigger a congestion control reaction; see Section 3, Bullet 7 of DPLPMTUD.  However, PMTU probes consume congestion window, which could delay subsequent transmission by an application. </ins> 14.4.1.


This limit does act as an additional constraint on datagram size in the same way as the path MTU, but it is a property of the <del> endpoint and not the path; see packet-size.  It is expected that </del> <ins> endpoint and not the path; see datagram-size.  It is expected that </ins> this is the space an endpoint dedicates to holding incoming packets.


tuple, as shown in transport-parameter-encoding-fig: The Transport Parameter Length field contains the length of the <del> Transport Parameter Value field. </del> <ins> Transport Parameter Value field in bytes. </ins> QUIC encodes transport parameters into a sequence of bytes, which is then included in the cryptographic handshake.


entity that receives an Initial packet from a client can recover the keys that will allow them to both read the contents of the packet and generate Initial packets that will be successfully authenticated at <del> either endpoint. </del> <ins> either endpoint.  The AEAD also protects Initial packets against accidental modification. </ins> All other packets are protected with keys derived from the cryptographic handshake.  The cryptographic handshake ensures that


the inclusion of uppercase field names, or <del> the inclusion of invalid characters in field names or values </del> <ins> the inclusion of invalid characters in field names or values. </ins> A request or response that includes a payload body can include a Content-Length header field.  A request or response is also malformed


intermediary not acting as a tunnel) MUST NOT forward a malformed request or response.  Malformed requests or responses that are detected MUST be treated as a stream error (errors) of type <del> H3_GENERAL_PROTOCOL_ERROR. </del> <ins> H3_MESSAGE_ERROR. </ins> For malformed requests, a server MAY send an HTTP response indicating the error prior to closing or resetting the stream.  Clients MUST NOT


The client's stream terminated without containing a fully-formed request. <ins> An HTTP message was malformed and cannot be processed. </ins> The TCP connection established in response to a CONNECT request was reset or abnormally closed.


The payload of this packet contains CRYPTO frames and could contain PING, PADDING, or ACK frames.  Handshake packets MAY contain CONNECTION_CLOSE frames of type 0x1c.  Endpoints MUST treat receipt <del> of Handshake packets with other frames as a connection error. </del> <ins> of Handshake packets with other frames as a connection error of type PROTOCOL_VIOLATION. </ins> Like Initial packets (see discard-initial), data in CRYPTO frames for Handshake packets is discarded - and no longer retransmitted - when


control across the entire connection, QUIC has the capability to improve the performance of HTTP compared to a TCP mapping.  QUIC also incorporates TLS 1.3 (TLS13) at the transport layer, offering <del> comparable security to running TLS over TCP, with the improved connection setup latency of TCP Fast Open (TFO). </del> <ins> comparable confidentiality and integrity to running TLS over TCP, with the improved connection setup latency of TCP Fast Open (TFO). </ins> This document defines a mapping of HTTP semantics over the QUIC transport protocol, drawing heavily on the design of HTTP/2.  While


The use of ALPN in the TLS and QUIC handshakes establishes the target application protocol before application-layer bytes are processed. <del> Because all QUIC packets are encrypted, it is difficult for an attacker to control the plaintext bytes of an HTTP/3 connection, which could be used in a cross-protocol attack on a plaintext protocol. </del> <ins> This ensures that endpoints have strong assurances that peers are using the same protocol. This does not guarantee protection from all cross-protocol attacks. Section 21.5 of QUIC-TRANSPORT describes some ways in which the plaintext of QUIC packets can be used to perform request forgery against endpoints that don't use authenticated transports. </ins> 10.3.


A PATH_RESPONSE frame received on any network path validates the path on which the PATH_CHALLENGE was sent. <del> If the PATH_CHALLENGE frame that resulted in successful path validation was sent in a datagram that was not expanded to at least 1200 bytes, the endpoint can regard the address as valid.  The endpoint is then able to send more than three times the amount of </del> <ins> If an endpoint sends a PATH_CHALLENGE frame in a datagram that is not expanded to at least 1200 bytes, and if the response to it validates the peer address, the path is validated but not the path MTU.  As a result, the endpoint can now send more than three times the amount of </ins> data that has been received.  However, the endpoint MUST initiate another path validation with an expanded datagram to verify that the <del> path supports required MTU. </del> <ins> path supports the required MTU. </ins> Receipt of an acknowledgment for a packet containing a PATH_CHALLENGE frame is not adequate validation, since the acknowledgment can be


authenticated negotiation of an application protocol (TLS uses ALPN ALPN for this purpose) <del> Endpoints can use packets sent during the handshake to test for Explicit Congestion Notification (ECN) support; see ecn.  An endpoint verifies support for ECN by observing whether the ACK frames acknowledging the first packets it sends carry ECN counts, as described in ecn-validation. </del> The CRYPTO frame can be sent in different packet number spaces (packet-numbers).  The offsets used by CRYPTO frames to ensure ordered delivery of cryptographic handshake data start from zero in


shown with a '*'.  Once completed, endpoints are able to exchange application data. <del> An endpoint validates support for Explicit Congestion Notification (ECN) by observing whether the ACK frames acknowledging the first packets it sends carry ECN counts, as described in ecn-validation. </del> <ins> Endpoints can use packets sent during the handshake to test for Explicit Congestion Notification (ECN) support; see ecn.  An endpoint validates support for ECN by observing whether the ACK frames acknowledging the first packets it sends carry ECN counts, as described in ecn-validation. </ins> Endpoints MUST explicitly negotiate an application protocol.  This avoids situations where there is a disagreement about the protocol


A token allows a server to correlate activity between the connection where the token was issued and any connection where it is used. <del> Clients that want to break continuity of identity with a server MAY </del> <ins> Clients that want to break continuity of identity with a server can </ins> discard tokens provided using the NEW_TOKEN frame.  In comparison, a token obtained in a Retry packet MUST be used immediately during the connection attempt and cannot be used in subsequent connection


The next bit (0x40) of byte 0 is set to 1.  Packets containing a zero value for this bit are not valid packets in this version and <del> MUST be discarded. </del> <ins> MUST be discarded.  A value of 1 for this bit allows QUIC to coexist with other protocols; see RFC7983. </ins> The next two bits (those with a mask of 0x30) of byte 0 contain a packet type.  Packet types are listed in long-packet-types.


The next bit (0x40) of byte 0 is set to 1.  Packets containing a zero value for this bit are not valid packets in this version and <del> MUST be discarded. </del> <ins> MUST be discarded.  A value of 1 for this bit allows QUIC to coexist with other protocols; see RFC7983. </ins> The third most significant bit (0x20) of byte 0 is the latency spin bit, set as described in spin-bit.


newer encryption level are available. An endpoint cannot discard keys for a given encryption level unless <del> it has both received and acknowledged all CRYPTO frames for that encryption level and when all CRYPTO frames for that encryption level have been acknowledged by its peer.  However, this does not guarantee that no further packets will need to be received or sent at that </del> <ins> it has received all the cryptographic handshake messages from its peer at that encryption level and its peer has done the same. Different methods for determining this are provided for Initial keys (discard-initial) and Handshake keys (discard-handshake).  These methods do not prevent packets from being received or sent at that </ins> encryption level because a peer might not have received all the <del> acknowledgments necessary to reach the same state. </del> <ins> acknowledgments necessary. </ins> Though an endpoint might retain older keys, new data MUST be sent at the highest currently-available encryption level.  Only ACK frames


21.13. Deployments should limit the ability of an attacker to target a new <del> connection to a particular server instance.  This means that client- controlled fields, such as the initial Destination Connection ID used on Initial and 0-RTT packets SHOULD NOT be used by themselves to make routing decisions.  Ideally, routing decisions are made independently of client-selected values; a Source Connection ID can be selected to route later packets to the same server. </del> <ins> connection to a particular server instance.  Ideally, routing decisions are made independently of client-selected values, including addresses.  Once an instance is selected, a connection ID can be selected so that later packets are routed to the same instance. </ins> 21.14.


The endpoint uses RTT samples and peer-reported host delays (see Section 13.2 of QUIC-TRANSPORT) to generate a statistical description of the network path's RTT.  An endpoint computes the following three <del> values for each path: the minimum value observed over the lifetime of the path (min_rtt), an exponentially-weighted moving average (smoothed_rtt), and the mean deviation (referred to as "variation" in the rest of this document) in the observed RTT samples (rttvar). </del> <ins> values for each path: the minimum value over a period of time (min_rtt), an exponentially-weighted moving average (smoothed_rtt), and the mean deviation (referred to as "variation" in the rest of this document) in the observed RTT samples (rttvar). </ins> 5.1.


5.2. min_rtt is the sender's estimate of the minimum RTT observed for a <del> given network path.  In this document, min_rtt is used by loss detection to reject implausibly small rtt samples. </del> <ins> given network path over a period of time.  In this document, min_rtt is used by loss detection to reject implausibly small rtt samples. </ins> min_rtt MUST be set to the latest_rtt on the first RTT sample. min_rtt MUST be set to the lesser of min_rtt and latest_rtt (latest-


in compliance with RFC6437, unless the local API does not allow setting IPv6 flow labels. <del> The IPv6 flow label SHOULD be a pseudo-random function of the source and destination addresses, source and destination UDP ports, and the Destination Connection ID field.  The flow label generation MUST be designed to minimize the chances of linkability with a previously used flow label, as a stable flow label would enable correlating activity on multiple paths; see migration-linkability. A possible implementation is to compute the flow label as a cryptographic hash function of the source and destination addresses, source and destination UDP ports, Destination Connection ID field, and a local secret. </del> <ins> The flow label generation MUST be designed to minimize the chances of linkability with a previously used flow label, as a stable flow label would enable correlating activity on multiple paths; see migration- linkability. RFC6437 suggests deriving values using a pseudorandom function to generate flow labels.  Including the Destination Connection ID field in addition to source and destination addresses when generating flow labels ensures that changes are synchronized with changes in other observable identifiers.  A cryptographic hash function that combines these inputs with a local secret is one way this might be implemented. </ins> 10.


QUIC begins every connection in slow start with the congestion window set to an initial value.  Endpoints SHOULD use an initial congestion window of 10 times the maximum datagram size (max_datagram_size), <del> limited to the larger of 14720 bytes or twice the maximum datagram size.  This follows the analysis and recommendations in RFC6928, increasing the byte limit to account for the smaller 8-byte overhead of UDP compared to the 20-byte overhead for TCP. </del> <ins> while limiting the window to the larger of 14720 bytes or twice the maximum datagram size.  This follows the analysis and recommendations in RFC6928, increasing the byte limit to account for the smaller 8-byte overhead of UDP compared to the 20-byte overhead for TCP. </ins> If the maximum datagram size changes during the connection, the initial congestion window SHOULD be recalculated with the new size.


If the recipient permits the migration, it MUST send subsequent packets to the new peer address and MUST initiate path validation (migrate-validate) to verify the peer's ownership of the address if <del> validation is not already underway. </del> <ins> validation is not already underway.  If the recipient has no unused connection IDs from the peer, it will not be able to send anything on the new path until the peer provides one; see migration-linkability. </ins> An endpoint only changes the address to which it sends packets in response to the highest-numbered non-probing packet.  This ensures


SHOULD begin processing partial HTTP messages once enough of the message has been received to make progress.  If a client-initiated stream terminates without enough of the HTTP message to provide a <del> complete response, the server SHOULD abort its response with the error code H3_REQUEST_INCOMPLETE; see errors. </del> <ins> complete response, the server SHOULD abort its response stream with the error code H3_REQUEST_INCOMPLETE; see errors. </ins> A server can send a complete response prior to the client sending an entire request if the response does not depend on any portion of the


data received, as specified in Section 8.1 of QUIC-TRANSPORT.  If no additional data can be sent, the server's PTO timer MUST NOT be armed until datagrams have been received from the client, because packets <del> sent on PTO count against the anti-amplification limit.  Note that the server could fail to validate the client's address even if 0-RTT is accepted. </del> <ins> sent on PTO count against the anti-amplification limit. When the server receives a datagram from the client, the amplification limit is increased and the server resets the PTO timer. If the PTO timer is then set to a time in the past, it is executed immediately.  Doing so avoids sending new 1-RTT packets prior to packets critical to the completion of the handshake.  In particular, this can happen when 0-RTT is accepted but the server fails to validate the client's address. </ins> Since the server could be blocked until more datagrams are received from the client, it is the client's responsibility to send packets to


An endpoint MUST include the value from the Source Connection ID field of the packet it receives in the Destination Connection ID <del> field.  The value for Source Connection ID MUST be copied from the Destination Connection ID of the received packet, which is initially randomly selected by a client.  Echoing both connection IDs gives clients some assurance that the server received the packet and that the Version Negotiation packet was not generated by an attacker that is unable to observe packets. </del> <ins> field.  The value for the Source Connection ID field MUST be copied from the Destination Connection ID field of the received packet, which is initially randomly selected by a client.  Echoing both connection IDs gives clients some assurance that the server received the packet and that the Version Negotiation packet was not generated by an attacker that is unable to observe packets. </ins> An endpoint that receives a Version Negotiation packet might change the version that it decides to use for subsequent packets.  The


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP <del> 14 BCP14 when, and only when, they appear in all capitals, as shown here. </del> <ins> 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> This document uses the variable-length integer encoding from QUIC- TRANSPORT.


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP <del> 14 BCP14 when, and only when, they appear in all capitals, as shown here. </del> <ins> 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> Definitions of terms that are used in this document:


The entries in iana-setting-table are registered by this document. <del> For fomatting reasons, setting names can be abbreviated by removing the 'SETTING_' prefix. </del> <ins> For formatting reasons, setting names can be abbreviated by removing the 'SETTINGS_' prefix. </ins> Each code of the format "0x1f * N + 0x21" for non-negative integer values of "N" (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe)


bytes.  An endpoint that includes this parameter supports the DATAGRAM frame types and is willing to receive such frames on this connection.  Endpoints MUST NOT send DATAGRAM frames until they have <del> sent and received the max_datagram_frame_size transport parameter. Endpoints MUST NOT send DATAGRAM frames of size strictly larger than the value of max_datagram_frame_size the endpoint has received from its peer.  An endpoint that receives a DATAGRAM frame when it has not sent the max_datagram_frame_size transport parameter MUST terminate the connection with error PROTOCOL_VIOLATION.  An endpoint that receives a DATAGRAM frame that is strictly larger than the value it sent in its max_datagram_frame_size transport parameter MUST terminate the connection with error PROTOCOL_VIOLATION.  Endpoints that wish to use DATAGRAM frames need to ensure they send a max_datagram_frame_size value sufficient to allow their peer to use them.  It is RECOMMENDED to send the value 65536 in the max_datagram_frame_size transport parameter as that indicates to the peer that this endpoint will accept any DATAGRAM frame that fits inside a QUIC packet. </del> <ins> received the max_datagram_frame_size transport parameter.  Endpoints MUST NOT send DATAGRAM frames of size strictly larger than the value of max_datagram_frame_size the endpoint has received from its peer. An endpoint that receives a DATAGRAM frame when it has not sent the max_datagram_frame_size transport parameter MUST terminate the connection with error PROTOCOL_VIOLATION.  An endpoint that receives a DATAGRAM frame that is strictly larger than the value it sent in its max_datagram_frame_size transport parameter MUST terminate the connection with error PROTOCOL_VIOLATION.  Endpoints that wish to use DATAGRAM frames need to ensure they send a max_datagram_frame_size value sufficient to allow their peer to use them.  It is RECOMMENDED to send the value 65536 in the max_datagram_frame_size transport parameter as that indicates to the peer that this endpoint will accept any DATAGRAM frame that fits inside a QUIC packet. The max_datagram_frame_size transport parameter is a unidirectional limit and indication of support of DATAGRAM frames.  Application protocols that use DATAGRAM frames MAY choose to only negotiate and use them in a single direction. </ins> When clients use 0-RTT, they MAY store the value of the server's max_datagram_frame_size transport parameter.  Doing so allows the


to receiving packets that only contain DATAGRAM frames, since the timing of these acknowledgements is not used for loss recovery. <ins> As with any ack-eliciting frame, when a sender suspects that a packet containing only DATAGRAM frames has been lost, it MAY send probe packets to elicit a faster acknowledgement as described in Section 6.2.4 of RFC9002. </ins> If a sender detects that a packet containing a specific DATAGRAM frame might have been lost, the implementation MAY notify the application that it believes the datagram was lost.


2.1. <del> A quota policy is described in terms of service-limit and a time- window.  It is an Item whose bare item is a service-limit, along with associated Parameters. </del> <ins> A quota policy is maintained by a server to limit the activity (counted in quota units) of a given client over a period of time (known as the time-window) to a specified amount (known as the service-limit). </ins> <del> The following parameters are defined in this specification: </del> <ins> Quota policies can be advertised by servers (see ratelimit-policy- field), but they are not required to be, and more than one quota policy can affect a given request from a client to a server. </ins> <del> The REQUIRED "w" parameter value conveys a time window value as defined in time-window. Other parameters are allowed and can be regarded as comments.  They ought to be registered within the "Hypertext Transfer Protocol (HTTP) RateLimit Parameters Registry", as described in iana-ratelimit- </del> <ins> A quota policy is expressed in Structured Fields STRUCTURED-FIELDS as an Integer that indicates the service limit with associated </ins> parameters. <del> For example, a quota policy of 100 quota units per minute: The definition of a quota policy does not imply any specific distribution of quota units within the time window.  If applicable, these details can be conveyed as extension parameters. </del> <ins> The following Parameters are defined in this specification: </ins> <del> For example, two quota policies containing further details via extension parameters: </del> <ins> The REQUIRED "w" parameter value conveys a time window (time- window). </ins> <del> To avoid clashes, implementers SHOULD prefix unregistered parameters with a vendor identifier, e.g. "acme-policy", "acme-burst".  While it is useful to define a clear syntax and semantics even for custom parameters, it is important to note that user agents are not required to process quota policy information. </del> <ins> For example, a quota policy of 100 quota units per minute is expressed as: </ins> <del> 2.2. </del> <ins> Other parameters are allowed and can be regarded as comments. Parameters for use by more than one implementation or service ought to be registered within the "Hypertext Transfer Protocol (HTTP) RateLimit Parameters Registry", as described in iana-ratelimit- parameters. </ins> <del> Rate limit policies limit the number of acceptable requests within a given time interval, known as a time window. </del> <ins> Implementation- or service-specific parameters SHOULD be prefixed parameters with a vendor identifier, e.g. "acme-policy", "acme- burst". </ins> <del> The time window is a non-negative Integer value expressing that interval in seconds, similar to the "delay-seconds" rule defined in Section 10.2.3 of HTTP.  Subsecond precision is not supported. </del> <ins> 2.2. </ins> <del> 2.3. </del> <ins> The service limit is a non-negative Integer indicating the maximum amount of activity that the server is willing to accept from what it identifies as the client (e.g., based upon originating IP or user authentication) during a time-window. </ins> <del> The service limit is associated with the maximum number of requests that the server is willing to accept from one or more clients on a given basis (originating IP, authenticated user, geographical, ..) during a time-window. </del> <ins> The activity being limited is usually the HTTP requests made by the client; for example "you can make 100 requests per minute".  However, a server might only rate limit some requests (based upon URI, method, user identity, etc.), and it might weigh requests differently. Therefore, quota policies are defined in terms of "quota units". Servers SHOULD document how they count quota units. </ins> <del> The service limit is a non-negative Integer expressed in quota units. </del> <ins> For example, a server could count requests like "/books/{id}" once, but count search requests like "/books?author=WuMing" twice.  This might result in the following counters: </ins> <del> The service limit SHOULD match the maximum number of acceptable requests.  However, the service limit MAY differ from the total number of acceptable requests when weight mechanisms, bursts, or other server policies are implemented. </del> <ins> Often, the service limit advertised will match the server's actual limit.  However, it MAY differ when weight mechanisms, bursts, or other server policies are implemented.  In that case the difference SHOULD be communicated using an extension or documented separately. </ins> <del> If the service limit does not match the maximum number of acceptable requests the relation with that SHOULD be communicated out-of-band. </del> <ins> 2.3. </ins> <del> Example: A server could </del> <ins> Quota policies limit the number of acceptable requests within a given time interval, known as a time window. </ins> <del> count once requests like "/books/{id}" </del> <ins> The time window is a non-negative Integer value expressing that interval in seconds, similar to the "delay-seconds" rule defined in Section 10.2.3 of HTTP.  Subsecond precision is not supported. </ins> <del> count twice search requests like "/books?author=WuMing" </del> <ins> By default, a quota policy does not constrain the distribution of quota units within the time window.  If necessary, these details can be conveyed as extension parameters. </ins> <del> so that we have the following counters </del> <ins> For example, two quota policies containing further details via extension parameters: </ins> 3.


header field names proliferates. <del> Client applications interfacing with different servers may thus need to process different headers, or the very same application interface </del> <ins> User Agents interfacing with different servers may thus need to process different headers, or the very same application interface </ins> that sits behind different reverse proxies may reply with different throttling headers.


"RateLimit-Reset": containing the time remaining in the current window, specified in seconds. <del> The behavior of "RateLimit-Reset" is compatible with the "delta- </del> <ins> The behavior of "RateLimit-Reset" is compatible with the "delay- </ins> seconds" notation of "Retry-After". The fields definition allows to describe complex policies, including


This specification does not cover the throttling scope, that may be the given resource-target, its parent path or the whole Origin <del> RFC6454 section 7. </del> <ins> (see Section 7 of RFC6454). </ins> The rate-limit headers may be returned in both Successful and non Successful responses.  This specification does not cover whether


capitals, as shown here. This document uses the Augmented BNF defined in RFC5234 and updated <del> by RFC7405 along with the "#rule" extension defined in Section 7 of MESSAGING. </del> <ins> by RFC7405 along with the "#rule" extension defined in Section 5.6.1 of SEMANTICS. </ins> <del> The term Origin is to be interpreted as described in RFC6454 section 7. </del> <ins> The term Origin is to be interpreted as described in Section 7 of RFC6454. </ins> <del> The "delta-seconds" rule is defined in CACHING section 1.2.1. </del> <ins> The "delay-seconds" rule is defined in Section 10.2.4 of SEMANTICS. </ins> 2.


The header value is <del> The delta-seconds format is used because: </del> <ins> The delay-seconds format is used because: </ins> it does not rely on clock synchronization and is resilient to clock adjustment and clock skew between client and server (see <del> SEMANTICS Section 4.1.1.1); </del> <ins> Section 5.6.7 of SEMANTICS); </ins> it mitigates the risk related to thundering herd when too many clients are serviced with the same timestamp.


5. <del> This section documents the considerations advised in Section 15.3.3 </del> <ins> This section documents the considerations advised in Section 16.3.3 </ins> of SEMANTICS. An intermediary that is not part of the originating service


8.3.1. <del> The server does not expose "RateLimit-Remaining" values, but resets the limit counter every second. </del> <ins> The server does not expose "RateLimit-Remaining" values (for example, because the underlying counters are not available).  Instead, it resets the limit counter every second. </ins> It communicates to the client the limit of 10 quota-units per second always returning the couple "RateLimit-Limit" and "RateLimit-Reset".


quotas. This was partially addressed by the "Retry-After" header field <del> defined in SEMANTICS to be returned in "429 Too Many Requests" (see STATUS429) or "503 Service Unavailable" responses. </del> <ins> defined in SEMANTICS to be returned in 429 (Too Many Request) (see STATUS429) or 503 (Service Unavailable) responses. </ins> Widely deployed quota mechanisms limit the number of acceptable requests in a given time window, e.g. 10 requests per second;


the current window; "RateLimit-Reset": containing the time remaining in the current <del> window, specified in seconds. </del> <ins> window, specified in seconds; "RateLimit-Policy": containing the quota policy information. </ins> The behavior of "RateLimit-Reset" is compatible with the "delay- seconds" notation of "Retry-After".


The term Origin is to be interpreted as described in Section 7 of RFC6454. <del> This specification uses Structured Fields SF to specify syntax. The terms sf-list, sf-item, sf-string, sf-token, sf-integer, bare- item and key refer to the structured types defined therein. </del> <ins> This document uses the following terminology from Section 3 of SF to specify syntax and parsing: List, Item, String, Token and Integer together with the concept of bare item. </ins> 2.


A time window is expressed in seconds, using the following syntax: <del> Where "delay-seconds" is a non-negative sf-integer compatible with the "delay-seconds" rule defined in Section 10.2.3 of SEMANTICS. </del> <ins> Where "delay-seconds" is a non-negative Integer compatible with the "delay-seconds" rule defined in Section 10.2.3 of SEMANTICS. </ins> Subsecond precision is not supported.


The "service-limit" is expressed in "quota-units" and has the following syntax: <del> where "quota-units" is a non-negative sf-integer. </del> <ins> where "quota-units" is a non-negative Integer. </ins> The "service-limit" SHOULD match the maximum number of acceptable requests.


available in that moment.  Nonetheless servers MAY decide to send the "RateLimit" fields in a trailer section. <del> To ease the migration from existing rate limit headers, a server SHOULD be able to provide the "RateLimit-Limit" field even without the optional "quota-policy" section. </del> 3.1. Servers are not required to return "RateLimit" fields in every


fields only when a given quota is going to expire. Implementers concerned with response fields' size, might take into <del> account their ratio with respect to the payload data, or use header- compression http features such as HPACK. </del> <ins> account their ratio with respect to the content length, or use header-compression HTTP features such as HPACK. </ins> 4.


otherwise gathered metrics) to better estimate the "RateLimit-Reset" moment intended by the server. <del> The "quota-policy" values and comments provided in "RateLimit-Limit" are informative and MAY be ignored. </del> <ins> The details provided in "RateLimit-Policy" are informative and MAY be ignored. </ins> If a response contains both the "RateLimit-Reset" and "Retry-After" fields, "Retry-After" MUST take precedence and "RateLimit-Reset" MAY


If the client exceeds that limit, it MAY not be served. <del> The field is a List Structured Field of positive length.  The first member is named "expiring-limit" and its syntax is "service-limit", while the syntax of the other optional members is "quota-policy" </del> <ins> The field is a non-negative Integer.  Its value is named "expiring- limit". </ins> The "expiring-limit" value MUST be set to the "service-limit" that is <del> closer to reach its limit. The "quota-policy" is defined in quota-policy, and its values are informative. A "time-window" associated to "expiring-limit" can be communicated via an optional "quota-policy" value, like shown in the following example If the "expiring-limit" is not associated to a "time-window", the "time-window" MUST either be: </del> <ins> closer to reach its limit, and the associated "time-window" MUST either be: </ins> inferred by the value of "RateLimit-Reset" at the moment of the reset, or communicated out-of-band (e.g. in the documentation). <ins> The "RateLimit-Policy" field (see ratelimit-policy-field), might contain information on the associated "time-window". This field MUST NOT occur multiple times and can be sent in a trailer section. 5.2. The "RateLimit-Policy" response field indicates the "quota" associated to the client and its value is informative. The field is a non-empty List of quota policies (see quota-policy). A "time-window" associated to "expiring-limit" can be communicated via "RateLimit-Policy", like shown in the following example. </ins> Policies using multiple quota limits MAY be returned using multiple "quota-policy" items, like shown in the following two examples: This field MUST NOT occur multiple times and can be sent in a trailer section. <del> 5.2. </del> <ins> 5.3. </ins> The "RateLimit-Remaining" response field indicates the remaining "quota-units" defined in service-limit associated to the client. <del> The field is an Integer Structured Field and its value is </del> <ins> The field is a non-negative Integer expressed in "quota-units". </ins> This field MUST NOT occur multiple times and can be sent in a trailer section.


One example of "RateLimit-Remaining" use is below. <del> 5.3. The "RateLimit-Reset" response field indicates either </del> <ins> 5.4. </ins> <del> the number of seconds until the quota resets. </del> <ins> The "RateLimit-Reset" response field indicates the number of seconds until the quota resets. </ins> <del> The field is an Integer Structured Field and its value is </del> <ins> The field is a non-negative Integer. </ins> The delay-seconds format is used because:


operations, and "core.rd-group" is used to discover the URI path for RD Group operations.  Upon success, the response will contain a payload with a link format entry for each RD function discovered, <del> indicating the URI path of the RD function returned and the corresponding Resource Type.  When performing multicast discovery, the multicast IP address used will depend on the scope required and the multicast capabilities of the network. </del> <ins> indicating the URI of the RD function returned and the corresponding Resource Type.  When performing multicast discovery, the multicast IP address used will depend on the scope required and the multicast capabilities of the network. </ins> A Resource Directory MAY provide hints about the content-formats it supports in the links it exposes or registers, using the "ct" link


An RD implementation of this specification MUST support query filtering for the rt parameter as defined in RFC6690. <ins> While the link targets in this discovery step are often expressed in path-absolute form, this is not a requirement.  Clients SHOULD therefore accept URIs of all schemes they support, both in absolute and relative forms, and not limit the set of discovered URIs to those hosted at the address used for URI discovery. </ins> The URI Discovery operation can yield multiple URIs of a particular resource type.  The client may use any of the discovered addresses initially.


on its configuration. The registration message is a list of links to registration resources <del> of the endpoints that belong to that group.  The endpoints MAY be hosted by a different RD than the the group hosting RD.  In that case the endpoint link points to the registration resource on the other RD. </del> <ins> of the endpoints that belong to that group.  The registration resources MAY be located on different hosts than the group hosting RD.  In that case the endpoint link points to the registration resource on the other RD.  The commissioning tool SHOULD NOT attempt to enter a foreign registration in a group unless it found it in the group RD's lookup results, or has other reasons to assume that the foreign registration will be accepted. </ins> The commissioning tool SHOULD not send any target attributes with the links to the registration resources, and the resource directory


does not need to make them accessible to clients.  Clients SHOULD NOT attempt to dereference or manipulate them. <ins> A Resource Directory can report endpoints or groups in lookup that are not hosted at the same address.  While the setup and management of such a distributed system is out of scope for this document, lookup clients MUST be prepared to see arbitrary URIs as registration or group resources in the results. </ins> 7.3. Using the Accept Option, the requester can control whether this list


associated domain of the registration. <del> A Context is a base URL that gives scheme and (typically) authority information about an Endpoint.  The Context of an Endpoint is provided at registration time, and is used by the Resource Directory to resolve relative references inside the registration into absolute URIs.  This is a distinct concept from the "link context" defined in RFC8288. </del> <ins> A Context is a base URL that typically gives scheme and authority information about an Endpoint.  The Context of an Endpoint is provided at registration time, and is used by the Resource Directory to resolve relative references inside the registration into absolute URIs.  This is a distinct concept from the "link context" defined in RFC8288. </ins> The target of a link is the destination address (URI) of the link.


one ep (endpoint with a unique name) <del> one con (a string describing the scheme://authority part) </del> <ins> one con (a string typically describing the scheme://authority part) </ins> one lt (lifetime),


Context (optional).  This parameter sets the Default Base URI under which the request's links are to be interpreted.  The <del> specified URI MUST NOT have a path component of its own, but MUST be suitable as a base URI to resolve any relative </del> <ins> specified URI typically does not have a path component of its own, and MUST be suitable as a base URI to resolve any relative </ins> references given in the registration.  The parameter is <del> therefore of the shape "scheme://authority" for HTTP and CoAP URIs.  In the absence of this parameter the scheme of the protocol, source address and source port of the registration request are assumed.  This parameter is mandatory when the directory is filled by a third party such as an commissioning tool.  If the endpoint uses an ephemeral port to register with, it MUST include the con parameter in the registration to provide a valid network path.  If the endpoint which is located behind a NAT gateway is registering with a Resource Directory which is on the network service side of the NAT gateway, the endpoint MUST use a persistent port for the outgoing registration in order to provide the NAT gateway with a valid network address for replies and incoming requests. </del> <ins> therefore usually of the shape "scheme://authority" for HTTP and CoAP URIs.  In the absence of this parameter the scheme of the protocol, source address and source port of the registration request are assumed.  This parameter is mandatory when the directory is filled by a third party such as an commissioning tool.  If the endpoint uses an ephemeral port to register with, it MUST include the con parameter in the registration to provide a valid network path.  If the endpoint which is located behind a NAT gateway is registering with a Resource Directory which is on the network service side of the NAT gateway, the endpoint MUST use a persistent port for the outgoing registration in order to provide the NAT gateway with a valid network address for replies and incoming requests. Endpoints that register with a con that contains a path component need to carefully consider the rules of relative URI resolution.  Typically, links submitted by such an endpoint are of the "path-noscheme" form. </ins> Additional registration attributes (optional).  The endpoint can pass any parameter registered at iana-registry to the


[ The RFC editor is asked to replace MCD1 and MCD2 with the assigned addresses throughout the document. ] <ins> 9.6. IANA is asked to extend the reference for the "core" URI suffix in the "Well-Known URIs" registry to reference this document next to RFC6690, as this defines the resource's behavior for POST requests. </ins> 10. Two examples are presented: a Lighting Installation example in lt-ex


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <del> "OPTIONAL" in this document are to be interpreted as described in RFC2119.  The term "byte" is used in its now customary sense as a synonym for "octet". </del> <ins> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. The term "byte" is used in its now customary sense as a synonym for "octet". </ins> This specification requires readers to be familiar with all the terms and concepts that are discussed in RFC3986, RFC8288 and RFC6690.


they do not limit what a server may respond under atypical circumstances. <del> REST clients (registrant-EPs / CTs, lookup clients, RD servers during simple registrations) MUST be prepared to receive any unsuccessful code and act upon it according to its definition, options and/or payload to the best of their capabilities, falling back to failing the operation if recovery is not possible.  In particular, they should retry the request upon 5.03 (Service Unavailable; 503 in HTTP) according to the Max-Age (Retry-After in HTTP) option, and fall back to link-format when receiving 4.15 (Unsupported Content-Format; 415 in HTTP). </del> <ins> REST clients (registrant-EPs and CTs during registration and maintenance, lookup clients, RD servers during simple registrations) MUST be prepared to receive any unsuccessful code and act upon it according to its definition, options and/or payload to the best of their capabilities, falling back to failing the operation if recovery is not possible.  In particular, they should retry the request upon 5.03 (Service Unavailable; 503 in HTTP) according to the Max-Age (Retry-After in HTTP) option, and fall back to link-format when receiving 4.15 (Unsupported Content-Format; 415 in HTTP). </ins> A resource directory MAY make the information submitted to it available to further directories, if it can ensure that a loop does


8.1. <del> An Endpoint (name, sector) pair is unique within the et of endpoints </del> <ins> An Endpoint (name, sector) pair is unique within the set of endpoints </ins> registered by the RD.  An Endpoint MUST NOT be identified by its protocol, port or IP address as these may change over the lifetime of an Endpoint.


IPv4 - "all CoRE resource directories" address MCD2 (suggestion: 224.0.1.189), from the "IPv4 Multicast Address Space Registry".  As the address is used for discovery that may span beyond a single <del> network, it has come from the Internetwork Control Block (224.0.1.x, RFC 5771). </del> <ins> network, it has come from the Internetwork Control Block (224.0.1.x) RFC5771. </ins> IPv6 - "all CoRE resource directories" address MCD1 (suggestions FF0X::FE), from the "IPv6 Multicast Address Space Registry", in the


depending on their current availability and capabilities as well as application requirements, thus avoiding silo like solutions.  One of the crucial enablers of such design is the ability to discover <del> resources (machines -- endpoints) capable of providing required information at a given time or acting on instructions from the end users. </del> <ins> resources (and thus the endpoints they are hosted on) capable of providing required information at a given time or acting on instructions from the end users. </ins> Imagine a scenario where endpoints installed on vehicles enable tracking of the position of these vehicles for fleet management


For cases where the device is not specifically configured with a way to find an RD, the network may want to provide a suitable default. <del> If the address configuration of the network is performed via SLAAC, this is provided by the RDAO option rdao. </del> <ins> The IPv6 Neighbor Discovery option RDAO rdao can do that. </ins> <del> If the address configuration of the network is performed via DHCP, this could be provided via a DHCP option (no such option is defined at the time of writing). </del> <ins> When DHCP is in use, this could be provided via a DHCP option (no such option is defined at the time of writing). </ins> Finally, if neither the device nor the network offers any specific configuration, the device may want to employ heuristics to find a


The First-Come-First-Remembered policy is added as an example and a potential default behavior. <ins> RD discovery: Drop the previously stated assumption that RDAO and any DHCP options would only be used together with SLAAC and DHCP for address configuration, respectivly. </ins> changes from -24 to -25 Large rework of section 7 (Security policies)


name and the same value, allowing for a trailing "*" wildcard operator as in Section 4.1 of RFC6690.  Attributes that are defined as "link-type" match if the search value matches any of their values <del> (see Section 4.1 of RFC6690; e.g. "?if=core.s" matches ";if="abc core.s";").  A resource link also matches a search criterion if its endpoint would match the criterion, and vice versa, an endpoint link matches a search criterion if any of its resource links matches it. </del> <ins> (see Section 4.1 of RFC6690; e.g. "?if=tag:example.net,2020:sensor" matches ";if="example.regname tag:example.net,2020:sensor";").  A resource link also matches a search criterion if its endpoint would match the criterion, and vice versa, an endpoint link matches a search criterion if any of its resource links matches it. </ins> Note that "href" is a valid search criterion and matches target references.  Like all search criteria, on a resource lookup it can


identifiers; the precise semantics of such links are left to future specifications. <del> The following example shows a client performing an endpoint type (et) lookup with the value oic.d.sensor (which is currently a registered rt value): </del> <ins> The following example shows a client performing an endpoint lookup limited to endpoints of endpoint type "tag:example.com,2020:platform": </ins> 7.


is specified in the coap-group resource. The presence sensor can learn the presence of groups that support <del> resources with rt=light in its own sector by sending the same request, as used by the luminary.  The presence sensor learns the multicast address to use for sending messages to the luminaries. </del> <ins> resources with rt=tag:example.com,2020:light in its own sector by sending the same request, as used by the luminary.  The presence sensor learns the multicast address to use for sending messages to the luminaries. </ins> 10.2.


RDAO: Clarify that it is an option for RAs and not other ND messages. <ins> Examples: Use example URIs rather than unclear reg names (unless it's RFC6690 examples, which were kept for continuity) </ins> changes from -24 to -25 Large rework of section 7 (Security policies)


at the CoAP layer then it may be inclined to use the endpoint name for looking up what information to provision to the malicious device. <del> Endpoint authentication needs to be checked independently of whether there are configured requirements on the credentials for a given endpoint name (secure-ep) or whether arbitrary names are accepted (arbitrary-ep). </del> <ins> Endpoint authorization needs to be checked on registration and registration resource operations independently of whether there are configured requirements on the credentials for a given endpoint name (secure-ep) or whether arbitrary names are accepted (arbitrary-ep). </ins> Simple registration could be used to circumvent address-based access control: An attacker would send a simple registration request with


and its links. <del> Commissioning Tool (CT) is a device that assists during the installation of the network by assigning values to parameters, naming endpoints and groups, or adapting the installation to the needs of the applications. </del> <ins> Commissioning Tool (CT) is a device that assists during installation events by assigning values to parameters, naming endpoints and groups, or adapting the installation to the needs of the applications. </ins> Registrant-ep is the endpoint that is registered into the RD.  The


any DHCP options would only be used together with SLAAC and DHCP for address configuration, respectivly. <ins> Terminology: Clarify that the CTs' installation events can occur multiple times. </ins> changes from -24 to -25 Large rework of section 7 (Security policies)