12. <del> Having discussed Transport Properties in connection-props and listed a number of Message Properties ("Ordered", "Idempotent" etc.) in message-props, we now provide a complete overview of a transport system's defined Transport Properties. Properties are structured in two ways: </del> <ins> Having discussed Selection Properties in selection-props, Connection Properties connection-props, and Message Properties (message-props), we now provide a complete overview of a transport system's defined Transport Properties. </ins> <del> By how they influence the transport system, which leads to a classification into "Selection Properties", "Protocol Properties", "Control Properties" and "Intents". </del> <ins> Transport Properties are structured by the phase and object they are applied: - Selection Properties apply to Preconnections - see selection-props - Connections Properties apply to Connections - see connection-props - Messages Properties apply to Messages - see </ins> <del> By the object they can be applied to: Preconnections, see connection-props, Connections, see introspection, and Messages, see message-props. Because some properties can be applied or queried on multiple objects, all Transport Properties are organized within a single namespace. </del> <ins> All Transport Properties are organized within a single namespace. This enables setting them as defaults in earlier stages and querying them in later stages: - Connections Properties can be set on Preconnections - Message Properties can be set on Preconnections and Connections - The effect of Selection Properties can be queried on Connections and Messages. </ins> Note that it is possible for a set of specified Transport Properties to be internally inconsistent, or to be inconsistent with the later


Comparison expressions are available for comparisons between primitive values (that is, numbers, strings, "true", "false", and <del> "null").  These can be obtained via literal values; Singular Paths, </del> <ins> "null").  These can be obtained via literal values; Singular Queries, </ins> each of which selects at most one node the value of which is then used; and function expressions (see fnex) of type "ValueType" or "NodesType" (see type-conv).


Organizations are a way of forming groups of contributors on GitHub. Each Working Group SHOULD create a new organization for the working <del> group. A working group organization SHOULD be named consistently so that it can be found.  For instance, the name could be ietf-<wgname> or ietf- <wgname>-wg. </del> <ins> group.  A working group organization SHOULD be named consistently so that it can be found.  For instance, the name could be ietf-<wgname> or ietf-<wgname>-wg. </ins> A single organization SHOULD NOT be used for all IETF activity, or all activity within an area.  Large organizations create too much


Change controller: n/a <del> 3.3. </del> <ins> 2.2.2. The following information serves as the registration form for the "application/openapi+yaml" media type. </ins> Type name: application


This alert notifies the recipient that the sender will not send any more messages on this connection.  Any data received after a <del> closure alert has been received MUST be ignored. </del> <ins> closure alert has been received MUST be ignored.  This alert MUST be sent with AlertLevel=warning. </ins> This alert notifies the recipient that the sender is canceling the handshake for some reason unrelated to a protocol failure.  If a


SHOULD be made accessible through a unified set of calls using the Transport Services API.  As a baseline, any Transport Services API SHOULD allow access to the minimal set of features offered by <del> transport protocols RFC8923. </del> <ins> transport protocols RFC8923.  If that minimal set is updated or expanded in the future, the Transport Services API ought to be extended to match. </ins> An application can specify constraints and preferences for the protocols, features, and network interfaces it will use via


6.3.1. A client may wish to change the public key that is associated with a <del> registration, e.g., in order to mitigate the risk of key compromise. To do this, the client first constructs a JSON object representing a request to update the registration: The string "reg", indicating an update to the registration. The JWK thumbprint of the new key RFC7638, base64url-encoded </del> <ins> registration in order to recover from a key compromise or proactively mitigate the impact of an unnoticed key compromise. </ins> <del> The client signs this object with the old key pair and encodes the object and signature as a JWS.  The client then sends this JWS to the server in the "rollover" field of a request to update the registration. </del> <ins> To change the key associate with an account, the client POSTs a key- change object with a "key" field containing a JWK representation of the new public key.  The JWS of this POST must have two signatures: one signature from the existing key on the account, and one signature from the new key that the client proposes to use.  This demonstrates that the client actually has control of the private key corresponding to the new public key.  The protected header must contain a JWK field containing the current account key. </ins> <del> On receiving a request to the registration URL with the "rollover" attribute set, the server MUST perform the following steps: </del> <ins> On receiving key-change request, the server MUST perform the following steps in addition to the typical JWS validation: </ins> <del> Check that the contents of the "rollover" attribute are a valid JWS </del> <ins> Check that the JWS protected header container a "jwk" field containing a key that matches a currently active account. </ins> <del> Check that the "rollover" JWS verifies using the account key corresponding to this registration </del> <ins> Check that there are exactly two signatures on the JWS. </ins> <del> Check that the payload of the JWS is a valid JSON object </del> <ins> Check that one of the signatures validates using the account key from (1). </ins> <del> Check that the "resource" field of the object has the value "reg" </del> <ins> Check that the "key" field contains a well-formed JWK that meets key strength requirements. </ins> <del> Check that the "newKey" field of the object contains the JWK thumbprint of the account key used to sign the request </del> <ins> Check that the "key" field is not equivalent to the current account key or any other currently active account key. </ins> <del> If all of these checks pass, then the server updates the registration by replacing the old account key with the public key carried in the "jwk" header of the request JWS. </del> <ins> Check that one of the two signatures on the JWS validates using the JWK from the "key" field. </ins> <del> If the update was successful, then the server sends a response with status code 200 (OK) and the updated registration object as its body. If the update was not successful, then the server responds with an error status code and a problem document describing the error. </del> <ins> If all of these checks pass, then the server updates the corresponding registration by replacing the old account key with the new public key and returns status code 200.  Otherwise, the server responds with an error status code and a problem document describing the error. </ins> 6.3.2.


responds with an error status code and a problem document describing the error. <del> 7.3.4. </del> <ins> 7.3.7. </ins> A client can deactivate an account by posting a signed update to the server with a status field of "deactivated."  Clients may wish to do


