jiebi/TextFlow huggingface dataset:
Original text:
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119.  2. This document recommends a two-step process for accessing resources

Reviewer comments:
mention the syntax update the reference type the citations consistently
1) It should be RFC 5234, not RFC 4234 2) If it's there, it should actually be mentioned somewhere in the spec.

Revised text:
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. <ins> 1.2. This document cites productions in Augmented Backus-Naur Form (ABNF) productions from RFC7233, using the notation defined in RFC5234. </ins> 2. This document recommends a two-step process for accessing resources
Original text:
It is RECOMMENDED that origin servers allow resources to explicitly configure whether early data is appropriate in requests.  Absent such <del> explicit information, they SHOULD mitigate against early data in requests that have unsafe methods, using the techniques outlined above. </del>  A request might be sent partially in early data with the remainder of the request being sent after the handshake completes.  This does not

Reviewer comments:
This makes mitigation mandatory. Either receive a signal that early data is safe for the given resource, or apply the mitigations. That's consistent with the other text.
LGTM

Revised text:
It is RECOMMENDED that origin servers allow resources to explicitly configure whether early data is appropriate in requests.  Absent such  <ins> explicit information, origin servers MUST either reject early data or implement the techniques described in this document for ensuring that requests are not processed prior to TLS handshake completion. </ins> A request might be sent partially in early data with the remainder of the request being sent after the handshake completes.  This does not
Original text:
The "Early-Data" header field is included in requests that might have been forwarded by an intermediary prior to the TLS handshake <del> completing. </del>  The 425 (Too Early) status code is defined for a server to indicate that a request could not be processed due to the

Reviewer comments:
I think that these are the main places where we weren't clear enough about the relevant TLS role.
LGTM

Revised text:
The "Early-Data" header field is included in requests that might have been forwarded by an intermediary prior to the TLS handshake  <ins> with its client completing. </ins> The 425 (Too Early) status code is defined for a server to indicate that a request could not be processed due to the
Original text:
For example: An intermediary that forwards a request prior to the completion of <del> the TLS handshake MUST send it with the "Early-Data" header field set to "1" (i.e., it adds it if not present in the request).  An intermediary MUST use the "Early-Data" header field if it might have forwarded the request prior to handshake completion (see be- consistent for details). </del>  An intermediary MUST NOT remove this header field if it is present in a request.

Reviewer comments:
I think that these are the main places where we weren't clear enough about the relevant TLS role.
LGTM

Revised text:
For example: An intermediary that forwards a request prior to the completion of  <ins> the TLS handshake with its client MUST send it with the "Early-Data" header field set to "1" (i.e., it adds it if not present in the request).  An intermediary MUST use the "Early-Data" header field if it might have forwarded the request prior to handshake completion (see be-consistent for details). </ins> An intermediary MUST NOT remove this header field if it is present in a request.
Original text:
Abstract <del> This document explains the risks of using early data for HTTP and describes techniques for reducing them.  In particular, it defines a mechanism that enables clients to communicate with servers about early data, to assure correct operation. </del>  1.

Reviewer comments:
John Mattsson pointed out that we didn't really discuss the risks of use of early data. That's fair, but we don't need to. This rewrites the abstract.
Just one fix : s/mechanisms that allows/mechanisms that allow/ Nice overall.

Revised text:
Abstract  <ins> Using TLS early data creates an exposure to the possibility of a replay attack.  This document defines mechanisms that allow clients to communicate with servers about HTTP requests that are sent in early data.  Techniques are described that use these mechanisms to mitigate the risk of replay. </ins> 1.
Original text:
If the server receives multiple requests in early data, it can determine whether to defer HTTP processing on a per-request basis. <del> This may require buffering the responses to preserve ordering in HTTP/1.1. </del> The server can cause a client to retry a request and not use early data by responding with the 425 (Too Early) status code (status),

Reviewer comments:
Hopefully none of this collides with other PRs in flight.
I think it's fine with this. Adding a bit of pragmatism as you did in the last commit also reminds that the low cost of retrying is not worth a lot of trouble :-)

