jiebi/TextFlow huggingface dataset:
Original text:
Endpoints MUST send this SETTINGS parameter as part of the first SETTINGS frame.  A sender MUST NOT change the SETTINGS_NO_RFC7540_PRIORITIES parameter value after the first <del> SETTINGS frame.  Detection of a change by a receiver MUST be treated as a connection error of type PROTOCOL_ERROR. </del>  The SETTINGS frame precedes any HTTP/2 priority signal sent from a client, so a server can determine if it needs to allocate any

Reviewer comments:
by taking NAME suggestion of MAY and bolts it to an "if you can detect" caveat
Since this is a change of normative requirement, lets solicit for some more WG input before landing
I noticed the same while reading the document and thought that MAY would be more suitable. Or in more precisely, "MUST ignore any change and MAY treat it as a connection error".
I couldn't see this being discussed in an issue so far. This seems unnecessary. While there is no value to changing the value, it creates a special rule for handling of the setting. In particular, endpoints that don't distinguish between SETTINGS-in-preface and other SETTINGS frames might have trouble generating the special handling necessary to police this rule. While I can see the value to an endpoint in terms of being able to defer creating the whole priority tree mess for new connections until they receive the preface, and maybe avoid creating that stuff entirely. But as long as priority signals are advisory, you get most of the value from a strong recommendation to use the preface, noting that making a change later might be too late. No special exceptions would be needed. I'm sure that the editors will disagree with me here. That's OK, but it's worth noting why this special handling is included in the specification. It's not immediately obvious.
Would it be sufficient to make this a "MAY be treated"? That provides a disincentive to change without requiring special processing.

Revised text:
Endpoints MUST send this SETTINGS parameter as part of the first SETTINGS frame.  A sender MUST NOT change the SETTINGS_NO_RFC7540_PRIORITIES parameter value after the first  <ins> SETTINGS frame.  Receivers that detect a change MAY treat it as a connection error of type PROTOCOL_ERROR. </ins> The SETTINGS frame precedes any HTTP/2 priority signal sent from a client, so a server can determine if it needs to allocate any
Original text:
4.1. The urgency parameter ("u") takes an integer between 0 and 7, in <del> descending order of priority.  This range provides sufficient granularity for prioritizing responses for ordinary web browsing, at minimal complexity. </del>  The value is encoded as an sf-integer.  The default value is 3.

Reviewer comments:
by taking MT's suggestion. This is the right thing to do editorially even if it might make NAME a little sad
It is not necessary to make this claim, or any claim, about the range of values. Such a claim would need to be supported with evidence. I don't think we have such evidence. Internal documentation I have lists about 30 different types of requests that a web browser might make that were put into about 11 different categories; you could make arguments that 30 or 11 is sufficient on that basis. And you might still be wrong. The good thing here is that you don't need to justify the choice of 8 different urgencies. Strike this sentence.

Revised text:
4.1. The urgency parameter ("u") takes an integer between 0 and 7, in  <ins> descending order of priority. </ins> The value is encoded as an sf-integer.  The default value is 3.
Original text:
The default value of the incremental parameter is false ("0"). <del> A server might distribute the bandwidth of a connection between incremental responses that share the same urgency, hoping that providing those responses in parallel would be more helpful to the client than delivering the responses one by one. </del>  If a client makes concurrent requests with the incremental parameter <del> 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. </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:
The change switches the order so that there is a more natural progress from presenting the incremental default of false, to discussing how a server could act on non-incremental requests, then how they might act on incremental requests.
(Emphasis mine.) I think that the goal of this text was to establish an expectation. That is, if a request is marked as incremental, there is no expectation that a server will attempt to send the entirety of a response before starting on other responses. It's a negation of the standard expectation that exists for : responses are transmitted in their entirety where possible. Consider rewording this bit.
Some suggestions, but I think that this is an improvement.Thank you for the PR. LGTM modulo the points below.