7. The data payload for the application/dns-message media type is a <del> single message of the DNS on-the-wire format defined in section 4.2.1 </del> <ins> single message of the DNS on-the-wire format defined in Section 4.2.1 </ins> of RFC1035.  The format was originally for DNS over UDP.  Although RFC1035 says "Messages carried by UDP are restricted to 512 bytes", that was later updated by RFC6891.  This media type restricts the maximum size of the DNS message to 65535 bytes.  Note that the wire format used in this media type is different than the wire format used <del> in RFC7858 (which uses the format defined in section 4.2.2 of </del> <ins> in RFC7858 (which uses the format defined in Section 4.2.2 of </ins> RFC1035). DoH clients using this media type MAY have one or more EDNS options


The client's TLS ClientHello may contain a Server Name Indication (SNI) RFC6066 extension, by which the client reveals the name of the server it intends to connect to, in order to allow the server to <del> present a certificate based on that name.  It may also contain an Application-Layer Protocol Negotiation (ALPN) RFC7301 extension, by which the client exposes the names of application-layer protocols it supports; an observer can deduce that one of those protocols will be used if the connection continues. </del> <ins> present a certificate based on that name.  SNI information is available to unidirectional observers on the client-to-server path, if present. The TLS ClientHello may also contain an Application-Layer Protocol Negotiation (ALPN) RFC7301 extension, by which the client exposes the names of application-layer protocols it supports; an observer can deduce that one of those protocols will be used if the connection continues. </ins> Work is currently underway in the TLS working group to encrypt the contents of the ClientHello in TLS 1.3 TLS-ECH.  This would make SNI-


All SenML Records in a Pack MUST have the same version number.  This is typically done by adding a Base Version field to only the first <del> Record in the Pack. </del> <ins> Record in the Pack, or by using the default value. </ins> Systems reading one of the objects MUST check for the Version field. If this value is a version number larger than the version which the


reordered ack-eliciting packet.  This extension modifies this behavior. <del> If an endpoint has not yet received an ACK_FREQUENCY frame, the endpoint immediately acknowledges any subsequent packets that are received out of order, as specified in Section 13.2 of QUIC- TRANSPORT.  An endpoint, that receives an ACK_FREQUENCY frame with a Reordering Threshold value other than 0x00, MUST immediately send an ACK frame when the packet number of largest unacknowledged packet since the last detected reordering event exceeds the Reordering Threshold. </del> <ins> In order to ensure timely loss detection, the Reordering Threshold provided in the ACK_FREQUENCY frame SHOULD NOT be larger than the re- ordering threshold used by the data sender for loss detection. (Section 18.2 of QUIC-RECOVERY) recommends a default packet threshold for loss detection of 3. An endpoint, that receives an ACK_FREQUENCY frame with a Reordering Threshold value other than 0x00, MUST immediately send an ACK frame when the packet number of largest unacknowledged packet since the last detected reordering event exceeds the Reordering Threshold. </ins> If the most recent ACK_FREQUENCY frame received from the peer has a "Reordering Threshold" value of 0x00, the endpoint does not make this


Abstract This memo defines Object Security of CoAP (OSCOAP), a method for <del> application layer protection of message exchanges with the Constrained Application Protocol (CoAP), using the CBOR Object Signing and Encryption (COSE) format.  OSCOAP provides end-to-end encryption, integrity and replay protection to CoAP payload, options, and header fields, as well as a secure binding between CoAP request and response messages.  The use of OSCOAP is signaled with the CoAP option Object-Security, also defined in this memo. </del> <ins> application layer protection of the Constrained Application Protocol (CoAP), using the CBOR Object Signing and Encryption (COSE).  OSCOAP provides end-to-end encryption, integrity and replay protection to CoAP payload, options, and header fields, as well as a secure message binding.  OSCOAP is designed for constrained nodes and networks and can be used across intermediaries and over any layer.  The use of OSCOAP is signaled with the CoAP option Object-Security, also defined in this memo. </ins> 1. <del> The Constrained Application Protocol (CoAP) RFC7252 is a web application protocol, designed for constrained nodes and networks RFC7228.  CoAP specifies the use of proxies for scalability and efficiency.  At the same time CoAP references DTLS RFC6347 for security.  Proxy operations on CoAP messages require DTLS to be terminated at the proxy.  The proxy therefore not only has access to the data required for performing the intended proxy functionality, but is also able to eavesdrop on, or manipulate any part of the CoAP payload and metadata, in transit between client and server.  The proxy can also inject, delete, or reorder packages without being protected or detected by DTLS. </del> <ins> The Constrained Application Protocol (CoAP) is a web application protocol, designed for constrained nodes and networks RFC7228.  CoAP specifies the use of proxies for scalability and efficiency.  At the same time CoAP RFC7252 references DTLS RFC6347 for security.  Proxy operations on CoAP messages require DTLS to be terminated at the proxy.  The proxy therefore not only has access to the data required for performing the intended proxy functionality, but is also able to eavesdrop on, or manipulate any part of the CoAP payload and metadata, in transit between client and server.  The proxy can also inject, delete, or reorder packages without being protected or detected by DTLS. </ins> This memo defines Object Security of CoAP (OSCOAP), a data object based security protocol, protecting CoAP message exchanges end-to- end, across intermediary nodes.  An analysis of end-to-end security for CoAP messages through intermediary nodes is performed in I- D.hartke-core-e2e-security-reqs, this specification addresses the <del> forwarding case. </del> <ins> forwarding case.  In addition to the core features defined in RFC7252, OSCOAP supports Observe RFC7641 and Blockwise RFC7959. </ins> <del> The solution provides an in-layer security protocol for CoAP which does not depend on underlying layers and is therefore favorable for providing security for "CoAP over foo", e.g.  CoAP messages passing over both unreliable and reliable transport I-D.ietf-core-coap-tcp- tls, CoAP over IEEE 802.15.4 IE I-D.bormann-6lo-coap-802-15-ie. </del> <ins> OSCOAP is designed for constrained nodes and networks and provides an in-layer security protocol for CoAP which does not depend on underlying layers.  OSCOAP can be used anywhere that CoAP can be used, including unreliable transport RFC7228, reliable transport I- D.ietf-core-coap-tcp-tls, and non-IP transport I-D.bormann-6lo-coap- 802-15-ie. </ins> OSCOAP builds on CBOR Object Signing and Encryption (COSE) I-D.ietf- <del> cose-msg, providing end-to-end encryption, integrity, and replay protection.  The use of OSCOAP is signaled with the CoAP option Object-Security, also defined in this memo.  The solution transforms an unprotected CoAP message into a protected CoAP message in the following way: the unprotected CoAP message is protected by including payload (if present), certain options, and header fields in a COSE object.  The message fields that have been encrypted are removed from the message whereas the Object-Security option and the COSE object are added.  We call the result the "protected" CoAP message.  Thus OSCOAP is a security protocol based on the exchange of protected CoAP messages (see oscoap-ex). OSCOAP provides protection of CoAP payload, certain options, and header fields, as well as a secure binding between CoAP request and response messages.  OSCOAP provides replay protection, but like DTLS, OSCOAP only provides relative freshness in the sense that the sequence numbers allows a recipient to determine the relative order of messages.  For applications having stronger demands on freshness (e.g. control of actuators), OSCOAP needs to be augmented with mechanisms providing absolute freshness I-D.mattsson-core-coap- actuators. </del> <ins> cose-msg, providing end-to-end encryption, integrity, replay protection, and secure message binding.  The use of OSCOAP is signaled with the CoAP option Object-Security, defined in obj-sec- option-section.  OSCOAP provides protection of CoAP payload, certain options, and header fields.  The solution transforms an unprotected CoAP message into a protected CoAP message in the following way: the unprotected CoAP message is protected by including payload (if present), certain options, and header fields in a COSE object.  The message fields that have been encrypted are removed from the message whereas the Object-Security option and the COSE object are added, see oscoap-ex. </ins> OSCOAP may be used in extremely constrained settings, where DTLS cannot be supported.  Alternatively, OSCOAP can be combined with


the PTO expiry, subject to address validation limits; see Section 8.1 of QUIC-TRANSPORT. <del> Peers can also use coalesced packets to ensure that each datagram elicits at least one acknowledgement.  For example, clients can </del> <ins> Endpoints can also use coalesced packets to ensure that each datagram elicits at least one acknowledgement.  For example, a client can </ins> coalesce an Initial packet containing PING and PADDING frames with a 0-RTT data packet and a server can coalesce an Initial packet containing a PING frame with one or more packets in its first flight.


1.4. This subsection provides a glossary of key terms related to the <del> Transport Services architecture.  It provides a simple description of </del> <ins> Transport Services architecture.  It provides a short description of </ins> key terms that are later defined in this document. Application: An entity that uses the transport layer for end-to-


Contains additional ranges of packets that are alternately not acknowledged (Gap) and acknowledged (ACK Range); see ack-ranges. <del> The three ECN Counts; see ack-ecn-counts. </del> <ins> The three ECN counts; see ack-ecn-counts. </ins> 19.3.1.


General background and concepts of DetNet can be found in the DetNet Architecture RFC8655. <del> I-D.ietf-detnet-ip specifies the DetNet data plane operation for IP hosts and routers that provide DetNet service to IP encapsulated data.  This document focuses on the scenario where DetNet IP nodes are interconnected by a TSN sub-network. </del> <ins> RFC8939 specifies the DetNet data plane operation for IP hosts and routers that provide DetNet service to IP encapsulated data.  This document focuses on the scenario where DetNet IP nodes are interconnected by a TSN sub-network. </ins> The DetNet Architecture decomposes the DetNet related data plane functions into two sub-layers: a service sub-layer and a forwarding sub-layer.  The service sub-layer is used to provide DetNet service protection and reordering.  The forwarding sub-layer is used to provides congestion protection (low loss, assured latency, and <del> limited reordering).  As described in I-D.ietf-detnet-ip no DetNet specific headers are added to support DetNet IP flows, only the forwarding sub-layer functions are supported inside the DetNet domain.  Service protection can be provided on a per sub-network basis as shown here for the IEEE802.1 TSN sub-network scenario. </del> <ins> limited reordering).  As described in RFC8939 no DetNet specific headers are added to support DetNet IP flows, only the forwarding sub-layer functions are supported inside the DetNet domain.  Service protection can be provided on a per sub-network basis as shown here for the IEEE802.1 TSN sub-network scenario. </ins> 2.


resulting in connection failures. A server MUST clear the QUIC bit only after processing transport <del> parameters from a client.  A server cannot remember that a client </del> <ins> parameters from a client.  A server MUST NOT remember that a client </ins> negotiated the extension in a previous connection and clear the QUIC Bit based on that information. <del> An endpoint cannot clear the QUIC Bit without knowing whether the </del> <ins> An endpoint MUST NOT clear the QUIC Bit without knowing whether the </ins> peer supports the extension.  As Stateless Reset packets (Section 10.3 of QUIC) are only used after a loss of connection state, endpoints are unlikely to be able to clear the QUIC Bit on


"Upgrade". the request SHALL include a single "Upgrade" header with value <del> "masque-udp". </del> <ins> "connect-udp". </ins> For example, if the client is configured with URI template "https://proxy.example.org/{target_host}/{target_port}/" and wishes


The EDHOC-KeyUpdate takes a context as input to enable binding of the updated PRK_out to some event that triggered the keyUpdate.  The Initiator and the Responder need to agree on the context, which can, <del> e.g., be a counter or a pseudorandom number such as a hash.  The Initiator and the Responder also need to cache the old PRK_out until it has verfied that the other endpoint has the correct new PRK_out. </del> <ins> e.g., be a counter or a pseudorandom number such as a hash.  To provide forward secrecy the old PRK_out and derived keys must be deleted as soon as they are not needed.  When to delete the old keys and how to verify that they are not needed is up to the application. </ins> I-D.ietf-core-oscore-key-update describes key update for OSCORE using EDHOC-KeyUpdate.


QUIC carries TLS handshake data in CRYPTO frames, each of which consists of a contiguous block of handshake data identified by an offset and length.  Those frames are packaged into QUIC packets and <del> encrypted under the current TLS encryption level.  As with TLS over TCP, once TLS handshake data has been delivered to QUIC, it is QUIC's </del> <ins> encrypted under the current encryption level.  As with TLS over TCP, once TLS handshake data has been delivered to QUIC, it is QUIC's </ins> responsibility to deliver it reliably.  Each chunk of data that is produced by TLS is associated with the set of keys that TLS is currently using.  If QUIC needs to retransmit that data, it MUST use the same keys even if TLS has already updated to newer keys. <del> One important difference between TLS records (used with TCP) and QUIC CRYPTO frames is that in QUIC multiple frames may appear in the same QUIC packet as long as they are associated with the same packet number space.  For instance, an endpoint can bundle a Handshake message and an ACK for some Handshake data into the same packet. </del> <ins> Each encryption level corresponds to a packet number space.  The packet number space that is used determines the semantics of frames. </ins> Some frames are prohibited in different packet number spaces; see Section 12.5 of QUIC-TRANSPORT.


An optional reference to a specification that describes the use of the setting. <ins> The value of the setting unless otherwise indicated.  SHOULD be the most restrictive possible value. </ins> The entries in the following table are registered by this document. Additionally, each code of the format "0x1f * N + 0x21" for integer


