jiebi/CodeConvo huggingface dataset:
Code change:
application or data format, since orthogonal technologies deserve orthogonal specification. <del> Since message parsing (message.body) needs to be independent of method semantics (aside from responses to HEAD), definitions of new methods cannot change the parsing algorithm or prohibit the presence of content on either the request or the response message. </del> <ins> Since message parsing (message.abstraction) needs to be independent of method semantics (aside from responses to HEAD), definitions of new methods cannot change the parsing algorithm or prohibit the presence of content on either the request or the response message. </ins> Definitions of new methods can specify that only a zero-length content is allowed by requiring a Content-Length header field with a value of "0".

Related discussion:
text: I think it would be better to separate this into the purely editorial changes (all except TRACE), and then give the change to TRACE the full treatment separately (it's a normative change after all). Will work on the former first.
Sorry for this being a question. I answered the same question for -caching by searching through and realizing that while caching might be a version-independent extension, a practical consequence of the structure of documents is that it is inextricably linked to -semantics. That's cool. Having the definition of HTTP/N rely on -caching is eminently sensible. There is a normative reference to -messaging though. Why would HTTP/3 care about that? If this were software, I'd be horrified by pulling in a dependency like that. Most of the references to -messaging are strictly examples. I could only see two cases where there was a potentially normative dependency: recommends "message/http" and . These seem like they could be broken (the second easier than the first, certainly) and the reference made normative.
I agree that this would be good.
A SHOULD-level requirement to use message/http. Moving the media type definition over is not going to help, because it essentially defines the HTTP/1.1 wire format as media type. It seems the only way to fix this would be to relax the SHOULD. That one could probably be replaced with a reference to the transfer coding registry (which is what counts here), and the pointer to the spec text would then become informative.
History in and linked issues.
Concrete recommendation for 1: a server (intermediary) responding to TRACE MUST generate a representation of the request that it received in any format. The message/http is one possible way to represent a request message, so that can be an informative reference instead.
Code change:
application or data format, since orthogonal technologies deserve orthogonal specification. <del> Since message parsing (message.body) needs to be independent of method semantics (aside from responses to HEAD), definitions of new methods cannot change the parsing algorithm or prohibit the presence of content on either the request or the response message. </del> <ins> Since message parsing (message.abstraction) needs to be independent of method semantics (aside from responses to HEAD), definitions of new methods cannot change the parsing algorithm or prohibit the presence of content on either the request or the response message. </ins> Definitions of new methods can specify that only a zero-length content is allowed by requiring a Content-Length header field with a value of "0".

Related discussion:
text: Make sure that all references to MESSAGING which are not normative are clearly informative. (This ticket is not about those references which right now are indeed normative, see ).
Code change:
after the TLS handshake completes.  By deferring processing, it can ensure that only a successfully completed connection is used for the request(s) therein.  This provides the server with some <del> assurance that the early data was not replayed. If the server receives multiple requests in early data, it can determine whether to defer HTTP processing on a per-request basis. </del> <ins> assurance that the early data was not replayed.  If the server receives multiple requests in early data, it can determine whether to defer HTTP processing on a per-request basis. </ins> The server can cause a client to retry individual requests and not use early data by responding with the 425 (Too Early) status code (status), in cases where the risk of replay is judged too great. <ins> Any of these techniques is equally effective and a server can use the method that best suits it. </ins> For a given request, the level of tolerance to replay risk is specific to the resource it operates upon (and therefore only known to the origin server).  The primary risk associated with using early

Related discussion:
text: This will conflict with the changes ekr suggested, but I integrated them, so merging shouldn't lose the important changes.
For "sent in early data on another connection", I think Spencer's proposal "sent in early data on a previous hop" would make it even clearer regarding the hop chain so as not to confuse this with another connection from the same user-agent. OK for the rest.
Code change:
This documents extends the verifiable data structure registry of I- D.steele-cose-merkle-tree-proofs with the following value: <ins> This document defines inclusion proofs for CCF ledgers.  Verifiers MUST reject all other proof types </ins> 2.1. <del> The input of the Merkle Tree Hash (MTH) function is a list of n byte strings, written D_n = {d[0], d[1], ..., d[n-1]}. The output is a single HASH_SIZE byte string, also called the Merkle root hash. </del> <ins> A CCF ledger is a binary Merkle Tree constructed from a hash function H, which is defined from the log type.  For instance, the hash function for "CCF_LEDGER_SHA256" is "SHA256", whose "HASH_SIZE" is 32 bytes. The Merkle tree encodes an ordered list of "n" transactions T_n = {T[0], T[1], ..., T[n-1]}. We define the Merkle Tree Hash (MTH) function, which takes as input a list of serialized transactions (as byte strings), and outputs a single HASH_SIZE byte string called the Merkle root hash, by induction on the list: </ins> This function is defined as follows:

Related discussion:
text: NAME NAME I have read through URL, and made some edits here as discussed to correct the leaf definition. This is deliberately quite light on details, but I am obviously very happy to expand wherever necessary.
NAME I had not seen the updates made in URL, I have attempted to merge them in here.
NAME if/when you have a chance, I would be grateful for a review and some feedback on how to take this forward :)
NAME I have tried to address your feedback, I hope I did not miss anything.
NAME may I ask you to check if the changes correctly addressed your feedback, and what the next steps are?
NAME thank you for the discussion yesterday, I have and added requested assignments for the labels. Please let me know if I need to do anything else before this can be merged.
:+1: let's pull this in and prepare for WG adoption call
Code change:
timely fashion.  Failure to do so could lead to a deadlock when critical frames, such as WINDOW_UPDATE, are not read and acted upon. <ins> 5.2.3. If an endpoint cannot ensure that its peer always has available flow control window space that is greater than the peer's bandwidth-delay product on this connection, its receive throughput will be limited by HTTP/2 flow control.  This will result in degraded performance. Sending timely WINDOW_UPDATE frames can improve performance. Endpoints will want to balance the need to improve receive throughput with the need to manage resource exhaustion risks, and should take careful note of dos in defining their strategy to manage window sizes. </ins> 5.3. In a multiplexed protocol like HTTP/2, prioritizing allocation of