Revised text:
If the server receives multiple requests in early data, it can determine whether to defer HTTP processing on a per-request basis.  The server can cause a client to retry a request and not use early data by responding with the 425 (Too Early) status code (status),
Original text:
If the server rejects early data at the TLS layer, a client MUST start sending again as though the connection was new.  This could entail using a different negotiated protocol ALPN than the one <del> optimistically used for the early data.  If HTTP/2 is selected after early data is rejected, a client sends another connection preface. Any requests sent in early data MUST be sent again, unless the client decides to abandon those requests. </del>  This automatic retry exposes the request to a potential replay attack.  An attacker sends early data to one server instance that

Reviewer comments:
Hopefully none of this collides with other PRs in flight.
I think it's fine with this. Adding a bit of pragmatism as you did in the last commit also reminds that the low cost of retrying is not worth a lot of trouble :-)

Revised text:
If the server rejects early data at the TLS layer, a client MUST start sending again as though the connection was new.  This could entail using a different negotiated protocol ALPN than the one  <ins> optimistically used for the early data.  Any requests sent in early data MUST be sent again, unless the client decides to abandon those requests. </ins> This automatic retry exposes the request to a potential replay attack.  An attacker sends early data to one server instance that
Original text:
A gateway that forwards requests that were received in early data MUST only do so if it knows that the origin server that receives those requests understands the "Early-Data" header field and will <del> correctly generate a 425 (Too Early) status code.  A gateway that isn't certain about origin server support SHOULD either delay forwarding the request until the TLS handshake with its client completes, or send a 425 (Too Early) status code in response.  A gateway that is uncertain about whether an origin server supports the "Early-Data" header field SHOULD disable early data. </del>  6.2.

Reviewer comments:
Hopefully none of this collides with other PRs in flight.
I think it's fine with this. Adding a bit of pragmatism as you did in the last commit also reminds that the low cost of retrying is not worth a lot of trouble :-)

Revised text:
A gateway that forwards requests that were received in early data MUST only do so if it knows that the origin server that receives those requests understands the "Early-Data" header field and will  <ins> correctly generate a 425 (Too Early) status code.  A gateway that is uncertain about origin server support for a given request SHOULD either delay forwarding the request until the TLS handshake with its client completes, or send a 425 (Too Early) status code in response. A gateway without at least one potential origin server that supports "Early-Data" header field expends significant effort for what can at best be a modest performance benefit from enabling early data.  If no origin server supports early data, disabling early data entirely is more efficient. </ins> 6.2.
Original text:
gateways) need to agree and either reject the request or delay processing.  A server MUST NOT act on early data before the handshake completes if it and any other server instance could make a different decision about how to handle the same data.

Reviewer comments:
Thanks NAME and NAME for pushing on this.
I think this is good and can even emphasize how to consistently disable 0-RTT across a cluster for any reason then consistently re-enable it.

Revised text:
gateways) need to agree and either reject the request or delay processing. <ins> Disabling early data, delaying requests, or rejecting requests with the 425 (Too Early) status code are all equally good measures for mitigating replay attacks on requests that might be vulnerable to replay.  Server instances can implement any of these measures and be considered to be consistent, even if different instances use different methods.  Critically, this means that it is possible to employ different mitigations in reaction to other conditions, such as server load. </ins> A server MUST NOT act on early data before the handshake completes if it and any other server instance could make a different decision about how to handle the same data.
Original text:
6.4. In protocols that deliver data out of order (such as QUIC HQ) early <del> data can arrive after the handshake completes.  This leads to potential ambiguity about the status of requests and could lead to inconsistent treatment (see be-consistent).  Implementations MUST either ensure that any early data that is delivered late is either discarded or consistently identified and processed. </del>  7.

Reviewer comments:
Thanks NAME and NAME for pushing on this.
I think this is good and can even emphasize how to consistently disable 0-RTT across a cluster for any reason then consistently re-enable it.

