jiebi/CodeConvo huggingface dataset:
Code change:
before being passed into a non-HTTP/2 context, such as an HTTP/1.1 connection, or a generic HTTP server application. <del> The Cookie header field MAY be split using a zero octet (0x0), as defined in HeaderOrdering.  When decoding, zero octets MUST be replaced with the cookie delimiter ("; "). 8.1.2.5. </del> <ins> 8.1.2.6. </ins> A malformed request or response is one that is an otherwise valid sequence of HTTP/2 frames, but is otherwise invalid due to the

Related discussion:
text: Now that we have decided to remove the reference set, the hacks we added to address header field ordering are no longer entirely necessary. This change does the following: remove the requirement to concatenate with '\0' require pseudo-header fields to all appear before regular header fields change 'header set' to 'header list'
This has implications beyond ordering w.r.t. compression efficiency, especially now that the number of items incurs a cost per item. , Martin Thomson EMAIL wrote:
nice, more red than green :)
Included into HPACK. Encoder and decoder SHOULD preserve ordering. :headers MUST appear before normal headers (in both encoded and decoded lists).
Code change:
authorization server MUST validate BOTH the JWTs present in the "client_assertion" parameter according to the criteria below. <ins> It is RECOMMENDED that the authorization server validate the Client Key Attestation prior to validating the Client Key Attestation PoP. </ins> 3.1.1. The following rules apply to validating the client key attestation

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:
contribute to harm and/or reduce fairness, these effects also ought to be evaluated. <del> At the time of writing, there are currently no Standards Track RFCs, but there is an Experimental RFC RFC6356 that specifies a concurrent multipath congestion control algorithm for TCP (MP-TCP). </del> <ins> At the time of writing (2024), there are currently no Standards Track RFCs, but there is an Experimental RFC RFC6356 that specifies a concurrent multipath congestion control algorithm for TCP (MPTCP RFC8684). </ins> 6.9.

Related discussion:
text: Thanks for the edits. I am a big fan of losing fewer words, so I reverted changes that went in the wrong direction.
Code change:
response, it indicates that the server would like the client to provide the respective Integrity field on future requests. <ins> Integrity preference fields are only a hint.  The receiver of the field can ignore it and send an Integrity field using any algorithm or omit the field entirely, for example see ex-server-selects- unsupported-algorithm.  It is not a protocol error if preferences are ignored.  Applications that use Integrity fields and Integrity preferences can define expectations or constraints that operate in addition to this specification.  How to deal with an ignored preferences is a scenario that should be considered. </ins> "Want-Content-Digest" and "Want-Repr-Digest" are of type "Dictionary" where each:

Related discussion:
text: And how users of digests are the ones responsible for deciding what to do if something is ignore.
Great NAME , thank you!
Murray asked: on the email thread, I responded with To which Murray confirmed it would be a reasonable resolution. Lets get this fixed as discussed
Code change:
(empty) <del> This document registers the 4NN (Too Early) status code in the </del> <ins> This document registers the 425 (Too Early) status code in the </ins> "Hypertext Transfer Protocol (HTTP) Status Code" registry established in RFC7231. <del> 4NN </del> <ins> 425 </ins> Too Early

Related discussion:
text: (I accidentally put this on master without noticing earlier, sorry.)
Can we just have 425 now that it's official-ish? From martinthomson/http-replay
Code change:
More generally, application protocols using HTTP face a number of design decisions, including: <del> Should it define a new URL scheme?  Use new ports? </del> <ins> Should it define a new URI scheme?  Use new ports? </ins> Should it use standard HTTP methods and status codes, or define new ones?

Related discussion:
text: This change switches from "URL" to "URI" specifically for two contexts: URI schemes URI syntax (It might be good to also add an explanation somewhere in the Introduction; I can make a proposal if needed)
It is a PR, no?
Weird, it didn't show the UX for PRs before, but does now. shrug
See URL
Code change:
operations use cases, but it is also a requirement for the Digital Twin. <ins> The following sections shows some example use case descriptions to initiate the discussion what type of info is needed to describe the use cases in the context of Digital Map.  The next version of the draft will include more info on these use cases, from the perspective of what is the value of the digital map for each use case and how the Digital Map API can be used.  This will also clarify if only read and if/when write interface is needed per use case. 3.1. The application will be able to retrieve physical topology from the controller via Digital Map API and from the response it will be able to retrieve physical inventory of individual devices and cables. The application may request either one or multiple layers of topology via the Digital Map API and and from the response it will be able to retrieve both physical and logical inventory. 3.2. 3.3. The application will be able to retrieve all services from the Digital Map API for selected network type.  The application will be able to retrieve the topology for selected services via Digital Map API and from the response it will be able to navigate via the supporting relationship top-down to the lower layers.  That way, it will be able to determine what logical resources are used by the service.  The supporting relations to the lowest layer will help application to determine what physical resources are used by the service. 3.4. The application will be able to navigate from the Physical, L2 or L3 topology to the services that use specific resources.  For example, the application will be able to select the resouce and by navigation the supporting relationship bottom-up come to the service and its nodes, tps and links. 3.5. The application will be able to retrieve topology layer and any network/node/tp/link instances from the controller via Digital Map API and from the response it will be able to determine the health of each instance by navigating to the SAIN subservices and its symptoms. 3.6. The application will be able to retieve the topology at any layer from the controller via Digital Map API and from the response it will be able to navigate any retrieve any KPIs for selected topology entity. 3.7. 3.8. 3.9. 3.10. 3.11. </ins> 4. 4.1.

