jiebi/TextFlow huggingface dataset:
Original text:
Such features SHOULD take into account the following aspects of the information exposed: <del> Exposing highly granular data can be used to help identify users across multiple requests to different origins.  Reducing the set of header field values that can be expressed, or restricting them to an enumerated range where the advertised value is close but is not an exact representation of the current value, can improve privacy and reduce risk of linkability by ensuring that the same value is sent by multiple users. The feature SHOULD NOT expose user sensitive information.  To that end, information available to the application, but gated behind specific user actions (e.g. a permission prompt or user activation) SHOULD NOT be exposed as a Client Hint. The feature SHOULD NOT expose user information that changes over time, unless the state change itself is also exposed (e.g. through JavaScript callbacks). </del>  Different features will be positioned in different points in the space between low-entropy, non-sensitive and static information (e.g.

Reviewer comments:
Non substantive change to improve the list's style, after feedback on URL
Landing, as this is non-substantive

Revised text:
Such features SHOULD take into account the following aspects of the information exposed:  <ins> Entropy - Exposing highly granular data can be used to help identify users across multiple requests to different origins. Reducing the set of header field values that can be expressed, or restricting them to an enumerated range where the advertised value is close but is not an exact representation of the current value, can improve privacy and reduce risk of linkability by ensuring that the same value is sent by multiple users. Sensitivity - The feature SHOULD NOT expose user sensitive information.  To that end, information available to the application, but gated behind specific user actions (e.g. a permission prompt or user activation) SHOULD NOT be exposed as a Client Hint. Change over time - The feature SHOULD NOT expose user information that changes over time, unless the state change itself is also exposed (e.g. through JavaScript callbacks). </ins> Different features will be positioned in different points in the space between low-entropy, non-sensitive and static information (e.g.
Original text:
PR 1082: Remove section mentioning Variants. PR 1097: Editorial feedback from mnot. PR 1131: Remove unused references.  8.  References

Reviewer comments:
Non substantive change to improve the list's style, after feedback on URL
Landing, as this is non-substantive

Revised text:
PR 1082: Remove section mentioning Variants. PR 1097: Editorial feedback from mnot. PR 1131: Remove unused references. <ins> PR 1132: Remove nested list. </ins> 8.  References
Original text:
Specification document(s): accept-ch of this document Related information: for Client Hints <del> 7. </del>  <del> 7.1. Issue 168 (make Save-Data extensible) updated ABNF. Issue 163 (CH review feedback) editorial feedback from httpwg list. Issue 153 (NetInfo API citation) added normative reference. 7.2. Issue 200: Moved Key reference to informative. Issue 215: Extended passive fingerprinting and mitigation considerations. Changed document status to experimental. 7.3. Issue 239: Updated reference to CR-css-values-3 Issue 240: Updated reference for Network Information API Issue 241: Consistency in IANA considerations Issue 250: Clarified Accept-CH 7.4. Issue 284: Extended guidance for Accept-CH Issue 308: Editorial cleanup Issue 306: Define Accept-CH-Lifetime 7.5. Issue 361: Removed Downlink Issue 361: Moved Key to appendix, plus other editorial feedback 7.6. Issue 372: Scoped CH opt-in and delivery to secure transports Issue 373: Bind CH opt-in to origin 7.7. Issue 524: Save-Data is now defined by NetInfo spec, dropping PR 775: Removed specific features to be defined in other specifications 7.8. Issue 761: Clarified that the defined headers are response headers. Issue 730: Replaced Key reference with Variants. Issue 700: Replaced ABNF with structured headers. PR 878: Removed Accept-CH-Lifetime based on feedback at IETF 105 7.9. PR 985: Describe the bytesize cost of hints. PR 776: Add Sec- and CH- prefix considerations. PR 1001: Clear CH persistence when cookies are cleared. 7.10. PR 1064: Fix merge issues with "cost of sending hints". 7.11. PR 1072: LC feedback from Julian Reschke. PR 1080: Improve list style. PR 1082: Remove section mentioning Variants. PR 1097: Editorial feedback from mnot. PR 1131: Remove unused references. PR 1132: Remove nested list. 8.  References 8.1.  URIs </del>  [1] https://lists.w3.org/Archives/Public/ietf-http-wg/

Reviewer comments:
Apparently the removal of one appendix now has moved all remaining appendics into the main section. They need to be moved back.
LGTM! Thanks for catching that :)

Revised text:
Specification document(s): accept-ch of this document Related information: for Client Hints  <ins> 7.  References </ins>  <ins> 7.1.  URIs </ins> [1] https://lists.w3.org/Archives/Public/ietf-http-wg/
Original text:
in this document are to be interpreted as described in I-D.ietf- httpbis-semantics. <del> The definition "validator" in this document is to be interpreted as described in Section 10.2 of I-D.ietf-httpbis-semantics. </del>  2.

Reviewer comments:
"validator" refers to validator fields used in preconditions. The term validator fields seems more faithful to the original cache-validators in RFC3230. URL and URL

Revised text:
in this document are to be interpreted as described in I-D.ietf- httpbis-semantics.  <ins> The definition "validator fields" in this document is to be interpreted as described in Section 10.2 of I-D.ietf-httpbis- semantics. </ins> 2.
Original text:
request and response. The resource is specified by the effective request URI and any <del> "validator" contained in the message. </del>  The relationship between Content-Location (see Section 6.2.5 of I- D.ietf-httpbis-semantics) and Digest is demonstrated in post-not-

Reviewer comments:
"validator" refers to validator fields used in preconditions. The term validator fields seems more faithful to the original cache-validators in RFC3230. URL and URL

Revised text:
request and response. The resource is specified by the effective request URI and any  <ins> "validator field" contained in the message. </ins> The relationship between Content-Location (see Section 6.2.5 of I- D.ietf-httpbis-semantics) and Digest is demonstrated in post-not-
Original text:
Serialize the cookie-list into a cookie-string by processing each cookie in the cookie-list in order: <del> Output the cookie's name, the %x3D ("=") character, and the cookie's value. </del>  If there is an unprocessed cookie in the cookie-list, output the characters %x3B and %x20 ("; ").

Reviewer comments:
Nameless cookies serialize as . Valueless cookies serialize as . No, this isn't what we would have chosen if we were designing cookies from scratch, but it's Chromium and Firefox's shipping behavior, and it's reasonable to just accept. This specification change is covered by 0021 and 0022 in the WPT repository (see URL). Closes URL
WDYT, NAME / NAME ?
Step 4 says: However looking at WPT tests (for example [1] / [2]) I can see that when we have (empty name with value ) the expectation is to have back, so perhaps these instructions should include a special case when the cookie name is empty. [1] URL [2] URL
Minor suggestion, OK for me either way.

Revised text:
Serialize the cookie-list into a cookie-string by processing each cookie in the cookie-list in order:  <ins> If the cookies' name is not empty, output the cookie's name followed by the %x3D ("=") character. If the cookies' value is not empty, output the cookie's value. </ins> If there is an unprocessed cookie in the cookie-list, output the characters %x3B and %x20 ("; ").
Original text:
http-only-flag is true, abort these steps and ignore the cookie entirely. <del> If the cookie's secure-only-flag is not set, and the scheme </del>  component of request-uri does not denote a "secure" protocol, then abort these steps and ignore the cookie entirely if the cookie store contains one or more cookies that meet all of the following

Reviewer comments:
The 'secure-only-flag' is never "not set". It is either "true" or "false". This patch fixes two places where we should have been checking for falsity. Closes URL
NAME / NAME WDYT?
Good. I should have sent a PR. :-)
URL Step 8 says: But then Step 12 says: It's impossible to reach step 12 with the not set because it's always set in step 8. I believe a better wording would be .

