jiebi/TextFlow huggingface dataset:
Original text:
4. A server can notify its support for CACHE_DIGEST frame by sending the <del> ACCEPT_CACHE_DIGEST (0x7) SETTINGS parameter.  If the server is tempted to making optimizations based on CACHE_DIGEST frames, it </del>  SHOULD send the SETTINGS parameter immediately after the connection is established.

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

Revised text:
4. A server can notify its support for CACHE_DIGEST frame by sending the  <ins> SETTINGS_ACCEPT_CACHE_DIGEST (0x7) SETTINGS parameter.  If the server is tempted to making optimizations based on CACHE_DIGEST frames, it </ins> SHOULD send the SETTINGS parameter immediately after the connection is established.
Original text:
client sends it's first flight data.  When such transport (e.g., TLS 1.3 I-D.ietf-tls-tls13 in full-handshake mode) is used, a client can postpone sending the CACHE_DIGEST frame until it receives a <del> ACCEPT_CACHE_DIGEST settings value. </del>  When the underlying transport does not have such property (e.g., TLS 1.3 in 0-RTT mode), a client can reuse the settings value found in

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

Revised text:
client sends it's first flight data.  When such transport (e.g., TLS 1.3 I-D.ietf-tls-tls13 in full-handshake mode) is used, a client can postpone sending the CACHE_DIGEST frame until it receives a  <ins> SETTINGS_ACCEPT_CACHE_DIGEST settings value. </ins> When the underlying transport does not have such property (e.g., TLS 1.3 in 0-RTT mode), a client can reuse the settings value found in
Original text:
Code: 0x7 <del> Name: ACCEPT_CACHE_DIGEST </del>  Initial Value: 0x0

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

Revised text:
Code: 0x7  <ins> Name: SETTINGS_ACCEPT_CACHE_DIGEST </ins> Initial Value: 0x0
Original text:
support the Tunnel-Protocol header field. The value of the Tunnel-Protocol header field could be falsified by a <del> client.  The use of protocols like RFC5246 make it very difficult or impossible to verify that the header field is correct even after a connection is established.  A proxy therefore cannot rely on the value of the Tunnel-Protocol header field as a policy input in all cases. </del> 

Reviewer comments:
This adds a section regarding falsification of Tunnel-Protocol. I didn't expand this to note that WebRTC won't suffer from this problem because the application won't be able to set the header field. That seemed like too much detail.

Revised text:
support the Tunnel-Protocol header field. The value of the Tunnel-Protocol header field could be falsified by a  <ins> client.  If the data being sent through the tunnel is encrypted (for example, with RFC5246), then the proxy might not be able to directly inspect the data to verify that the claimed protocol is the one which is actually being used, though a proxy might be able to perform traffic analysis TRAFFIC.  A proxy therefore cannot rely on the value of the Tunnel-Protocol header field as a policy input in all cases. </ins>
Original text:
configuration of underlying encryption, allowing a "http" URI to be accessed using TLS RFC5246 opportunistically. <del> Currently, "https" URIs require acquiring and configuring a valid </del>  certificate, which means that some deployments find supporting TLS <del> difficult.  Therefore, this document describes a usage model whereby sites can serve "http" URIs over TLS without being required to support strong server authentication. </del>  Opportunistic Security RFC7435 does not provide the same guarantees as using TLS with "https" URIs; it is vulnerable to active attacks,

Reviewer comments:
for encryption. I had these in my local repo. They weren't pushed, but I wanted to make sure that they are OK before merging them.

Revised text:
configuration of underlying encryption, allowing a "http" URI to be accessed using TLS RFC5246 opportunistically.  <ins> Serving "https" URIs require acquiring and configuring a valid </ins> certificate, which means that some deployments find supporting TLS  <ins> difficult.  This document describes a usage model whereby sites can serve "http" URIs over TLS without being required to support strong server authentication. </ins> Opportunistic Security RFC7435 does not provide the same guarantees as using TLS with "https" URIs; it is vulnerable to active attacks,
Original text:
there will be no "lock icon"). By its nature, this technique is vulnerable to active attacks.  A <del> mechanism for partially mitigating them is described in http-tls.  It does not offer the same level of protection as afforded to "https" URIs, but increases the likelihood that an active attack be detected. </del>  1.1.