[ The CoAP option numbers 13 and 21 are both consistent with the <del> properties of the EDHOC Option defined in signalling, and they both </del> <ins> properties of the EDHOC Option defined in edhoc-option, and they both </ins> allow the EDHOC Option to always result in an overall size of 1 byte. This is because:


D.draft-bormann-jsonpath-iregexp for performance issues in regular expression implementations.)  Implementers need to be aware that good average performance is not sufficient as long as an attacker can <del> choose to submit specially crafted JSONPath queries that trigger surprisingly high, possibly exponential, CPU usage. </del> <ins> choose to submit specially crafted JSONPath queries or arguments that trigger surprisingly high, possibly exponential, CPU usage or, for example via a naive recursive implementation of the descendant selector, stack overflow.  Implementations need to have appropriate resource management to mitigate these attacks. </ins> 5.2.


Message Properties can be set and queried using the Message Context: <del> These Message Properties may be generic properties or protocol- </del> <ins> These Message Properties may be generic properties or Protocol- </ins> specific Properties. For MessageContexts returned by send Events (see send-events) and


guaranteed by a digital signature on each message from the sender's signature key. <ins> The signature keys held by group members are critical to the security of MLS against active attacks.  If a member's signature key is compromised, then an attacker can create KeyPackages impersonating the member; depending on the application, this can then allow the attacker to join the group with the compromised member's identity. For example, if a group has enabled external parties to join via external commits, then an attacker that has compromised a member's signature key could use an external commit to insert themselves into the group - even using a "resync"-style external commit to replace the compromised member in the group. Applications can mitigate the risks of signature key compromise using pre-shared keys.  If a group requires joiners to know a PSK in addition to authenticating with a credential, then in order to mount an impersonation attack, the attacker would need to compromise the relevant PSK as well as the victim's signature key.  The cost of this mitigation is that the application needs some external arrangement that ensures that the legitimate members of the group to have the required PSKs. </ins> 15.3. Post-compromise security is provided between epochs by members


connection ID. If the spin bit is enabled for the connection, the endpoint maintains <del> a spin value and sets the spin bit in the short header to the currently stored value when a packet with a short header is sent out. The spin value is initialized to 0 in the endpoint at connection start.  Each endpoint also remembers the highest packet number seen from its peer on the connection. When a server receives a short header packet that increments the highest packet number seen by the server from the client, it sets the spin value to be equal to the spin bit in the received packet. When a client receives a short header packet that increments the highest packet number seen by the client from the server, it sets the spin value to the inverse of the spin bit in the received packet. An endpoint resets its spin value to zero when sending the first packet of a given connection with a new connection ID.  This reduces the risk that transient spin bit state can be used to link flows across connection migration or ID change. </del> <ins> a spin value for each network path and sets the spin bit in the short header to the currently stored value when a packet with a short header is sent on that path.  The spin value is initialized to 0 in the endpoint for each network path.  Each endpoint also remembers the highest packet number seen from its peer on each path. When a server receives a short header packet that increases the highest packet number seen by the server from the client on a given network path, it sets the spin value for that path to be equal to the spin bit in the received packet. When a client receives a short header packet that increases the highest packet number seen by the client from the server on a given network path, it sets the spin value for that path to the inverse of the spin bit in the received packet. An endpoint resets the spin value for a network path to zero when changing the connection ID being used on that network path. </ins> With this mechanism, the server reflects the spin value received, while the client 'spins' it after one RTT.  On-path observers can


integer value (represented as a variable-length integer) that represents the maximum size of a DATAGRAM frame (including the frame type, length, and payload) the endpoint is willing to receive, in <del> 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 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 65535 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> bytes. The default for this parameter is 0, which indicates that the endpoint does not support DATAGRAM frames.  A value greater than 0 indicates that the endpoint supports the DATAGRAM frame types and is willing to receive such frames on this connection. An endpoint MUST NOT send DATAGRAM frames until it has received the max_datagram_frame_size transport parameter with a non-zero value. An endpoint MUST NOT send DATAGRAM frames that are larger than the max_datagram_frame_size value it has received from its peer.  An endpoint that receives a DATAGRAM frame when it has not indicated support via the transport parameter MUST terminate the connection with an error of type PROTOCOL_VIOLATION.  Similarly, an endpoint that receives a DATAGRAM frame that is larger than the value it sent in its max_datagram_frame_size transport parameter MUST terminate the connection with an error of type PROTOCOL_VIOLATION. For most uses of DATAGRAM frames, it is RECOMMENDED to send a value of 65535 in the max_datagram_frame_size transport parameter to indicate that this endpoint will accept any DATAGRAM frame that fits inside a QUIC packet. </ins> The max_datagram_frame_size transport parameter is a unidirectional limit and indication of support of DATAGRAM frames.  Application


6. <ins> 6.1. </ins> This document requests that a code point be allocated from the "TLS ContentType registry.  This value must be in the range 0-31 (inclusive).  The row to be added in the registry has the following


Error alert message.  In earlier versions of TLS, error alerts could be warnings or fatal.  In TLS 1.3, error alerts are always fatal and the only alerts sent at warning level are "close_notify" and <del> "user_cancelled", both of which indicate that the connection is not </del> <ins> "user_canceled", both of which indicate that the connection is not </ins> going to continue normally, see RFC8446. In TLS 1.3 RFC8446, error alerts are not mandatory to send after a


4.2. <ins> In the specific case of media ingestion into a streaming service, some assumptions can be made about the server-side which simplifies the WebRTC compliance burden, as detailed in WebRTC-gateway document draft-ietf-rtcweb-gateways. </ins> In order to reduce the complexity of implementing WHIP in both clients and media servers, WHIP imposes the following restrictions regarding WebRTC usage:


12.3.16. <del> Protocol Property (Generic) Integer Connection This property specifies the part of the received data that needs to be covered by a checksum.  It is given in Bytes.  A value of 0 means that no checksum is required, and a special value (e.g., -1) indicates full checksum coverage. </del> <ins> Integer Connection Property - see </ins> 12.3.17.


threshold, or the quality of RTT or loss rate is becoming worse) and wants to close the initial path. <del> In Figure fig-example-path-close the server's 1-RTT packets use DCID C1, which has a sequence number of 1, for the first path; the client's 1-RTT packets use DCID S2, which has a sequence number of 2. For the second path, the server's 1-RTT packets use DCID C2, which has a sequence number of 2; the client's 1-RTT packets use CID S3, which has a sequence number of 3.  Note that two paths use different packet number space. The client initiates the path closure for the path with ID 1 by sending a packet with an PATH_ABANDON frame.  When the server received the PATH_ABANDON frame, it also sends an PATH_ABANDON frame in the next packet.  Afterwards the connection IDs in both directions can be retired using the RETIRE_CONNECTION_ID frame. </del> <ins> fig-example-path-close1 illustrates an example of path closing when both the client and the server use non-zero-length CIDs.  For the first path, the server's 1-RTT packets use DCID C1, which has a sequence number of 1; the client's 1-RTT packets use DCID S2, which has a sequence number of 2.  For the second path, the server's 1-RTT packets use DCID C2, which has a sequence number of 2; the client's 1-RTT packets use DCID S3, which has a sequence number of 3.  Note that the paths use different packet number spaces.  In this case, the client is going to close the first path.  It identifies the path by the sequence number of the received packet's DCID over that path (path identifier type 0x00), hence using the path_id 1.  Optionally, the server confirms the path closure by sending an PATH_ABANDON frame using the sequence number of the received packet's DCID over that path (path identifier type 0x00) as path identifier, which corresponds to the path_id 2.  Both the client and the server can close the path after receiving the RETIRE_CONNECTION_ID frame for that path. fig-example-path-close2 illustrates an example of path closing when the client chooses to receive zero-length CIDs while the server chooses to receive non-zero-length CIDs.  Because there is a zero- length CID in one direction, single packet number spaces are used. For the first path, the client's 1-RTT packets use DCID S2, which has a sequence number of 2.  For the second path, the client's 1-RTT packets use DCID S3, which has a sequence number of 3.  Again, in this case, the client is going to close the first path.  Because the client now receives zero-length CID packets, it needs to use path identifier type 0x01, which identifies a path by the DCID sequence number of the packets it sends over that path, and hence, it uses a path_id 2 in its PATH_ABANDON frame.  The server SHOULD stop sending new data on the path indicated by the PATH_ABANDON frame after receiving it.  However, The client may want to repeat the PATH_ABANDON frame if it sees the server continuing to send data. When the client's PATH_ABANDON frame is acknowledged, it sends out a RETIRE_CONNECTION_ID frame for the CID used on the first path.  The server can readily close the first path when it receives the RETIRE_CONNECTION_ID frame from the client.  However, since the client will not receive a RETIRE_CONNECTION_ID frame, after sending out the RETIRE_CONNECTION_ID frame, the client waits for 3 RTO before closing the path. </ins> 11.


stored or transported, as compared to the less efficient text-based form of the original vocabulary. <ins> Through use of CDDL-based integer labels, CoSWID allows for future expansion in subsequent revisions of this specification and through extensions (see model-extension).  New constructs can be associated with a new integer index.  A deprecated construct can be replaced by a new construct with a new integer index.  An implementation can use these integer indexes to identify the construct to parse.  The CoSWID Items registry, defined in iana-coswid-items, is used to ensure that new constructs are assigned a unique index value on a first-come, first-served basis.  This approach avoids the need to have an explicit CoSWID version. </ins> The root of the CDDL specification provided by this document is the rule "coswid" (as defined in tagged):


