jiebi/TextFlow huggingface dataset:
Original text:
The value is encoded as an sf-integer.  The default value is 3. <del> This parameter indicates the sender's recommendation, based on the expectation that the server would transmit HTTP responses in the order of their urgency values if possible.  The smaller the value, the higher the precedence. </del>  The following example shows a request for a CSS file with the urgency set to "0":

Reviewer comments:
. By replacing "sender" with "client", we make the urgency and incremental section more consistent with how they discuss these concepts.
Paraphrasing NAME feedback, in S 4.1 we say we might consider clearer statements about the actors are i.e. who sends this parameter, and who actions it.
For clarity, it's mainly the term "sender" in "sender's recommendations" that I find unclear here, since the server can also "send" Priority information, where it doesn't always reflect the server's "recommendation" when doing so (e.g., sometimes it's just echo'ing the client's value).
We don't really need to hammer home the "recommendation" concept, that's explained elsewhere in the document. I'll propose an editorial change to this text to focus on the thing we care about

Revised text:
The value is encoded as an sf-integer.  The default value is 3.  <ins> Endpoints use this parameter to communicate their view of the precedence of HTTP responses.  The chosen value of urgency can be based on the expectation that servers might use this information to transmit HTTP responses in the order of their urgency.  The smaller the value, the higher the precedence. </ins> The following example shows a request for a CSS file with the urgency set to "0":
Original text:
If a client makes concurrent requests with the incremental parameter set to false, there is no benefit serving responses with the same <del> urgency in parallel because the client is not going to process those </del>  responses incrementally.  Serving non-incremental responses with the same urgency one by one, in the order in which those requests were generated is considered to be the best strategy. If a client makes concurrent requests with the incremental parameter <del> set to true, serving requests with the same urgency in parallel might be beneficial.  Doing this distributes the connection bandwidth, meaning that responses take longer to complete.  Incremental delivery is most useful where multiple partial responses might provide some value to clients ahead of a complete response being available. </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:
Paraphrasing NAME in S 4.2 we say Resources are not sent in parallel (implying "at the same time"), but rather multiplexed vs sequential. We don't want to leave the impression that setting i=1 would give better perf due to actual "parallel" sending.

Revised text:
If a client makes concurrent requests with the incremental parameter set to false, there is no benefit serving responses with the same  <ins> urgency concurrently because the client is not going to process those </ins> responses incrementally.  Serving non-incremental responses with the same urgency one by one, in the order in which those requests were generated is considered to be the best strategy. If a client makes concurrent requests with the incremental parameter  <ins> set to true, serving requests with the same urgency concurrently might be beneficial.  Doing this distributes the connection bandwidth, meaning that responses take longer to complete. Incremental delivery is most useful where multiple partial responses might provide some value to clients ahead of a complete response being available. </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:
about how a server should use size, type or any other input to decide how to prioritize. <del> The following examples demonstrate how a server that strictly abides the scheduling guidance based on urgency and request generation order could find that early requests prevent serving of later requests. </del>  At the same urgency level, a non-incremental request for a large resource followed by an incremental request for a small resource.

Reviewer comments:
As described on the issue, there are many permutations of this and we'll encounter heat death if we try to explain everything. This change pulls a Captain Kirk.
Thank you!
Paraphrasing NAME S 10 is still somewhat ambiguous on what to do if you have both non-incremental and incremental resources at the same urgency level. There is no single correct answer here, and the "starvation" text partially addresses this, but I'm not sure that's enough. Maybe explicitly pointing out the situation and saying no guidance is given? Editors suggestion here is NOT to add any more normative guidance but to provide a better linkage between the the paragraphs that touch on these matters.
I still personally feel it would be good to call out this specific situation, since it's an edge case you probably -will- encounter and for which you need to (in my opinion) make a conscious decision. The starvation text already calls out other examples, so I feel this edge case could also use some text.

Revised text:
about how a server should use size, type or any other input to decide how to prioritize.  <ins> There can be scenarios where a server will need to schedule multiple incremental and non-incremental responses at the same urgency level. Strictly abiding the scheduling guidance based on urgency and request generation order might lead to sub-optimal results at the client, as early non-incremental responses might prevent serving of incremental responses issued later.  The following are examples of such challenges. </ins> At the same urgency level, a non-incremental request for a large resource followed by an incremental request for a small resource.
Original text:
Digest field calculations are tied to the "Content-Encoding" and "Content-Type" header fields.  Therefore, a given resource may have <del> multiple different checksum values when transferred with HTTP.  To allow both parties to exchange a simple checksum with no content codings (see Section 8.4.1 of SEMANTICS), two more digest-algorithms are added ("id-sha-256" and "id-sha-512"). </del>  Digest fields do not provide integrity for HTTP messages or fields. However, they can be combined with other mechanisms that protect