Revised text:
The default value of the incremental parameter is false ("0").  <ins> If a client makes concurrent requests with the incremental parameter set to false, there is no benefit serving responses with the same urgency in parallel because the client is not going to process those 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. </ins> If a client makes concurrent requests with the incremental parameter  <ins> 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. </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:
In order to mitigate this fairness problem, a server could use knowledge about the intermediary as another signal in its prioritization decisions.  For instance, if a server knows the <del> intermediary is coalescing requests, then it could serve the responses in round-robin manner.  This can work if the constrained </del>  resource is network capacity between the intermediary and the user agent, as the intermediary buffers responses and forwards the chunks based on the prioritization scheme it implements.

Reviewer comments:
We accept that a strong suggestion to use round-robin isn't ideal. And look for other ways to phrase the suggestion of distributing or timeslicing. Fortunately we already had some text in the next paragraph that explained the ways that timing of delivery of incremental resources parts is important to clients and the sorts of things that servers need to consider. So this PR rearranges the text a bit and gives it dust off to make sure it is in line with our understanding now.
This recommendation is too strong. There is still value in allowing requests to complete. This suggests that pieces of all responses be provided concurrently. That leads to more context switching than necessary, or even inefficiencies in transmissions (one byte from each at a time would have excessive overheads). I would instead say:
I agree that "round-robin manner" is poorly defined and could be interpreted as 1 byte of everything. That would be bad. However, the full context of that SHOULD is in relation to the other requirements in that paragraph RECOMMENDing respect with no guidance on what that means seems a bit iffy to me. Your suggestion might get misinterpreted as relaxing the RECOMMEND. Rewriting that paragraph risks kicking the hornets nest of one the most divisive issues we had (URL). I sort of inclined to keep the SHOULD but expand on what we intended to say with "round-robin"
LGTM, some suggestions only.

