jiebi/CodeConvo huggingface dataset:
been changed, then the original value will already be in the OHB, so no update to the OHB is required. <ins> A Media Distributor that decrypts, modifies, and re-encrypts packets in this way MUST use an independent key for each recipient, SHOULD use an independent salt for each recipient, and MUST NOT re-encrypt the packet using the sender's keys.  If the Media Distributor decrypts and re-encrypts with the same key and salt, it will result in the reuse of a (key, nonce) pair, undermining the security of GCM. </ins> 5.3. To decrypt a packet, the endpoint first decrypts and verifies using
1. This document describes the values of the qlog name ("category" + <del> "event") and "data" fields and their semantics for the HTTP/3 and QPACK protocols.  This document is based on draft-34 of the HTTP/3 I-D QUIC-HTTP and draft-21 of the QPACK I-D QUIC-QPACK.  QUIC events are defined in a separate document QLOG-QUIC. </del> <ins> "event") and "data" fields and their semantics for HTTP/3 RFC9114 and QPACK QPACK. </ins> Feedback and discussion are welcome at https://github.com/quicwg/qlog [1].  Readers are advised to refer to the "editor's draft" at that
1. This document describes the values of the qlog name ("category" + <del> "event") and "data" fields and their semantics for the QUIC protocol. This document is based on draft-34 of the QUIC I-Ds QUIC-TRANSPORT, QUIC-RECOVERY, and QUIC-TLS.  HTTP/3 and QPACK events are defined in a separate document QLOG-H3. </del> <ins> "event") and "data" fields and their semantics for QUIC; see QUIC- TRANSPORT, QUIC-RECOVERY, and QUIC-TLS. </ins> Feedback and discussion are welcome at https://github.com/quicwg/qlog [1].  Readers are advised to refer to the "editor's draft" at that
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
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
1. <del> QUIC RFC9000 has numerous extension points, including the version number that occupies the second through fifth octets of every long header (see RFC8999).  If experimental versions are rare, and QUIC version 1 constitutes the vast majority of QUIC traffic, there is the potential for middleboxes to ossify on the version octets always being 0x00000001. </del> <ins> QUIC QUIC has numerous extension points, including the version number that occupies the second through fifth octets of every long header (see RFC8999).  If experimental versions are rare, and QUIC version 1 constitutes the vast majority of QUIC traffic, there is the potential for middleboxes to ossify on the version octets always being 0x00000001. </ins> Furthermore, version 1 Initial packets are encrypted with keys derived from a universally known salt, which allow observers to
provisional value 0xff020000, which might change with each edition of this document. <del> The salt used to derive Initial keys in Sec 5.2 of RFC9001 changes to </del> <ins> The salt used to derive Initial keys in Section 5.2 of QUIC-TLS changes to: </ins> <del> The labels used in RFC9001 to derive packet protection keys (Sec 5.1), header protection keys (Sec 5.4), Retry Integrity Tag keys (Sec 5.8), and key updates (Sec 6.1) change from "quic key" to </del> <ins> The labels used in QUIC-TLS to derive packet protection keys (Section Section 5.1 of QUIC-TLS), header protection keys (Section Section 5.4 of QUIC-TLS), Retry Integrity Tag keys (Section Section 5.8 of QUIC-TLS), and key updates (Section Section 6.1 of QUIC-TLS) change from "quic key" to </ins> "quicv2 key", from "quic iv" to "quicv2 iv", from "quic hp" to "quicv2 hp", and from "quic ku" to "quicv2 ku", to meet the <del> guidance for new versions in Section 9.6 of that document. </del> <ins> guidance for new versions in Section Section 9.6 of QUIC-TLS of that document. </ins> <del> The key and nonce used for the Retry Integrity Tag (Sec 5.8 of RFC9001) change to: </del> <ins> The key and nonce used for the Retry Integrity Tag (Section 5.8 of QUIC-TLS) change to: </ins> 4.
QUIC QUIC has numerous extension points, including the version number that occupies the second through fifth bytes of every long header <del> (see RFC8999).  If experimental versions are rare, and QUIC version 1 constitutes the vast majority of QUIC traffic, there is the potential for middleboxes to ossify on the version bytes always being </del> <ins> (see QUIC-INVARIANTS).  If experimental versions are rare, and QUIC version 1 constitutes the vast majority of QUIC traffic, there is the potential for middleboxes to ossify on the version bytes always being </ins> 0x00000001. <del> Furthermore, version 1 Initial packets are encrypted with keys derived from a universally known salt, which allow observers to inspect the contents of these packets, which include the TLS Client Hello and Server Hello messages.  Again, middleboxes may ossify on </del> <ins> In QUIC version 1, Initial packets are encrypted with the version- specific salt as described in Section 5.2 of QUIC-TLS.  Protecting Initial packets in this way allows observers to inspect their contents, which includes the TLS Client Hello or Server Hello messages.  Again, there is the potential for middleboxes to ossify on </ins> the version 1 key derivation and packet formats. Finally QUIC-VN provides two mechanisms for endpoints to negotiate
to implement version negotiation to protect against downgrade attacks. <del> I-D.duke-quic-version-aliasing is a more robust, but much more complicated, proposal to address these ossification problems.  By design, it requires incompatible version negotiation.  QUICv2 enables exercise of compatible version negotiation mechanism. </del> 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
3. QUIC version 2 endpoints MUST implement the QUIC version 1 <del> specification as described in QUIC, QUIC-TLS, and RFC9002, with the following changes. </del> <ins> specification as described in QUIC, QUIC-TLS, and RFC9002.  However, the following differences apply in version 2. </ins> 3.1. <del> The version field of long headers is 0x709a50c4. </del> <ins> The Version field of long headers is 0x709a50c4. </ins> 3.2. <del> Initial packets use a packet type field of 0b01. 0-RTT packets use a packet type field of 0b10.  Handshake packets use a packet type field of 0b11.  Retry packets use a packet type field of 0b00. </del> <ins> All version 2 long header packet types are different.  The Type field values are: Initial: 0b01 0-RTT: 0b10 Handshake: 0b11 Retry: 0b00 </ins> 3.3.
TLS session tickets and NEW_TOKEN tokens are specific to the QUIC version of the connection that provided them.  Clients SHOULD NOT use <del> a session ticket or token from a QUICv1 connection to initiate a QUICv2 connection, or vice versa. </del> <ins> a session ticket or token from a QUIC version 1 connection to initiate a QUIC version 2 connection, or vice versa. </ins> Servers MUST validate the originating version of any session ticket or token and not accept one issued from a different version.  A
6. QUIC version 2 provides protection against some forms of <del> ossification.  Devices that assume that all long headers will contain encode version 1, or that the version 1 Initial key derivation formula will remain version-invariant, will not correctly process version 2 packets. </del> <ins> ossification.  Devices that assume that all long headers will encode version 1, or that the version 1 Initial key derivation formula will remain version-invariant, will not correctly process version 2 packets. </ins> However, many middleboxes such as firewalls focus on the first packet in a connection, which will often remain in the version 1 format due
This version of QUIC provides no change from QUIC version 1 relating to the capabilities available to applications.  Therefore, all Application Layer Protocol Negotiation (ALPN) (RFC7301) codepoints <del> specified to operate over QUICv1 can also operate over this version of QUIC.  In particular, both the "h3" I-D.ietf-quic-http and "doq" I-D.ietf-dprive-dnsoquic ALPNs can operate over QUICv2. </del> <ins> specified to operate over QUIC version 1 can also operate over this version of QUIC.  In particular, both the "h3" I-D.ietf-quic-http and "doq" I-D.ietf-dprive-dnsoquic ALPNs can operate over QUIC version 2. </ins> All QUIC extensions defined to work with version 1 also work with version 2.
version of QUIC.  In particular, both the "h3" I-D.ietf-quic-http and "doq" I-D.ietf-dprive-dnsoquic ALPNs can operate over QUIC version 2. <del> All QUIC extensions defined to work with version 1 also work with version 2. </del> <ins> Unless otherwise stated, all QUIC extensions defined to work with version 1 also work with version 2. </ins> 8.
1. <del> QUIC QUIC has numerous extension points, including the version number that occupies the second through fifth bytes of every long header (see QUIC-INVARIANTS).  If experimental versions are rare, and QUIC version 1 constitutes the vast majority of QUIC traffic, there is the potential for middleboxes to ossify on the version bytes always being 0x00000001. </del> <ins> QUIC version 1QUIC has numerous extension points, including the version number that occupies the second through fifth bytes of every long header (see QUIC-INVARIANTS).  If experimental versions are rare, and QUIC version 1 constitutes the vast majority of QUIC traffic, there is the potential for middleboxes to ossify on the version bytes always being 0x00000001. </ins> In QUIC version 1, Initial packets are encrypted with the version- specific salt as described in QUIC-TLS.  Protecting Initial packets
and validate the version_information transport parameter specified in QUIC-VN to prevent version downgrade attacks. <del> Note that version 2 meets that document's definition of a compatible </del> <ins> Note that version 2 meets the QUIC-VN definition of a compatible </ins> version with version 1, and version 1 is compatible with version 2. Therefore, servers can use compatible negotiation to switch a connection between the two versions.  Endpoints that support both
If the server sends a Retry packet, it MUST use the original version. The client ignores Retry packets using other versions.  The client <del> MUST NOT use a different version in the subsequent Initial that contains the Retry token.  The server MAY encode the QUIC version in its Retry token to validate that the client did not switch versions, and drop the packet if it switched. </del> <ins> MUST NOT use a different version in the subsequent Initial packet that contains the Retry token.  The server MAY encode the QUIC version in its Retry token to validate that the client did not switch versions, and drop the packet if it switched. </ins> QUIC version 2 uses the same transport parameters to authenticate the Retry as QUIC version 1.  After switching to a negotiated version
3.1. <del> The Version field of long headers is 0x709a50c4.  This randomly chosen value is meant to avoid creating patterns in specified version numbers. </del> <ins> The Version field of long headers is 0x6b3343cf.  This was generated by taking the first four bytes of the sha256sum of "QUICv2 version number". </ins> This version number will not change in subsequent versions of this draft, unless there is a behavior change that breaks compatibility.
The key and nonce used for the Retry Integrity Tag (QUIC-TLS) change to: <ins> The secret is the sha256sum of "QUICv2 retry secret".  The key and nonce are derived from this secret with the labels "quicv2 key" and "quicv2 iv", respectively. </ins> 4. QUIC version 2 is not intended to deprecate version 1.  Endpoints
2.1.2. <ins> A dynamic table entry is considered blocking and cannot be evicted until its insertion has been acknowledged and there are no outstanding unacknowledged references to the entry.  In particular, a dynamic table entry that has never been referenced can still be blocking. A blocking entry is unrelated to a blocked stream, which is a stream that a decoder cannot decode as a result of references to entries that are not yet available.  Any encoder that uses the dynamic table has to keep track of blocked entries, whereas blocked streams are optional. </ins> An encoder MUST NOT insert an entry into the dynamic table (or <del> duplicate an existing entry) if doing so would evict an entry with unacknowledged references.  For header blocks that might rely on the newly added entry, the encoder can use a literal representation. </del> <ins> duplicate an existing entry) if doing so would evict a blocking entry.  In this case, the encoder can send literal representations of header fields. </ins> To ensure that the encoder is not prevented from adding new entries, the encoder can avoid referencing entries that are close to eviction.
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
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
Before a new entry is added to the dynamic table, entries are evicted from the end of the dynamic table until the size of the dynamic table is less than or equal to (table capacity - size of new entry) or <del> until the table is empty.  The encoder MUST NOT evict a dynamic table entry unless it has first been acknowledged by the decoder. </del> <ins> until the table is empty.  The encoder MUST NOT evict a blocking dynamic table entry (see blocked-insertion). </ins> If the size of the new entry is less than or equal to the dynamic table capacity, then that entry is added to the table.  It is an
connection error of type "HTTP_QPACK_ENCODER_STREAM_ERROR". Reducing the dynamic table capacity can cause entries to be evicted <del> (see eviction).  This MUST NOT cause the eviction of entries with outstanding references (see reference-tracking).  Changing the capacity of the dynamic table is not acknowledged as this instruction does not insert an entry. </del> <ins> (see eviction).  This MUST NOT cause the eviction of blocking entries (see blocked-insertion).  Changing the capacity of the dynamic table is not acknowledged as this instruction does not insert an entry. </ins> 4.4.
acknowledgement is received that establishes loss or delivery of packets. <del> When an ACK frame is received that establishes loss after a threshold number of consecutive PTOs (pto_count is more than kPersistentCongestionThreshold, see cc-consts-of-interest), the network is considered to be experiencing persistent congestion, and the sender's congestion window MUST be reduced to the minimum congestion window (kMinimumWindow).  This response of collapsing the congestion window on persistent congestion is functionally similar to a sender's response on a Retransmission Timeout (RTO) in TCP RFC5681. </del> <ins> When an ACK frame is received that establishes loss of all in-flight packets sent prior to a threshold number of consecutive PTOs (pto_count is more than kPersistentCongestionThreshold, see cc- consts-of-interest), the network is considered to be experiencing persistent congestion, and the sender's congestion window MUST be reduced to the minimum congestion window (kMinimumWindow).  This response of collapsing the congestion window on persistent congestion is functionally similar to a sender's response on a Retransmission Timeout (RTO) in TCP RFC5681. </ins> 7.6.
A server MAY send Retry packets in response to Initial and 0-RTT packets.  A server can either discard or buffer 0-RTT packets that it receives.  A server can send multiple Retry packets as it receives <del> Initial or 0-RTT packets. </del> <ins> Initial or 0-RTT packets.  A server MUST NOT send more than one Retry packet in response to a single UDP datagram. </ins> A client MUST accept and process at most one Retry packet for each connection attempt.  After the client has received and processed an
4. <del> As discussed above, frames are carried on QUIC streams and used on control streams, request streams, and push streams.  This section describes HTTP framing in QUIC.  For a comparison with HTTP/2 frames, see h2-frames. </del> <ins> HTTP frames are carried on QUIC streams, as described in stream- mapping.  HTTP/3 defines three stream types: control stream, request stream, and push stream.  This section describes HTTP/3 frame formats and the streams types on which they are permitted; see stream-frame- mapping for an overiew.  A comparison between HTTP/2 and HTTP/3 frames is provided in h2-frames. </ins> 4.1.
can be mounted using spoofed source addresses.  In determining this limit, servers only count the size of successfully processed packets. <del> Clients MUST pad UDP datagrams that contain only Initial packets to at least 1200 bytes.  Once a client has received an acknowledgment </del> <ins> Clients MUST ensure that UDP datagrams containing Initial packets are sized to at least 1200 bytes, adding padding to packets in the datagram as necessary.  Once a client has received an acknowledgment </ins> for a Handshake packet it MAY send smaller datagrams.  Sending padded datagrams ensures that the server is not overly constrained by the amplification restriction.
for responses in request-response.  Due to reordering, data on a push stream can arrive before the corresponding PUSH_PROMISE, in which case both the associated client request and the pushed request <del> headers are unknown.  Clients which receive a new push stream with an </del> <ins> headers are unknown.  Clients that receive a new push stream with an </ins> as-yet-unknown Push ID can buffer the stream data in expectation of the matching PUSH_PROMISE.  A client can use stream flow control (see section 4.1 of QUIC-TRANSPORT) to limit the amount of data a server
The final size is the amount of flow control credit that is consumed by a stream.  Assuming that every contiguous byte on the stream was sent once, the final size is the number of bytes sent.  More <del> generally, this is one higher than the largest byte offset sent on the stream. </del> <ins> generally, this is one higher than the offset of the byte with the largest offset sent on the stream, or zero if no bytes were sent. </ins> For a stream that is reset, the final size is carried explicitly in a RESET_STREAM frame.  Otherwise, the final size is the offset plus the
Endpoints MUST NOT send this extension in a TLS connection that does not use QUIC (such as the use of TLS with TCP defined in TLS13).  A <del> fatal unsupported_extension alert MUST be sent if this extension is received when the transport is not QUIC. </del> <ins> fatal unsupported_extension alert MUST be sent by an implementation that supports this extension if the extension is received when the transport is not QUIC. </ins> 8.3.
maximum value for a Push ID that the server can use in a PUSH_PROMISE frame.  Consequently, this also limits the number of push streams that the server can initiate in addition to the limit set by the QUIC <del> MAX_STREAM_ID frame. </del> <ins> MAX_STREAMS frame. </ins> The MAX_PUSH_ID frame is always sent on the control stream.  Receipt of a MAX_PUSH_ID frame on any other stream MUST be treated as a
permitted; receipt of a second stream which claims to be a control stream MUST be treated as a connection error of type HTTP_WRONG_STREAM_COUNT.  The sender MUST NOT close the control <del> stream.  If the control stream is closed at any point, this MUST be treated as a connection error of type HTTP_CLOSED_CRITICAL_STREAM. </del> <ins> stream, and the receiver MUST NOT request that the sender close the control stream.  If either control stream is closed at any point, this MUST be treated as a connection error of type HTTP_CLOSED_CRITICAL_STREAM. </ins> A pair of unidirectional streams is used rather than a single bidirectional stream.  This allows either peer to send data as soon
The DUPLICATE_PUSH frame carries a single variable-length integer that identifies the Push ID of a resource that the server has <del> previously promised (see frame-push-promise). </del> <ins> previously promised (see frame-push-promise), though that promise might not be received before this frame.  A server MUST NOT use a Push ID that is larger than the client has provided in a MAX_PUSH_ID frame (frame-max-push-id).  A client MUST treat receipt of a DUPLICATE_PUSH that contains a larger Push ID than the client has advertised as a connection error of type HTTP_MALFORMED_FRAME. </ins> This frame allows the server to use the same server push in response to multiple concurrent requests.  Referencing the same server push
A TCP connection error is signaled with QUIC RESET_STREAM frame.  A proxy treats any error in the TCP connection, which includes receiving a TCP segment with the RST bit set, as a stream error of <del> type HTTP_CONNECT_ERROR (http-error-codes).  Correspondingly, a proxy MUST send a TCP segment with the RST bit set if it detects an error with the stream or the QUIC connection. </del> <ins> type HTTP_CONNECT_ERROR (http-error-codes).  Correspondingly, if a proxy detects an error with the stream or the QUIC connection, it MUST close the TCP connection.  If the underlying TCP implementation permits it, the proxy SHOULD send a TCP segment with the RST bit set. </ins> 4.3.
HTTP/3 endpoint is authoritative for other origins without an explicit signal. <ins> Prior to making requests for an origin whose scheme is not "https," the client MUST ensure the server is willing to serve that scheme. If the client intends to make requests for an origin whose scheme is "http", this means that it MUST obtain a valid "http-opportunistic" response for the origin as described in RFC8164 prior to making any such requests.  Other schemes might define other mechanisms. </ins> A server that does not wish clients to reuse connections for a particular origin can indicate that it is not authoritative for a request by sending a 421 (Misdirected Request) status code in