Related discussion:
text: Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3 (partial, just examples), 5, 6, 7
Code change:
3.4. Secure Reliable Transport (SRT) (I-D.draft-sharabayko-srt) itself is <del> a general purpose transport protocol primarily for contribution transport use cases and this specification covers the encapsulation and delivery of SRT on top of QUIC using datagram frame types.  This </del> <ins> a general purpose transport protocol primarily for ingest transport use cases and this specification covers the encapsulation and delivery of SRT on top of QUIC using datagram frame types.  This </ins> specification sets some requirements regarding how the two interact and leaves considerations for congestion control and pacing to prevent conflict between the two protocols.  Apart from that, SRT

Related discussion:
text: It's likely that only NAME and I will care about this, but I think it matters :grin:
Code change:
6. <del> The CCF 2 tree algorithm specifies an algorithm based on a binary </del> <ins> The CCF tree algorithm specifies an algorithm based on a binary </ins> Merkle tree over the sequence of all ledger entries, as implemented <del> in the CCF version 2 framework (see CCF_Merkle_Tree). </del> <ins> in the CCF framework (see CCF_Merkle_Tree). </ins> 6.1. The algorithm requires that the TS define additional parameters: <del> Hash Algorithm: The hash algorithm used in its Merkle Tree (see hash-alg-registry). Signature Algorithm: The signature algorithm used (see sig-alg- registry). </del> <ins> Signature Algorithm: The ECDSA signature algorithm used to sign the Merkle tree root (see sig-alg-registry). </ins> Service Certificate: The self-signed X.509 certificate used as trust anchor to verify signatures generated by the transparency service using the Signature Algorithm. <del> All definitions in this section use the hash algorithm set in the TS parameters (see Section parameters).  We write HASH to refer to this algorithm, and HASH_SIZE for the fixed length of its output in bytes. </del> <ins> All definitions in this section use the hash algorithm required by the signature algorithm set in the TS parameters (see Section parameters).  We write HASH to refer to this algorithm, and HASH_SIZE for the fixed length of its output in bytes. </ins> 6.2.

Related discussion:
text: Changes: Remove initial version from CCF tree alg identifier. The idea is to not be linked directly to major CCF software releases but rather version independently here. For now, there is no need to include a version number in the tree alg identifier. Remove CCF hash alg parameter as that is always implied by the signature alg. CCF signs pre-hashed data (the Merkle tree root) and doesn't hash twice.
Code change:
3. This draft currently has no requirements for IANA.  If the <del> CACHE_DIGEST frame is standardised, it will need to be assigned a frame type. </del> <ins> specification is standardised, the CACHE_DIGEST frame will need to be assigned a frame type and the Cache-Digest header will need to be registered. </ins> 4.

Related discussion:
text: . Since I wasn't sure if we can make normative references from an appendix, RFC5234 (ABNF) and RFC4648 (Base64) has been added as informative references.
NAME Thank you for your review. I believe that I have addressed all four issues in the commit above.
NAME Would it make sense to also describe the cookie-based method in this spec?
While we could do that, I am kind of negative against it. We need a specification for Cache-digest using HTTP/2 frames or HTTP/1 headers, since it needs to be defined as an interaction between a server and a client (that has the knowledge of what is being cached). OTOH, we do not need a specification for a Cache-Digest cookie, since it is totally controlled by the server. So it is entirely up to each server implementation to use whatever format it wants. Also, it is not easy to find out the right way to implement a cookie-based Cache-Digest that would work on all web browsers, since the timing the browser consumes the cookies sent from the server depend on the timing of the response. To summarize, the relatively low necessity and the technical difficulty makes me hesitate in pursuing the idea.
Code change:
9. <del> Privacy Considerations </del> <ins> Unless advertised by the TS, every issuer should treat its claims as public.  In particular, their envelope and statement should not carry any private information in plaintext. </ins> 10. <del> Security Considerations </del> <ins> On its own, verifying a transparent claim does not guarantee that its envelope or contents are trustworthy--just that they have been signed by the apparent issuer and counter-signed by the TS.  If the verifier trusts the issuer, it can infer that the claim was issued with this envelope and contents, which may be interpreted as the issuer saying the artifact is fit for its intended purpose.  If the verifier trusts the TS, it can independently infer that the claim passed the TS registration policy and that has been persisted in the ledger. Unless advertised in the TS registration policu, the verifier should not assume that the ordering of transparent claims in the ledger matches the ordering of their issuance. Similarly, the fact that an issuer can be held accountable for its transparent claims does not on its own provide any mitigation or remediation mechanism in case one of these claims turned out to be misleading or malicious--just that signed evidence will be available to support them. Issuers SHOULD ensure that the statements in their claims are correct and unambiguous, for example by avoiding ill-defined or ambiguous formats that may cause verifiers to interpret the claim as valid for some other purpose. Issuers and Transparency Services SHOULD carefully protect their private signing keys and avoid these keys for any purpose not described in this architecture.  In case key re-use is unavoidable, they MUST NOT sign any other message that may be verified as an envelope. </ins> 11.

