jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: rfc9204

Commentary: These track corrections I 've asked the RFC Editor to make directly in their copy prior to publication . It appears that some http - core sections moved since the last time we did a full sweep of our references .
Paragraph (version A):
The QUIC transport protocol (QUIC-TRANSPORT) is designed to support
HTTP semantics, and its design subsumes many of the features of
HTTP/2 (RFC7540).  HTTP/2 uses HPACK (RFC7541) for compression of the
header and trailer sections.  If HPACK were used for HTTP/3 (HTTP3),
it would induce head-of-line blocking for field sections due to
built-in assumptions of a total ordering across frames on all
streams.
Paragraph (version B):
The QUIC transport protocol (QUIC-TRANSPORT) is designed to support
HTTP semantics, and its design subsumes many of the features of
HTTP/2 (RFC9113).  HTTP/2 uses HPACK (RFC7541) for compression of the
header and trailer sections.  If HPACK were used for HTTP/3
(RFC9114), it would induce head-of-line blocking for field sections
due to built-in assumptions of a total ordering across frames on all
streams.
Paragraph (version A):
A name-value pair sent as part of an HTTP field section.  See
Sections 6.3 and 6.5 of SEMANTICS.
Paragraph (version B):
A name-value pair sent as part of an HTTP field section.  See
Sections 6.3 and 6.5 of RFC9110.
Paragraph (version A):
This document makes multiple registrations in the registries defined
by HTTP3.  The allocations created by this document are all assigned
permanent status and list a change controller of the IETF and a
contact of the HTTP working group (ietf-http-wg@w3.org).
Paragraph (version A):
This document specifies two settings.  The entries in the following
table are registered in the "HTTP/3 Settings" registry established in
HTTP3.
Paragraph (version B):
This document makes multiple registrations in the registries defined
by RFC9114.  The allocations created by this document are all
assigned permanent status and list a change controller of the IETF
and a contact of the HTTP working group (ietf-http-wg@w3.org).
Paragraph (version B):
This document specifies two settings.  The entries in the following
table are registered in the "HTTP/3 Settings" registry established in
RFC9114.
Paragraph (version A):
This document specifies two stream types.  The entries in the
following table are registered in the "HTTP/3 Stream Types" registry
established in HTTP3.
Paragraph (version B):
This document specifies two stream types.  The entries in the
following table are registered in the "HTTP/3 Stream Types" registry
established in RFC9114.
Draft: rfc9204

Commentary: Inspired by suggestion ; 
 Is " to the encoder " intended ? Should this be " within the encoder " or might " contain " be made " limit " or something else ? Original : QPACK is designed to contain the more complex state tracking to the encoder , while the decoder is relatively simple . 
 " Limit " is probably the closest if we want to keep the phrase as - is . Writing something   might be better , but I 'm having trouble coming up with anything pithy . 
 Some alternatives ( aka throwing mud at the wall ) " The design of QPACK requires an encoder to implement relatively more - complex state tracking than a decoder . " " QPACK 's design requires state tracking in various degrees of complexity . In relative terms , encoders have complex requirements , while decoders are more simple . " QPACK is designed to put the state tracking complexity onus on encoders , resulting in relatively simple decoders . " 
 I like the third one . 
 Fixed in with a variant of the third option . 
 LGTM
Paragraph (version A):
QPACK is designed to contain the more complex state tracking to the
encoder, while the decoder is relatively simple.
Paragraph (version B):
QPACK is designed to place the burden of optional state tracking on
the encoder, resulting in relatively simple decoders.
Draft: rfc9204