Reviewer comments:
for encryption. I had these in my local repo. They weren't pushed, but I wanted to make sure that they are OK before merging them.

Revised text:
there will be no "lock icon"). By its nature, this technique is vulnerable to active attacks.  A  <ins> mechanism for partially mitigating them is described in http-tls. </ins> 1.1.
Original text:
attack can be detected. A final (but significant) goal is to provide for ease of <del> implementation, deployment and operation.  This mechanism should have a minimal impact upon performance, and should not require extensive </del>  administrative effort to configure. 1.2.

Reviewer comments:
for encryption. I had these in my local repo. They weren't pushed, but I wanted to make sure that they are OK before merging them.

Revised text:
attack can be detected. A final (but significant) goal is to provide for ease of  <ins> implementation, deployment and operation.  This mechanism is expected to have a minimal impact upon performance, and a trivial </ins> administrative effort to configure. 1.2.
Original text:
A client that places the importance of protection against passive attacks over performance might choose to withhold requests until an encrypted connection is available.  However, if such a connection <del> cannot be successfully established, the client MAY resume its use of </del>  the cleartext connection. A client can also explicitly probe for an alternative service

Reviewer comments:
for encryption. I had these in my local repo. They weren't pushed, but I wanted to make sure that they are OK before merging them.

Revised text:
A client that places the importance of protection against passive attacks over performance might choose to withhold requests until an encrypted connection is available.  However, if such a connection  <ins> cannot be successfully established, the client can resume its use of </ins> the cleartext connection. A client can also explicitly probe for an alternative service
Original text:
is proffered by the alternative service, is not necessarily checked for validity, expiration, issuance by a trusted certificate authority or matched against the name in the URI.  Therefore, the alternative <del> service MAY provide any certificate, or even select TLS cipher suites </del>  that do not include authentication. A client MAY perform additional checks on the offered certificate if

Reviewer comments:
for encryption. I had these in my local repo. They weren't pushed, but I wanted to make sure that they are OK before merging them.

Revised text:
is proffered by the alternative service, is not necessarily checked for validity, expiration, issuance by a trusted certificate authority or matched against the name in the URI.  Therefore, the alternative  <ins> service can provide any certificate, or even select TLS cipher suites </ins> that do not include authentication. A client MAY perform additional checks on the offered certificate if
Original text:
4. <del> When using alternative services, both "http" and "https" URIs might use the same connection, because HTTP/2 permits requests for multiple origins on the same connection. </del>  Since "https" URIs rely on server authentication, a connection that is initially created for "http" URIs without authenticating the

Reviewer comments:
for encryption. I had these in my local repo. They weren't pushed, but I wanted to make sure that they are OK before merging them.

Revised text:
4.  <ins> When using alternative services, requests for resources identified by both "http" and "https" URIs might use the same connection, because HTTP/2 permits requests for multiple origins on the same connection. </ins> Since "https" URIs rely on server authentication, a connection that is initially created for "http" URIs without authenticating the
Original text:
A client that doesn't perform authentication is an easy victim of server impersonation, through man-in-the-middle attacks. <del> A client that is willing to use cleartext to resolve the resource will do so if access to any TLS-enabled alternative services is blocked at the network layer. </del>  Given that the primary goal of this specification is to prevent passive attacks, these are not critical failings (especially

Reviewer comments:
for encryption. I had these in my local repo. They weren't pushed, but I wanted to make sure that they are OK before merging them.