5.1. The media type is "application/dns-udpwireformat".  The body is the <del> DNS on-the-wire format is defined in RFC1035.  The body MUST be encoded with base64url RFC4648.  Padding characters for base64url MUST NOT be included. </del> <ins> DNS on-the-wire format is defined in RFC1035. When using the GET method, the body MUST be encoded with base64url RFC4648.  Padding characters for base64url MUST NOT be included. When using the POST method, the body is not encoded. </ins> DNS API clients using the DNS wire format MAY have one or more EDNS(0) extensions RFC6891 in the request.


RFC2119. This document assumes that readers are familiar with the terms and <del> concepts that are used in RFC6455 and RFC7252. </del> <ins> concepts that are used in RFC6455, RFC7252, and RFC7641. </ins> The term "reliable transport" only refers to stream-based transport protocols such as TCP.


5.3. <ins> A server operating in Shared Mode uses PaddedServerNameList.sni as if it were the "server_name" extension to finish the handshake.  It SHOULD pad the Certificate message, via padding at the record layer, such that its length equals the size of the largest possible Certificate (message) covered by the same ESNI key. 5.4. </ins> The Hidden Server ignores both the "encrypted_server_name" and the "server_name" (if any) and completes the handshake as usual.  If in Shared Mode, the server will still know the true SNI, and can use it for certificate selection.  In Split Mode, it may not know the true <del> SNI and so will generally be configured to use a single certificate </del> <ins> SNI and so will generally be configured to use a single certificate. </ins> communicating-sni describes a mechanism for communicating the true <del> SNI to the hidden server.  [[OPEN ISSUE: Do we want "encrypted_server_name" in EE?  It's clearer communication, but gets in the way of stock servers.]] </del> <ins> SNI to the hidden server. Similar to the Shared Mode behavior, the hidden server in Split Mode SHOULD pad the Certificate message, via padding at the record layer such that its length equals the size of the largest possible Certificate (message) covered by the same ESNI key. [[OPEN ISSUE: Do we want "encrypted_server_name" in EE?  It's clearer communication, but gets in the way of stock servers.]] </ins> 6.


If the argument is "Nothing" or contains multiple nodes, the result is "Nothing". <del> Note: a Singular Query may be used anywhere where a ValueType is </del> <ins> Note: a singular query may be used anywhere where a ValueType is </ins> expected, so there is no need to use the "value" function extension <del> with a Singular Query. </del> <ins> with a singular query. </ins> 2.6.9.


Specify a Local Endpoint using a STUN server: <del> 6.1.4. </del> <ins> 6.1.5. </ins> Specify a Local Endpoint using an Any-Source Multicast group to join on a named local interface:


where Ns is as defined in OPRF, Section 4. The Issuer generates an HTTP response with status code 200 whose body <del> consists of TokenResponse, with the content type set as "message/ token-response". </del> <ins> consists of TokenResponse, with the content type set as "application/ private-token-response". </ins> 5.3.


value than what was included in a previous ACK frame could cause ECN to be unnecessarily disabled; see ecn-validation. <ins> ack-tracking describes an exemplary approach for determining what packets to acknowledge in each ACK frame.  Though the goal of this algorithm is to generate an acknowledgment for every packet that is processed, it is still possible for acknowledgments to be lost. 13.2.4. When a packet containing an ACK frame is sent, the largest acknowledged in that frame may be saved.  When a packet containing an ACK frame is acknowledged, the receiver can stop acknowledging packets less than or equal to the largest acknowledged in the sent ACK frame. </ins> A receiver that sends only non-ack-eliciting packets, such as ACK frames, might not receive an acknowledgement for a long period of time.  This could cause the receiver to maintain state for a large


be perceived as creating a conflict of interest for a particular MLS DE, that MLS DE SHOULD defer to the judgment of the other MLS DEs. <del> 17.9. </del> <ins> 17.10. </ins> This document registers the "message/mls" MIME media type in order to allow other protocols (e.g., HTTP RFC7540) to convey MLS messages.


Claims are assertions that represent characteristics of an Attester's Target Environment. <del> Claims are part Conceptual Message and are, for example, used to appraise the integrity of Attesters via a Verifiers.  The other </del> <ins> Claims are part of a Conceptual Message and are, for example, used to appraise the integrity of Attesters via Verifiers.  The other </ins> information elements in this section can be expressed as Claims in any type of Conceptional Messages. <ins> _optional_ Event Logs accompany Claims by providing event trails of security- critical events in a system.  The primary purpose of Event Logs is to support Claim reproducibility by providing information on how Claims originated. </ins> _mandatory_ Reference Values as defined in I-D.ietf-rats-architecture.  This


may be using a version of WebTransport extension that is different from the one used by the server. <ins> In addition to the setting above, the server MUST send a SETTINGS_MAX_WEBTRANSPORT_SESSIONS parameter indicating the maximum number of concurrent sessions it is willing to receive.  The default value for the SETTINGS_MAX_WEBTRANSPORT_SESSIONS parameter is "0", meaning that the server is not willing to receive any WebTransport sessions. </ins> 3.2. RFC8441 defines an extended CONNECT method in Section 4, enabled by


treat receipt of a non-empty value as a connection error of type TRANSPORT_PARAMETER_ERROR. <del> Advertising the grease_quic_bit transport parameter indicates that packets sent to this endpoint MAY set a value of 0 for the QUIC Bit. The QUIC Bit is defined as the second-to-most significant bit of the first byte of QUIC packets (that is, the value 0x40). </del> <ins> An endpoint that advertises the grease_quic_bit transport parameter MUST accept packets with the QUIC Bit set to a value of 0.  The QUIC Bit is defined as the second-to-most significant bit of the first byte of QUIC packets (that is, the value 0x40). </ins> A server MUST respect the value it previously provided for the grease_quic_bit transport parameter if it accepts 0-RTT.  A client


3.4.1. <del> If the ClientHello is not encrypted, it can be derived from the </del> <ins> If the ClientHello is not encrypted, SNI can be derived from the </ins> client's Initial packet by calculating the Initial secret to decrypt the packet payload and parsing the QUIC CRYPTO Frame containing the TLS ClientHello.


mechanism to allow for such application-specific features and options to be configured or otherwise negotiated. <ins> Transport dependency: None. Application dependency: Specification of application-layer features or functionality. </ins> Configuration extensions: The protocol negotiation should be extensible with addition of new configuration options. <ins> Transport dependency: None. Application dependency: Specification of application-specific extensions. </ins> Session caching and management: Sessions should be cacheable to enable reuse and amortize the cost of performing session establishment handshakes. <del> 4.2.2. </del> <ins> Transport dependency: None. </ins> <del> Connection mobility: Sessions should not be bound to a network connection (or 5-tuple).  This allows cryptographic key material and other state information to be reused in the event of a connection change.  Examples of this include a NAT rebinding that occurs without a client's knowledge. </del> <ins> Application dependency: None. </ins> 5. This section describes the interface surface exposed by the security <del> protocols described above, with each interface.  Note that not all protocols support each interface. </del> <ins> protocols described above.  Note that not all protocols support each interface.  We partition these interfaces into pre-connection (configuration), connection, and post-connection interfaces. </ins> 5.1.


The COSE_encrypt structure for the recipient is organized as follows: <ins> The 'protected', 'aad', 'iv', and 'tag' fields all use the 'null' value. At a minimum, the 'unprotected' field SHOULD contain the 'alg' parameter as well as a parameter identifying the asymmetric key. The 'unprotected' field MUST contain the 'epk' parameter. </ins> 5.2.5. Key Agreement with Key Wrapping uses a randomly generated CEK.  The


6. <ins> When a client creates a QUIC connection, its goal is to use an application layer protocol.  Therefore, when considering which versions are compatible, clients will only consider versions that support one of the intended application layer protocols.  If the client's first flight advertises multiple Application Layer Protocol Negotiation (ALPN) ALPN tokens and multiple compatible versions, it is possible for some application layer protocols to not be able to run over some of the offered compatible versions.  It is the server's responsibility to only select an ALPN token that can run over the compatible QUIC version that it selects. A given ALPN token MUST NOT be used with a new QUIC version different from the version for which the ALPN token was originally defined, unless all the following requirements are met: The new QUIC version supports the transport features required by the application protocol. The new QUIC version supports ALPN. The version of QUIC for which the ALPN token was originally defined is compatible with the new QUIC version. When incompatible version negotiation is in use, the second connection which is created in response to the received version negotiation packet MUST restart its application layer protocol negotiation process without taking into account the original version. 7. </ins> In order to facilitate the deployment of future versions of QUIC, designers of future versions SHOULD attempt to design their new version such that commonly deployed versions are compatible with it.


the option is sent with a modified value.  Its starting value is its base value. <del> 4.3.3. </del> <ins> 4.3.2. </ins> A sender can use the elective Block-wise Transfer Option to indicate that it supports the block-wise transfer protocol RFC7959.


The initial contents of this registry are shown in iana-tp-table. <del> Additionally, each value of the format "31 * N + 27" for integer values of N (that is, 27, 58, 89, ...) are reserved and MUST NOT be assigned by IANA. </del> <ins> Each value of the format "31 * N + 27" for integer values of N (that is, 27, 58, 89, ...) are reserved; these values MUST NOT be assigned by IANA and MUST NOT appear in the listing of assigned values. </ins> 22.3.


4. <del> Packet diagrams in this document use a format defined in QUIC- TRANSPORT to illustrate the order and size of fields. </del> <ins> The format of packets is described using the notation defined in this section.  This notation is the same as that used in QUIC-TRANSPORT. </ins> Complex fields are named and then followed by a list of fields surrounded by a pair of matching braces.  Each field in this list is