Revised text:
6.4. In protocols that deliver data out of order (such as QUIC HQ) early  <ins> data can arrive after the handshake completes.  A server MAY process requests received in early data after handshake completion if it can rely on other instances correctly handling replays of the same requests. </ins> 7.
Original text:
that have indeterminate length representations. Two steps are necessary because of limitations with the Range request <del> header and the Content-Range response header fields.  A server cannot know from a range request that a client wishes to receive a response that does not have a definite end.  More critically, the header fields do not allow the server to signal that a resource has </del>  indeterminate length without also providing a fixed portion of the resource.

Reviewer comments:
Note this was manually incorporated into draft-ietf-httpbis-rand-access-live-03

Revised text:
that have indeterminate length representations. Two steps are necessary because of limitations with the Range request  <ins> header fields and the Content-Range response header fields.  A server cannot know from a range request that a client wishes to receive a response that does not have a definite end.  More critically, the header fields do not allow the server to signal that a resource has </ins> indeterminate length without also providing a fixed portion of the resource.
Original text:
and leave last-byte-pos absent.  A server that receives a satisfiable byte-range request (with first-byte-pos smaller than the current representation length) may respond with a 206 status code (Partial <del> Content) with a Content-Range header indicating the currently </del>  satisfiable byte range.  For example: returns a response of the form:

Reviewer comments:
Note this was manually incorporated into draft-ietf-httpbis-rand-access-live-03

Revised text:
and leave last-byte-pos absent.  A server that receives a satisfiable byte-range request (with first-byte-pos smaller than the current representation length) may respond with a 206 status code (Partial  <ins> Content) with a Content-Range header field indicating the currently </ins> satisfiable byte range.  For example: returns a response of the form:
Original text:
a live video stream. Unlike a byte-range Range request, a byte-range Content-Range <del> response header cannot be "open ended", per RFC7233: </del>  Specifically, last-byte-pos is required in byte-range.  So in order to preserve interoperability with existing HTTP clients, servers,

Reviewer comments:
Note this was manually incorporated into draft-ietf-httpbis-rand-access-live-03

Revised text:
a live video stream. Unlike a byte-range Range request, a byte-range Content-Range  <ins> response header field cannot be "open ended", per RFC7233: </ins> Specifically, last-byte-pos is required in byte-range.  So in order to preserve interoperability with existing HTTP clients, servers,
Original text:
In response, a server may indicate that it is supplying a continuously aggregating ("live") response by supplying the client <del> request's last-byte-pos in the Content-Range response header. </del>  For example:

Reviewer comments:
Note this was manually incorporated into draft-ietf-httpbis-rand-access-live-03

Revised text:
In response, a server may indicate that it is supplying a continuously aggregating ("live") response by supplying the client  <ins> request's last-byte-pos in the Content-Range response header field. </ins> For example:
Original text:
A server that does return a continuously aggregating ("live") response should return data using chunked transfer coding and not <del> provide a Content-Length header.  A 0-length chunk indicates the end of the transfer, per RFC7230. </del>  3.

Reviewer comments:
Note this was manually incorporated into draft-ietf-httpbis-rand-access-live-03

Revised text:
A server that does return a continuously aggregating ("live") response should return data using chunked transfer coding and not  <ins> provide a Content-Length header field.  A 0-length chunk indicates the end of the transfer, per RFC7230. </ins> 3.
Original text:
learn what range the server has currently available and initiate an indeterminate-length transfer.  For example: <del> With the Content-Range response header indicating the (or ranges) available.  For example: </del>  The client can then issue a request for a range starting at the end value (using a very large value for the end of a range) and receive

Reviewer comments:
Note this was manually incorporated into draft-ietf-httpbis-rand-access-live-03

Revised text:
learn what range the server has currently available and initiate an indeterminate-length transfer.  For example:  <ins> With the Content-Range response header field indicating the (or ranges) available.  For example: </ins> The client can then issue a request for a range starting at the end value (using a very large value for the end of a range) and receive
Original text:
learn what range the server has currently available and initiate an indeterminate-length transfer.  For example: <del> With the Content-Range response header field indicating the (or </del>  ranges) available.  For example: The client can then issue a request for a range starting at the end