Revised text:
http-only-flag is true, abort these steps and ignore the cookie entirely.  <ins> If the cookie's secure-only-flag is false, and the scheme </ins> component of request-uri does not denote a "secure" protocol, then abort these steps and ignore the cookie entirely if the cookie store contains one or more cookies that meet all of the following
Original text:
Expired cookies. <del> Cookies whose secure-only-flag is not set, and which share a domain field with more than a predetermined number of other cookies. </del>  Cookies that share a domain field with more than a predetermined number of other cookies.

Reviewer comments:
The 'secure-only-flag' is never "not set". It is either "true" or "false". This patch fixes two places where we should have been checking for falsity. Closes URL
NAME / NAME WDYT?
Good. I should have sent a PR. :-)
URL Step 8 says: But then Step 12 says: It's impossible to reach step 12 with the not set because it's always set in step 8. I believe a better wording would be .

Revised text:
Expired cookies.  <ins> Cookies whose secure-only-flag is false, and which share a domain field with more than a predetermined number of other cookies. </ins> Cookies that share a domain field with more than a predetermined number of other cookies.
Original text:
This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle <del> HTTP header and trailer fields, known as "Structured Fields", or "Structured Headers".  It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values. </del>  Note to Readers

Reviewer comments:
Editorial: add one reference to Structured Trailers in a list of the types, and correct what appears to be a typo of Structured Field --> Structured Trailer.
Happened to spot these when perusing the structured headers spec; apologies if I've misread and the original text was correct.
Thanks!