Time-Sensitive Networking, TSN is a Task Group of the IEEE 802.1 Working Group. <del> 2.3. 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 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> 3. <del> I-D.ietf-detnet-ip describes how IP is used by DetNet nodes, i.e., hosts and routers, to identify DetNet flows and provide a DetNet service.  From a data plane perspective, an end-to-end IP model is followed.  DetNet uses "6-tuple" based flow identification, where "6-tuple" refers to information carried in IP and higher layer protocol headers. </del> <ins> RFC8939 describes how IP is used by DetNet nodes, i.e., hosts and routers, to identify DetNet flows and provide a DetNet service.  From a data plane perspective, an end-to-end IP model is followed.  DetNet uses "6-tuple" based flow identification, where "6-tuple" refers to information carried in IP and higher layer protocol headers. </ins> DetNet flow aggregation may be enabled via the use of wildcards, masks, prefixes and ranges.  IP tunnels may also be used to support


that the registry will receive between 5 and 50 registrations in total over the next years. <ins> 9.4. The Endpoint Type parameter is described as follows: An endpoint registering at an RD can describe itself with endpoint types, similar to how resources are described with Resource Types in RFC6690.  An endpoint type is expressed as a string, which can be either a URI or one of the values defined in the Endpoint Type subregistry; it SHOULD be shorter than 63 bytes.  Endpoint types can be passed in the "et" query parameter as part of extra-attrs at the Registration step, are shown on endpoint lookups using the "et" target attribute, and can be filtered for using "et" as a search criterion in resource and endpoint lookup.  Multiple endpoint types are given as separate query parameters or link attributes. Note that Endpoint Type differs from Resource Type in that it uses multiple attributes rather than space separated values.  As a result, Resource Directory implementations automatically support correct filtering in the lookup interfaces from the rules for unknown endpoint attributes. This specification establishes a new sub-registry under "CoRE Parameters" called "Endpoint Type".  The registry properties (required policy, requirements, template) are identical to those of the Resource Type parameters in RFC6690.  The registry is initially empty. </ins> 10. Two examples are presented: a Lighting Installation example in lt-ex


_mandatory_ <ins> Collected Claims represent a (sub-)set of Claims created by an Attester. Collected Claims are gathered based on the Claims selected in the Claim Selection.  If a Verifier does not provide a Claim Selection, then all available Claims on the Attester are part of the Collected Claims. _mandatory_ </ins> A set of Claims that consists of a list of Authentication Secret IDs that each identifies an Authentication Secret in a single Attesting Environment, the Attester Identity, Claims, and a


domain RFC7556, measurements by the Protocol Stack, or other sources. <ins> 9.1.1. Boolean This property specifies whether an application considers it useful to be informed in case sent data was retransmitted more often than a certain threshold.  When set to true, the effect is twofold: The application may receive events in case excessive retransmissions.  In addition, the transport system considers this as a preference to use transports stacks that can provide this notification.  This is not a strict requirement.  If set to false, no notification of excessive retransmissions will be sent and this transport feature is ignored for protocol selection. The default is to have this option. 9.1.2. Integer This property specifies after how many retransmissions to inform the application about "Excessive Retransmissions". 9.1.3. Boolean This property specifies whether an application considers it useful to be informed when an ICMP error message arrives that does not force termination of a connection.  When set to true, received ICMP errors will be available as SoftErrors.  Note that even if a protocol supporting this property is selected, not all ICMP errors will necessarily be delivered, so applications cannot rely on receiving them.  Setting this option also implies a preference to prefer transports stacks that can provide this notification.  If not set, no events will be sent for ICMP soft error message and this transport feature is ignored for protocol selection. This property applies to Connections and Connection Groups.  The default is not to have this option. 9.1.4. Integer This property specifies the part of the received data that needs to be covered by a checksum.  It is given in Bytes.  A value of 0 means that no checksum is required, and a special value (e.g., -1) indicates full checksum coverage. 9.1.5. Integer This Property is a non-negative integer representing the relative inverse priority of this Connection relative to other Connections in the same Connection Group.  It has no effect on Connections not part of a Connection Group.  As noted in groups, this property is not entangled when Connections are cloned. 9.1.6. Integer This property specifies how long to wait before aborting a Connection during establishment, or before deciding that a Connection has failed after establishment.  It is given in seconds. 9.1.7. Enum This property specifies which scheduler should be used among Connections within a Connection Group, see groups.  The set of schedulers can be taken from I-D.ietf-tsvwg-sctp-ndata. 9.1.8. Integer (read only) This property represents the maximum Message size that can be sent before or during Connection establishment, see also msg-idempotent. It is given in Bytes. 9.1.9. Integer (read only) This property, if applicable, represents the maximum Message size that can be sent without incurring network-layer fragmentation or transport layer segmentation at the sender. 9.1.10. Integer (read only) This property represents the maximum Message size that can be sent. 9.1.11. Integer (read only) This numeric property represents the maximum Message size that can be received. 9.2. </ins> Slightly different from "querying", a SoftError Event can also occur, informing the application about the receipt of an ICMP error message related to the Connection.  This will only happen if the underlying


4.2.4. The CANCEL_PUSH frame (type=0x3) is used to request cancellation of a <del> server push prior to the push stream being created.  The CANCEL_PUSH </del> <ins> server push prior to the push stream being received.  The CANCEL_PUSH </ins> frame identifies a server push by Push ID (see frame-push-promise), encoded as a variable-length integer.


2.1. This document uses the terminology and concepts established in the <del> DetNet architecture RFC8655 and I-D.ietf-detnet-data-plane-framework, and I-D.ietf-detnet-mpls.  The reader is assumed to be familiar with these documents and their terminology. </del> <ins> DetNet architecture RFC8655 and RFC8938, and I-D.ietf-detnet-mpls. The reader is assumed to be familiar with these documents and their terminology. </ins> 2.2.


record MUST contain the same public key.  The update is signed using SIG(0), using the private key that corresponds to the public key in the KEY record.  The lifetimes of the records in the update is set <del> using the EDNS(0) Update Lease option I-D.sekar-dns-ul. </del> <ins> using the EDNS(0) Update Lease option I-D.ietf-dnssd-update-lease. </ins> The KEY record in Service Description updates MAY be omitted for brevity; if it is omitted, the SRP registrar MUST behave as if the


set to "webtransport", the HTTP/3 server can check if it has a WebTransport server associated with the specified ":authority" and ":path" values.  If it does not, it SHOULD reply with status code 404 <del> (Section 15.5.4, HTTP).  If it does, it MAY accept the session by replying with a 2xx series status code, as defined in Section 15.3 of HTTP.  The WebTransport server MUST verify the "Origin" header to </del> <ins> (Section 15.5.5 of HTTP).  When the request contains the "Origin" header, the WebTransport server MUST verify the "Origin" header to </ins> ensure that the specified origin is allowed to access the server in <del> question. </del> <ins> question.  If the verification fails, the WebTransport server SHOULD reply with status code 403 (Section 15.5.4 of HTTP).  If all checks pass, the WebTransport server MAY accept the session by replying with a 2xx series status code, as defined in Section 15.3 of HTTP. </ins> From the client's perspective, a WebTransport session is established when the client receives a 2xx response.  From the server's


its own, but needs a framing protocol on top to determine message boundaries. <del> Both stacks MUST offer the transport services that are required by the application.  For example, if an application specifies that it requires reliable transmission of data, then a Protocol Stack </del> <ins> Both stacks MUST offer the transport services that are requested by the application.  For example, if an application specifies that it requires reliable transmission of data, then a Protocol Stack </ins> using UDP without any reliability layer on top would not be allowed to replace a Protocol Stack using TCP.  However, if the application does not require reliability, then a Protocol Stack


setting, HSMs and secure enclaves can be used to protect signature keys. <ins> 6.6. Various academic works have analyzed MLS and the different security guarantees it aims to provide.  The security of large parts of the protocol has been analyzed by [BBN19] (draft 7), [ACDT21] (draft 11) and [AJM20] (draft 12). Individual components of various drafts of the MLS protocol have been analyzed in isolation and with differing adversarial models, for example, [BBR18], [ACDT19], [ACCKKMPPWY19], [AJM20] and [ACJM20] analyze the ratcheting tree as the sub-protocol of MLS that facilitates key agreement, while [BCK21] analyzes the key derivation paths in the ratchet tree and key schedule.  Finally, [CHK19] analyzes the authentication and cross-group healing guarantees provided by MLS. </ins> 7. <ins> ACDT19: https://eprint.iacr.org/2019/1189 ACCKKMPPWY19: https://eprint.iacr.org/2019/1489 ACJM20: https://eprint.iacr.org/2020/752 AJM20: https://eprint.iacr.org/2020/1327 ACDT21: https://eprint.iacr.org/2021/1083 AHKM21: https://eprint.iacr.org/2021/1456 CHK19: https://eprint.iacr.org/2021/137 BCK21: https://eprint.iacr.org/2021/137 BBR18: https://hal.inria.fr/hal-02425247 BBN19: https://hal.laas.fr/INRIA/hal-02425229 8. </ins> This document makes no requests of IANA.


object must be a randomly sampled nonce of length "KDF.Nh" to avoid key re-use. <del> 10.1.1. </del> <ins> 10.2.1. </ins> If a client wants to create a subgroup of an existing group, they MAY choose to include a "PreSharedKeyID" in the "GroupSecrets" object of