Commentary: builds on . 
 stream type MUST be treated as a connection error of type H3CLOSEDCRITICALSTREAM . I 'd like to clarify that whether this effectively says that receiver is not allowed to send STOPSENDING . STOPSENDING is elicit RESETSTREAM that closes a stream . MUST send a RESETSTREAM frame if the stream is in the " Ready " or " Send " state . STOPSENDING itself does not close a stream , but it is an action to request a closure . I found in interop runner test , one implementation sends STOPSENDING to QPACK streams . My implementation sends RESET_STREAM when it is received as mandated by spec , and upon stream closure , the connection is closed because QPACK streams are closed , then the test fails . HTTP draft explicitly says that requesting closure for the control stream is prohibited : request that the sender close the control stream . It would be nice to add the similar statement to QPACK streams . 
 It 's super - late in the process , but maybe the editors can see a way to squeeze an editorial change in . 
 Thanks  . I agree , IMO the intention was always for consistent treatment of open control streams and open qpack streams when it comes to not closing them . Finding a way to address this during AUTH48 would be nice . 
 I agree , this was the intention -- closing the stream is treated as an error , and being asked to commit an error is itself an error . One could squint and say it 's covered by the existing text -- upon receipt of the STOP_SENDING , the send is required to close the stream ; closure of the stream is already required to be treated as an error . It 's technically a normative change , but there 's no effective change in behavior . 
 If it 's a normative change , is it still OK to change in auth48 just with a WG consensus call or is more process required ? 
 The AD has to decide what to do and approve this change to the RFC editor . 
 Since the fix includes a gentle normative change , marking this as a design issue and we 'll put out a consensus call to the list . 
  was declared , so was merged .
Paragraph (version A):
These streams MUST NOT be closed.  Closure of either unidirectional
stream type MUST be treated as a connection error of type
H3_CLOSED_CRITICAL_STREAM.
Paragraph (version B):
The sender MUST NOT close either of these streams, and the receiver
MUST NOT request that the sender close either of these streams.
Closure of either unidirectional stream type MUST be treated as a
connection error of type H3_CLOSED_CRITICAL_STREAM.
Draft: rfc9114

Commentary: was helpful enough to show me how to do this in , so now singular and plural versions of the same term are a single index entry .
Paragraph (version A):
Two stream types are defined in this document: control streams
(control-streams) and (push-streams).  RFC9204 defines two additional
stream types.  Other stream types can be defined by extensions to
HTTP/3; see extensions for more details.  Some stream types are
reserved (stream-grease).
Paragraph (version B):
Two stream types are defined in this document: (control-streams) and
(push-streams).  RFC9204 defines two additional stream types.  Other
stream types can be defined by extensions to HTTP/3; see extensions
for more details.  Some stream types are reserved (stream-grease).
Paragraph (version A):
If an entire connection needs to be terminated, QUIC similarly
provides mechanisms to communicate a reason; see QUIC-TRANSPORT.
This is referred to as a "".  Similar to stream errors, an HTTP/3
implementation can terminate a QUIC connection and communicate the
reason using an error code from http-error-codes.
Paragraph (version B):
If an entire connection needs to be terminated, QUIC similarly
provides mechanisms to communicate a reason; see QUIC-TRANSPORT.
This is referred to as a "".  Similar to , an HTTP/3 implementation
can terminate a QUIC connection and communicate the reason using an
error code from http-error-codes.
Draft: rfc9114

Commentary: which also occurs in H3 but apparently was n't caught . 
 Throughout , the document uses " SETTINGS " as the first part of thte HTTP/3 setting names . We have updated this sentence for consistency . Please let us know if any corrections are needed . Original : For fomatting reasons , the setting names here are abbreviated by removing the ' SETTING ' prefix . Current : For formatting reasons , the setting names here are abbreviated by removing the ' SETTINGS _ ' prefix . 
 Fixed in .
Paragraph (version A):
For fomatting reasons, setting names can be abbreviated by removing
the 'SETTING_' prefix.
Paragraph (version B):
For formatting reasons, setting names can be abbreviated by removing
the 'SETTINGS_' prefix.
Draft: rfc9114

Commentary: I believe I wound up lower - casing all instances of " stream ID " outside of diagrams since H3 has no reason to talk directly about the payloads of QUIC frames . The H3 frames mostly talk about the stream ID being encoded in the packet without giving the field a name per se . For  ID , there are some direct references to the field , so I left a few capitalized instances -- primarily in PUSH_PROMISE and a few in GOAWAY . I would appreciate a review of the ones I did n't change , in case anyone things I should lower - case them as well . 
 Multiple related points ( split slightly differently from how the RFC  did it ): In general , the intent is to use " stream ID " or " frame payload " ( lowercase ) to refer to the identifier or payload itself , but " Stream ID " or " Frame Payload " ( capitalized ) to refer to the name of a field in a frame which carries an identifier or payload . ( Field names are intended to be capitalized in all cases . ) I will review instances of these terms to double - check whether that convention is used correctly throughout . " Push ID " is deliberately capital , but by parallel with similar terms , it should probably be lowercase except when referring to the actual field . 
  ID -push ID suggestion works for me 
 Yep , as  says : Concept : push ID Field :  ID 
 Fixed in .