Revised text:
This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle  <ins> HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers".  It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values. </ins> Note to Readers
Original text:
Identify whether the field is a Structured Header (i.e., it can only be used in the header section - the common case), a <del> Structured Field (only in the trailer section), or a Structured </del>  Field (both). Specify the type of the field value; either List (list),

Reviewer comments:
Editorial: add one reference to Structured Trailers in a list of the types, and correct what appears to be a typo of Structured Field --> Structured Trailer.
Happened to spot these when perusing the structured headers spec; apologies if I've misread and the original text was correct.
Thanks!

Revised text:
Identify whether the field is a Structured Header (i.e., it can only be used in the header section - the common case), a  <ins> Structured Trailer (only in the trailer section), or a Structured </ins> Field (both). Specify the type of the field value; either List (list),
Original text:
Clients and servers that will accept requests for HTTP-layer certificate authentication indicate this using the HTTP/2 <del> "SETTINGS_HTTP_CERT_AUTH" (0xSETTING-TBD) setting. The initial value for the "SETTINGS_HTTP_CERT_AUTH" setting is 0, indicating that the peer does not support HTTP-layer certificate authentication.  If a peer does support HTTP-layer certificate authentication, the value is non-zero. </del>  In order to ensure that the TLS connection is direct to the server, rather than via a TLS-terminating proxy, each side will separately <del> compute and confirm the value of this setting.  The setting is derived from a TLS exporter (see Section 7.5 of RFC8446 and RFC5705 for more details on exporters).  Clients MUST NOT use an early exporter during their 0-RTT flight, but MUST send an updated SETTINGS frame using a regular exporter after the TLS handshake completes. </del>  The exporter is constructed with the following input:

Reviewer comments:
Instead of a four-byte exporter, uses an eight-byte exporter and splits into two values. Support for exchanging server certificates and client certificates is now indicated separately.
The current advertisement scheme does not allow for a client to decide it is willing to implement secondary server certificates but not client certificates or vice versa. It may be worth having two SETTINGS values, one for whether you're willing to do either of the two flows.