Related discussion:
text: NAME added security considerations and architecture picture
Thanks for the diagram, the sec-sec and all the other additional polish! I thought about tinkering with the diagram, but am in doubt that I'll improve it significantly. LGTM!
Code change:
This document registers the "HTTP2-Settings" header field for use in HTTP. <ins> This document registers the "PRI" method for use in HTTP, to avoid collisions with the ConnectionHeader. </ins> 12.1. This document creates a registration for the identification of

Related discussion:
text: In URL;list=ietf-http-wg, it was proposed that the PRI method be reserved in the HTTP/1.1 method registration document to avoid possible future reservation and ensure that the magic string remains a reliable way of differentiating HTTP/1.1 connections from HTTP/2.0 connections. There was a +1 and some offline discussion along the same vein, no dissent that I heard or saw. However, I don’t see it in URL, presumably because no RFC exists to reference. The appropriate doc is probably HTTP/2.0 rather than breaking the glass on the prepopulated registrations.
There was a question whether "SM" should also be reserved; I personally don't think so, since that line will never be interpreted as a potentially-valid HTTP request line or header. However, I don't think it would break anything if we did.
Break things, no. Squat on prime name-real-estate, a little.
Code change:
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> <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 <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> <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

Related discussion:
text: 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.
Code change:
Signature (JWS) RFC7515 digital signatures.  A consumer of a signed JWT that has checked the signature can safely assume that the contents of the token have not been modified.  However, anyone <del> receiving an unencrypted JWT can read all of the claims and likewise, </del> <ins> receiving an unencrypted JWT can read all the claims and likewise, </ins> anyone with the decryption key receiving an encrypted JWT can also <del> read all of the claims. </del> <ins> read all the claims. </ins> One of the common use cases of a signed JWT is representing a user's identity.  As long as the signed JWT is one-time use, it typically

Related discussion:
text: for add a bit more context/background to the intro about the indented general applicability of SD-JWT and the relation to JWT and the OAuth WG
Code change:
16.3. <del> The delivery order (delivery-order depends on the desired user experience during congestion: </del> <ins> The send order (send-order depends on the desired user experience during congestion: </ins> <del> if media should be skipped: delivery order = PTS </del> <ins> if media should be skipped: send order = PTS </ins> <del> if media should not be skipped: delivery order = -PTS </del> <ins> if media should not be skipped: send order = -PTS </ins> <del> if video should be skipped before audio: audio delivery order < video delivery order </del> <ins> if video should be skipped before audio: audio send order < video send order </ins> <del> The delivery order may be changed if the content changes.  For example, switching from a live stream (skippable) to an advertisement </del> <ins> The send order may be changed if the content changes.  For example, switching from a live stream (skippable) to an advertisement </ins> (unskippable).

Related discussion:
text: Matches the terminology used by W3C is generally much better. This is the order at which objects are sent, but does not guarantee delivery in this order. Doesn't preclude further conversations about prioritization.
This is just a rename so maybe merge it after fixing conflicts (you'll need another approval), or abandon? Based on the discussion today we'll be updating the priority section to indicate other possibilities for expressing priority.
Looks good to me. I would like to see this merged soon, so we can make the proper references to "send order" in the additional PRs.I do think that send order make more sense than delivery order but the parts of this that have to do with the prioritization scheme should probably be moved to a new section of the draft where we talk about the algorithms to decide what to send next.
Code change:
Attackers exploit the unauthenticated channel by changing the context of the user code or QR code and then sending a message to a user <del> (e-mail, text, instant messaging etc).  By deploying content filtering (e.g., anti-spam filter), these messages can be blocked and prevented from reaching the end-users.  It may be possible to fine- tune content filtering solutions to detect artefacts like QR codes or user codes that are included in a message that is sent to multiple recipients in the expectation that at least one of the recipients will be convinced by the message and grant authorization to access restricted resources. </del> <ins> (e-mail, text messaging, instant messaging or other communication mechanisms).  By deploying content filtering (e.g., anti-spam filter), these messages can be blocked and prevented from reaching the end-users.  It may be possible to fine-tune content filtering solutions to detect artefacts like QR codes or user codes that are included in a message that is sent to multiple recipients in the expectation that at least one of the recipients will be convinced by the message and grant authorization to access restricted resources. </ins> Some scenarios may require legitimate re-transmission of user, QR and authorization data (e.g., retries).  To prevent the disruption of

Related discussion:
text: See issue
NAME NAME if you have a moment, can you take a look and approve? I want to merge all PRs and publish an update.
Consider removing the use of etc with either concrete examples or replace with text.