jiebi/TextFlow huggingface dataset:
Original text:
If Accept-CH-Lifetime occurs in a message more than once, the last value overrides all previous occurrences. <del> 2.2.3. </del>  When selecting an optimized response based on one or more Client Hints, and if the resource is cacheable, the server needs to generate

Reviewer comments:
NAME - can you take a look and see if that clarifies things?
This seems helpful given what's currently in the spec. However, I think some of the material I was talking about when I filed is no longer there. But I suspect that material may now be in other specs, and could perhaps still gain from being clarified at its current location.
I've been reading Client Hints (both and the ), and I'm having a little trouble understanding how things fit together in terms of which header fields are sent when and lead to what. My confusion started when I looked at the section and noticed (to my surprise) that was being registered as both a request header field and a response header field (when, having read the spec quickly, I was expecting it to be only a response header field, and wasn't sure what it would mean as a request header field). Then I looked back over the spec, and noticed that section 2 of the spec is called but that the entirety of the section appears (I think) to be about response header fields. I think it would help the spec be easier to understand if it: more carefully distinguished between request header fields and response header fields, and more clearly explained what the request header field is.
lgtm, thank you!

Revised text:
If Accept-CH-Lifetime occurs in a message more than once, the last value overrides all previous occurrences.  <ins> 3.2.1. </ins> When selecting an optimized response based on one or more Client Hints, and if the resource is cacheable, the server needs to generate
Original text:
Above example indicates that the cache key needs to include the Sec- CH-Example and Sec-CH-Example-2 header fields. <del> 3. </del>  The request header fields defined in this document, and those that extend it, expose information about the user's environment to enable

Reviewer comments:
NAME - can you take a look and see if that clarifies things?
This seems helpful given what's currently in the spec. However, I think some of the material I was talking about when I filed is no longer there. But I suspect that material may now be in other specs, and could perhaps still gain from being clarified at its current location.
I've been reading Client Hints (both and the ), and I'm having a little trouble understanding how things fit together in terms of which header fields are sent when and lead to what. My confusion started when I looked at the section and noticed (to my surprise) that was being registered as both a request header field and a response header field (when, having read the spec quickly, I was expecting it to be only a response header field, and wasn't sure what it would mean as a request header field). Then I looked back over the spec, and noticed that section 2 of the spec is called but that the entirety of the section appears (I think) to be about response header fields. I think it would help the spec be easier to understand if it: more carefully distinguished between request header fields and response header fields, and more clearly explained what the request header field is.
lgtm, thank you!

Revised text:
Above example indicates that the cache key needs to include the Sec- CH-Example and Sec-CH-Example-2 header fields.  <ins> 4. </ins> The request header fields defined in this document, and those that extend it, expose information about the user's environment to enable
Original text:
clear persisted opt-in preferences when any one of site data, browsing history, browsing cache, or similar, are cleared. <del> 4. </del>  This document defines the "Accept-CH" and "Accept-CH-Lifetime" HTTP response fields, and registers them in the Permanent Message Header Fields registry. <del> 4.1. </del>  Header field name: Accept-CH Applicable protocol: HTTP

Reviewer comments:
NAME - can you take a look and see if that clarifies things?
This seems helpful given what's currently in the spec. However, I think some of the material I was talking about when I filed is no longer there. But I suspect that material may now be in other specs, and could perhaps still gain from being clarified at its current location.
I've been reading Client Hints (both and the ), and I'm having a little trouble understanding how things fit together in terms of which header fields are sent when and lead to what. My confusion started when I looked at the section and noticed (to my surprise) that was being registered as both a request header field and a response header field (when, having read the spec quickly, I was expecting it to be only a response header field, and wasn't sure what it would mean as a request header field). Then I looked back over the spec, and noticed that section 2 of the spec is called but that the entirety of the section appears (I think) to be about response header fields. I think it would help the spec be easier to understand if it: more carefully distinguished between request header fields and response header fields, and more clearly explained what the request header field is.
lgtm, thank you!

Revised text:
clear persisted opt-in preferences when any one of site data, browsing history, browsing cache, or similar, are cleared.  <ins> 5. </ins> This document defines the "Accept-CH" and "Accept-CH-Lifetime" HTTP response fields, and registers them in the Permanent Message Header Fields registry.  <ins> 5.1. </ins> Header field name: Accept-CH Applicable protocol: HTTP
Original text:
Specification document(s): accept-ch of this document Related information: for Client Hints <del> 4.2. </del>  Header field name: Accept-CH-Lifetime Applicable protocol: HTTP

Reviewer comments:
NAME - can you take a look and see if that clarifies things?
This seems helpful given what's currently in the spec. However, I think some of the material I was talking about when I filed is no longer there. But I suspect that material may now be in other specs, and could perhaps still gain from being clarified at its current location.
I've been reading Client Hints (both and the ), and I'm having a little trouble understanding how things fit together in terms of which header fields are sent when and lead to what. My confusion started when I looked at the section and noticed (to my surprise) that was being registered as both a request header field and a response header field (when, having read the spec quickly, I was expecting it to be only a response header field, and wasn't sure what it would mean as a request header field). Then I looked back over the spec, and noticed that section 2 of the spec is called but that the entirety of the section appears (I think) to be about response header fields. I think it would help the spec be easier to understand if it: more carefully distinguished between request header fields and response header fields, and more clearly explained what the request header field is.
lgtm, thank you!

Revised text:
Specification document(s): accept-ch of this document Related information: for Client Hints  <ins> 5.2. </ins> Header field name: Accept-CH-Lifetime Applicable protocol: HTTP
Original text:
Specification document(s): accept-ch-lifetime of this document Related information: for Client Hints <del> 5.  References </del>  <del> 5.1.  URIs </del>  [1] https://lists.w3.org/Archives/Public/ietf-http-wg/

Reviewer comments:
NAME - can you take a look and see if that clarifies things?
This seems helpful given what's currently in the spec. However, I think some of the material I was talking about when I filed is no longer there. But I suspect that material may now be in other specs, and could perhaps still gain from being clarified at its current location.
I've been reading Client Hints (both and the ), and I'm having a little trouble understanding how things fit together in terms of which header fields are sent when and lead to what. My confusion started when I looked at the section and noticed (to my surprise) that was being registered as both a request header field and a response header field (when, having read the spec quickly, I was expecting it to be only a response header field, and wasn't sure what it would mean as a request header field). Then I looked back over the spec, and noticed that section 2 of the spec is called but that the entirety of the section appears (I think) to be about response header fields. I think it would help the spec be easier to understand if it: more carefully distinguished between request header fields and response header fields, and more clearly explained what the request header field is.
lgtm, thank you!

Revised text:
Specification document(s): accept-ch-lifetime of this document Related information: for Client Hints  <ins> 6.  References </ins>  <ins> 6.1.  URIs </ins> [1] https://lists.w3.org/Archives/Public/ietf-http-wg/
Original text:
Extra Parameters: <del> details: a sh-string containing the checksum or SPKI of the certificate received from the next hop. Recommended HTTP status code: 502 3.26. Name: tls_unexpected_peer_identity Description: The intermediary received peer certificate with unexpected identity (e.g., Subject Alternative Name doesn't match) during TLS handshake with the next hop. </del>  <del> Extra Parameters: </del>  <del> details: a sh-string containing the identity of the next hop. </del>  Recommended HTTP status code: 502 <del> 3.27. </del>  Name: tls_missing_proxy_certificate

Reviewer comments:
Signed-off-by: Piotr Sikora
cc NAME
This field uses for a specific purpose, but that's already in the generic parameters. Suggest or similar. /cc NAME
Looks like has the same issue. Should we use for both? Note that the identifier is context-based, since if proxy configured SHA256-based validation, then would be , if it configured SPKI-based validation, then would be , etc. We could also use and instead of (and for ), but that doesn't seem very future-proof. What do you think?
Hmm, that's awkward. Maybe two fields? E.g., : [, ... ] : ... Is there a registry we can refer to, maybe?
I'm afraid that there isn't any registry that we can refer to, at least none that I know of. (opaque type) and (opaque value) seem a bit awkward. Wouldn't it be easier to just have and params? Also, in Envoy, we actually configure list of acceptable and values, and matching against any of them works, so we should probably emit both of them anyway. I could envision merging and into a single status type that lists all 3 params, e.g. See . What do you think?
Better than what we had :)

Revised text:
Extra Parameters:  <ins> identity: a sh-string containing a comma-separated list of Subject Alternative Names from the certificate received from the next hop. </ins>  <ins> sha256: a sh-string containing the hex-encoded SHA-256 of the certificate received from the next hop. </ins>  <ins> spki: a sh-string containing the base64-encoded SHA-256 of the Subject Public Key Info (SPKI) from the certificate received from the next hop. </ins> Recommended HTTP status code: 502  <ins> 3.26. </ins> Name: tls_missing_proxy_certificate
Original text:
Recommended HTTP status code: 500 <del> 3.28. </del>  Name: tls_rejected_proxy_certificate

Reviewer comments:
Signed-off-by: Piotr Sikora
cc NAME
This field uses for a specific purpose, but that's already in the generic parameters. Suggest or similar. /cc NAME
Looks like has the same issue. Should we use for both? Note that the identifier is context-based, since if proxy configured SHA256-based validation, then would be , if it configured SPKI-based validation, then would be , etc. We could also use and instead of (and for ), but that doesn't seem very future-proof. What do you think?
Hmm, that's awkward. Maybe two fields? E.g., : [, ... ] : ... Is there a registry we can refer to, maybe?
I'm afraid that there isn't any registry that we can refer to, at least none that I know of. (opaque type) and (opaque value) seem a bit awkward. Wouldn't it be easier to just have and params? Also, in Envoy, we actually configure list of acceptable and values, and matching against any of them works, so we should probably emit both of them anyway. I could envision merging and into a single status type that lists all 3 params, e.g. See . What do you think?
Better than what we had :)

Revised text:
Recommended HTTP status code: 500  <ins> 3.27. </ins> Name: tls_rejected_proxy_certificate
Original text:
Recommended HTTP status code: 500 <del> 3.29. </del>  Name: tls_error

Reviewer comments:
Signed-off-by: Piotr Sikora
cc NAME
This field uses for a specific purpose, but that's already in the generic parameters. Suggest or similar. /cc NAME
Looks like has the same issue. Should we use for both? Note that the identifier is context-based, since if proxy configured SHA256-based validation, then would be , if it configured SPKI-based validation, then would be , etc. We could also use and instead of (and for ), but that doesn't seem very future-proof. What do you think?
Hmm, that's awkward. Maybe two fields? E.g., : [, ... ] : ... Is there a registry we can refer to, maybe?
I'm afraid that there isn't any registry that we can refer to, at least none that I know of. (opaque type) and (opaque value) seem a bit awkward. Wouldn't it be easier to just have and params? Also, in Envoy, we actually configure list of acceptable and values, and matching against any of them works, so we should probably emit both of them anyway. I could envision merging and into a single status type that lists all 3 params, e.g. See . What do you think?
Better than what we had :)

Revised text:
Recommended HTTP status code: 500  <ins> 3.28. </ins> Name: tls_error
Original text:
Recommended HTTP status code: 502 <del> 3.30. </del>  Name: http_request_error

Reviewer comments:
Signed-off-by: Piotr Sikora
cc NAME
This field uses for a specific purpose, but that's already in the generic parameters. Suggest or similar. /cc NAME
Looks like has the same issue. Should we use for both? Note that the identifier is context-based, since if proxy configured SHA256-based validation, then would be , if it configured SPKI-based validation, then would be , etc. We could also use and instead of (and for ), but that doesn't seem very future-proof. What do you think?
Hmm, that's awkward. Maybe two fields? E.g., : [, ... ] : ... Is there a registry we can refer to, maybe?
I'm afraid that there isn't any registry that we can refer to, at least none that I know of. (opaque type) and (opaque value) seem a bit awkward. Wouldn't it be easier to just have and params? Also, in Envoy, we actually configure list of acceptable and values, and matching against any of them works, so we should probably emit both of them anyway. I could envision merging and into a single status type that lists all 3 params, e.g. See . What do you think?
Better than what we had :)

Revised text:
Recommended HTTP status code: 502  <ins> 3.29. </ins> Name: http_request_error
Original text:
Recommended HTTP status code: The applicable 4xx status code <del> 3.31. </del>  Name: http_request_denied

Reviewer comments:
Signed-off-by: Piotr Sikora
cc NAME
This field uses for a specific purpose, but that's already in the generic parameters. Suggest or similar. /cc NAME
Looks like has the same issue. Should we use for both? Note that the identifier is context-based, since if proxy configured SHA256-based validation, then would be , if it configured SPKI-based validation, then would be , etc. We could also use and instead of (and for ), but that doesn't seem very future-proof. What do you think?
Hmm, that's awkward. Maybe two fields? E.g., : [, ... ] : ... Is there a registry we can refer to, maybe?
I'm afraid that there isn't any registry that we can refer to, at least none that I know of. (opaque type) and (opaque value) seem a bit awkward. Wouldn't it be easier to just have and params? Also, in Envoy, we actually configure list of acceptable and values, and matching against any of them works, so we should probably emit both of them anyway. I could envision merging and into a single status type that lists all 3 params, e.g. See . What do you think?
Better than what we had :)

Revised text:
Recommended HTTP status code: The applicable 4xx status code  <ins> 3.30. </ins> Name: http_request_denied
Original text:
Recommended HTTP status code: 400 <del> 3.32. </del>  Name: http_upgrade_failed

Reviewer comments:
Signed-off-by: Piotr Sikora
cc NAME
This field uses for a specific purpose, but that's already in the generic parameters. Suggest or similar. /cc NAME
Looks like has the same issue. Should we use for both? Note that the identifier is context-based, since if proxy configured SHA256-based validation, then would be , if it configured SPKI-based validation, then would be , etc. We could also use and instead of (and for ), but that doesn't seem very future-proof. What do you think?
Hmm, that's awkward. Maybe two fields? E.g., : [, ... ] : ... Is there a registry we can refer to, maybe?
I'm afraid that there isn't any registry that we can refer to, at least none that I know of. (opaque type) and (opaque value) seem a bit awkward. Wouldn't it be easier to just have and params? Also, in Envoy, we actually configure list of acceptable and values, and matching against any of them works, so we should probably emit both of them anyway. I could envision merging and into a single status type that lists all 3 params, e.g. See . What do you think?
Better than what we had :)