Revised text:
Clients and servers that will accept requests for HTTP-layer certificate authentication indicate this using the HTTP/2  <ins> "SETTINGS_HTTP_CLIENT_CERT_AUTH" (0xSETTING-TBD1) and "SETTINGS_HTTP_SERVER_CERT_AUTH" (0xSETTING-TBD2) settings. The initial value for both settings is 0, indicating that the peer does not support HTTP-layer certificate authentication.  If a peer does support HTTP-layer certificate authentication, one or both of the values is non-zero.  "SETTINGS_HTTP_CLIENT_CERT_AUTH" indicates that servers can use certificates for client authentication, while "SETTINGS_HTTP_SERVER_CERT_AUTH" indicates that servers are able to offer additional certificates to demonstrate control over other origin hostnames. </ins> In order to ensure that the TLS connection is direct to the server, rather than via a TLS-terminating proxy, each side will separately  <ins> compute and confirm the value of these settings.  The setting values are derived from a TLS exporter (see Section 7.5 of RFC8446 and RFC5705 for more details on exporters).  Clients MUST NOT use an early exporter during their 0-RTT flight, but MUST send an updated SETTINGS frame using a regular exporter after the TLS handshake completes. </ins> The exporter is constructed with the following input:
Original text:
Context: Empty <del> Length: Four bytes </del>  <del> The resulting exporter is converted to a setting value as: </del>  That is, the most significant bit will always be set, regardless of the value of the exporter.  Each endpoint will compute the expected <del> value from their peer.  If the setting is not received, or if the </del>  value received is not the expected value, the frames defined in this <del> document SHOULD NOT be sent. </del>  2.2. When both peers have advertised support for HTTP-layer certificates <del> as in setting, either party can supply additional certificates into the connection at any time.  This means that clients or servers which predict a certificate will be required could supply the certificate before being asked.  These certificates are available for reference by future "USE_CERTIFICATE" frames. </del>  Certificates supplied by servers can be considered by clients without further action by the server.  A server SHOULD NOT send certificates

Reviewer comments:
Instead of a four-byte exporter, uses an eight-byte exporter and splits into two values. Support for exchanging server certificates and client certificates is now indicated separately.
The current advertisement scheme does not allow for a client to decide it is willing to implement secondary server certificates but not client certificates or vice versa. It may be worth having two SETTINGS values, one for whether you're willing to do either of the two flows.

Revised text:
Context: Empty  <ins> Length: Eight bytes The value of the exporter is split into two four-byte values.  The first four bytes are used for the "SETTINGS_HTTP_CLIENT_CERT_AUTH" value, while the following four bytes are used for the "SETTINGS_HTTP_SERVER_CERT_AUTH" value. </ins>  <ins> Each is converted to a setting value as: </ins> That is, the most significant bit will always be set, regardless of the value of the exporter.  Each endpoint will compute the expected  <ins> values from their peer.  If the setting is not received, or if the </ins> value received is not the expected value, the frames defined in this  <ins> document SHOULD NOT be sent in the indicated direction. </ins> 2.2. When both peers have advertised support for HTTP-layer certificates  <ins> in a given direction as in setting, the indicated endpoint can supply additional certificates into the connection at any time.  That is, if both endpoints have sent "SETTINGS_HTTP_SERVER_CERT_AUTH" and validated the value received from the peer, the server may send certificates.  If both endpoints have sent "SETTINGS_HTTP_CLIENT_CERT_AUTH" and validated the value received from the peer, the client may send certificates. Implementations which predict a certificate will be required could supply the certificate before being asked.  These certificates are available for reference by future "USE_CERTIFICATE" frames. </ins> Certificates supplied by servers can be considered by clients without further action by the server.  A server SHOULD NOT send certificates
Original text:
current connection, but MAY use the ORIGIN frame RFC8336 to indicate that not all covered origins will be served. <del> Likewise, either party can supply a "CERTIFICATE_REQUEST" that outlines parameters of a certificate they might request in the future.  Upon receipt of a "CERTIFICATE_REQUEST", endpoints SHOULD provide a corresponding certificate in anticipation of a request shortly being blocked.  Clients MAY wait for a "CERTIFICATE_NEEDED" frame to assist in associating the certificate request with a particular HTTP transaction. </del>  2.3.

Reviewer comments:
Instead of a four-byte exporter, uses an eight-byte exporter and splits into two values. Support for exchanging server certificates and client certificates is now indicated separately.
The current advertisement scheme does not allow for a client to decide it is willing to implement secondary server certificates but not client certificates or vice versa. It may be worth having two SETTINGS values, one for whether you're willing to do either of the two flows.

