jiebi/TextFlow huggingface dataset:
Original text:
2.1. <del> Clients control which Client Hints are sent in requests, based on their default settings, user configuration, and server preferences. The client and server can use an opt-in mechanism outlined below to negotiate which header fields need to be sent to allow for efficient content adaption, and optionally use additional mechanisms to negotiate delegation policies that control access of third parties to same header fields. </del>  Implementers SHOULD be aware of the passive fingerprinting implications when implementing support for Client Hints, and follow

Reviewer comments:
LGTM! thx
Some of this is very nit-picky; feel free to do what you like with it... ^ There's something weird going on with tense in this sentence. "Such techniques are expensive... are not portable... and make it hard..." The third doesn't fit with the first two. "Client Hints mitigate the performance concerns..." probably just "Client Hints mitigate performance concerns..." Likewise for "the privacy concerns" below. "This document defines the Client Hints infrastructure, a framework that enables servers to opt-in to specific proactive content negotiation features, which will enable them to adapt their content accordingly." --> "This document defines Client Hints, a framework that enables servers to opt-in to specific proactive content negotiation features, adapting their content accordingly." as a normative reference probably isn't going to fly, given its status. Why is it normative? maybe instead: Be aware that HTTP doesn't require presence of when proactive conneg is in use; if the response is truly uncacheable, it isn't necessary. maybe instead: instead: BTW, nothing is said about precedence between the two different mechanisms; separate issue? The reference to 6454 is spurious, and it's pretty indirect. Perhaps: It's kind of weird to have this list just appear. Perhaps turn these into prose? Put "For example" above the example to introduce it. Limits CH to just "optimisation." Probably should just be:
Thanks for reviewing! :) PR underway The here is conditional on cacheability. Is that OK? We're now considering removing http-equiv support for this: URL Maybe it's best to simply remove that reference here?
Ah, I missed that, sorry. WRT http-equiv; that might be best, then.

Revised text:
2.1.  <ins> Clients choose what Client Hints to send in a request based on their default settings, user configuration, and server preferences expressed in "Accept-CH".  The client and server can use an opt-in mechanism outlined below to negotiate which header fields need to be sent to allow for efficient content adaption, and optionally use additional mechanisms to negotiate delegation policies that control access of third parties to same header fields. </ins> Implementers SHOULD be aware of the passive fingerprinting implications when implementing support for Client Hints, and follow
Original text:
selected response and whether the selected response is appropriate for a later request. <del> Further, depending on the hint used, the server can generate additional response header fields to convey related values to aid client processing. </del>  3.

Reviewer comments:
LGTM! thx
Some of this is very nit-picky; feel free to do what you like with it... ^ There's something weird going on with tense in this sentence. "Such techniques are expensive... are not portable... and make it hard..." The third doesn't fit with the first two. "Client Hints mitigate the performance concerns..." probably just "Client Hints mitigate performance concerns..." Likewise for "the privacy concerns" below. "This document defines the Client Hints infrastructure, a framework that enables servers to opt-in to specific proactive content negotiation features, which will enable them to adapt their content accordingly." --> "This document defines Client Hints, a framework that enables servers to opt-in to specific proactive content negotiation features, adapting their content accordingly." as a normative reference probably isn't going to fly, given its status. Why is it normative? maybe instead: Be aware that HTTP doesn't require presence of when proactive conneg is in use; if the response is truly uncacheable, it isn't necessary. maybe instead: instead: BTW, nothing is said about precedence between the two different mechanisms; separate issue? The reference to 6454 is spurious, and it's pretty indirect. Perhaps: It's kind of weird to have this list just appear. Perhaps turn these into prose? Put "For example" above the example to introduce it. Limits CH to just "optimisation." Probably should just be:
Thanks for reviewing! :) PR underway The here is conditional on cacheability. Is that OK? We're now considering removing http-equiv support for this: URL Maybe it's best to simply remove that reference here?
Ah, I missed that, sorry. WRT http-equiv; that might be best, then.

Revised text:
selected response and whether the selected response is appropriate for a later request.  <ins> Furthermore, the server can generate additional response header fields (as specified by the hint or hints in use) that convey related values to aid client processing. </ins> 3.
Original text:
3.1. <del> The Accept-CH response header field or the equivalent HTML meta element with http-equiv attribute (Section 4.2.5.3 of HTML) indicate server support for particular hints indicated in its value. </del>  Accept-CH is a Structured Header I-D.ietf-httpbis-header-structure. Its value MUST be an sh-list (Section 3.1 of I-D.ietf-httpbis-header-

Reviewer comments:
LGTM! thx
Some of this is very nit-picky; feel free to do what you like with it... ^ There's something weird going on with tense in this sentence. "Such techniques are expensive... are not portable... and make it hard..." The third doesn't fit with the first two. "Client Hints mitigate the performance concerns..." probably just "Client Hints mitigate performance concerns..." Likewise for "the privacy concerns" below. "This document defines the Client Hints infrastructure, a framework that enables servers to opt-in to specific proactive content negotiation features, which will enable them to adapt their content accordingly." --> "This document defines Client Hints, a framework that enables servers to opt-in to specific proactive content negotiation features, adapting their content accordingly." as a normative reference probably isn't going to fly, given its status. Why is it normative? maybe instead: Be aware that HTTP doesn't require presence of when proactive conneg is in use; if the response is truly uncacheable, it isn't necessary. maybe instead: instead: BTW, nothing is said about precedence between the two different mechanisms; separate issue? The reference to 6454 is spurious, and it's pretty indirect. Perhaps: It's kind of weird to have this list just appear. Perhaps turn these into prose? Put "For example" above the example to introduce it. Limits CH to just "optimisation." Probably should just be:
Thanks for reviewing! :) PR underway The here is conditional on cacheability. Is that OK? We're now considering removing http-equiv support for this: URL Maybe it's best to simply remove that reference here?
Ah, I missed that, sorry. WRT http-equiv; that might be best, then.

