jiebi/CodeConvo huggingface dataset:
Code change:
NAME noted a bunch of minor editorial issues, so this fixes them.
Thank you for working on the changes. They look like great improvements to me modulo the concern below.

Related discussion:
text: facing edge might support HTTP/2 and HTTP/3 while communication to back end servers is done using HTTP/1.1.  Unlike with connection coalescing, the CDN will "de-mux" requests into discrete connections <del> to the back end.  As HTTP/1.1 and older do not provide a way to concurrently transmit multiple responses, there is no immediate fairness issue in protocol.  However, back end servers MAY still use client headers for request scheduling.  Back end servers SHOULD only schedule based on client priority information where that information can be scoped to individual end clients.  Authentication and other session information might provide this linkability. </del> <ins> to the back end.  HTTP/1.1 and older do not support response multiplexing in a single connection, so there is not a fairness problem.  However, back end servers MAY still use client headers for request scheduling.  Back end servers SHOULD only schedule based on client priority information where that information can be scoped to individual end clients.  Authentication and other session information might provide this linkability. </ins> 13.3.
Code change:
. 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

Related discussion:
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> <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":
Code change:
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.

Related discussion:
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> <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 <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> <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
Code change:
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.

Related discussion:
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> <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.
Code change:
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

Related discussion:
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> <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
Code change:
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

Related discussion:
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
Code change:
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

Related discussion:
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
Code change:
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

Related discussion:
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> <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
Code change:
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

Related discussion:
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
Code change:
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!

Related discussion:
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> <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
Code change:
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.

Related discussion:
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> <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
Code change:
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

Related discussion:
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> <ins> algorithms describes algorithms and their relation to Digest, </ins> 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.
Code change:
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

Related discussion:
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> <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.
Code change:
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.

Related discussion:
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> <ins> with the entries in iana-parameter-table; see register for its associated procedures. </ins> 17.  References
Code change:
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.

Related discussion:
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> <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.
Code change:
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.

Related discussion:
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> <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.
Code change:
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.

Related discussion:
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> <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
Code change:
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).

Related discussion:
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> <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
Code change:
Addresses Eb, Ec, Ed of This cuts some text to reduce the waffle factor ;)
This is nice condensation.

Related discussion:
text: In contrast to the prioritization scheme of HTTP/2 that uses a hop- by-hop frame, the Priority header field is defined as end-to-end. <del> The rationale is that the Priority header field transmits how each response affects the client's processing of those responses, rather than how relatively urgent each response is to others.  The way a client processes a response is a property associated to that client generating that request.  Not that of an intermediary.  Therefore, it is an end-to-end property.  How these end-to-end properties carried by the Priority header field affect the prioritization between the responses that share a connection is a hop-by-hop issue. </del> <ins> The way that a client processes a response is a property associated with the client generating that request.  Not that of an intermediary.  Therefore, it is an end-to-end property.  How these end-to-end properties carried by the Priority header field affect the prioritization between the responses that share a connection is a hop-by-hop issue. </ins> Having the Priority header field defined as end-to-end is important for caching intermediaries.  Such intermediaries can cache the value
Code change:
Addresses Eb, Ec, Ed of This cuts some text to reduce the waffle factor ;)
This is nice condensation.

Related discussion:
text: only because the header field is defined as end-to-end rather than hop-by-hop. <del> It should also be noted that the use of a header field carrying a textual value makes the prioritization scheme extensible; see the discussion below. </del> 15. RFC7540 stream prioritization relies on dependencies.  Considerations
Code change:
Addresses Ea of Bob comments that the "no guidance is provided" sounds like it is in conflict with the rest of the section that includes some normative recommendations. The intent of this text was to highlight there is no (or at least very little) about how servers are supposed to combine priority parameters with the million other things that they have to worry about. This change shuffles the sentences around to try and make the original intent clearer.
This is much better than the original. Thank you for the PR.

Related discussion:
text: priority.  Expressing priority is therefore only a suggestion. A server can use priority signals along with other inputs to make <del> scheduling decisions.  No guidance is provided about how this can or should be done.  Factors such as implementation choices or deployment environment also play a role.  Any given connection is likely to have many dynamic permutations.  For these reasons, there is no unilateral perfect scheduler and this document only provides some basic recommendations for implementations. </del> <ins> scheduling decisions.  Factors such as implementation choices or deployment environment also play a role.  Any given connection is likely to have many dynamic permutations.  For these reasons, there is no unilateral perfect scheduler.  This document provides some basic, non-exhaustive, recommendations for how servers might act on priority parameters.  It does not describe in detail how servers might combine priority signals with other factors. </ins> Clients cannot depend on particular treatment based on priority signals.  Servers can use other information to prioritize responses.