Paragraph (version A):
A client SHOULD NOT abort reading on a push stream prior to reading
the Push ID, as this could lead to disagreement between client and
server on which Push IDs have already been consumed.
Paragraph (version B):
A client SHOULD NOT abort reading on a push stream prior to reading
the push stream header, as this could lead to disagreement between
client and server on which push IDs have already been consumed.
Paragraph (version A):
The CANCEL_PUSH frame carries a Push ID encoded as a variable-length
integer.  The Push ID identifies the server push that is being
cancelled; see server-push.  If a CANCEL_PUSH frame is received that
references a Push ID greater than currently allowed on the
connection, this MUST be treated as a connection error of type
H3_ID_ERROR.
Paragraph (version B):
The CANCEL_PUSH frame carries a push ID encoded as a variable-length
integer.  The Push ID field identifies the server push that is being
cancelled; see server-push.  If a CANCEL_PUSH frame is received that
references a push ID greater than currently allowed on the
connection, this MUST be treated as a connection error of type
H3_ID_ERROR.
Draft: rfc9114

Commentary: The RFC Editor asks : 
 Along the way , there are two equivalent statements that need to be deduplicated that this change touches : I would suggest collapsing these two into the first statement , but using OPTIONS as an example and keeping the reference into http - core . Or perhaps that should be a question -- is there a difference between asterisk - form and OPTIONS - without - path ? 
 Resolved in .
Paragraph (version A):
To allow for better compression efficiency, the "Cookie" field
(RFC6265) MAY be split into separate field lines, each with one or
more cookie-pairs, before compression.  If a decompressed field
section contains multiple cookie field lines, these MUST be
concatenated into a single byte string using the two-byte delimiter
of 0x3b, 0x20 (the ASCII string "; ") before being passed into a
context other than HTTP/2 or HTTP/3, such as an HTTP/1.1 connection,
or a generic HTTP server application.
Paragraph (version B):
To allow for better compression efficiency, the "Cookie" field
(RFC6265) MAY be split into separate field lines, each with one or
more cookie-pairs, before compression.  If a decompressed field
section contains multiple cookie field lines, these MUST be
concatenated into a single byte string using the two-byte delimiter
of "; " (ASCII 0x3b, 0x20) before being passed into a context other
than HTTP/2 or HTTP/3, such as an HTTP/1.1 connection, or a generic
HTTP server application.
Paragraph (version A):
Like HTTP/2, HTTP/3 employs a series of pseudo-header fields, where
the field name begins with the ':' character (ASCII 0x3a).  These
pseudo-header fields convey message control data; see HTTP.
Paragraph (version B):
Like HTTP/2, HTTP/3 employs a series of pseudo-header fields, where
the field name begins with the ":" character (ASCII 0x3a).  These
pseudo-header fields convey message control data; see HTTP.
Paragraph (version A):
Similarly, HTTP/3 can transport field values that are not valid.
While most values that can be encoded will not alter field parsing,
carriage return (CR, ASCII 0x0d), line feed (LF, ASCII 0x0a), and the
zero character (NUL, ASCII 0x00) might be exploited by an attacker if
they are translated verbatim.  Any request or response that contains
a character not permitted in a field value MUST be treated as
malformed (malformed).  Valid characters are defined by the "field-
content" ABNF rule in HTTP.
Paragraph (version B):
Similarly, HTTP/3 can transport field values that are not valid.
While most values that can be encoded will not alter field parsing,
carriage return (ASCII 0x0d), line feed (ASCII 0x0a), and the null
character (ASCII 0x00) might be exploited by an attacker if they are
translated verbatim.  Any request or response that contains a
character not permitted in a field value MUST be treated as malformed
(malformed).  Valid characters are defined by the "field-content"
ABNF rule in HTTP.
Draft: rfc9114