Revised text:
A client that doesn't perform authentication is an easy victim of server impersonation, through man-in-the-middle attacks.  <ins> A client that is willing to use HTTP over cleartext to resolve the resource will do so if access to any TLS-enabled alternative services is blocked at the network layer. </ins> Given that the primary goal of this specification is to prevent passive attacks, these are not critical failings (especially
Original text:
5.1. A alternative service can make this commitment by sending a "HTTP- <del> TLS" header field: </del>  When it appears in a HTTP response from a strongly authenticated alternative service, this header field indicates that the

Reviewer comments:
for encryption. I had these in my local repo. They weren't pushed, but I wanted to make sure that they are OK before merging them.

Revised text:
5.1. A alternative service can make this commitment by sending a "HTTP-  <ins> TLS" header field, described here using the '#' ABNF extension defined in Section 7 of RFC7230: </ins> When it appears in a HTTP response from a strongly authenticated alternative service, this header field indicates that the
Original text:
creates some risks for clients (see pinrisks). Authentication for HTTP over TLS is described in Section 3.1 of <del> RFC2818, noting the additional requirements in I-D.ietf-httpbis-alt- svc.  The header field MUST be ignored if strong authentication fails; otherwise, an attacker could create a persistent denial of service by falsifying a commitment. </del>  The commitment to use authenticated TLS persists for a period determined by the value of the "ma" parameter.  See Section 4.2.3 of

Reviewer comments:
for encryption. I had these in my local repo. They weren't pushed, but I wanted to make sure that they are OK before merging them.

Revised text:
creates some risks for clients (see pinrisks). Authentication for HTTP over TLS is described in Section 3.1 of  <ins> RFC2818, noting the additional requirements in Section 2.1 of I- D.ietf-httpbis-alt-svc.  The header field MUST be ignored if strong authentication fails; otherwise, an attacker could create a persistent denial of service by falsifying a commitment. </ins> The commitment to use authenticated TLS persists for a period determined by the value of the "ma" parameter.  See Section 4.2.3 of
Original text:
The commitment made by the "HTTP-TLS" header field applies only to the origin of the resource that generates the "HTTP-TLS" header <del> field.  Requests for an origin that has a persisted, unexpired value for "HTTP-TLS" MUST fail if they cannot be made over an authenticated TLS connection. </del>  Note that the commitment is not bound to a particular alternative service.  Clients SHOULD use alternative services that they become

Reviewer comments:
for encryption. I had these in my local repo. They weren't pushed, but I wanted to make sure that they are OK before merging them.

Revised text:
The commitment made by the "HTTP-TLS" header field applies only to the origin of the resource that generates the "HTTP-TLS" header  <ins> field. Requests for an origin that has a persisted, unexpired value for "HTTP-TLS" MUST fail if they cannot be made over an authenticated TLS connection. </ins> Note that the commitment is not bound to a particular alternative service.  Clients SHOULD use alternative services that they become
Original text:
NOTE: This algorithm parses both Integers and Floats float, and returns the corresponding structure. <del> If the first character of input_string is not "-" or a DIGIT, fail parsing. </del>  <del> Let input_number be the result of consuming input_string up to (but not including) the first character that is not in DIGIT, "-", and ".". </del>  <del> If any character of input_number after the first is "-", fail </del>  parsing. <del> If input_number contains ".", parse it as a floating point number and let output_number be the result. </del>  <del> Otherwise, parse input_number as an integer and let output_number be the result. </del>  <del> Return output_number. </del>  4.6.

Reviewer comments:
This algorithm automatically enforces the ABNF syntax, including length limits. It still punts on the actual strtoi/strtof part. ?
Much better, thanks!