Revised text:
Recommended HTTP status code: 400  <ins> 3.31. </ins> Name: http_upgrade_failed
Original text:
Recommended HTTP status code: 502 <del> 3.33. </del>  Name: proxy_internal_response

Reviewer comments:
Signed-off-by: Piotr Sikora
cc NAME
This field uses for a specific purpose, but that's already in the generic parameters. Suggest or similar. /cc NAME
Looks like has the same issue. Should we use for both? Note that the identifier is context-based, since if proxy configured SHA256-based validation, then would be , if it configured SPKI-based validation, then would be , etc. We could also use and instead of (and for ), but that doesn't seem very future-proof. What do you think?
Hmm, that's awkward. Maybe two fields? E.g., : [, ... ] : ... Is there a registry we can refer to, maybe?
I'm afraid that there isn't any registry that we can refer to, at least none that I know of. (opaque type) and (opaque value) seem a bit awkward. Wouldn't it be easier to just have and params? Also, in Envoy, we actually configure list of acceptable and values, and matching against any of them works, so we should probably emit both of them anyway. I could envision merging and into a single status type that lists all 3 params, e.g. See . What do you think?
Better than what we had :)

Revised text:
Recommended HTTP status code: 502  <ins> 3.32. </ins> Name: proxy_internal_response
Original text:
Recommended HTTP status code: <del> 3.34. </del>  Name: proxy_internal_error

