jiebi/TextFlow huggingface dataset:
Original 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>  Having the Priority header field defined as end-to-end is important for caching intermediaries.  Such intermediaries can cache the value

Reviewer comments:
Addresses Eb, Ec, Ed of This cuts some text to reduce the waffle factor ;)
This is nice condensation.

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

Reviewer comments:
Addresses Eb, Ec, Ed of This cuts some text to reduce the waffle factor ;)
This is nice condensation.

Revised text:
only because the header field is defined as end-to-end rather than hop-by-hop.  15. RFC7540 stream prioritization relies on dependencies.  Considerations
Original 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>  Clients cannot depend on particular treatment based on priority signals.  Servers can use other information to prioritize responses.

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

Revised text:
priority.  Expressing priority is therefore only a suggestion. A server can use priority signals along with other inputs to make  <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.
Original text:
The incremental parameter indicates how a client processes response bytes as they arrive.  It is RECOMMENDED that, when possible, servers <del> respect the incremental parameter (incremental).  Non-incremental resources can only be used when all of the response payload has been received.  Therefore, non-incremental responses of the same urgency SHOULD be served in their entirety, one-by-one, based on the stream </del>  ID, which corresponds to the order in which clients make requests. Doing so ensures that clients can use request ordering to influence response order.

Reviewer comments:
As discussed in URL, to avoid confusion, we can stop short of using phrases like "one-by-one" or "entirety," simply stating that non-incremental responses should be served in the order of the stream ID. Addresses the original point of .
LGTM me thank you. Please merge when you're ready.

Revised text:
The incremental parameter indicates how a client processes response bytes as they arrive.  It is RECOMMENDED that, when possible, servers  <ins> respect the incremental parameter (incremental). Non-incremental responses of the same urgency SHOULD be served by prioritizing bandwidth allocation in ascending order of the stream </ins> ID, which corresponds to the order in which clients make requests. Doing so ensures that clients can use request ordering to influence response order.
Original text:
15. <del> RFC7540 stream prioritization relies on dependencies.  Considerations are presented to implementations, describing how limiting state or work commitments can avoid some types of problems.  In addition, CVE- 2019-9513 aka "Resource Loop", is an example of a DoS attack that abuses stream dependencies.  Extensible priorities does not use dependencies, which avoids these issues. </del> frame describes considerations for server buffering of PRIORITY_UPDATE frames.

Reviewer comments:
In Bob's TSVART review, he notes in Tb that the mention the H2 DoS attack in Security seems useful and we should probably expand on it. The mentions of H2 have been whittled down as 7540bis progresses and the reference to CVE-2019-9513 in the security section now seems misplaced. It's cleaner to just remove it so that the section focuses on considerations for using this document. P.S I think this means that MT was right ;)

Revised text:
15.  frame describes considerations for server buffering of PRIORITY_UPDATE frames.
Original text:
12. Transport protocols such as TCP and QUIC provide reliability by <del> detecting packet losses and retransmitting lost information.  While this document specifies HTTP-layer prioritization, its effectiveness can be further enhanced if the transport layer factors priority into scheduling both new data and retransmission data.  The remainder of </del>  this section discusses considerations when using QUIC. QUIC states "Endpoints SHOULD prioritize retransmission of data over

Reviewer comments:
Addresses Te of the TSVART review We don't have much evidence to quantify effectiveness. So drop that part and keep the focus purely on the considerations.

Revised text:
12. Transport protocols such as TCP and QUIC provide reliability by  <ins> detecting packet losses and retransmitting lost information.  In addition to the considerations in server-scheduling, scheduling of retransmission data could compete with new data.  The remainder of </ins> this section discusses considerations when using QUIC. QUIC states "Endpoints SHOULD prioritize retransmission of data over
Original text:
SETTINGS_ENABLE_CONNECT_PROTOCOL value is 0x08 (decimal 8), as in HTTP/2.  4. This document introduces no new security considerations beyond those