Revised text:
In order to mitigate this fairness problem, a server could use knowledge about the intermediary as another signal in its prioritization decisions.  For instance, if a server knows the  <ins> intermediary is coalescing requests, then it could avoid serving the responses in their entirety and instead distribute bandwidth (for example, in a round-robin manner).  This can work if the constrained </ins> resource is network capacity between the intermediary and the user agent, as the intermediary buffers responses and forwards the chunks based on the prioritization scheme it implements.
Original text:
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. <del> 1.2. </del>  The ORIGIN HTTP/2 frame (RFC7540, Section 4) indicates what origin(s) RFC6454 the sender considers this connection authoritative for (in

Reviewer comments:
Putting the meat of the document in Section 1.2 was a bit odd. Also, the fields descriptions were glommed together.
Weird; didn't happen on local copies.

Revised text:
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119.  <ins> 2. </ins> The ORIGIN HTTP/2 frame (RFC7540, Section 4) indicates what origin(s) RFC6454 the sender considers this connection authoritative for (in
Original text:
The ORIGIN frame contains the following fields, sets of which may be repeated within the frame to indicate multiple origins: <del> Origin-Len: An unsigned, 16-bit integer indicating the length, in octets, of the Origin field.  Origin: An optional sequence of characters containing the ASCII serialization of an origin (RFC6454, Section 6.2) that the sender believes this connection is authoritative for. </del>  The ORIGIN frame does not define any flags.  It can contain one or more Origin-Len/Origin pairs.

Reviewer comments:
Putting the meat of the document in Section 1.2 was a bit odd. Also, the fields descriptions were glommed together.
Weird; didn't happen on local copies.

Revised text:
The ORIGIN frame contains the following fields, sets of which may be repeated within the frame to indicate multiple origins:  <ins> An unsigned, 16-bit integer indicating the length, in octets, of the Origin field. An optional sequence of characters containing the ASCII serialization of an origin (RFC6454, Section 6.2) that the sender believes this connection is authoritative for. </ins> The ORIGIN frame does not define any flags.  It can contain one or more Origin-Len/Origin pairs.
Original text:
Clients configured to use a proxy MUST ignore any ORIGIN frames received from it. <del> 2. </del>  Clients that blindly trust the ORIGIN frame's contents will be vulnerable to a large number of attacks; hence the reinforcement that

Reviewer comments:
Putting the meat of the document in Section 1.2 was a bit odd. Also, the fields descriptions were glommed together.
Weird; didn't happen on local copies.

Revised text:
Clients configured to use a proxy MUST ignore any ORIGIN frames received from it.  <ins> 3. </ins> Clients that blindly trust the ORIGIN frame's contents will be vulnerable to a large number of attacks; hence the reinforcement that
Original text:
Stream ID MUST be within the client-initiated bidirectional stream limit.  If a server receives a PRIORITY_UPDATE (type=0xF0700) with a Stream ID that is beyond the stream limits, this SHOULD be treated as <del> a connection error of type H3_ID_ERROR. </del>  The push-stream variant PRIORITY_UPDATE (type=0xF0701) MUST reference a promised push stream.  If a server receives a PRIORITY_UPDATE

Reviewer comments:
Editorial change related to . This may not close the issue on its own, so lets resolve that separate.
Simplification; but WFM either way.

Revised text:
Stream ID MUST be within the client-initiated bidirectional stream limit.  If a server receives a PRIORITY_UPDATE (type=0xF0700) with a Stream ID that is beyond the stream limits, this SHOULD be treated as  <ins> a connection error of type H3_ID_ERROR.  Generating an error is not mandatory because HTTP/3 implementations might have practical barriers to determining the active stream concurrency limit that is applied by the QUIC layer. </ins> The push-stream variant PRIORITY_UPDATE (type=0xF0701) MUST reference a promised push stream.  If a server receives a PRIORITY_UPDATE
Original text:
dependencies, which avoids these issues. frame describes considerations for server buffering of <del> PRIORITY_UPDATE frames.  HTTP/3 implementations might have practical barriers to determining reasonable stream concurrency limits depending on the information that is available to them from the QUIC transport layer. </del>  server-scheduling presents examples where servers that prioritize responses in a certain way might be starved of the ability to

Reviewer comments:
Editorial change related to . This may not close the issue on its own, so lets resolve that separate.
Simplification; but WFM either way.

Revised text:
dependencies, which avoids these issues. frame describes considerations for server buffering of  <ins> PRIORITY_UPDATE frames. </ins> server-scheduling presents examples where servers that prioritize responses in a certain way might be starved of the ability to
Original text:
The problems and insights set out above provided the motivation for deprecating RFC 7540 stream priority (see Section 5.3 of RFC7540). <del> The SETTINGS_NO_RFC7540_PRIORITIES setting is defined by this </del>  document in order to allow endpoints to explicitly opt out of using HTTP/2 priority signals (see Section 5.3.2 of HTTP2).  Endpoints are encouraged to use alternative priority signals (for example, header-

Reviewer comments:
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.

Revised text:
The problems and insights set out above provided the motivation for deprecating RFC 7540 stream priority (see Section 5.3 of RFC7540).  <ins> The SETTINGS_NO_RFC7540_PRIORITIES HTTP/2 setting is defined by this </ins> document in order to allow endpoints to explicitly opt out of using HTTP/2 priority signals (see Section 5.3.2 of HTTP2).  Endpoints are encouraged to use alternative priority signals (for example, header-
Original text:
The value of SETTINGS_NO_RFC7540_PRIORITIES MUST be 0 or 1.  Any value other than 0 or 1 MUST be treated as a connection error (see <del> Section 5.4.1 of HTTP2) of type PROTOCOL_ERROR. </del>  Endpoints MUST send this SETTINGS parameter as part of the first SETTINGS frame.  A sender MUST NOT change the

Reviewer comments:
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.

Revised text:
The value of SETTINGS_NO_RFC7540_PRIORITIES MUST be 0 or 1.  Any value other than 0 or 1 MUST be treated as a connection error (see  <ins> Section 5.4.1 of HTTP2) of type PROTOCOL_ERROR.  The initial value is 0. </ins> Endpoints MUST send this SETTINGS parameter as part of the first SETTINGS frame.  A sender MUST NOT change the
Original text:
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 <del> 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. </del>  In both cases, the set of priority parameters is encoded as a Structured Fields Dictionary (see Section 3.2 of STRUCTURED-FIELDS).

Reviewer comments:
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.

Revised text:
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  <ins> PRIORITY_UPDATE 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 Fields Dictionary (see Section 3.2 of STRUCTURED-FIELDS).
Original text:
4.2. The incremental parameter ("i") takes an sf-boolean as the value that <del> indicates if an HTTP response can be processed incrementally, i.e. </del>  provide some meaningful output as chunks of the response arrive. The default value of the incremental parameter is false ("0").

Reviewer comments:
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.

Revised text:
4.2. The incremental parameter ("i") takes an sf-boolean as the value that  <ins> indicates if an HTTP response can be processed incrementally, i.e., </ins> provide some meaningful output as chunks of the response arrive. The default value of the incremental parameter is false ("0").
Original text:
combine the priority information from client requests and server responses to correct or amend the precedence.  Clients cannot interpret the appearance or omission of a Priority response header as <del> acknowledgement that any prioritization has occurred. </del>  Priority is a Dictionary (Section 3.2 of STRUCTURED-FIELDS):

Reviewer comments:
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.

Revised text:
combine the priority information from client requests and server responses to correct or amend the precedence.  Clients cannot interpret the appearance or omission of a Priority response header as  <ins> acknowledgement that any prioritization has occurred.  Guidance for how endpoints can act on Priority header values is given in server- scheduling and client-scheduling. </ins> Priority is a Dictionary (Section 3.2 of STRUCTURED-FIELDS):
Original text:
the priority update. The priority update value in ASCII text, encoded using Structured <del> Fields. </del>  When the PRIORITY_UPDATE frame applies to a request stream, clients SHOULD provide a Prioritized Stream ID that refers to a stream in the

Reviewer comments:
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.

Revised text:
the priority update. The priority update value in ASCII text, encoded using Structured  <ins> Fields.  This is the same representation as the Priority header field value. </ins> When the PRIORITY_UPDATE frame applies to a request stream, clients SHOULD provide a Prioritized Stream ID that refers to a stream in the
Original text:
update. The priority update value in ASCII text, encoded using Structured <del> Fields. </del>  The request-stream variant of PRIORITY_UPDATE (type=0xF0700) MUST reference a request stream.  If a server receives a PRIORITY_UPDATE

Reviewer comments:
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.

Revised text:
update. The priority update value in ASCII text, encoded using Structured  <ins> Fields.  This is the same representation as the Priority header field value. </ins> The request-stream variant of PRIORITY_UPDATE (type=0xF0700) MUST reference a request stream.  If a server receives a PRIORITY_UPDATE
Original text:
because there is no explicit client-signalled initial priority.  A server can apply priority signals provided in an origin response; see the merging guidance given in merging.  In the absence of origin <del> signals, applying default parameter values could be suboptimal.  How ever a server decides to schedule a pushed response, it can signal the intended priority to the client by including the Priority field in a PUSH_PROMISE or HEADERS frame. </del>  10.1.

Reviewer comments:
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.

Revised text:
because there is no explicit client-signalled initial priority.  A server can apply priority signals provided in an origin response; see the merging guidance given in merging.  In the absence of origin  <ins> signals, applying default parameter values could be suboptimal.  By whatever means a server decides to schedule a pushed response, it can signal the intended priority to the client by including the Priority field in a PUSH_PROMISE or HEADERS frame. </ins> 10.1.
Original text:
Section 6.2.4 of QUIC-RECOVERY, also highlights consideration of application priorities when sending probe packets after Probe Timeout <del> timer expiration.  An QUIC implementation supporting application- </del>  indicated priorities might use the relative priority of streams when choosing probe data. 13. As a general guideline, a server SHOULD NOT use priority information <del> for making schedule decisions across multiple connections, unless it knows that those connections originate from the same client.  Due to this, priority information conveyed over a non-coalesced HTTP </del>  connection (e.g., HTTP/1.1) might go unused. The remainder of this section discusses scenarios where unfairness is

Reviewer comments:
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.

Revised text:
Section 6.2.4 of QUIC-RECOVERY, also highlights consideration of application priorities when sending probe packets after Probe Timeout  <ins> timer expiration.  A QUIC implementation supporting application- </ins> indicated priorities might use the relative priority of streams when choosing probe data. 13. As a general guideline, a server SHOULD NOT use priority information  <ins> for making scheduling decisions across multiple connections, unless it knows that those connections originate from the same client.  Due to this, priority information conveyed over a non-coalesced HTTP </ins> connection (e.g., HTTP/1.1) might go unused. The remainder of this section discusses scenarios where unfairness is
Original 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>  13.3.

Reviewer comments:
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.

Revised 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  <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.