groups marked "No" range from "good" to "bad" from a cryptographic standpoint. <ins> If an item is not marked as recommended it does not necessarily mean that it is flawed; rather, it indicates that either the item has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases. </ins> The designated expert RFC8126 only ensures that the specification is publicly available.  An Internet Draft that is posted and never published or a standard in another standards body, industry


6.2. Message Framers generate an event whenever a Connection sends a new <del> Message. </del> <ins> Message.  The parameters to the event align with the Send call in the API (Section 9.2 of I-D.ietf-taps-interface). </ins> Upon receiving this event, a framer implementation is responsible for performing any necessary transformations and sending the resulting


13. <del> QUIC provides integrity protection for its version negotiation process.  This process assumes that the set of versions that a server supports is fixed.  This complicates the process for deploying new QUIC versions or disabling old versions when servers operate in </del> <ins> QUIC version 1 does not specify a version negotation mechanism in the base spec but I-D.draft-ietf-quic-version-negotiation proposes an extension.  This process assumes that the set of versions that a server supports is fixed.  This complicates the process for deploying new QUIC versions or disabling old versions when servers operate in </ins> clusters. A server that rolls out a new version of QUIC can do so in three


be sent in multiple parts. Protocols that provide the framing (such as length-value protocols, <del> or protocols that use delimiters) provide data boundaries that may be longer than the typical datagram.  Each Message for framing protocols </del> <ins> or protocols that use delimiters) may support Message sizes that do not fit within a single datagram.  Each Message for framing protocols </ins> corresponds to a single frame, which may be sent either as a complete <del> Message, or in multiple parts. </del> <ins> Message in the underlying protocol, or in multiple parts. </ins> 5.1.


acknowledgment (see sending-acknowledgements). A packet that does not increase the largest received packet number <del> for its packet number space by exactly one.  A packet can arrive out of order if it is delayed or if earlier packets are lost or delayed. </del> <ins> for its packet number space (packet-numbers) by exactly one.  A packet can arrive out of order if it is delayed or if earlier packets are lost or delayed. </ins> An entity that can participate in a QUIC connection by generating, receiving, and processing QUIC packets.  There are only two types


RFC7657 apply. The Capacity Profile for a selected protocol stack may be modified on <del> a per-Message basis using the Transmission Profile Message Context Property; see send-profile. </del> <ins> a per-Message basis using the Transmission Profile Message Property; see send-profile. </ins> 9.2.


1.2. <del> A frequently emphasized advantage of XML is the availability of powerful tools to analyse, transform and selectively extract data from XML documents.  XPath is one of these tools. </del> <ins> This document picks up Stefan Goessner's popular JSONPath specification dated 2007-02-21 JSONPath-orig and provides a normative definition for it. inspired-by-xpath provides a brief synopsis with XML's XPath XPath, which was the inspiration that led to the definition of JSONPath. JSONPath was intended as a light-weight companion to JSON implementations on platforms such as PHP and JavaScript, so instead of defining its own expression language like XPath did, JSONPath delegated this to the expression language of the platform.  While the languages in which JSONPath is used do have significant commonalities, over time this caused non-portability of JSONPath expressions between the ensuing platform-specific dialects. The present specification intends to remove platform dependencies and server as a common JSONPath specification that can be used across platforms.  Obviously, this means that backwards compatibility could not always be achieved; a design principle of this specification is to go with a "consensus" between implementations even if it is rough, as long as that does not jeopardize the objective of obtaining a usable, stable JSON query language. </ins> <del> In 2007, the need for something solving the same class of problems for the emerging JSON community became apparent, specifically for: Finding data interactively and extracting them out of RFC8259 JSON values without special scripting. Specifying the relevant parts of the JSON data in a request by a client, so the server can reduce the amount of data in its response, minimizing bandwidth usage. So what does such a tool look like for JSON?  When defining a JSONPath, how should expressions look? The XPath expression looks like or in popular programming languages such as JavaScript, Python and PHP, with a variable x holding the argument.  Here we observe that such languages already have a fundamentally XPath-like feature built in. The JSONPath tool in question should: be naturally based on those language characteristics. cover only essential parts of XPath 1.0. be lightweight in code size and memory consumption. </del> <ins> 1.3. </ins> <del> be runtime efficient. </del> <ins> JSONPath expressions are applied to a JSON value, the </ins> <del> 1.3. </del> <ins> .  Within the JSONPath expression, the abstract name "$" is used to refer to the </ins> <del> JSONPath expressions always apply to a value in the same way as XPath expressions are used in combination with an XML document.  Since a value is anonymous, JSONPath uses the abstract name "$" to refer to the root node of the argument. </del> <ins> of the argument, i.e., to the argument as a whole. </ins> JSONPath expressions can use the or the <del> for paths input to a JSONPath processor.  [1] Where a JSONPath processor uses JSONPath expressions as output paths, these will always be converted to Output Paths which employ the more general .  [2] Bracket notation is more general than dot notation and can serve as a canonical form when a JSONPath processor uses JSONPath expressions as output paths. JSONPath allows the wildcard symbol "*" for member names and array indices.  It borrows the descendant operator ".." from E4X and the array slice syntax proposal "[start:end:step]" SLICE from ECMASCRIPT 4. JSONPath was originally designed to employ an </del> <ins> to build paths that are input to a JSONPath processor.  Bracket notation is more general than dot notation and can serve as a canonical form (for instance, when a JSONPath processor uses JSONPath expressions as output paths). </ins> <del> for computing expressions.  The present specification defines a simple expression language that is independent from any scripting language in use on the platform. </del> <ins> JSONPath allows the wildcard symbol "*" to select any member of an object or any element of an array (wildcard).  The descendant operator ".." selects the node and all its descendants (descendant- selector).  The array slice syntax "[start:end:step]" allows selecting a regular selection of an element from an array, giving a start position, an end position, and possibly a step value that moves the position from the start to the end (slice). </ins> <del> JSONPath can use expressions, written in parentheses: "(<expr>)", as an alternative to explicit names or indices as in: </del> <ins> JSONPath employs an </ins> <del> The symbol "@" is used for the current node.  Filter expressions are supported via the syntax "?(<boolean expr>)" as in </del> <ins> for computing values and making decisions.  The present specification defines a simple expression language that is independent from any scripting language in use on the platform.  JSONPath can use such expression language expressions, written in parentheses: "(<expr>)", as an alternative to explicit names or indices as in [no-dot-length]: </ins> <del> Here is a complete overview and a side by side comparison of the JSONPath syntax elements with their XPath counterparts. </del> <ins> The symbol "@" is used for the current node, i.e., the node in the context of which the expression is evaluated. </ins> <del> XPath has a lot more to offer (location paths in unabbreviated syntax, operators and functions) than listed here.  Moreover there is a significant difference how the subscript operator works in Xpath and JSONPath: </del> <ins> Filter expressions are supported via the syntax "?(<boolean expr>)" as in </ins> <del> Square brackets in XPath expressions always operate on the resulting from the previous path fragment.  Indices always start at 1. With JSONPath, square brackets operate on the or addressed by the previous path fragment.  Array indices always start at 0. </del> <ins> tbl-overview provides a quick overview of the JSONPath syntax elements. </ins> 2.


The comparison "a <= b" yields true if and only if "a < b" yields true or "a == b" yields true. <del> The comparison "a >= b" yields true if and only if "a > b" yields </del> <ins> The comparison "a > b" yields true if and only if "b < a" yields true. The comparison "a >= b" yields true if and only if "b < a" yields </ins> true or "a == b" yields true. 3.5.5.2.3.


session-level attributes.  The process here is identical to that indicated in the Initial Offers section above. <ins> The next step is to generate lip sync groups as defined in RFC5888, Section 7.  For each MediaStream with more than one MediaStreamTrack, a group of type "LS" MUST be added that contains the mid values for each MediaStreamTrack in that MediaStream.  In some cases this may result in adding a mid to a given LS group that was not in that LS group in the associated offer.  Although this is not allowed by RFC5888, it is allowed when implementing this specification. </ins> The next step is to generate m= sections for each m= section that is present in the remote offer, as specified in RFC3264, Section 6.  For the purposes of this discussion, any session-level attributes in the


multipath negotiation is ambiguous, they MUST be interpreted as acknowledging packets sent on path 0. <ins> Endpoints negotiate the use of one packet number space for all paths or separate packet number spaces per path during the connection handshake nego.  While separate packet number spaces allow for more efficient ACK encoding, especially when paths have highly different latencies, this approach requires the use of a connection ID. Therefore use of a single number space can be beneficial when endpoints use zero-length connection ID for less overhead. </ins> 7.1. If the multipath option is negotiated to use one packet number space


Update the "Reference" to also refer to this document. <del> Add the following notes: Experts are to verify that there is in fact a publicly available standard.  An Internet Draft that is posted and never published or a standard in another standards body, industry consortium, university site, etc. suffices. As specified in RFC8126, assignments made in the Private Use space are not generally useful for broad interoperability.  It is the responsibility of those making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use). For widespread experiments, temporary reservations are available. </del> See expert-pool for additional information about the designated expert pool.


invoking packet included in the ICMP packet and only forward the ICMP packet to the client whose scoping matches the invoking packet. <ins> Since there are known risks with some IPv6 extension headers (e.g., ROUTING-HDR), implementers need to follow the latest guidance regarding handling of IPv6 extension headers. </ins> 11. 11.1.


where a flight is very large and the receiver is forced to elide acknowledgements for records which have already been ACKed.  As noted above, the receipt of any record responding to a given flight MUST be <del> taken as an implicit acknowledgement for the entire flight. </del> <ins> taken as an implicit acknowledgement for the entire flight to which it is responding. </ins> 7.3.