Revised text:
3.1.  <ins> The Accept-CH response header field indicates server support for the hints indicated in its value. </ins> Accept-CH is a Structured Header I-D.ietf-httpbis-header-structure. Its value MUST be an sh-list (Section 3.1 of I-D.ietf-httpbis-header-
Original text:
interoperability. The rich flexibility of client-driven HTTP/2 prioritization tree <del> building is rarely exercised; experience shows that clients either choose a single model optimized for a web use case (and don't vary it) or do nothing at all.  But every client builds their prioritization tree in a different way, which makes it difficult for servers to understand their intent and act or intervene accordingly. </del>  Many HTTP/2 server implementations do not include support for the priority scheme, some favoring instead bespoke server-driven schemes based on heuristics and other hints, like the content type of <del> resources and the order in which requests arrive.  For example, a server, with knowledge of the document structure, might want to prioritize the delivery of images that are critical to user experience above other images, but below the CSS files.  Since client trees vary, it is impossible for the server to determine how such images should be prioritized against other responses. </del>  The HTTP/2 scheme allows intermediaries to coalesce multiple client trees into a single tree that is used for a single upstream HTTP/2

Reviewer comments:
A few editorial tweaks to improve readability, including some x-refs to the Header / frames. The most contentious change is at L262, the sentence read a bit weird so I juggled it around to make the intent (as I understand it) clearer.
Thank you for the changes. L262 reads better now. Thank you.

Revised text:
interoperability. The rich flexibility of client-driven HTTP/2 prioritization tree  <ins> building is rarely exercised.  Experience has shown that clients tend to choose a single model optimized for a web use case and experiment within the model constraints, or do nothing at all.  Furthermore, many clients build their prioritization tree in a unique way, which makes it difficult for servers to understand their intent and act or intervene accordingly. </ins> Many HTTP/2 server implementations do not include support for the priority scheme, some favoring instead bespoke server-driven schemes based on heuristics and other hints, like the content type of  <ins> resources and the request generation order.  For example, a server, with knowledge of the document structure, might want to prioritize the delivery of images that are critical to user experience above other images, but below the CSS files.  Since client trees vary, it is impossible for the server to determine how such images should be prioritized against other responses. </ins> The HTTP/2 scheme allows intermediaries to coalesce multiple client trees into a single tree that is used for a single upstream HTTP/2
Original text:
the client learns that the HTTP/2 priority scheme is deprecated, it SHOULD stop sending the HTTP/2 priority signals.  If the client learns that the HTTP/2 priority scheme is not deprecated, it SHOULD <del> stop sending PRIORITY_UPDATE frames, but MAY continue sending the Priority header field, as it is an end-to-end signal that might be useful to nodes behind the server that the client is directly connected to. </del>  The SETTINGS frame precedes any priority signal sent from a client in HTTP/2, so a server can determine if it should respect the HTTP/2

Reviewer comments:
A few editorial tweaks to improve readability, including some x-refs to the Header / frames. The most contentious change is at L262, the sentence read a bit weird so I juggled it around to make the intent (as I understand it) clearer.
Thank you for the changes. L262 reads better now. Thank you.

Revised text:
the client learns that the HTTP/2 priority scheme is deprecated, it SHOULD stop sending the HTTP/2 priority signals.  If the client learns that the HTTP/2 priority scheme is not deprecated, it SHOULD  <ins> stop sending PRIORITY_UPDATE frames (h2-update-frame), but MAY continue sending the Priority header field (header-field), as it is an end-to-end signal that might be useful to nodes behind the server that the client is directly connected to. </ins> The SETTINGS frame precedes any priority signal sent from a client in HTTP/2, so a server can determine if it should respect the HTTP/2
Original text:
room for future extensions.  Each key-value pair represents a priority parameter. <del> The Priority HTTP header field is an end-to-end way to transmit this set of parameters when a request or a response is issued.  In order to reprioritize a request, HTTP-version-specific frames are used by clients to transmit the same information on a single hop.  If intermediaries want to specify prioritization on a multiplexed HTTP connection, it SHOULD use a PRIORITY_UPDATE frame and SHOULD NOT change the Priority header field. </del>  In both cases, the set of priority parameters is encoded as a Structured Headers Dictionary (STRUCTURED-HEADERS).

Reviewer comments:
A few editorial tweaks to improve readability, including some x-refs to the Header / frames. The most contentious change is at L262, the sentence read a bit weird so I juggled it around to make the intent (as I understand it) clearer.
Thank you for the changes. L262 reads better now. Thank you.

Revised text:
room for future extensions.  Each key-value pair represents a priority parameter.  <ins> The Priority HTTP header field (header-field) is an end-to-end way to transmit this set of parameters when a request or a response is issued.  In order to reprioritize a request, HTTP-version-specific frames (h2-update-frame and h3-update-frame) are used by clients to transmit the same information on a single hop.  If intermediaries want to specify prioritization on a multiplexed HTTP connection, they SHOULD use a PRIORITY_UPDATE frame and SHOULD NOT change the Priority header field. </ins> In both cases, the set of priority parameters is encoded as a Structured Headers Dictionary (STRUCTURED-HEADERS).
Original text:
providing those responses in parallel would be more helpful to the client than delivering the responses one by one. <del> There is no benefit in providing multiple responses with their incremental parameters set to false in parallel, as the client is not going to process those responses incrementally.  Serving non- incremental responses one by one, in the order in which those requests were generated is considered to be the best strategy. </del>  The following example shows a request for a JPEG file with the urgency parameter set to "5" and the incremental parameter set to

Reviewer comments:
A few editorial tweaks to improve readability, including some x-refs to the Header / frames. The most contentious change is at L262, the sentence read a bit weird so I juggled it around to make the intent (as I understand it) clearer.
Thank you for the changes. L262 reads better now. Thank you.

Revised text:
providing those responses in parallel would be more helpful to the client than delivering the responses one by one.  <ins> If a client makes concurrent requests with the incremental parameter set to false, there is no benefit serving responses in parallel because the client is not going to process those responses incrementally.  Serving non-incremental responses one by one, in the order in which those requests were generated is considered to be the best strategy. </ins> The following example shows a request for a JPEG file with the urgency parameter set to "5" and the incremental parameter set to
Original text:
the Priority request header field set to "u=7" (background).  Then, when the user navigates to a page which references the new JavaScript file, while the prefetch is in progress, the browser would send a <del> reprioritization frame with the priority field value set to "u=0" (prerequisite). </del>  In HTTP/2 and HTTP/3, after a request message is sent on a stream, the stream transitions to a state that prevents the client from

Reviewer comments:
A few editorial tweaks to improve readability, including some x-refs to the Header / frames. The most contentious change is at L262, the sentence read a bit weird so I juggled it around to make the intent (as I understand it) clearer.
Thank you for the changes. L262 reads better now. Thank you.

Revised text:
the Priority request header field set to "u=7" (background).  Then, when the user navigates to a page which references the new JavaScript file, while the prefetch is in progress, the browser would send a  <ins> reprioritization frame with the priority field value set to "u=0". </ins> In HTTP/2 and HTTP/3, after a request message is sent on a stream, the stream transitions to a state that prevents the client from
Original text:
Response:  3.  Digest algorithm values are used to indicate a specific digest computation.  For some algorithms, one or more parameters may be supplied.

Reviewer comments:
Moves Digest Algorithms down
I verified the formatting here URL
This looks good but note the similar comment I made elsewhere about the trailing spaces after colons e.g. we need or else the formatting seems to get screwed up

Revised text:
Response: <ins> 2.1. A representation digest is the value of the output of a digest algorithm, together with an indication of the algorithm used (and any parameters). As explained in resource-representation the digest is computed on the entire selected "representation data" of the resource defined in RFC7231: The encoded digest output uses the encoding format defined for the specific digest-algorithm. 2.1.1. The "sha-256" digest-algorithm uses base64 encoding.  Note that digest-algorithm values are case insensitive. The "UNIXsum" digest-algorithm uses ASCII string of decimal digits. </ins> 3. <ins> The Want-Digest message header field indicates the sender's desire to receive a representation digest on messages associated with the request URI and representation metadata. If a digest-algorithm is not accompanied by a qvalue, it is treated as if its associated qvalue were 1.0. The sender is willing to accept a digest-algorithm if and only if it is listed in a Want-Digest header field of a message, and its qvalue is non-zero. If multiple acceptable digest-algorithm values are given, the sender's preferred digest-algorithm is the one (or ones) with the highest qvalue. Two examples of its use are 4. The Digest header field provides a digest of the representation data. "Representation data" might be: fully contained in the message body, partially-contained in the message body, or not at all contained in the message body. The resource is specified by the effective request URI and any "validator" contained in the message. For example, in a response to a HEAD request, the digest is calculated using the representation data that would have been enclosed in the payload body if the same request had been a GET. Digest can be used in requests too. The "Digest" value depends on the representation metadata. A Digest header field MAY contain multiple representation-data-digest values.  This could be useful for responses expected to reside in caches shared by users with different browsers, for example. A recipient MAY ignore any or all of the representation-data-digests in a Digest header field.  This allows the recipient to chose which digest-algorithm(s) to use for validation instead of verifying every received representation-data-digest. A sender MAY send a representation-data-digest using a digest- algorithm without knowing whether the recipient supports the digest- algorithm, or even knowing that the recipient will ignore it. Two examples of its use are 5. </ins> Digest algorithm values are used to indicate a specific digest computation.  For some algorithms, one or more parameters may be supplied.
Original text:
MUST either be represented as a quoted string, or MUST NOT include ";" or "," in the character sets used for the encoding. <del> 3.1. A representation digest is the value of the output of a digest algorithm, together with an indication of the algorithm used (and any parameters). As explained in resource-representation the digest is computed on the entire selected "representation data" of the resource defined in RFC7231: The encoded digest output uses the encoding format defined for the specific digest-algorithm. 3.1.1. The "sha-256" digest-algorithm uses base64 encoding.  Note that digest-algorithm values are case insensitive. The "UNIXsum" digest-algorithm uses ASCII string of decimal digits. 4. The Want-Digest message header field indicates the sender's desire to receive a representation digest on messages associated with the request URI and representation metadata. If a digest-algorithm is not accompanied by a qvalue, it is treated as if its associated qvalue were 1.0. The sender is willing to accept a digest-algorithm if and only if it is listed in a Want-Digest header field of a message, and its qvalue is non-zero. If multiple acceptable digest-algorithm values are given, the sender's preferred digest-algorithm is the one (or ones) with the highest qvalue. Two examples of its use are 5. The Digest header field provides a digest of the representation data. "Representation data" might be: fully contained in the message body, partially-contained in the message body, or not at all contained in the message body. The resource is specified by the effective request URI and any "validator" contained in the message. For example, in a response to a HEAD request, the digest is calculated using the representation data that would have been enclosed in the payload body if the same request had been a GET. Digest can be used in requests too. The "Digest" value depends on the representation metadata. A Digest header field MAY contain multiple representation-data-digest values.  This could be useful for responses expected to reside in caches shared by users with different browsers, for example. A recipient MAY ignore any or all of the representation-data-digests in a Digest header field.  This allows the recipient to chose which digest-algorithm(s) to use for validation instead of verifying every received representation-data-digest. A sender MAY send a representation-data-digest using a digest- algorithm without knowing whether the recipient supports the digest- algorithm, or even knowing that the recipient will ignore it. Two examples of its use are </del> 6. POST and PATCH requests may appear to convey partial representations

Reviewer comments:
Moves Digest Algorithms down
I verified the formatting here URL
This looks good but note the similar comment I made elsewhere about the trailing spaces after colons e.g. we need or else the formatting seems to get screwed up

Revised text:
MUST either be represented as a quoted string, or MUST NOT include ";" or "," in the character sets used for the encoding.  6. POST and PATCH requests may appear to convey partial representations
Original text:
7.11. <del> PR 1072: LC feedback from Julian Reschke </del>  8.  References

Reviewer comments:
This is a simple editorial change of the "changes" section, to add the latest PRs.
Landing as this change is not substantive

Revised text:
7.11.  <ins> PR 1072: LC feedback from Julian Reschke. PR 1080: Improve list style. PR 1082: Remove section mentioning Variants. PR 1097: Editorial feedback from mnot. </ins> 8.  References