Related discussion:
text: Brought over the QUIC text about flow control performance. cc NAME
Thank you Cory. After the first sentence, I'd like to add the following because I'm pretty certain it is easily overlooked, especially in gateways where there's basically no way to figure the really available room:
Under what circumstances can that happen?
NAME basically any time on the forward path: if you only count on the local buffer you're using to receive a stream, the window will always be ridiculously low, while you know that you have plenty of buffers on the other side (e.g. forwarding to H1, which is dedicated to your stream, you can count on the H1 buffers and system socket buffers). When forwarding to H2 you can theoretically at least count on min(streamwindow,connectionwindow,buffer room+system buffers), though it can be quite hard to figure. The problem with a multiplexed protocol (when doing fctl-over-fctl like H2 does with TCP) is that your per-stream buffers are always smaller than the connection-level buffers (that include the system's huge socket buffers), which are usually automatically tuned to accommodate the BDP. So in the end relying on stream buffers only implies you can never reach the BDP and will be forced to limit the single-stream bandwidth. This problem doesn't happen with other protocols like QUIC simply because there's no need in-order buffering in the system that you have to rely on. In the end, a reasonable approach consists in having a configurable margin on top of the per-stream buffer room to figure what to advertise, but we need to warn about the risks of advertising too large a window.
Hmm, sorry NAME but I don't see how that relates to the original note you gave. Where is there a head-of-line blocking issue? Having small stream window sizes prevents a single stream reaching full network performance, sure, but that isn't a head-of-line blocking problem. It's a window management problem. If you have multiple streams, all with small windows but all of which can make progress, you can in principal avoid any issues with window management. What am I missing that brings HOL blocking into play?
Sorry Cory if my explanation was not clear. What I meant is that when you start to use reasonable (i.e.
Code change:
timely fashion.  Failure to do so could lead to a deadlock when critical frames, such as WINDOW_UPDATE, are not read and acted upon. <ins> 5.2.3. If an endpoint cannot ensure that its peer always has available flow control window space that is greater than the peer's bandwidth-delay product on this connection, its receive throughput will be limited by HTTP/2 flow control.  This will result in degraded performance. Sending timely WINDOW_UPDATE frames can improve performance. Endpoints will want to balance the need to improve receive throughput with the need to manage resource exhaustion risks, and should take careful note of dos in defining their strategy to manage window sizes. </ins> 5.3. In a multiplexed protocol like HTTP/2, prioritizing allocation of

Related discussion:
text: small) windows for your streams, you immediately see the network performance become horrible, despite all the buffering capacity around (kernel etc), only because of the streams window. I've had users complain about 5 Mbps uploads for example with 64kB windows :-/ As such it's extremely tempting to overprovision the stream window to make it cover some of the extra buffers available around that you're almost certain exists (i.e. the output buffer for where that frame is going to be forwarded), but when starting to play with this you risk HOL because it's often very hard to be certain about really available room (i.e. if you forward that over H2 and several streams consider that same room as available etc). Window-in-window is a very well-known anti-pattern and we knew it was going to hit one way or another and we have to live with it here. For most use cases where a browser is the sole owner of a connection, it's trivial to advertise huge windows and deal with it this way (no real risk that the browser blocks itself). When coalescing multiple agents it becomes quite visible a problem. I hope I managed to make it clearer this time, otherwise do not hesitate to let me know :-)
Thanks Willy, this is definitely clarifying things. So let me try to verify my understanding in bullets. The default per-stream window size (64kB), and other small per-stream window sizes, has performance problems over fat links. This is true. It is not necessarily true if you have multiple streams in flight and your connection window is larger, but it is definitely true for single streams. To that end it is tempting to advertise larger stream windows, to improve throughput. However that window may not be available in the target logical stream, such that if the user actually consumes it your application would have to buffer it. Possible reasons for this include the TCP send buffer not having room, the target H2 connection window not having room, the target H2 stream window not having room, etc. So this is definitely a resource management issue. Presumably the reason there's an HOL issue here is that, in response to needing to buffer on the outbound side, you stop reading from the H2 connection. I can think of a few ways to manage this, but this isn't really the forum for that kind of engineering chat.
Code change:
timely fashion.  Failure to do so could lead to a deadlock when critical frames, such as WINDOW_UPDATE, are not read and acted upon. <ins> 5.2.3. If an endpoint cannot ensure that its peer always has available flow control window space that is greater than the peer's bandwidth-delay product on this connection, its receive throughput will be limited by HTTP/2 flow control.  This will result in degraded performance. Sending timely WINDOW_UPDATE frames can improve performance. Endpoints will want to balance the need to improve receive throughput with the need to manage resource exhaustion risks, and should take careful note of dos in defining their strategy to manage window sizes. </ins> 5.3. In a multiplexed protocol like HTTP/2, prioritizing allocation of