Reviewer comments:
I think this is an issue. and we need graceful way to fall back to fallback. I do not believe that HTTP11REQUIRED and 421 response code are the right solution. I think it would be good to make this part of WebSockets over HTTP3 spec. edit: remove double negation -> I think that HTTP11REQUIRED and 421 response code are not the answer.
I agree the options we have today are not the right fit. This document could provide that and update RFC 8441.
The server could just close the stream with H3VERSIONFALLBACK. Is that not sufficient?
Perhaps for WebSockets, but there's a more general question here. When a client uses Extended CONNECT with an unknown protocol, what is the correct failure mode? There's no guarantee that HTTP/1.1 would support an arbitrary requested protocol, even if it might be more likely to work with WebSockets.
I'm not sure we need a general solution, because it isn't clear that we have a general problem. The answer here will depend on why the client is using this protocol in the first place. For example with MASQUE, the client will know which proxy to connect to thanks to out-of-band configuration, so the proxy operator is responsible for ensuring its HTTP servers are in sync with its config servers. For WebSocket on the other hand, the issue is that WebSockets were originally designed for h1 and there exist servers that are gradually deploying h2 or h3 for GET but don't yet support WebSocket there. For those, H3VERSIONFALLBACK should be sufficient.
That's nice in theory. We should still say what happens when the proxy operator makes a mistake.
Why is this specific to extended CONNECT then? A server operator could make a mistake and end up with some GET resources not working on h3 too, right?
The example I would use here is a server that supports masque on H3 and H2 CONNECT. If for some reason a proxy operator gets desyncd with the config that it may or may not be responsible for, then things could go wrong. In a scenario where version fallback to HTTP/1.1 is not desirable, articulating such an error is underspecified. Similarly for H2 and H3 websocket, telling client the resource is not available or the stream was reset with the fallback error code is misinformation.
a header describing why?
Yes, that should work. This should be in the spec.
Sent out URL to address this using the 501 response code recommendation.

Revised text:
SETTINGS_ENABLE_CONNECT_PROTOCOL value is 0x08 (decimal 8), as in HTTP/2. <ins> If a server which advertises support for Extended CONNECT but receives an Extended CONNECT request with a ":protocol" value that is unknown or is not supported, the server SHOULD respond to the request with a 501 (Not Implemented) status code (HTTP).  A server MAY provide more information via a Problem Details resoponse RFC7807. </ins> 4. This document introduces no new security considerations beyond those
Original text:
13. <del> As a general guideline, a server SHOULD NOT use priority information 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 connection (e.g., HTTP/1.1) might go unused. The remainder of this section discusses scenarios where unfairness is problematic and presents possible mitigations, or where unfairness is desirable. </del>  13.1.

Reviewer comments:
As discussed in URL and URL, describe fairness and how that relates to priorities.
As part of the TSVART review, Bob said This seems like a fair point and we likely shouldn't say anything. We can remove this statement entirely but it is normative text so it'll be a change.
I initially thought the same, but now I have a counter-argument. This section (Section 13. Fairness) discusses distributing bandwidth between multiple connections. and 13.2 cover considerations when intermediaries coalesce requests originating from multiple connections onto a single backend connection, or split requests being received on one connection to multiple backend connections. Section 13.3 distributing bandwidth between multiple connections that might share same path. I would argue that all of these belong to IETF, and that they should be covered in the document. We can probably improve the explanation to avoid confusion.
OK that works for me too, could you tackle that?
:+1: Will do alongside .
From the TSVART review, Bob says: We should address this.
I think there's confusion here. Section 13 discusses fairness of bandwidth allocated between end clients, not requests. I think clarifying this might help.
Minor edits

Revised text:
13.  <ins> Typically, HTTP implementations depend on the underlying transport to maintain fairness between connections competing for bandwidth.  When HTTP requests are forwarded through intermediaries, progress made by each connection originating from end clients can become different over time, depending on how intermediaries coalesce or split requests into backend connections.  This unfairness can expand if priority signals are used. coalescing and h1-backends discuss mitigations against this expansion of unfairness. Conversely, intentional-unfairness discusses how servers might intentionally allocate unequal bandwidth to some connections depending on the priority signals. </ins> 13.1.
Original text:
When an intermediary coalesces HTTP requests coming from multiple clients into one HTTP/2 or HTTP/3 connection going to the backend <del> server, requests that originate from one client might have higher precedence than those coming from others. </del>  It is sometimes beneficial for the server running behind an intermediary to obey Priority header field values.  As an example, a