Revised text:
NOTE: This algorithm parses both Integers and Floats float, and returns the corresponding structure.  <ins> Let type be "integer". Let sign be 1. Let input_number be an empty string. If the first character of input_string is "-", remove it from input_string and set sign to -1. </ins>  <ins> If input_string is empty, fail parsing. </ins>  <ins> If the first character of input_string is not a DIGIT, fail </ins> parsing.  <ins> While input_string is not empty: Let char be the result of removing the first character of input_string. If char is a DIGIT, append it to input_number. Else, if type is "integer" and char is ".", append char to input_number and set type to "float". Otherwise, fail parsing. If type is "integer" and input_number contains more than 19 characters, fail parsing. If type is "float" and input_number contains more than 16 characters, fail parsing. If type is "integer", parse input_number as an integer and let output_number be the result. Otherwise: If the final character of input_number is ".", fail parsing. </ins>  <ins> Parse input_number as a float and let output_number be the result. </ins>  <ins> Return the product of output_number and sign. </ins> 4.6.
Original text:
syntactically, this is done only to allow parsers to be generic; as per RFC7231, Section 4.3.1, a body on a GET has no meaning, and will be either ignored or rejected by generic HTTP software.  As a result, <del> applications that use HTTP SHOULD NOT define GET to have any sde </del>  effects upon their resources. 4.6.

Reviewer comments:
This just fixes a typo, but this text has more problems. I'm having trouble connecting this final sentence to the text that precedes it. I think that the point is that including a body on GET is unwise because it might cause explosions. A point about side effects needs far more exposition, especially since GET is defined to be free from overt side effects (safe, idempotent, and all that business). If this were just another statement and the "As a result" is dropped, that's different.
Barg, I think that's a copy/paste error, will fix. thx.

Revised text:
syntactically, this is done only to allow parsers to be generic; as per RFC7231, Section 4.3.1, a body on a GET has no meaning, and will be either ignored or rejected by generic HTTP software.  As a result,  <ins> applications that use HTTP SHOULD NOT define GET to have any side </ins> effects upon their resources. 4.6.
Original text:
cache or by forwarding the request towards the origin - by following the algorithm defined in cache. <del> Its companion the Variant-Key response header field (variant-key) indicates which representation was selected, so that it can be reliably reused in the future.  When this specification is in use, the example above might become: </del>  Proactive content negotiation mechanisms that wish to be used with Variants need to define how to do so explicitly; see define.  As a

Reviewer comments:
For
Allow a response to associate itself with more than one variant. (moved from mnot/I-D)

Revised text:
cache or by forwarding the request towards the origin - by following the algorithm defined in cache.  <ins> Its companion Variant-Key response header field (variant-key) indicates the applicable key(s) that the response is associated with, so that it can be reliably reused in the future.  When this specification is in use, the example above might become: </ins> Proactive content negotiation mechanisms that wish to be used with Variants need to define how to do so explicitly; see define.  As a
Original text:
3. The Variant-Key HTTP response header field is used to indicate the <del> value(s) from the Variants header field that identify the </del>  representation it occurs within. <del> Each value indicates the selected available-value, in the same order as the variants listed in the Variants header field. </del>  Therefore, Variant-Key MUST be the same length (in comma-separated members) as Variants, and each member MUST correspond in position to

Reviewer comments:
For
Allow a response to associate itself with more than one variant. (moved from mnot/I-D)

Revised text:
3. The Variant-Key HTTP response header field is used to indicate the  <ins> values from the Variants header field that identify the </ins> representation it occurs within.  <ins> Each member of the list contains the selected available-value(s), in the same order as the variants listed in the Variants header field. </ins> Therefore, Variant-Key MUST be the same length (in comma-separated members) as Variants, and each member MUST correspond in position to
Original text:
This header pair indicates that the representation has a "gzip" content-coding and "fr" content-language. <del> Note that Variant-Key is only used to indicate what request attributes are associated with the response containing it; this is different from headers like Content-Encoding, which indicate attributes of the response itself.  In the example above, it might be that a gzip'd version of the French content is not available, in which case the response will include: </del>  <del> even though Content-Encoding does not contain "gzip". </del>  3.1. <del> This algorithm generates a normalised string for Variant-Key, suitable for comparison with values generated by cache. </del>  Given stored-headers, a set of headers from a stored response, a <del> normalised variant-key for that message can be generated by: </del>  Let variant-key-header be a string, the result of selecting all field-values of stored-headers whose field-name is "Variant-Key" and joining them with a comma (","). <del> Remove all whitespace from variant-key-header. </del>  <del> Return variant-key-header. </del>  4.