Related discussion:
text: The thing is that due to the window-in-window you don't even benefit from the outer buffering (including the wire) if you have too small stream windows. With a single stream (or even H1) this problem does not exist at all as TCP acks at the edge. Here it's different, the data need to be delivered to userland and wait for its turn before the window can open again. I've seen POST requests slow down to 1 Mbps where the equivalent in H1 were 20 times higher using the same buffer size and TCP stack. So users bump the advertised window to compensate for this horrible performance and face random trouble. And on the server side the issue is the same but less visible, it mostly appears when the coalescing gateway and the servers are located on different datacenters a few milliseconds apart. But even at 4 ms with 64k windows it's only 128 Mbps per stream, so you can be sure that users are quite tempted to increase this for certain use cases where they see their devices twiddling thumbs on their 10/40/100G NICs. This is where it is possible to use the whole pipe's length when it's reserved or all streams of a given connection. What I'm seeking is not to fix the protocol, it is how it is and we all knew about this limitation during its design, but rather to warn users against the risks and effects of not accurately calculating the advertised stream window size in case of combined streams.
By the way, one easy trap to fall into is to advertise a window corresponding to the buffer used at the connection level, while what matters is how much you can extract from this connection to be able to immediately parse subsequent frames. And often you have no precise ideas of how much space there is outside.
Let's try to pull something in, maybe copy from QUIC: URL
Code change:
It is RECOMMENDED that the server certificate contain a DNS SAN that the client can use to perform standard host name validation <del> (RFC9525).  The client SHOULD also extract the WIMSE identity from </del> <ins> (RFC9525).  The client SHOULD also extract the WIMSE identifier from </ins> the certificate if it is present and validate that the WIMSE trust domain matches the intended trust domain for the server.  The client <del> MAY then further use the WIMSE identity in applying authorization </del> <ins> MAY then further use the WIMSE identifier in applying authorization </ins> policy to the server.  If the client does not use the DNS SAN then <del> the client MUST match the WIMSE identity in the certificate against </del> <ins> the client MUST match the WIMSE identifier in the certificate against </ins> the WIMSE identity of the workload of the intended server according to a locally defined policy.  The host portion of the WIMSE URI is NOT treated as a host name as specified in section 6.4 of RFC9525 but rather as a trust domain.  The server identity is encoded in the path <del> portion of the WIMSE identity in a deployment specific way. </del> <ins> portion of the WIMSE identifier in a deployment specific way. </ins> 5.2. <del> The client or server application may retrieve the WIMSE identity from the TLS layer for use in authorization, accounting and auditing.  For example, the full URI may be matched against ACLs and other policy constructs to authorize actions requested by the peer. </del> <ins> The client or server application may retrieve the WIMSE identifier from the TLS layer for use in authorization, accounting and auditing. For example, the full URI may be matched against ACLs and other policy constructs to authorize actions requested by the peer. </ins> 6.