Reviewer comments:
Small editorial nit in relation to .
This looks ok but I still think we need a additional broader consideration of precedence to address the multiple comments about the term.

Revised text:
When an intermediary coalesces HTTP requests coming from multiple clients into one HTTP/2 or HTTP/3 connection going to the backend  <ins> server, requests that originate from one client might carry priority signals indicating higher precedence than those coming from others. </ins> It is sometimes beneficial for the server running behind an intermediary to obey Priority header field values.  As an example, a
Original text:
parameters, which are a standardized and extensible format of priority information. header-field defines the Priority HTTP header field, a protocol-version-independent and end-to-end priority signal. <del> Clients can use this header to signal priority to servers in order to specify the precedence of HTTP responses.  Similarly, servers behind an intermediary can use it to signal priority to the intermediary. </del>  After sending a request, a client can change the priority of the response (see reprioritization) using HTTP-version-specific frames defined in h2-update-frame and h3-update-frame.

Reviewer comments:
Replace use of "precedence" that could be confusing with something better. With this PR, there are still two remaining occurrences of "precedence," in , and . I think that those two are fine, as they are surrounded by other text explaining the context. I think it'd be clear to readers that we are using the term to describe difference of importance between multiple responses. FIxes Ea of .
Thank you, this looks good. I agree with your rationale about why we don't need to remove all instances.

Revised text:
parameters, which are a standardized and extensible format of priority information. header-field defines the Priority HTTP header field, a protocol-version-independent and end-to-end priority signal.  <ins> Clients can send this header field to signal their view of how responses should be prioritized.  Similarly, servers behind an intermediary can use it to signal priority to the intermediary. </ins> After sending a request, a client can change the priority of the response (see reprioritization) using HTTP-version-specific frames defined in h2-update-frame and h3-update-frame.
Original text:
parameters).  It can appear in requests and responses.  It is an end- to-end signal of the request priority from the client or the response priority from the server.  merging describes how intermediaries can <del> 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 acknowledgement that any prioritization has occurred.  Guidance for how endpoints can act on Priority header values is given in server- scheduling and client-scheduling. </del>  Priority is a Dictionary (STRUCTURED-FIELDS):

Reviewer comments:
Replace use of "precedence" that could be confusing with something better. With this PR, there are still two remaining occurrences of "precedence," in , and . I think that those two are fine, as they are surrounded by other text explaining the context. I think it'd be clear to readers that we are using the term to describe difference of importance between multiple responses. FIxes Ea of .
Thank you, this looks good. I agree with your rationale about why we don't need to remove all instances.

Revised text:
parameters).  It can appear in requests and responses.  It is an end- to-end signal of the request priority from the client or the response priority from the server.  merging describes how intermediaries can  <ins> combine the priority information sent from clients and servers. Clients cannot interpret the appearance or omission of a Priority response header field as 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 (STRUCTURED-FIELDS):
Original text:
When an intermediary coalesces HTTP requests coming from multiple clients into one HTTP/2 or HTTP/3 connection going to the backend <del> server, requests that originate from one client might carry priority signals indicating higher precedence than those coming from others. </del>  It is sometimes beneficial for the server running behind an intermediary to obey Priority header field values.  As an example, a resource-constrained server might defer the transmission of software update files that would have the background urgency being associated. <del> However, in the worst case, the asymmetry between the precedence </del>  declared by multiple clients might cause responses going to one user agent to be delayed totally after those going to another.

Reviewer comments:
Replace use of "precedence" that could be confusing with something better. With this PR, there are still two remaining occurrences of "precedence," in , and . I think that those two are fine, as they are surrounded by other text explaining the context. I think it'd be clear to readers that we are using the term to describe difference of importance between multiple responses. FIxes Ea of .
Thank you, this looks good. I agree with your rationale about why we don't need to remove all instances.