Reviewer comments:
strip out id-* algorithms from this specid- are complex to address in this document they will be better addressed in URL
Fix typo. Thx NAME I'll wait a couple of days to allow further feedback :)
LGTM modulo the comment I made

Revised text:
Digest field calculations are tied to the "Content-Encoding" and "Content-Type" header fields.  Therefore, a given resource may have  <ins> multiple different checksum values when transferred with HTTP. </ins> Digest fields do not provide integrity for HTTP messages or fields. However, they can be combined with other mechanisms that protect
Original text:
Status: insecure <del> To allow sender and recipient to provide a checksum which is independent from "Content-Encoding", the following additional digest- algorithms are defined: Description: The sha-512 digest of the representation data of the resource when no content coding is applied Reference: RFC6234, RFC4648, this document. Status: standard Description: The sha-256 digest of the representation data of the resource when no content coding is applied Reference: RFC6234, RFC4648, this document. Status: standard </del> 7. When the representation enclosed in a state-changing request does not

Reviewer comments:
strip out id-* algorithms from this specid- are complex to address in this document they will be better addressed in URL
Fix typo. Thx NAME I'll wait a couple of days to allow further feedback :)
LGTM modulo the comment I made

Revised text:
Status: insecure  7. When the representation enclosed in a state-changing request does not
Original text:
because user-agent can validate that resource retrieval succeeded before handing off to a HTML parser, video player etc. for parsing. <del> Identity digest-algorithms (e.g. "id-sha-256" and "id-sha-512") are particularly useful for end-to-end integrity because they allow piecing together a resource from different sources with different HTTP messaging characteristics.  For example, different servers that apply different content codings. </del> Note that using digest fields alone does not provide end-to-end integrity of HTTP messages over multiple hops, since metadata could be manipulated at any stage.  Methods to protect metadata are

Reviewer comments:
strip out id-* algorithms from this specid- are complex to address in this document they will be better addressed in URL
Fix typo. Thx NAME I'll wait a couple of days to allow further feedback :)
LGTM modulo the comment I made

Revised text:
because user-agent can validate that resource retrieval succeeded before handing off to a HTML parser, video player etc. for parsing.  Note that using digest fields alone does not provide end-to-end integrity of HTTP messages over multiple hops, since metadata could be manipulated at any stage.  Methods to protect metadata are
Original text:
8.5. Digest fields may expose details of encrypted payload when the <del> checksum is computed on the unencrypted data.  For example, the use of the "id-sha-256" digest-algorithm in conjunction with the encrypted content-coding RFC8188. </del>  The checksum of an encrypted payload can change between different messages depending on the encryption algorithm used; in those cases

Reviewer comments:
strip out id-* algorithms from this specid- are complex to address in this document they will be better addressed in URL
Fix typo. Thx NAME I'll wait a couple of days to allow further feedback :)
LGTM modulo the comment I made

Revised text:
8.5. Digest fields may expose details of encrypted payload when the  <ins> checksum is computed on the unencrypted data. </ins> The checksum of an encrypted payload can change between different messages depending on the encryption algorithm used; in those cases
Original text:
The status of "MD5" and "SHA" has been updated to "insecure", and their description has been modified accordingly. <del> The "id-sha-256" and "id-sha-512" algorithms have been added to the registry. </del> 9.5. This section registers the "Want-Digest" field in the "Hypertext

Reviewer comments:
strip out id-* algorithms from this specid- are complex to address in this document they will be better addressed in URL
Fix typo. Thx NAME I'll wait a couple of days to allow further feedback :)
LGTM modulo the comment I made

Revised text:
The status of "MD5" and "SHA" has been updated to "insecure", and their description has been modified accordingly.  9.5. This section registers the "Want-Digest" field in the "Hypertext
Original text:
Intermediaries can consume and produce priority signals in a PRIORITY_UPDATE frame or Priority header field.  Sending a PRIORITY_UPDATE frame preserves the signal from the client, but <del> provides a signal that overrides for the next hop; see header-field- rationale.  Replacing or adding a Priority header field overrides any signal from a client and can affect prioritization for all subsequent recipients. </del>  For both the Priority header field and the PRIORITY_UPDATE frame, the set of priority parameters is encoded as a Structured Fields

Reviewer comments:
I have trouble parsing this sentence, specifically around "a signal that overrides for the next hop". Overrides what? Is a word missing here, or can we restructure the sentence to be clearer?
Original context was a proposal from MT here URL So I think we are missing a that_, e.g. . I made to fix that that.
Thanks!