Reviewer comments:
For
Allow a response to associate itself with more than one variant. (moved from mnot/I-D)

Revised text:
This header pair indicates that the representation has a "gzip" content-coding and "fr" content-language.  <ins> A more complex example involves listing multiple available-values in a list member, to indicate that the response can be used to satisfy requests with any of those values.  For example: </ins>  <ins> indicates that this response can be used for requests whose Content- Encoding algorithm selects "gzip" or "identity", as long as the Content-Language algorithm selects "fr" - perhaps because there is no gzip-compressed French representation. This highlights an important aspect of Variant-Key; it is only used to indicate what request attributes are associated with the response containing it; this is different from headers like Content-Encoding, which indicate attributes of the response itself. </ins> 3.1.  <ins> This algorithm generates a list of normalised strings from Variant- Key, suitable for comparison with values generated by cache. </ins> Given stored-headers, a set of headers from a stored response, a  <ins> normalised list of variant-keys for that message can be generated by: Let variant-keys be an empty list. </ins> Let variant-key-header be a string, the result of selecting all field-values of stored-headers whose field-name is "Variant-Key" and joining them with a comma (",").  <ins> Let value-list be the result of splitting variant-key-header on commas (","). For each value in value-list: Remove all whitespace from value. Let items be the result of splitting value on ";". append items to variant-keys. </ins>  <ins> Return the result of running Compute Possible Keys (find) on variant-keys, an empty string and an empty list. </ins> 4.
Original text:
indicating available-values that are acceptable to the client, in order of preference, greatest to least. <del> Return result of running Find Available Keys (find) on sorted- </del>  variants, an empty string and an empty list. This returns a list of strings suitable for comparing to normalised

Reviewer comments:
For
Allow a response to associate itself with more than one variant. (moved from mnot/I-D)

Revised text:
indicating available-values that are acceptable to the client, in order of preference, greatest to least.  <ins> Return result of running Compute Possible Keys (find) on sorted- </ins> variants, an empty string and an empty list. This returns a list of strings suitable for comparing to normalised
Original text:
4.1. <del> Given sorted-variants, a list of lists, and key-stub, a string </del>  representing a partial key, and possible-keys, a list: <del> Let sorted-values be the first member of sorted-variants. </del>  <del> For each sorted-value in sorted-values: </del>  If key-stub is an empty string, let this-key be a copy of <del> sorted-value. </del>  Otherwise:

Reviewer comments:
For
Allow a response to associate itself with more than one variant. (moved from mnot/I-D)

Revised text:
4.1.  <ins> Given key-facets, a list of lists, and key-stub, a string </ins> representing a partial key, and possible-keys, a list:  <ins> Let values be the first member of key-facets. </ins>  <ins> For each value in values: </ins> If key-stub is an empty string, let this-key be a copy of  <ins> value. </ins> Otherwise:
Original text:
Append a comma (",") to this-key. <del> Append sorted-value to this-key. </del>  <del> Let remaining-variants be a copy of all of the members of sorted-variants except the first. </del>  <del> If remaining-variants is empty, append this-key to possible- keys. </del>  <del> Otherwise, run Find Available Keys on remaining-variants, this- </del>  key and possible-keys. Return possible-keys.

Reviewer comments:
For
Allow a response to associate itself with more than one variant. (moved from mnot/I-D)

Revised text:
Append a comma (",") to this-key.  <ins> Append value to this-key. </ins>  <ins> Let remaining-facets be a copy of all of the members of key- facets except the first. </ins>  <ins> If remaining-facets is empty, append this-key to possible-keys. </ins>  <ins> Otherwise, run Find Available Keys on remaining-facets, this- </ins> key and possible-keys. Return possible-keys.