Revised text:
When an intermediary coalesces HTTP requests coming from multiple clients into one HTTP/2 or HTTP/3 connection going to the backend  <ins> server, requests that originate from one client might carry signals indicating higher priority than those coming from others. </ins> It is sometimes beneficial for the server running behind an intermediary to obey Priority header field values.  As an example, a resource-constrained server might defer the transmission of software update files that would have the background urgency being associated.  <ins> However, in the worst case, the asymmetry between the priority </ins> declared by multiple clients might cause responses going to one user agent to be delayed totally after those going to another.
Original text:
Trailer section.  This contains zero or more trailer fields.  All lengths and numeric values are encoded using the variable-length integer encoding from QUIC.

Reviewer comments:
This adds the ability to pad messages to the binary HTTP format. The design is pretty simple: add zero-valued bytes to the end.
What if someone adds a non-zero byte in the padding block?

Revised text:
Trailer section.  This contains zero or more trailer fields. <ins> Optional padding.  Any amount of zero-valued bytes. </ins> All lengths and numeric values are encoded using the variable-length integer encoding from QUIC.
Original text:
Omitting content by truncating a message is only possible if the content is zero-length.  4. This document describes a number of ways that a message can be

Reviewer comments:
This adds the ability to pad messages to the binary HTTP format. The design is pretty simple: add zero-valued bytes to the end.
What if someone adds a non-zero byte in the padding block?

Revised text:
Omitting content by truncating a message is only possible if the content is zero-length. <ins> 3.8. Messages can be padded with any number of zero-valued bytes.  Non- zero padding bytes cause a message to be invalid (see invalid). Unlike other parts of a message, a processor MAY decide not to validate the value of padding bytes. Padding is compatible with truncation of empty parts of the messages. Zero-valued bytes will be interpreted as zero-length part, which is semantically equivalent to the part being absent. </ins> 4. This document describes a number of ways that a message can be
Original text:
shown in ex-bini-request.  As the content of this message is empty, the difference in formats is negligible. <del> This indefinite-length encoding can be truncated by two bytes in the same way. </del>  5.2.

Reviewer comments:
This adds the ability to pad messages to the binary HTTP format. The design is pretty simple: add zero-valued bytes to the end.
What if someone adds a non-zero byte in the padding block?

Revised text:
shown in ex-bini-request.  As the content of this message is empty, the difference in formats is negligible.  <ins> This indefinite-length encoding contains 10 bytes of padding.  As two additional bytes can be truncated in the same way as the known-length example, anything up to 12 bytes can be removed from this message without affecting its meaning. </ins> 5.2.
Original text:
8.5. <del> Digest fields may expose details of encrypted payload when the checksum is computed on the unencrypted data. </del> The checksum of an encrypted payload can change between different messages depending on the encryption algorithm used; in those cases its value could not be used to provide a proof of integrity "at rest"

Reviewer comments:
Remove cleartext references.
From NAME WGLC review: I think this was added to cover the id-sha-* algorithms that we defined but have since removed. Let's consider removing this consideration unless it still applies (and if it does, maybe we need some more text).

Revised text:
8.5.  The checksum of an encrypted payload can change between different messages depending on the encryption algorithm used; in those cases its value could not be used to provide a proof of integrity "at rest"
Original text:
has been superseded by "selected representation". This document replaces RFC3230.  The changes described in the <del> following paragraphs are intended to be semantically compatible with existing implementations where possible. </del>  The "Digest" and "Want-Digest" field definitions are updated to align with the terms and notational conventions in SEMANTICS.

Reviewer comments:
Add syntactic compatibility.
From NAME WGLC review: This wording is awkward, we can editorialize this to be clearer what the scope and intent of changes are.

Revised text:
has been superseded by "selected representation". This document replaces RFC3230.  The changes described in the  <ins> following paragraphs are intended to be syntactically and semantically compatible with existing implementations where possible. </ins> The "Digest" and "Want-Digest" field definitions are updated to align with the terms and notational conventions in SEMANTICS.