Imported PSKs do not collide with future protocol versions and KDFs. <del> There is no known interference between the process for computing Imported PSKs from an external PSK and the processing of existing external PSKs used in (D)TLS 1.2 and below.  However, only limited analysis has been done, which is an additional reason why applications SHOULD provision separate PSKs for (D)TLS 1.3 and prior versions, even when the importer interface is used in (D)TLS 1.3. </del> <ins> There are no known related outputs or security issues caused from the process for computing Imported PSKs from an external PSK and the processing of existing external PSKs used in (D)TLS 1.2 and below, as noted in rollout.  However, only limited analysis has been done, which is an additional reason why applications SHOULD provision separate PSKs for (D)TLS 1.3 and prior versions, even when the importer interface is used in (D)TLS 1.3. </ins> The PSK Importer does not prevent applications from constructing non- importer PSK identities that collide with imported PSK identities.


Determining which entries are too close to eviction to reference is an encoder preference.  One heuristic is to target a fixed amount of available space in the dynamic table: either unused space or space <del> that can be reclaimed by evicting unreferenced entries.  To achieve </del> <ins> that can be reclaimed by evicting non-blocking entries.  To achieve </ins> this, the encoder can maintain a draining index, which is the smallest absolute index in the dynamic table that it will emit a reference for.  As new entries are inserted, the encoder increases


from the "path_secret[n]" value assigned to the root node. If the "path" value is not populated: Define "commit_secret" as <del> the all-zero vector of the same length as a "path_secret" value would be. </del> <ins> the all-zero vector of length "KDF.Nh" (the same length as a "path_secret" value would be). </ins> Update the confirmed and interim transcript hashes using the new Commit, and generate the new GroupContext.


At the time this is published, the response types are works in progress.  The only known response type is "application/dns- <del> udpwireformat", but it is likely that at least one JSON-based </del> <ins> udpwireformat", but it is possible that at least one JSON-based </ins> response format will be defined in the future. The DNS response for "application/dns-udpwireformat" in dnswire MAY


the public key from the configuration, "pkR", and <del> a selected combination of KDF, identified by "kdf_id", and AEAD, identified by "aead_id". </del> <ins> a combination of KDF, identified by "kdf_id", and AEAD, identified by "aead_id", that the selects from those in the . </ins> The then constructs an , "enc_request", from a binary encoded HTTP request BINARY, "request", as follows:


setting Connection and Message Properties in Pre-Establishment) or have been omitted for brevity and simplicity. <ins> In this diagram, the lifetime of a Connection object is broken into three phases: Pre-Establishment, the Established state, and Termination. Pre-Establishment is based around a Preconnection object, that contains various sub-objects that describe the properties and parameters of desired Connections (Local and Remote Endpoints, Transport Properties, and Security Parameters).  A Preconnection can be used to start listening for inbound connections, in which case a Listener object is created, or can be used to establish a new connection directly using Initiate() (for outbound connections) or Rendezvous() (for peer-to-peer connections). Once a Connection is in the Established state, an application can send and receive Message objects, and receive state updates. Closing or aborting a connection, either locally or from the peer, can terminate a connection. </ins> 4.1.1. Endpoint: An endpoint represents an identifier for one side of a


A signature algorithm <del> MLS uses draft-07 of HPKE I-D.irtf-cfrg-hpke for public-key </del> <ins> MLS uses draft-08 of HPKE I-D.irtf-cfrg-hpke for public-key </ins> encryption.  The "DeriveKeyPair" function associated to the KEM for the ciphersuite maps octet strings to HPKE key pairs.


A Preconnection Object holds properties reflecting the application's requirements and preferences for the transport.  These include Selection Properties for selecting protocol stacks and paths, as well <del> as Connection Properties for configuration of the detailed operation of the selected Protocol Stacks. </del> <ins> as Connection Properties and Message Properties for configuration of the detailed operation of the selected Protocol Stacks on a per- Connection and Message level. </ins> The protocol(s) and path(s) selected as candidates during establishment are determined and configured using these properties.


Number by one.  Compute the AEAD nonce from the Sender ID, Common IV, and Partial IV. <del> Add the following step after step 5: B.  If the message is an Observe notification, store it in memory for use with re-registrations (see replay-protection), and delete from memory any older one previously stored. </del> 8.4. A client receiving a response containing the OSCORE option SHALL


single underlying transport connection where possible.  This is not a strict requirement.  The default is to not have this option. <del> 5.2.6. </del> <ins> 5.2.7. </ins> Type: Boolean


14. <del> I-D.draft-ietf-quic-datagram specifies a QUIC extension to enable sending and receiving unreliable datagrams over QUIC.  Unlike operating directly over UDP, applications that use the QUIC datagram service do not need to implement their own congestion control, per RFC8085, as QUIC datagrams are congestion controlled. </del> <ins> I-D.ietf-quic-datagram specifies a QUIC extension to enable sending and receiving unreliable datagrams over QUIC.  Unlike operating directly over UDP, applications that use the QUIC datagram service do not need to implement their own congestion control, per RFC8085, as QUIC datagrams are congestion controlled. </ins> QUIC datagrams are not flow-controlled, and as such data chunks may be dropped if the receiver is overloaded.  While the reliable


Calling "Close" on a UDP Multicast Receive Connection (ABORT.UDP(- Lite)) releases the local port reservation and leaves the group. <ins> The Connection then issues a "Closed" Event. </ins> Calling "Abort" on a UDP Multicast Receive Connection (ABORT.UDP(- <del> Lite)) is identical to calling "Close". </del> <ins> Lite)) is identical to calling "Close", except that the Connection will send a "ConnectionError" Event rather than a "Closed" Event. </ins> Calling "CloseGroup" on a UDP Multicast Receive Connection (ABORT.UDP(-Lite)) is identical to calling "Close" on this


Knowledge that a header block with references to the dynamic table has been processed permits the encoder to evict entries to which no <del> unacknowledged references remain, regardless of whether those references were potentially blocking (see blocked-insertion).  When a </del> <ins> unacknowledged references remain (see blocked-insertion).  When a </ins> stream is reset or abandoned, the indication that these header blocks <del> will never be processed serves a similar function; see stream- cancellation. </del> <ins> will never be processed serves a similar function (see stream- cancellation). </ins> The decoder chooses when to emit Insert Count Increment instructions (see insert-count-increment).  Emitting an instruction after adding


I-D.ietf-tls-dtls13.  The presentation language used in this document is described in Section 4 of RFC8446. <ins> This document reuses the definition of "anti-amplification limit" from RFC9000 to mean three times the amount of data received from an unvalidated address.  This includes all DTLS records originating from that source address, excluding discarded ones. </ins> 3. The use of RRC is negotiated via the "rrc" DTLS-only extension.  On


have a route for the destination address, or if it is configured to reject a destination prefix by policy, or if the MTU of the outgoing link is lower than the size of the packet to be forwarded.  In such <del> scenarios, CONNECT-IP endpoints SHOULD use ICMP ICMP to signal the forwarding error to its peer. </del> <ins> scenarios, CONNECT-IP endpoints SHOULD use ICMP ICMP ICMPV6 to signal the forwarding error to its peer. Endpoints are free to select the most appropriate ICMP errors to send.  Some examples that are relevant for CONNECT-IP include: For invalid source addresses, send Destination Unreachable ICMPV6 with code 5, "Source address failed ingress/egress policy". For unroutable destination addresses, send Destination Unreachable ICMPV6 with a code 0, "No route to destination", or code 1, "Communication with destination administratively prohibited". For packets that cannot fit within the MTU of the outgoing link, send Packet Too Big ICMPV6. In order to receive these errors, endpoints need to be prepared to receive ICMP packets.  If an endpoint sends ROUTE_ADVERTISEMENT capsules, its routes SHOULD include an allowance for receiving ICMP messages.  If an endpoint does not send ROUTE_ADVERTISEMENT capsules, such as a client opening an IP flow through a proxy, it SHOULD process proxied ICMP packets from its peer in order to receive these errors.  Note that ICMP messages can originate from a source address different from that of the CONNECT-IP peer. </ins> 8.


6. Clients MUST ignore any received Version Negotiation packets that <del> contain the version that they initially attempted.  Once a client has reacted to a Version Negotiation packet, it MUST drop all subsequent Version Negotiation packets on that connection. </del> <ins> contain the version that they initially attempted.  A client that makes a connection attempt based on information received from a Version Negotiation packet MUST ignore any Version Negotiation packets it receives in response to that connection attempt. </ins> Both endpoints MUST parse their peer's Version Information during the handshake.  If parsing the Version Information failed (for example,


This section defines how proxies operate in a group communication scenario.  In particular, sec-proxy-forward defines operations of forward-proxies, while sec-proxy-reverse defines operations of <del> reverse-proxies. </del> <ins> reverse-proxies.  Security operations for a proxy are discussed later in chap-proxy-security. </ins> 3.5.1.


The rsabssa_blind_sign function is defined in BLINDRSA, Section 5.1.2..  The Issuer generates an HTTP response with status code 200 whose body consists of TokenResponse, with the content type <del> set as "message/token-response". </del> <ins> set as "application/private-token-response". </ins> 6.3.