Related discussion:
text: Editorial.
Commenting as identity enthusiast as opposed to WIMSE co-chair. Consider replacing WIMSE Identities with WIMSE Credentials since it is the credential that is being verified, which may include a Workload identifier and possibly other claims.
WIT stays though.
Code change:
5.5. <del> Given the TS parameters, a signed envelope, and a Receipt for it, the following steps must be followed to verify this Receipt. </del> <ins> Given a signed envelope and a Receipt for it, the following steps must be followed to verify this Receipt. Decode the protected header of the Receipt and look-up the TS parameters using the service_id field. </ins> Verify that the Receipt Content structure is well-formed, as described in ReceiptContents. Construct a "Countersign_structure" as described in <del> cose_sign1_countersign, using "sign_protected" from the "leaf_info" field of the receipt contents. </del> <ins> cose_sign1_countersign, using the protected header of the Receipt as "sign_protected". </ins> Compute "LeafBytes" as the bytestring concatenation of the internal hash, the hash of internal data, and the hash of the

Related discussion:
text: Given that all tree algorithms must include a protected header of the countersigner, it makes sense to move that to the top as a common structure. This serves two purposes: inspecting the protected header without verifying the receipt (useful if verification happened elsewhere and a tree-algorithm-agnostic service wants to index general information about the receipt), and allowing for more flexible key discovery schemes in the future that would rely on information in the protected header. Note that this change is independent of the discussions in the mailing list around COSE countersignatures.
Code change:
Furthermore, applications using HTTP MUST NOT re-specify the semantics of HTTP status codes, even if it is only by copying their <del> definition.  They MUST NOT require specific status phrases to be used; the status phrase has no function in HTTP, and is not guaranteed to be preserved by implementations. </del> <ins> definition.  They MUST NOT require specific reason phrases to be used; the reason phrase has no function in HTTP, and is not guaranteed to be preserved by implementations.  The reason phrase is not carried in the RFC7540 message format. </ins> Typically, applications using HTTP will convey application-specific information in the message body and/or HTTP header fields, not the

Related discussion:
text: Port over of PR from mnot repo. Modified last sentence to avoid to much usage of the word "further".
Thanks!
Code change:
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.

Related discussion:
text: 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.
Code change:
the time window during which the JWT can be used.  The authorization server MUST reject any JWT with an expiration time that has passed, subject to allowable clock skew between systems. <del> Note that the authorization server may reject JWTs with an "exp" claim value that is unreasonably far in the future. </del> The JWT MUST contain an "cnf" claim conforming RFC7800 that conveys the key to be used for sender constraining tokens issued

Related discussion:
text: The following changes are encapsulated in this PR: Update references from RFC7523 to RFC7521. Added a recommendation around order of validation for the two JWTs in the client_assertion parameter. Removed the note from the exp and iat claims for the client key Attestation JWT that imply this cannot be re-used across multiple requests. Removed the ability to use MAC based algorithms when producing the client key Attestation JWT. Updated the requirements around the presence of the JTI claim for the client key attestation PoP to be a MUST inline with DPoP PoPs for reliable basic replay attack detection mechanism. Added references to the JWT RFC. Added an implementation consideration that highlights a client instance can re-use a client key attestation JWT in multiple AS interactions/requests. Added aud as a required claim in the client attestation pop JWT. Add IANA registration request for the new client assertion type and token endpoint authentication method.
Code change:
discretion of the verifying party. The following is a non-normative example for a Status List Token in <del> CWT format (not including the type header yet): </del> <ins> CWT format in Hex: </ins> <del> The following is the CBOR diagnostic output of the example above: </del> <ins> The following is the CBOR Annotated Hex output of the example above: </ins> 6.

Related discussion:
text: Changes the CWT example to a Hex and annotated Hex version instead of diagnstic. Rendered version: URL Did you have time to check this example with your team NAME
We have a CWT in 6.3 in diagnostic notation and decided to add a raw (hex) example to the annex