Reviewer comments:
Signed-off-by: Piotr Sikora
cc NAME
This field uses for a specific purpose, but that's already in the generic parameters. Suggest or similar. /cc NAME
Looks like has the same issue. Should we use for both? Note that the identifier is context-based, since if proxy configured SHA256-based validation, then would be , if it configured SPKI-based validation, then would be , etc. We could also use and instead of (and for ), but that doesn't seem very future-proof. What do you think?
Hmm, that's awkward. Maybe two fields? E.g., : [, ... ] : ... Is there a registry we can refer to, maybe?
I'm afraid that there isn't any registry that we can refer to, at least none that I know of. (opaque type) and (opaque value) seem a bit awkward. Wouldn't it be easier to just have and params? Also, in Envoy, we actually configure list of acceptable and values, and matching against any of them works, so we should probably emit both of them anyway. I could envision merging and into a single status type that lists all 3 params, e.g. See . What do you think?
Better than what we had :)

Revised text:
Recommended HTTP status code:  <ins> 3.33. </ins> Name: proxy_internal_error
Original text:
Recommended HTTP status code: 500 <del> 3.35. </del>  Name: proxy_loop_detected

Reviewer comments:
Signed-off-by: Piotr Sikora
cc NAME
This field uses for a specific purpose, but that's already in the generic parameters. Suggest or similar. /cc NAME
Looks like has the same issue. Should we use for both? Note that the identifier is context-based, since if proxy configured SHA256-based validation, then would be , if it configured SPKI-based validation, then would be , etc. We could also use and instead of (and for ), but that doesn't seem very future-proof. What do you think?
Hmm, that's awkward. Maybe two fields? E.g., : [, ... ] : ... Is there a registry we can refer to, maybe?
I'm afraid that there isn't any registry that we can refer to, at least none that I know of. (opaque type) and (opaque value) seem a bit awkward. Wouldn't it be easier to just have and params? Also, in Envoy, we actually configure list of acceptable and values, and matching against any of them works, so we should probably emit both of them anyway. I could envision merging and into a single status type that lists all 3 params, e.g. See . What do you think?
Better than what we had :)