content.  Before being encrypted, the sender data is encoded as an object of the following form: <del> MLSSenderData.sender is assumed to be a "member" sender type.  When constructing an MLSSenderData from a Sender object, the sender MUST verify Sender.sender_type is "member" and use Sender.sender for MLSSenderData.sender. </del> <ins> When constructing an MLSSenderData from a Sender object, the sender MUST verify Sender.sender_type is "member" and use Sender.leaf_index for MLSSenderData.leaf_index. </ins> The "reuse_guard" field contains a fresh random value used to avoid nonce reuse in the case of state loss or corruption, as described in


7. <del> The Homenet Zone provides information about the home network.  Some users may be tempted to have provide responses dependent on the origin of the DNS query.  More specifically, some users may be tempted to provide a different view for DNS queries originating from the home network and for DNS queries coming from the Internet.  Each view could then be associated with a dedicated Homenet Zone. <!--Regarding {{fig-naming-arch}}, an example of an implementation of two distinct view could be the Homenet Zone that describes the homenet view and the Public Homenet Zone that contains the Internet view, with these two zones being different.--> Note that this document does not specify how DNS queries originating from the home network are addressed to the Homenet Zone.  This could be done via hosting the DNS resolver on the HNA for example. This section is not normative. sec-reasons details why some nodes may only be reachable from the home network and not from the global Internet. sec-consequences briefly describes the consequences of having distinct views such as a "home network view" and an "Internet view".  Finally, sec-guidance provides guidance on how to resolve names that are only significant in the home network, without creating different views. 7.1. The motivation for supporting different views is to provide different answers dependent on the origin of the DNS query, for reasons such as: 1: An end user may want to have services not published on the Internet.  Services like the HNA administration interface that provides the GUI to administer your HNA might not seem advisable to publish on the Internet.  Similarly, services like the mapper that registers the devices of your home network may also not be desirable to be published on the Internet.  In both cases, these services should only be known or used by the network administrator.  To restrict the access of such services, the home network administrator may choose to publish these pieces of information only within the home network, where it might be assumed that the users are more trusted than on the Internet.  Even though this assumption may not be valid, at least this may reduce the surface of any attack. 2: Services within the home network may be reachable using non global IP addresses.  IPv4 and NAT may be one reason.  On the other hand IPv6 may favor link-local or site-local IP addresses.  These IP addresses are not significant outside the boundaries of the home network.  As a result, they MAY be published in the home network view, and SHOULD NOT be published in the Public Homenet Zone. 7.2. Enabling different views leads to a non-coherent naming system. Depending on where resolution is performed, some services will not be available.  This may be especially inconvenient with devices with multiple interfaces that are attached both to the Internet via a 3G/4G interface and to the home network via a WLAN interface. Devices may also cache the results of name resolution, and these cached entries may no longer be valid if a mobile device moves between a homenet connection and an internet connection e.g. a device temporarily loses wifi signal and switches to 3G. Regarding local-scope IP addresses, such devices may end up with poor connectivity.  Suppose, for example, that DNS resolution is performed via the WLAN interface attached to the HNA, and the response provides local-scope IP addresses, but the communication is initiated on the 3G/4G interface.  Communications with local-scope addresses will be unreachable on the Internet, thus aborting the communication.  The same situation occurs if a device is flip / flopping between various WLAN networks. Regarding DNSSEC, if the HNA does not sign the Homenet Zone and outsources the signing process, the two views are different, because one is protected with DNSSEC whereas the other is not.  Devices with multiple interfaces will have difficulty securing the naming resolution, as responses originating from the home network may not be signed. For devices with all its interfaces attached to a single administrative domain, that is to say the home network, or the Internet.  Incoherence between DNS responses may still also occur if the device is able to perform DNS resolutions both using the DNS resolving server of the home network, or one of the ISP.  DNS resolution performed via the HNA or the ISP resolver may be different than those performed over the Internet. 7.3. As documented in sec-consequences, it is RECOMMENDED to avoid different views.  If network administrators choose to implement multiple views, impacts on devices' resolution SHOULD be evaluated. As a consequence, the Homenet Zone is expected to be an exact copy of the Public Homenet Zone.  As a result, services that are not expected to be published on the Internet SHOULD NOT be part of the Homenet Zone, local-scope addresses SHOULD NOT be part of the Homenet Zone, and when possible, the HNA SHOULD sign the Homenet Zone. The Homenet Zone is expected to host public information only.  It is not the scope of the DNS service to define local home network boundaries.  Instead, local scope information is expected to be provided to the home network using local scope naming services. mDNS RFC6762 DNS-SD RFC6763 are two examples of these services.  Currently mDNS is limited to a single link network.  However, future protocols are expected to leverage this constraint as pointed out in RFC7558. 7.4. </del> This section is focused on the Homenet Reverse Zone. Firstly, all considerations for the Homenet Zone apply to the Homenet


RD registration URI (mandatory).  This is the location of the RD, as obtained from discovery. <del> Endpoint name (mandatory).  The endpoint name is an identifier that MUST be unique within a domain.  The maximum length of this parameter is 63 bytes. </del> <ins> Endpoint name (mostly mandatory).  The endpoint name is an identifier that MUST be unique within a domain.  The maximum length of this parameter is 63 bytes.  If the RD is configured to recognize the endpoint (eg. based on its security context), the endpoint can elide the endpoint name, and assign one based on the configuration. </ins> Domain (optional).  The domain to which this endpoint belongs. The maximum length of this parameter is 63 bytes.  When this


verification) or make sure there is common context for the server to verify the address using a service-generated token. <ins> The service must also communicate the source connection ID of the Retry packet to the server so that it can include it in a transport parameter for client verification. </ins> There are two different mechanisms to allow offload of DoS mitigation to a trusted network service.  One requires no shared state; the server need only be configured to trust a retry service, though this


to "cid_spare", then either existing or new CID MAY be used. Endpoints SHOULD use receiver-provided CIDs in the order they were <del> provided.  Endpoints MUST NOT have more than one NewConnectionId message outstanding. </del> <ins> provided.  Implementations which receive more spare CIDs than they wish to maintain MAY simply discard any extra CIDs.  Endpoints MUST NOT have more than one NewConnectionId message outstanding. </ins> Implementations which either did not negotiate the "connection_id" extension or which have negotiated receiving an empty CID MUST NOT


request that is made to the target.  This means that only the gateway or target are in a position to identify abuse.  A gateway MAY send signals toward the relay to provide feedback about specific requests. <del> A relay that acts on this feedback could - either inadvertently or by design - lead to clients being deanonymized. </del> <ins> For example, a gateway could respond differently to requests it cannot decapsulate, as mentioned in errors.  A relay that acts on this feedback could - either inadvertently or by design - lead to client deanonymization. </ins> 7.2.2.


This document defines two new DATAGRAM QUIC frame types, which carry application data without requiring retransmissions. <ins> Note that DATAGRAM frames are only meant for unreliable transmissions.  Reliable transmission is already supported by QUIC via STREAM frames. </ins> Discussion of this work is encouraged to happen on the QUIC IETF mailing list quic@ietf.org [3] or on the GitHub repository which contains the draft: https://github.com/quicwg/datagram [4].


This specification defines the following protocol messages, along with their corresponding media types: <del> TokenRequest: "message/token-request" </del> <ins> TokenRequest: "application/private-token-request" </ins> <del> TokenResponse: "message/token-response" </del> <ins> TokenResponse: "application/private-token-response" </ins> The definition for each media type is in the following subsections. 8.2.1. <del> message </del> <ins> application </ins> <del> token-request </del> <ins> private-token-request </ins> N/A


4. <del> This section describes a typical RTCWeb session and shows how the </del> <ins> This section describes a typical WebRTC session and shows how the </ins> various security elements interact and what guarantees are provided to the user.  The example in this section is a "best case" scenario in which we provide the maximal amount of user authentication and


An intermediary can reencode HTTP Datagrams as it forwards them.  In other words, an intermediary MAY send a DATAGRAM capsule to forward <del> an HTTP Datagram which was received in a QUIC DATAGRAM frame, and vice versa. </del> <ins> an HTTP Datagram that was received in a QUIC DATAGRAM frame, and vice versa.  Intermediaries MUST NOT perform this reencoding unless they have identified the use of the Capsule Protocol on the corresponding request stream; see capsule-protocol. </ins> Note that while DATAGRAM capsules that are sent on a stream are reliably delivered in order, intermediaries can reencode DATAGRAM


conditions that irrevocably lead to the termination of the Connection are signaled using ConnectionError instead (see termination). <del> The ReceiveError event passes an optional associated messageContext. </del> <ins> The ReceiveError event passes an optional associated MessageContext. </ins> This may indicate that a Message that was being partially received previously, but had not completed, encountered an error and will not be completed.


a POST request with an empty update.  That is, it should send a JWS whose payload is an empty object ({}). <del> 7.3.1. </del> <ins> 7.3.4. </ins> As described above, a client can indicate its agreement with the CA's terms of service by setting the "terms-of-service-agreed" field in


The value for hpke_init_key MUST be a public key for the asymmetric encryption scheme defined by cipher_suite.  The whole structure is signed using the client's signature key.  A KeyPackage object with an <del> invalid signature field MUST be considered malformed.  The input to the signature computation comprises all of the fields except for the signature field. </del> <ins> invalid signature field MUST be considered malformed. The signature is computed by the function "SignWithLabel" with a label "KeyPackage" and a content comprising of all of the fields except for the signature field. </ins> KeyPackage objects MUST contain at least two extensions, one of type "capabilities", and one of type "lifetime".  The "capabilities"


Clients encapsulate a request "request" using values from a key configuration: <del> the key identifier from the configuration, "keyID", </del> <ins> the key identifier from the configuration, "keyID", with the corresponding KEM identified by "kemID", </ins> the public key from the configuration, "pkR", and