Reviewer comments:
Note this was manually incorporated into draft-ietf-httpbis-rand-access-live-03

Revised text:
learn what range the server has currently available and initiate an indeterminate-length transfer.  For example:  <ins> With the Content-Range response header field indicating the range (or </ins> ranges) available.  For example: The client can then issue a request for a range starting at the end
Original text:
This document adds a new SETTINGS Parameter to those defined by RFC7540, Section 6.5.2. <del> The new parameter is ENABLE_CONNECT_PROTOCOL (type = 0x8).  The value of the parameter MUST be 0 or 1. </del>  <del> Upon receipt of ENABLE_CONNECT_PROTOCOL with a value of 1 a client MAY use the Extended CONNECT definition of this document when </del>  creating new streams.  Receipt of this parameter by a server does not have any impact. <del> A sender MUST NOT send a ENABLE_CONNECT_PROTOCOL parameter with the value of 0 after previously sending a value of 1. </del>  The use of a SETTINGS Parameter to opt-in to an otherwise incompatible protocol change is a use of "Extending HTTP/2" defined by Section 5.5 of RFC7540.  If a client were to use the provisions of the extended CONNECT method defined in this document without first <del> receiving a ENABLE_CONNECT_PROTOCOL parameter with the value of 1 it would be a protocol violation. </del>  4.

Reviewer comments:
Add SETTINGS prefix to parameter name ENABLECONNECT_PROTOCOL. Fix one typo ("s/a entry/an entry/"). Remove "(type = 0x8)" which is ambigous (what is type?) and redundant with code listed in IANA Considerations section.
thanks

Revised text:
This document adds a new SETTINGS Parameter to those defined by RFC7540, Section 6.5.2.  <ins> The new parameter name is SETTINGS_ENABLE_CONNECT_PROTOCOL.  The value of the parameter MUST be 0 or 1. </ins>  <ins> Upon receipt of SETTINGS_ENABLE_CONNECT_PROTOCOL with a value of 1 a client MAY use the Extended CONNECT definition of this document when </ins> creating new streams.  Receipt of this parameter by a server does not have any impact.  <ins> A sender MUST NOT send a SETTINGS_ENABLE_CONNECT_PROTOCOL parameter with the value of 0 after previously sending a value of 1. </ins> The use of a SETTINGS Parameter to opt-in to an otherwise incompatible protocol change is a use of "Extending HTTP/2" defined by Section 5.5 of RFC7540.  If a client were to use the provisions of the extended CONNECT method defined in this document without first  <ins> receiving a SETTINGS_ENABLE_CONNECT_PROTOCOL parameter with the value of 1 it would be a protocol violation. </ins> 4.
Original text:
9. <del> This document establishes a entry for the HTTP/2 Settings Registry </del>  that was established by Section 11.3 of RFC7540. <del> Name: ENABLE_CONNECT_PROTOCOL </del>  Code: 0x8

Reviewer comments:
Add SETTINGS prefix to parameter name ENABLECONNECT_PROTOCOL. Fix one typo ("s/a entry/an entry/"). Remove "(type = 0x8)" which is ambigous (what is type?) and redundant with code listed in IANA Considerations section.
thanks

Revised text:
9.  <ins> This document establishes an entry for the HTTP/2 Settings Registry </ins> that was established by Section 11.3 of RFC7540.  <ins> Name: SETTINGS_ENABLE_CONNECT_PROTOCOL </ins> Code: 0x8
Original text:
This specification defines the "Authentication-Info" and "Proxy- Authentication-Info" response header fields for use in HTTP <del> authentication schemes which need to return additional information during or after authentication. </del>  Editorial Note (To be removed by RFC Editor)

Reviewer comments:
Herve, could you please open an issue for this, so that we can assure that we track the underlying issue? It's OK to merge the proposal if the editor feels that it's helpful, but we need to make sure the WG gets consensus here. Thanks,
Linked to issue .