Revised text:
current connection, but MAY use the ORIGIN frame RFC8336 to indicate that not all covered origins will be served.  <ins> Likewise, a party can supply a "CERTIFICATE_REQUEST" that outlines parameters of a certificate they might request in the future.  Upon receipt of a "CERTIFICATE_REQUEST", endpoints SHOULD provide a corresponding certificate in anticipation of a request shortly being blocked.  Clients MAY wait for a "CERTIFICATE_NEEDED" frame to assist in associating the certificate request with a particular HTTP transaction. </ins> 2.3.
Original text:
If the TLS certificate does not contain the new origin, but the server has claimed support for that origin (with an ORIGIN frame, see <del> RFC8336) and advertised support for HTTP-layer certificates (see setting), the client MAY send a "CERTIFICATE_REQUEST" frame </del>  describing the desired origin.  The client then sends a "CERTIFICATE_NEEDED" frame for stream zero referencing the request, indicating that the connection cannot be used for that origin until

Reviewer comments:
Instead of a four-byte exporter, uses an eight-byte exporter and splits into two values. Support for exchanging server certificates and client certificates is now indicated separately.
The current advertisement scheme does not allow for a client to decide it is willing to implement secondary server certificates but not client certificates or vice versa. It may be worth having two SETTINGS values, one for whether you're willing to do either of the two flows.

Revised text:
If the TLS certificate does not contain the new origin, but the server has claimed support for that origin (with an ORIGIN frame, see  <ins> RFC8336) and advertised support for HTTP-layer server certificates (see setting), the client MAY send a "CERTIFICATE_REQUEST" frame </ins> describing the desired origin.  The client then sends a "CERTIFICATE_NEEDED" frame for stream zero referencing the request, indicating that the connection cannot be used for that origin until
Original text:
stream zero.  Multiple "CERTIFICATE_NEEDED" frames on any other stream MUST be considered a stream error of type "PROTOCOL_ERROR". <del> The "CERTIFICATE_NEEDED" frame MUST NOT be sent to a peer which has not advertised support for HTTP-layer certificate authentication. </del>  The "CERTIFICATE_NEEDED" frame MUST NOT reference a stream in the "half-closed (local)" or "closed" states RFC7540.  A client that

Reviewer comments:
Instead of a four-byte exporter, uses an eight-byte exporter and splits into two values. Support for exchanging server certificates and client certificates is now indicated separately.
The current advertisement scheme does not allow for a client to decide it is willing to implement secondary server certificates but not client certificates or vice versa. It may be worth having two SETTINGS values, one for whether you're willing to do either of the two flows.

Revised text:
stream zero.  Multiple "CERTIFICATE_NEEDED" frames on any other stream MUST be considered a stream error of type "PROTOCOL_ERROR".  <ins> The "CERTIFICATE_NEEDED" frame MUST NOT be sent to a client which has not advertised the "SETTINGS_HTTP_CLIENT_CERT_AUTH", or to a server which has not advertised the "SETTINGS_HTTP_SERVER_CERT_AUTH" setting. </ins> The "CERTIFICATE_NEEDED" frame MUST NOT reference a stream in the "half-closed (local)" or "closed" states RFC7540.  A client that
Original text:
to a request that has not yet been received, servers SHOULD cache the indication briefly in anticipation of the request. <del> Receipt of more than one unsolicited "USE_CERTIFICATE" frames or an </del>  unsolicited "USE_CERTIFICATE" frame which is not the first in reference to a given stream MUST be treated as a stream error of type "CERTIFICATE_OVERUSED".

Reviewer comments:
Instead of a four-byte exporter, uses an eight-byte exporter and splits into two values. Support for exchanging server certificates and client certificates is now indicated separately.
The current advertisement scheme does not allow for a client to decide it is willing to implement secondary server certificates but not client certificates or vice versa. It may be worth having two SETTINGS values, one for whether you're willing to do either of the two flows.

Revised text:
to a request that has not yet been received, servers SHOULD cache the indication briefly in anticipation of the request.  <ins> Receipt of more than one unsolicited "USE_CERTIFICATE" frame or an </ins> unsolicited "USE_CERTIFICATE" frame which is not the first in reference to a given stream MUST be treated as a stream error of type "CERTIFICATE_OVERUSED".