Revised text:
Intermediaries can consume and produce priority signals in a PRIORITY_UPDATE frame or Priority header field.  Sending a PRIORITY_UPDATE frame preserves the signal from the client, but  <ins> provides a signal that overrides that for the next hop; see header- field-rationale.  Replacing or adding a Priority header field overrides any signal from a client and can affect prioritization for all subsequent recipients. </ins> For both the Priority header field and the PRIORITY_UPDATE frame, the set of priority parameters is encoded as a Structured Fields
Original text:
clients signal stream dependencies and weights to describe an unbalanced tree.  It suffered from limited deployment and interoperability and was deprecated in a revision of HTTP/2 HTTP2. <del> However, in order to maintain wire compatibility, HTTP/2 priority signals are still mandatory to handle (see HTTP2). </del>  Clients can build RFC 7540 trees with rich flexibility but experience has shown this is rarely exercised.  Instead they tend to choose a

Reviewer comments:
Not a complete solution, but hopefully helpful. More to come for those who are less cautious than I.
Thank you, this looks clear and accurate to me.

Revised text:
clients signal stream dependencies and weights to describe an unbalanced tree.  It suffered from limited deployment and interoperability and was deprecated in a revision of HTTP/2 HTTP2.  <ins> HTTP/2 retains these protocol elements in order to maintain wire compatibility (see HTTP2), which means that they might still be used in the absence of alternative signaling, such as the scheme this document describes. </ins> Clients can build RFC 7540 trees with rich flexibility but experience has shown this is rarely exercised.  Instead they tend to choose a
Original text:
want-fields defines the Want-Digest and Want-Content-Digest request and response header and trailer field, <del> algorithms and deprecate-contentMD5 describe algorithms and their relation to Digest, </del>  state-changing-requests details computing representation digests, <del> obsolete-parameters obsoletes Digest field parameters, and </del> examples-unsolicited and examples-solicited provide examples of using Digest and Want-Digest.

Reviewer comments:
This editorial change combines most references to how this document relates to RFC 3230. By dropping the appendix, it makes the flow of the document more smooth, which is reflected in the ToC.
LGTM

Revised text:
want-fields defines the Want-Digest and Want-Content-Digest request and response header and trailer field,  <ins> algorithms describes algorithms and their relation to Digest, </ins> state-changing-requests details computing representation digests,  examples-unsolicited and examples-solicited provide examples of using Digest and Want-Digest.
Original text:
has evolved since RFC3230 was published.  The concept of "instance" has been superseded by "selected representation". <del> This document replaces RFC3230.  The "Digest" and "Want-Digest" field definitions are updated to align with the terms and notational conventions in SEMANTICS.  Changes are intended to be semantically compatible with existing implementations but note that negotiation of "Content-MD5" is deprecated deprecate-contentMD5 and has been replaced by "Content-Digest" negotiation via "Want-Content-Digest". "Digest" field parameters are obsoleted obsolete-parameters and the algorithm table has been updated to reflect the current state of the art. </del>  1.4.

Reviewer comments:
This editorial change combines most references to how this document relates to RFC 3230. By dropping the appendix, it makes the flow of the document more smooth, which is reflected in the ToC.
LGTM

Revised text:
has evolved since RFC3230 was published.  The concept of "instance" has been superseded by "selected representation".  <ins> This document replaces RFC3230.  The changes described in the following paragraphs are intended to be semantically compatible with existing implementations where possible. The "Digest" and "Want-Digest" field definitions are updated to align with the terms and notational conventions in SEMANTICS. Negotiation of "Content-MD5" is deprecated and has been replaced by "Content-Digest" negotiation via "Want-Content-Digest". Sections 4.1.1 and 4.2 of RFC3230 defined field parameters.  This document obsoletes the usage of parameters with "Digest" because this feature has not been widely deployed and complicates field-value processing.  RFC3230 intended field parameters to provide a common way to attach additional information to a representation-data-digest. However, if parameters are used as an input to validate the checksum, an attacker could alter them to steer the validation behavior.  A digest-algorithm can still be parameterized by defining its own way to encode parameters into the representation-data-digest, in such a way as to mitigate security risks related to its computation. The algorithm table has been updated to reflect the current state of the art, (see algorithms). </ins> 1.4.
Original text:
Active <del> RSASSA-PSS using SHA-256 </del>  [[This document]],

Reviewer comments:
It looks like SHA-512 was intended here, as that is what the description and name use. Maybe someone had in mind to add an additional rsa-pss-sha256 method.
Good catch, thank you!

Revised text:
Active  <ins> RSASSA-PSS using SHA-512 </ins> [[This document]],
Original text:
Upon publication, please create the HTTP Priority Parameters registry at https://iana.org/assignments/http-priority [2] and populate it <del> with the types defined in parameters; see register for its associated procedures. </del>  17.  References