Revised text:
This specification defines the "Authentication-Info" and "Proxy- Authentication-Info" response header fields for use in HTTP  <ins> authentication schemes which need to return information once the client's authentication credentials have been accepted. </ins> Editorial Note (To be removed by RFC Editor)
Original text:
This specification defines the "Authentication-Info" and "Proxy- Authentication-Info" response header fields for use in HTTP <del> authentication schemes (RFC7235) which need to return additional information during or after authentication. </del>  Both were previously defined in RFC2617, defining the HTTP "Digest" authentication scheme.  This document generalizes the description for

Reviewer comments:
Herve, could you please open an issue for this, so that we can assure that we track the underlying issue? It's OK to merge the proposal if the editor feels that it's helpful, but we need to make sure the WG gets consensus here. Thanks,
Linked to issue .

Revised text:
This specification defines the "Authentication-Info" and "Proxy- Authentication-Info" response header fields for use in HTTP  <ins> authentication schemes (RFC7235) which need to return information once the client's authentication credentials have been accepted. </ins> Both were previously defined in RFC2617, defining the HTTP "Digest" authentication scheme.  This document generalizes the description for
Original text:
3. HTTP authentication schemes can use the Authentication-Info response <del> header field to communicate additional information regarding the successful authentication. </del>  The field value is a list of parameters (name/value pairs), using the "auth-param" syntax defined in RFC7235.  This specification only

Reviewer comments:
Herve, could you please open an issue for this, so that we can assure that we track the underlying issue? It's OK to merge the proposal if the editor feels that it's helpful, but we need to make sure the WG gets consensus here. Thanks,
Linked to issue .

Revised text:
3. HTTP authentication schemes can use the Authentication-Info response  <ins> header field to communicate information after the client's authentication credentials have been accepted.  This information can include a finalization message from the server (e.g., it can contain the server authentication). </ins> The field value is a list of parameters (name/value pairs), using the "auth-param" syntax defined in RFC7235.  This specification only
Original text:
Furthermore, applications using HTTP MUST NOT re-specify the semantics of HTTP status codes, even if it is only by copying their <del> definition.  They MUST NOT require specific status phrases to be used; the status phrase has no function in HTTP, and is not guaranteed to be preserved by implementations. </del>  Typically, applications using HTTP will convey application-specific information in the message body and/or HTTP header fields, not the

Reviewer comments:
Port over of PR from mnot repo. Modified last sentence to avoid to much usage of the word "further".
Thanks!

Revised text:
Furthermore, applications using HTTP MUST NOT re-specify the semantics of HTTP status codes, even if it is only by copying their  <ins> definition.  They MUST NOT require specific reason phrases to be used; the reason phrase has no function in HTTP, and is not guaranteed to be preserved by implementations.  The reason phrase is not carried in the RFC7540 message format. </ins> Typically, applications using HTTP will convey application-specific information in the message body and/or HTTP header fields, not the
Original text:
This document specifies best practices for these protocols' use of HTTP.  Note to Readers Discussion of this draft takes place on the HTTP working group

Reviewer comments:
Mention obsoletion in the abstract, tune section title in appendix, and actually cite RFC 3205.

Revised text:
This document specifies best practices for these protocols' use of HTTP. <ins> This document obsoletes RFC 3205. </ins> Note to Readers Discussion of this draft takes place on the HTTP working group
Original text:
3. A Client SHOULD notify its support for CACHE_DIGEST frames by sending <del> the SENDING_CACHE_DIGEST (0xXXX) SETTINGS parameter. </del>  The value of the parameter is a bit-field of which the following bits are defined:

Reviewer comments:
Aligns with other SETTINGS parameter names defined in other docs.
NAME icymi
Thank you for the fix!

Revised text:
3. A Client SHOULD notify its support for CACHE_DIGEST frames by sending  <ins> the SETTINGS_SENDING_CACHE_DIGEST (0xXXX) SETTINGS parameter. </ins> The value of the parameter is a bit-field of which the following bits are defined: