jiebi/TextFlow huggingface dataset:
Original text:
Automatic retry creates the potential for a replay attack.  An attacker intercepts a connection that uses early data and copies the early data to another server instance.  The second server instance <del> accepts and processes the early data.  The attacker then allows the original connection to complete.  Even if the early data is detected as a duplicate and rejected, the first server instance might allow the connection to complete.  If the client then retries requests that </del>  were sent in early data, the request will be processed twice. Replays are also possible if there are multiple server instances that

Reviewer comments:
NAME had a few comments in the review of this that are easy to solve.
All changes are OK to me as well. Thanks!
43d2c16 does a great job capturing the point that I made poorly off-list; thanks again!

Revised text:
Automatic retry creates the potential for a replay attack.  An attacker intercepts a connection that uses early data and copies the early data to another server instance.  The second server instance  <ins> accepts and processes the early data, even though it will not complete the TLS handshake.  The attacker then allows the original connection to complete.  Even if the early data is detected as a duplicate and rejected, the first server instance might allow the connection to complete.  If the client then retries requests that </ins> were sent in early data, the request will be processed twice. Replays are also possible if there are multiple server instances that
Original text:
replayed.  A retried or replayed request can produce different side effects on the server.  In addition to those side effects, replays and retries might be used for traffic analysis to recover information <del> about requests or the resources those requests target. </del>  6.1.

Reviewer comments:
NAME had a few comments in the review of this that are easy to solve.
All changes are OK to me as well. Thanks!
43d2c16 does a great job capturing the point that I made poorly off-list; thanks again!

Revised text:
replayed.  A retried or replayed request can produce different side effects on the server.  In addition to those side effects, replays and retries might be used for traffic analysis to recover information  <ins> about requests or the resources those requests target.  In particular, a request that is replayed might result in a different response, which might be observable from the length of protected data even if the content remains confidential. </ins> 6.1.
Original text:
eliminate the chance of data being replayed and ensure a fixed upper limit to the number of replays. <del> The server can reject early data.  A server cannot selectively reject early data, so this results in all requests sent in early data being discarded. </del>  The server can choose to delay processing of early data until after the TLS handshake completes.  By deferring processing, it

Reviewer comments:
Just editorial suggestions here, but all good ones.
Nice wording, I really like this new version. Thanks!

Revised text:
eliminate the chance of data being replayed and ensure a fixed upper limit to the number of replays.  <ins> The server can reject early data at the TLS layer.  A server cannot selectively reject early data, so this results in all requests sent in early data being discarded. </ins> The server can choose to delay processing of early data until after the TLS handshake completes.  By deferring processing, it
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> 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), in cases where the risk of replay is judged too great. </del>  For a given request, the level of tolerance to replay risk is specific to the resource it operates upon (and therefore only known <del> to the origin server).  In general, if processing a request does not have state-changing side effects, the consequences of replay are not significant. </del>  The request method's safety (RFC7231, Section 4.2.1) is one way to <del> determine this.  However, some resources do elect to associate side effects with safe methods, so this cannot be universally relied upon. </del>  It is RECOMMENDED that origin servers allow resources to explicitly configure whether early data is appropriate in requests.  Absent such

Reviewer comments:
Just editorial suggestions here, but all good ones.
Nice wording, I really like this new version. Thanks!

Revised text:
If the server receives multiple requests in early data, it can determine whether to defer HTTP processing on a per-request basis.  <ins> The server can cause a client to retry individual requests and not use early data by responding with the 425 (Too Early) status code (status), in cases where the risk of replay is judged too great. </ins> For a given request, the level of tolerance to replay risk is specific to the resource it operates upon (and therefore only known  <ins> to the origin server).  The primary risk associated with using early data is in the actions a server takes when processing a request; processing a duplicated request might result in duplicated effects and side effects.  Appendix E.5 of TLS13 also describes other effects produced by processing duplicated requests. </ins> The request method's safety (RFC7231, Section 4.2.1) is one way to  <ins> determine if a request is free from side effects.  However, some resources do elect to associate side effects with safe methods, so this cannot be universally relied upon. </ins> It is RECOMMENDED that origin servers allow resources to explicitly configure whether early data is appropriate in requests.  Absent such
Original text:
A server can limit the amount of early data with the "max_early_data_size" field of the "early_data" TLS extension.  This can be used to avoid committing an arbitrary amount of memory for <del> deferred requests.  A server SHOULD ensure that when it accepts early data, it can defer processing of requests until after the TLS handshake completes. </del>  4.

Reviewer comments:
Just editorial suggestions here, but all good ones.
Nice wording, I really like this new version. Thanks!

Revised text:
A server can limit the amount of early data with the "max_early_data_size" field of the "early_data" TLS extension.  This can be used to avoid committing an arbitrary amount of memory for  <ins> requests that it might defer until the handshake completes. </ins> 4.
Original text:
start sending again as though the connection was new.  This could entail using a different negotiated protocol ALPN than the one optimistically used for the early data.  Any requests sent in early <del> data MUST be sent again, unless the client decides to abandon those requests. </del>  Automatic retry creates the potential for a replay attack.  An attacker intercepts a connection that uses early data and copies the

Reviewer comments:
Just editorial suggestions here, but all good ones.
Nice wording, I really like this new version. Thanks!

Revised text:
start sending again as though the connection was new.  This could entail using a different negotiated protocol ALPN than the one optimistically used for the early data.  Any requests sent in early  <ins> data will need to be sent again, unless the client decides to abandon those requests. </ins> Automatic retry creates the potential for a replay attack.  An attacker intercepts a connection that uses early data and copies the
Original text:
Replays are also possible if there are multiple server instances that will accept early data, or if the same server accepts early data <del> multiple times (though this would be in violation of requirements in Section 8 of TLS13). </del>  Clients that use early data MUST retry requests upon receipt of a 425 (Too Early) status code; see status.

Reviewer comments:
Just editorial suggestions here, but all good ones.
Nice wording, I really like this new version. Thanks!

Revised text:
Replays are also possible if there are multiple server instances that will accept early data, or if the same server accepts early data  <ins> multiple times (though the latter would be in violation of requirements in Section 8 of TLS13). </ins> Clients that use early data MUST retry requests upon receipt of a 425 (Too Early) status code; see status.
Original text:
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 <del> (see be-consistent for details). </del>  An intermediary MUST NOT remove this header field if it is present in a request.  "Early-Data" MUST NOT appear in a "Connection" header

Reviewer comments:
Just editorial suggestions here, but all good ones.
Nice wording, I really like this new version. Thanks!

Revised text:
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  <ins> (be-consistent describes considerations for clusters of servers). </ins> An intermediary MUST NOT remove this header field if it is present in a request.  "Early-Data" MUST NOT appear in a "Connection" header
Original text:
A server decides whether or not to offer a client the ability to send early data on future connections when sending the TLS session ticket.  When a server enables early data, there are a number of techniques it can use to mitigate the risks of replay: <del> TLS TLS13 mandates the use of replay detection strategies that reduce the ability of an attacker to successfully replay early data.  These anti-replay techniques reduce but don't completely eliminate the chance of data being replayed and ensure a fixed upper limit to the number of replays. </del> The server can reject early data at the TLS layer.  A server cannot selectively reject early data, so this results in all requests sent in early data being discarded.

Reviewer comments:
This will conflict with the changes ekr suggested, but I integrated them, so merging shouldn't lose the important changes.
For "sent in early data on another connection", I think Spencer's proposal "sent in early data on a previous hop" would make it even clearer regarding the hop chain so as not to confuse this with another connection from the same user-agent. OK for the rest.

Revised text:
A server decides whether or not to offer a client the ability to send early data on future connections when sending the TLS session ticket. <ins> TLS TLS13 mandates the use of replay detection strategies that reduce the ability of an attacker to successfully replay early data.  These anti-replay techniques reduce but don't completely eliminate the chance of data being replayed and ensure a fixed upper limit to the number of replays. </ins> When a server enables early data, there are a number of techniques it can use to mitigate the risks of replay:  The server can reject early data at the TLS layer.  A server cannot selectively reject early data, so this results in all requests sent in early data being discarded.
Original text:
after the TLS handshake completes.  By deferring processing, it can ensure that only a successfully completed connection is used for the request(s) therein.  This provides the server with some <del> assurance that the early data was not replayed. If the server receives multiple requests in early data, it can determine whether to defer HTTP processing on a per-request basis. </del>  The server can cause a client to retry individual requests and not use early data by responding with the 425 (Too Early) status code (status), in cases where the risk of replay is judged too great.  For a given request, the level of tolerance to replay risk is specific to the resource it operates upon (and therefore only known to the origin server).  The primary risk associated with using early

Reviewer comments:
This will conflict with the changes ekr suggested, but I integrated them, so merging shouldn't lose the important changes.
For "sent in early data on another connection", I think Spencer's proposal "sent in early data on a previous hop" would make it even clearer regarding the hop chain so as not to confuse this with another connection from the same user-agent. OK for the rest.

Revised text:
after the TLS handshake completes.  By deferring processing, it can ensure that only a successfully completed connection is used for the request(s) therein.  This provides the server with some  <ins> assurance that the early data was not replayed.  If the server receives multiple requests in early data, it can determine whether to defer HTTP processing on a per-request basis. </ins> The server can cause a client to retry individual requests and not use early data by responding with the 425 (Too Early) status code (status), in cases where the risk of replay is judged too great. <ins> Any of these techniques is equally effective and a server can use the method that best suits it. </ins> For a given request, the level of tolerance to replay risk is specific to the resource it operates upon (and therefore only known to the origin server).  The primary risk associated with using early
Original text:
Because HTTP requests can span multiple "hops", it is necessary to explicitly communicate whether a request has been sent in early data <del> on a previous connection.  Likewise, some means of explicitly triggering a retry when early data is not desirable is necessary. Finally, it is necessary to know whether the client will actually perform such a retry. </del>  To meet these needs, two signalling mechanisms are defined:

Reviewer comments:
This will conflict with the changes ekr suggested, but I integrated them, so merging shouldn't lose the important changes.
For "sent in early data on another connection", I think Spencer's proposal "sent in early data on a previous hop" would make it even clearer regarding the hop chain so as not to confuse this with another connection from the same user-agent. OK for the rest.

Revised text:
Because HTTP requests can span multiple "hops", it is necessary to explicitly communicate whether a request has been sent in early data  <ins> on a previous hop.  Likewise, some means of explicitly triggering a retry when early data is not desirable is necessary.  Finally, it is necessary to know whether the client will actually perform such a retry. </ins> To meet these needs, two signalling mechanisms are defined:
Original text:
A 425 (Too Early) status code indicates that the server is unwilling to risk processing a request that might be replayed. <del> User agents that send a request in early data MUST automatically retry the request when receiving a 425 (Too Early) response status code.  Such retries MUST NOT be sent in early data. </del>  In all cases, an intermediary can forward a 425 (Too Early) status code.  Intermediaries MUST forward a 425 (Too Early) status code if

Reviewer comments:
This will conflict with the changes ekr suggested, but I integrated them, so merging shouldn't lose the important changes.
For "sent in early data on another connection", I think Spencer's proposal "sent in early data on a previous hop" would make it even clearer regarding the hop chain so as not to confuse this with another connection from the same user-agent. OK for the rest.

Revised text:
A 425 (Too Early) status code indicates that the server is unwilling to risk processing a request that might be replayed.  <ins> User agents that send a request in early data are expected to retry the request when receiving a 425 (Too Early) response status code.  A user agent MAY do so automatically, but any retries MUST NOT be sent in early data. </ins> In all cases, an intermediary can forward a 425 (Too Early) status code.  Intermediaries MUST forward a 425 (Too Early) status code if
Original text:
In protocols that deliver data out of order (such as QUIC HQ) early data can arrive after the handshake completes.  A server MAY process <del> requests received in early data after handshake completion if it can rely on other instances correctly handling replays of the same </del>  requests. 7.

Reviewer comments:
This will conflict with the changes ekr suggested, but I integrated them, so merging shouldn't lose the important changes.
For "sent in early data on another connection", I think Spencer's proposal "sent in early data on a previous hop" would make it even clearer regarding the hop chain so as not to confuse this with another connection from the same user-agent. OK for the rest.

Revised text:
In protocols that deliver data out of order (such as QUIC HQ) early data can arrive after the handshake completes.  A server MAY process  <ins> requests received in early data after handshake completion only if it can rely on other instances correctly handling replays of the same </ins> requests. 7.
Original text:
certificate are not already available, they will need to be sent as described in cert-available as part of this exchange.  3. The "CERTIFICATE_REQUEST" and "CERTIFICATE_NEEDED" frames are

Reviewer comments:
Follow-on to ; in the process of fixing this, I noticed that I'd added a "server" header but missed adding a corresponding "client" header, so the client discussion appeared in the server section.
For some reason, that seems to be endemic in this doc. Let's do that cleanup separately.
I appreciate the addition of the section heading. Though Section Headings Use Title Case.

Revised text:
certificate are not already available, they will need to be sent as described in cert-available as part of this exchange. <ins> If the client does not have the desired certificate, it instead sends an Empty Authenticator, as described in Section 5 of I-D.ietf-tls- exported-authenticator, in a "CERTIFICATE" frame in response to the request, followed by a "USE_CERTIFICATE" frame which references the Empty Authenticator.  In this case, or if the client has not advertised support for HTTP-layer certificates, the server processes the request based solely on the certificate provided during the TLS handshake, if any.  This might result in an error response via HTTP, such as a status code 403 (Not Authorized). </ins> 3. The "CERTIFICATE_REQUEST" and "CERTIFICATE_NEEDED" frames are
Original text:
their default settings, user configuration, and server preferences. The client and server can use an opt-in mechanism outlined below to negotiate which fields should be sent to allow for efficient content <del> adaption, and optinally use additional mechanisms to negotiate </del>  delegation policies that control access of third parties to same fields.