Reviewer comments:
During IANA review of the document it was noted that the instructions for populating the new HTTP Priority Parameters registry with the urgency and incremental parameters was not that clear. So this change lists both and to make it clear what we want.
LGTM. Thank you for the quick work.

Revised text:
Upon publication, please create the HTTP Priority Parameters registry at https://iana.org/assignments/http-priority [2] and populate it  <ins> with the entries in iana-parameter-table; see register for its associated procedures. </ins> 17.  References
Original text:
interoperability and was deprecated in a revision of HTTP/2 HTTP2. HTTP/2 retains these protocol elements in order to maintain wire compatibility (see HTTP2), which means that they might still be used <del> in the absence of alternative signaling, such as the scheme this document describes. </del>  Many RFC 7540 server implementations do not act on HTTP/2 priority signals.

Reviewer comments:
Addresses Ea of Bob correctly highlights that absence of a replacement might not be the only condition under which the prior signals might be used. So lets be more accurate.
Thank you for the PR. Looks good.

Revised text:
interoperability and was deprecated in a revision of HTTP/2 HTTP2. HTTP/2 retains these protocol elements in order to maintain wire compatibility (see HTTP2), which means that they might still be used  <ins> even in the presence of alternative signaling, such as the scheme this document describes. </ins> Many RFC 7540 server implementations do not act on HTTP/2 priority signals.
Original text:
3. <del> The priority scheme defined by this document considers only the prioritization of HTTP messages and tunnels, see client-scheduling, server-scheduling, and connect-scheduling. Where HTTP extensions change stream behavior or define new data carriage mechanisms, they can also define how this priority scheme can be applied. </del>  4.

Reviewer comments:
Addressed Ea of Reference the HTTP terms we are using. Be clearer that we focus on "normal" responses and that there are other possible uses. But avoid making the entire document a piece of abstract art.

Revised text:
3.  <ins> The priority scheme defined by this document is primarily focused on the prioritization of HTTP response messages (see HTTP).  It defines new priority parameters (parameters) and their conveyors (header- field and frame) intended to communicate the priority of responses to a server that is responsible for prioritizing them. server-scheduling provides considerations for servers about acting on those signals in combination with other inputs and factors. The CONNECT method (see HTTP) can be used to establish tunnels. Signaling applies similarly to tunnels; additional considerations for server prioritization are given in connect-scheduling. client-scheduling describes how clients can optionally apply elements of this scheme locally to the request messages that they generate. Some forms of HTTP extensions might change HTTP/2 or HTTP/3 stream behavior or define new data carriage mechanisms.  Such extensions can define themselves how this priority scheme is to be applied. </ins> 4.
Original text:
This document defines the urgency("u") and incremental("i") parameters.  When receiving an HTTP request that does not carry these priority parameters, a server SHOULD act as if their default values <del> were specified.  Note that handling of omitted parameters is different when processing an HTTP response; see merging. </del>  Receivers parse the Dictionary as defined in STRUCTURED-FIELDS. Where the Dictionary is successfully parsed, this document places the

Reviewer comments:
Addresses Eb of . Bob highlights the actor is unclear. This attempts to address that in a minimal way without going too far down the rabbit hole of intermediaries.

Revised text:
This document defines the urgency("u") and incremental("i") parameters.  When receiving an HTTP request that does not carry these priority parameters, a server SHOULD act as if their default values  <ins> were specified. An intermediary can combine signals from requests and responses that it forwards.  Note that omission of parameters in responses is handled differently from omission in requests; see merging. </ins> Receivers parse the Dictionary as defined in STRUCTURED-FIELDS. Where the Dictionary is successfully parsed, this document places the
Original text:
commitment interval starts when the commitment is received and authenticated and runs for a number of seconds equal to value of the "tls-commit" member, less the current age of the http-opportunistic <del> response (as defined in Section 4.2.3 of RFC7234).  A client SHOULD avoid sending requests via cleartext protocols or to unauthenticated alternative services for the duration of the commitment interval, except to discover new potential alternatives. </del>  A commitment is not bound to a particular alternative service. Clients are able to use alternative services that they become aware

Reviewer comments:
We make this decision explicitly, and we don't want to imply that just because you don't have a fresh "http-opportunistic" resource, any commitment is shortened as a result (which is a reasonable interpretation based on the current text).

Revised text:
commitment interval starts when the commitment is received and authenticated and runs for a number of seconds equal to value of the "tls-commit" member, less the current age of the http-opportunistic  <ins> response (as defined in Section 4.2.3 of RFC7234).  Note that the commitment interval MAY exceed the freshness lifetime of the "http- opportunistic" resource. A client SHOULD avoid sending requests via cleartext protocols or to unauthenticated alternative services for the duration of the commitment interval, except to discover new potential alternatives. </ins> A commitment is not bound to a particular alternative service. Clients are able to use alternative services that they become aware