Revised text:
Recommended HTTP status code: 500  <ins> 3.34. </ins> Name: proxy_loop_detected
Original text:
Description: The MD5 algorithm, as specified in RFC1321.  The output of this algorithm is encoded using the base64 encoding <del> RFC4648.  The MD5 algorithm is NOT RECOMMENDED as it's now </del>  vulnerable to collision attacks CMU-836068. Reference: RFC1321, RFC4648, this document. <del> Status: obsoleted </del> 

Reviewer comments:
States that MUST NOT be used. Sets the MD5 status to deprecated.
Looks good, thanks!

Revised text:
Description: The MD5 algorithm, as specified in RFC1321.  The output of this algorithm is encoded using the base64 encoding  <ins> RFC4648.  The MD5 algorithm MUST NOT be used as it's now </ins> vulnerable to collision attacks CMU-836068. Reference: RFC1321, RFC4648, this document.  <ins> Status: deprecated </ins>
Original text:
6. <del> The MD5 algorithm is NOT RECOMMENDED as it's now vulnerable to </del>  collision attacks CMU-836068. The SHA algorithm is NOT RECOMMENDED as it's now vulnerable to

Reviewer comments:
States that MUST NOT be used. Sets the MD5 status to deprecated.
Looks good, thanks!

Revised text:
6.  <ins> The MD5 algorithm MUST NOT be used as it's now vulnerable to </ins> collision attacks CMU-836068. The SHA algorithm is NOT RECOMMENDED as it's now vulnerable to
Original text:
However, these rely on collision-resistance for their security proofs CMU-836068.  The MD5 and SHA-1 algorithms are vulnerable to <del> collisions attacks and they are NOT RECOMMENDED. </del>  8.3.

Reviewer comments:
States that MUST NOT be used. Sets the MD5 status to deprecated.
Looks good, thanks!

Revised text:
However, these rely on collision-resistance for their security proofs CMU-836068.  The MD5 and SHA-1 algorithms are vulnerable to  <ins> collisions attacks, so MD5 MUST NOT be used and SHA-1 is NOT RECOMMENDED. </ins> 8.3.
Original text:
9.7. <del> The status has been updated to "obsoleted" for both "SHA" and "MD5", and their descriptions states that those algorithms are NOT RECOMMENDED. </del>  The status for all other algorithms have been updated to "standard".

Reviewer comments:
States that MUST NOT be used. Sets the MD5 status to deprecated.
Looks good, thanks!

Revised text:
9.7.  <ins> The status of "MD5" has been updated to "deprecated", and its description states that this algoritm MUST NOT be used. The status of "SHA" has been updated to "obsoleted", and its description states that this algorithm is NOT RECOMMENDED. </ins> The status for all other algorithms have been updated to "standard".