Commentary: This looks great to me . 
 that 's a good point . Let me reword it to use the operation terms rather than the v1 frame names . 
 From ... : be improved in h3 . Not the TCP RST part , but the bit that leads up to it . Otherwise , we might not get the right behaviour . If the proxy just closes the connection in response to RESETSTREAM , it might then just end the stream ( with a FIN bit ) , which would be wrong . Perhaps instead : Somewhat substantive , unfortunately , and very , very , very late . I 'm happy to wait and file an erratum . 
 This seems like a solid improvement , but it 's definitely not editorial . and will need to decide whether this is a change they 're willing to accept post - IESG . 
 Endpoints that overlook the proposed behaviour risk zombie streams . This seems like something worth addressing while we have the opportunity . Can one of you please file create a PR and we 'll take it to the AD . 
 Closed in . 
 Better than my text :) This looks ready to go , are we merging it soon ?
Paragraph (version A):
A TCP connection error is signaled by abruptly terminating the
stream.  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 type H3_CONNECT_ERROR; see errors.  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.
Paragraph (version B):
A TCP connection error is signaled by abruptly terminating the
stream.  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 type H3_CONNECT_ERROR; see errors.
Paragraph (version B):
Correspondingly, if a proxy detects an error with the stream or the
QUIC connection, it MUST close the TCP connection.  If the proxy
detects that the client has reset the stream or aborted reading from
the stream, it MUST close the TCP connection.  If the stream is reset
or reading is aborted by the client, a proxy SHOULD perform the same
operation on the other direction in order to ensure that both
directions of the stream are cancelled.  In all these cases, if the
underlying TCP implementation permits it, the proxy SHOULD send a TCP
segment with the RST bit set.
Draft: rfc9114

Commentary: sorted in reverse orderGood catch !
Paragraph (version A):
Similarly, HTTP/3 can transport field values that are not valid.
While most values that can be encoded will not alter field parsing,
carriage return (CR, ASCII 0x0d), line feed (LF, ASCII 0x0d), and the
zero character (NUL, ASCII 0x0d) might be exploited by an attacker if
they are translated verbatim.  Any request or response that contains
a character not permitted in a field value MUST be treated as
malformed (malformed).  Valid characters are defined by the "field-
content" ABNF rule in Section 5.5 of HTTP.
Paragraph (version B):
Similarly, HTTP/3 can transport field values that are not valid.
While most values that can be encoded will not alter field parsing,
carriage return (CR, ASCII 0x0d), line feed (LF, ASCII 0x0a), and the
zero character (NUL, ASCII 0x00) might be exploited by an attacker if
they are translated verbatim.  Any request or response that contains
a character not permitted in a field value MUST be treated as
malformed (malformed).  Valid characters are defined by the "field-
content" ABNF rule in Section 5.5 of HTTP.
Draft: rfc9114

Commentary: Noticed in that we 're pointing to different sections : 6.1 is the Transfer - Encoding header 7.1 is specifically 7 is transfer codings in general Since this passage is referring to the concept in general not being present in HTTP/3 , Section 7 is the correct reference .
Paragraph (version A):
Transfer codings (see Section 6.1 of HTTP11) are not defined for
HTTP/3; the Transfer-Encoding header field MUST NOT be used.
Paragraph (version B):
Transfer codings (see Section 7 of HTTP11) are not defined for
HTTP/3; the Transfer-Encoding header field MUST NOT be used.
Draft: draft-ietf-quic-qpack

Commentary: The repeated " when " clauses in this sentence make it difficult to parse . If our suggestion does not correctly capture your intent , could you please rephrase ? Original : A stream becomes unblocked when the  Count becomes unblocked when the  Count becomes greater than or equal to the Required Insert Count for all encoded field sections the decoder has started reading from the stream . Perhaps : A stream becomes unblocked when the  Count becomes unblocked . When the  Count becomes greater than or equal to the Required Insert Count for all encoded field sections , the decoder has started reading from the stream . 
 It actually looks as though the words " becomes unblocked when the  Count " are duplicated , which would make the corrected text : That might still be confusing , but the proposed text certainly is n't the right change . The key point to capture is : The decoder has started reading at least one encoded field section from the stream and encountered a Required Insert Count value in some or all of them which exceeds its current   . This caused the stream to be considered blocked . When the  Count is greater than or equal to the RIC value from all of the encoded field sections the decoder has attempted to process , the stream becomes unblocked . 
 Fixed in . 
 Good catch .