Reviewer comments:
Per discussions in fetch [1], update the opt-in example to apply to same-origin resources only, with Accept-CH-Lifetime being processed on navigation requests. [1] URL /cc NAME NAME

Revised text:
their default settings, user configuration, and server preferences. The client and server can use an opt-in mechanism outlined below to negotiate which fields should be sent to allow for efficient content  <ins> adaption, and optionally use additional mechanisms to negotiate </ins> delegation policies that control access of third parties to same fields.
Original text:
origin that isn't HTTPS. For example, based on the Accept-CH and Accept-CH-Lifetime example <del> above, which is received from "https://bar.example.com" in response to a resource request initiated by "https://foo.example.com", both delivered over a secure transport: a user agent SHOULD persist an Accept-CH preference bound to "https://foo.example.com", for requests initiated to "https://bar.example.com" from "https://foo.example.com", for up to 86400 seconds (1 day).  This preference SHOULD NOT extend to requests initiated to "https://bar.example.com" from other origins. </del>  If Accept-CH-Lifetime occurs in a message more than once, the last value overrides all previous occurrences.

Reviewer comments:
Per discussions in fetch [1], update the opt-in example to apply to same-origin resources only, with Accept-CH-Lifetime being processed on navigation requests. [1] URL /cc NAME NAME

Revised text:
origin that isn't HTTPS. For example, based on the Accept-CH and Accept-CH-Lifetime example  <ins> above, which is received in response to a user agent navigating to "https://example.com", and delivered over a secure transport: a user agent SHOULD persist an Accept-CH preference bound to "https://example.com" for up to 86400 seconds (1 day), and use it for user agent navigations to "https://example.com" and any same-origin resource requests initiated by the page constructed from the navigation's response.  This preference SHOULD NOT extend to resource requests initiated to "https://example.com" from other origins. </ins> If Accept-CH-Lifetime occurs in a message more than once, the last value overrides all previous occurrences.
Original text:
as shown here. This document uses the Augmented Backus-Naur Form (ABNF) notation of <del> RFC5234, including the VCHAR, DIGIT, ALPHA and DQUOTE rules from that document.  It also includes the OWS rule from RFC7230. </del>  This document uses algorithms to specify parsing and serialisation behaviours, and ABNF to illustrate expected syntax.

Reviewer comments:
Step 4.4 equates "the range %x00-1f or %x7f" to "not in VCHAR", but VCHAR doesn't include %x20; this change adds "or SP" and imports SP from RFC5234.
Thanks!

Revised text:
as shown here. This document uses the Augmented Backus-Naur Form (ABNF) notation of  <ins> RFC5234, including the VCHAR, SP, DIGIT, ALPHA and DQUOTE rules from that document.  It also includes the OWS rule from RFC7230. </ins> This document uses algorithms to specify parsing and serialisation behaviours, and ABNF to illustrate expected syntax.
Original text:
Given a string as input: If input is not a sequence of characters, or contains characters <del> outside the range allowed by VCHAR, fail serialisation. </del>  Let output be an empty string.

Reviewer comments:
Step 4.4 equates "the range %x00-1f or %x7f" to "not in VCHAR", but VCHAR doesn't include %x20; this change adds "or SP" and imports SP from RFC5234.
Thanks!

Revised text:
Given a string as input: If input is not a sequence of characters, or contains characters  <ins> outside the range allowed by VCHAR or SP, fail serialisation. </ins> Let output be an empty string.
Original text:
Else, if char is DQUOTE, return output_string. Else, if char is in the range %x00-1f or %x7f (i.e., is not in <del> VCHAR), fail parsing. </del>  Else, append char to output_string.

Reviewer comments:
Step 4.4 equates "the range %x00-1f or %x7f" to "not in VCHAR", but VCHAR doesn't include %x20; this change adds "or SP" and imports SP from RFC5234.
Thanks!

Revised text:
Else, if char is DQUOTE, return output_string. Else, if char is in the range %x00-1f or %x7f (i.e., is not in  <ins> VCHAR or SP), fail parsing. </ins> Else, append char to output_string.
Original text:
Append value to output.  Return output. 4.1.2.

Reviewer comments:
Serialisation algorithms for dictionary and parameterised-list didn't include commas (?) This copies the equivalent steps from the algorithm
Just noticed that this is
Thx.

Revised text:
Append value to output. <ins> If more members remain in input: Append a COMMA to output. Append a single WS to output. </ins> Return output. 4.1.2.
Original text:
Append value to output.  Return output. 4.1.4.

Reviewer comments:
Serialisation algorithms for dictionary and parameterised-list didn't include commas (?) This copies the equivalent steps from the algorithm
Just noticed that this is
Thx.

Revised text:
Append value to output. <ins> If more members remain in input: Append a COMMA to output. Append a single WS to output. </ins> Return output. 4.1.4.