jiebi/CodeConvo huggingface dataset:
Code change:
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.

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

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

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

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

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

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

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

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

Related discussion:
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> <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. <del> However, in the worst case, the asymmetry between the precedence </del> <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.
Code change:
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?

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

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

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

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

Related discussion:
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> <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.
Code change:
Consistent use of "checksum".
From NAME WGLC review: Personally, I think the use of both terms is ok. Mainly because digest is overloaded in the document. But it wouldn't hurt us to review the document for usages and perhaps add a note in notational conventions about the use of terms.
is a generic checksum computation, should be the actual digest algoritm computation. We need to clarify this and probably introduce new terminology.

Related discussion:
text: This document defines two digest integrity mechanisms for HTTP. First, representation data integrity, which acts on representation <del> data (Section 3.2 of SEMANTICS).  Second, content digest integrity, which acts on conveyed content (Section 6.4 of SEMANTICS).  Both mechanisms operate independent of transport integrity, offering the potential to detect programming errors and corruption of data in flight or at rest.  They can be used across multiple hops in order to provide end-to-end integrity guarantees, which can aid fault diagnosis when resources are transferred across hops and system boundaries.  Finally, they can be used to validate integrity when reconstructing a resource fetched using different HTTP connections. </del> <ins> data (Section 3.2 of SEMANTICS).  Second, content integrity, which acts on conveyed content (Section 6.4 of SEMANTICS).  Both mechanisms operate independent of transport integrity, offering the potential to detect programming errors and corruption of data in flight or at rest.  They can be used across multiple hops in order to provide end- to-end integrity guarantees, which can aid fault diagnosis when resources are transferred across hops and system boundaries. Finally, they can be used to validate integrity when reconstructing a resource fetched using different HTTP connections. </ins> This document obsoletes RFC3230.
Code change:
Consistent use of "checksum".
From NAME WGLC review: Personally, I think the use of both terms is ok. Mainly because digest is overloaded in the document. But it wouldn't hurt us to review the document for usages and perhaps add a note in notational conventions about the use of terms.
is a generic checksum computation, should be the actual digest algoritm computation. We need to clarify this and probably introduce new terminology.

Related discussion:
text: (e.g.  SHA-1, CRC32c) whereas digest-algorithm tokens are quoted (e.g. "sha", "crc32c"). <ins> The term "checksum" describes the output of the application of an algorithm to a sequence of bytes, whereas digest is only used in relation to the value of the fields. </ins> 2. The representation digest is an integrity mechanism for HTTP
Code change:
Consistent use of "checksum".
From NAME WGLC review: Personally, I think the use of both terms is ok. Mainly because digest is overloaded in the document. But it wouldn't hurt us to review the document for usages and perhaps add a note in notational conventions about the use of terms.
is a generic checksum computation, should be the actual digest algoritm computation. We need to clarify this and probably introduce new terminology.

Related discussion:
text: SEMANTICS. When an incremental digest-algorithm is used, the sender and the <del> receiver can dynamically compute the digest value while streaming the </del> <ins> receiver can dynamically compute a checksum while streaming the </ins> content. A non-comprehensive set of examples showing the impacts of
Code change:
Consistent use of "checksum".
From NAME WGLC review: Personally, I think the use of both terms is ok. Mainly because digest is overloaded in the document. But it wouldn't hurt us to review the document for usages and perhaps add a note in notational conventions about the use of terms.
is a generic checksum computation, should be the actual digest algoritm computation. We need to clarify this and probably introduce new terminology.

Related discussion:
text: Section 6.5.1 of SEMANTICS. When an incremental digest-algorithm is used, the sender and the <del> receiver can dynamically compute the digest value while streaming the </del> <ins> receiver can dynamically compute the checksum while streaming the </ins> content. 5.
Code change:
Consistent use of "checksum".
From NAME WGLC review: Personally, I think the use of both terms is ok. Mainly because digest is overloaded in the document. But it wouldn't hurt us to review the document for usages and perhaps add a note in notational conventions about the use of terms.
is a generic checksum computation, should be the actual digest algoritm computation. We need to clarify this and probably introduce new terminology.

Related discussion:
text: e.g. according to the type and status of the primary document in which the algorithm is defined; "insecure" when the <del> algorithm is insecure; "reserved" when Digest algorithm references a reserved token value </del> <ins> algorithm is insecure; "reserved" when the algorithm references a reserved token value </ins> Description: the description of the digest-algorithm and its encoding
Code change:
Consistent use of "checksum".
From NAME WGLC review: Personally, I think the use of both terms is ok. Mainly because digest is overloaded in the document. But it wouldn't hurt us to review the document for usages and perhaps add a note in notational conventions about the use of terms.
is a generic checksum computation, should be the actual digest algoritm computation. We need to clarify this and probably introduce new terminology.

Related discussion:
text: Insecure digest algorithms MAY be used to preserve integrity against corruption, but MUST NOT be used in a potentially adversarial <del> setting; for example, when signing the digest of content for </del> <ins> setting; for example, when signing digest fields' values for </ins> authenticity. The registry is initialized with the tokens listed below.
Code change:
Consistent use of "checksum".
From NAME WGLC review: Personally, I think the use of both terms is ok. Mainly because digest is overloaded in the document. But it wouldn't hurt us to review the document for usages and perhaps add a note in notational conventions about the use of terms.
is a generic checksum computation, should be the actual digest algoritm computation. We need to clarify this and probably introduce new terminology.

Related discussion:
text: Such signatures can protect one or more HTTP fields and there are additional considerations when "Digest" is included in this set. <del> Since digest fields are hashes of resource representations, they </del> <ins> Since digest fields are checksums of resource representations, they </ins> explicitly depend on the "representation metadata" (e.g. the values of "Content-Type", "Content-Encoding" etc).  A signature that protects "Digest" but not other "representation metadata" can expose