Paragraph (version A):
While blocked, encoded field section data SHOULD remain in the
blocked stream's flow control window.  This data is unusable until
the stream becomes unblocked, and releasing the flow control
prematurely makes the decoder vulnerable to memory exhaustion
attacks.  A stream becomes unblocked when the Insert Count becomes
unblocked when the Insert Count becomes greater than or equal to the
Required Insert Count for all encoded field sections the decoder has
started reading from the stream.
Paragraph (version B):
While blocked, encoded field section data SHOULD remain in the
blocked stream's flow control window.  This data is unusable until
the stream becomes unblocked, and releasing the flow control
prematurely makes the decoder vulnerable to memory exhaustion
attacks.  A stream becomes unblocked when the Insert Count becomes
greater than or equal to the Required Insert Count for all encoded
field sections the decoder has started reading from the stream.
Draft: rfc9002

Commentary: You made one pass and I made two and we still missed some lol
Paragraph (version A):
A Retry packet causes a client to send another Initial packet,
effectively restarting the connection process.  A Retry packet
indicates that the Initial packet was received but not processed.  A
Retry packet cannot be treated as an acknowledgment, because it does
not indicate that a packet was processed or specify the packet
number.
Paragraph (version B):
A Retry packet causes a client to send another Initial packet,
effectively restarting the connection process.  A Retry packet
indicates that the Initial packet was received but not processed.  A
Retry packet cannot be treated as an acknowledgment because it does
not indicate that a packet was processed or specify the packet
number.
Draft: rfc9000

Commentary: Do you need to rebase ? There 's a change that seems to have been repeated in a previously merged PR .
Paragraph (version A):
An on-path attacker can prevent use of a path for a connection,
causing the connection to fail if it cannot use a different path
that does not contain the attacker.  This can be achieved by
dropping all packets, modifying them so that they fail to decrypt,
or other methods.
Paragraph (version B):
An on-path attacker can prevent the use of a path for a
connection, causing the connection to fail if it cannot use a
different path that does not contain the attacker.  This can be
achieved by dropping all packets, modifying them so that they fail
to decrypt, or other methods.
Draft: rfc9000

Commentary: The rest is wrapping , as just said .
Paragraph (version A):
From any state that is one of"Ready", "Send", or "Data Sent", an
application can signal that it wishes to abandon transmission of
stream data.  Alternatively, an endpoint might receive a STOP_SENDING
frame from its peer.  In either case, the endpoint sends a
RESET_STREAM frame, which causes the stream to enter the "Reset Sent"
state.
Paragraph (version B):
From any state that is one of "Ready", "Send", or "Data Sent", an
application can signal that it wishes to abandon transmission of
stream data.  Alternatively, an endpoint might receive a STOP_SENDING
frame from its peer.  In either case, the endpoint sends a
RESET_STREAM frame, which causes the stream to enter the "Reset Sent"
state.
Draft: rfc8999

Commentary: The names are capitalized , but we do n't say " the ... field . " We probably should .
Paragraph (version A):
An endpoint MUST include the value from the Source Connection ID
field of the packet it receives in the Destination Connection ID
field.  The value for Source Connection ID MUST be copied from the
Destination Connection ID of the received packet, which is initially
randomly selected by a client.  Echoing both connection IDs gives
clients some assurance that the server received the packet and that
the Version Negotiation packet was not generated by an attacker that
is unable to observe packets.
Paragraph (version B):
An endpoint MUST include the value from the Source Connection ID
field of the packet it receives in the Destination Connection ID
field.  The value for the Source Connection ID field MUST be copied
from the Destination Connection ID field of the received packet,
which is initially randomly selected by a client.  Echoing both
connection IDs gives clients some assurance that the server received
the packet and that the Version Negotiation packet was not generated
by an attacker that is unable to observe packets.