jiebi/CodeConvo huggingface dataset:
Code change:
ua-requirements), the user agent will send a Cookie header field that conforms to the following grammar: <ins> Servers MUST be tolerant of multiple cookie headers.  For example, an HTTP/2 RFC9113 or HTTP/3 RFC9114 connection might split a cookie header to improve compression. </ins> 4.2.2. Each cookie-pair represents a cookie stored by the user agent.  The

Related discussion:
text: I bet there is a server side or two out there that then will not appreciate getting multiple such header fields, perhaps because the h2/h3 special case is not taken care of. But this is just be being worried, I don't know for sure this is the case.
Agreed that such a limit should apply to the total here. I think that would follow from treating this as a funny HPACK encoding of a single field, rather than semantically sending multiple fields. That's not precisely how it's described today, but it results in the exact same behavior on the wire. I.e. we can still get the compression benefits of compressing individual cookies separately, and resolve the slightly awkward phrasing.
Safari started splitting Cookies in h2 and h3 a few years ago, it actually improved website compatibility where the h2 load balancer had a per-field size limit but the ultimate h1 origin did not.
Understood and agreed. So yes, that "MUST NOT" doesn't make any sense, and it's inconsistent with the base HTTP spec. Would be interesting to find out how that got there.
I can't recall the discussions about it on the http-state list back in the day (man, it's been over a decade already!) and I could not find any relevant threads when I casually searched the archives.
Changed from SHOULD NOT to MUST NOT between draft 09 and 10: https://author-URL
I think the wording is intended to be internal to HPACK/QPACK -- that is, there can only ever be one Cookie field as far as HTTP is concerned, but Cookie is special-cased to be split when encoded. To deal with the special case, any occurrence of multiple values gets coalesced. I don't see this as a contradiction.
Are there any remaining concerns before I close this issue? I agree with Mike's interpretation that this isn't a contradiction. The spec mandates that UAs generate a single header field which the server expects on the other end. I don't believe that another layer transparently muxing/demuxing this field is an issue.
I agree that Mike's interpretation is the sensible one to draw from this. I disagree that this is what the specs actually say in the written words.
I can see the potential for confusion here.
Code change:
ua-requirements), the user agent will send a Cookie header field that conforms to the following grammar: <ins> Servers MUST be tolerant of multiple cookie headers.  For example, an HTTP/2 RFC9113 or HTTP/3 RFC9114 connection might split a cookie header to improve compression. </ins> 4.2.2. Each cookie-pair represents a cookie stored by the user agent.  The

Related discussion:
text: This seems to stem from 6265bis's tendency to re-implement other specs requirements, but in a somewhat inferior way. The cookie spec probably shouldn't care how the HTTP request is specifically formed so long as the invariant of a single cookie-string from UA -> Server is maintained by the time the server's cookie processing code receives it. URL would probably help here. In the meantime, I'd prefer if we didn't special case actions such as 9113's cookie header field splitting, so maybe some rephrasing could avoid the issue? Here's a rough draft of what I mean. My intention here is to make it clear that the UA (more specifically the cookie code) should create a single cookie-string to attach as the header's value. This would lead to a single header in the default case, but should still allow for header splitting.
9113 and 9114 have to special-case Cookies for one simple reason: they're a semicolon-delimited list rather than a comma-delimited list. 9110 ; the text in question applies the same logic to Cookies despite the different delimiter and points out that for compression reasons it's particularly useful to split Cookie fields. (It might have been worth noting that other list fields might see similar gains from being split and recombined across the compression boundary, too.) I think NAME proposed text on generation is fine -- there should always be exactly one Cookie header generated from UA->server, though a lower layer might mux it before compression. After decompression, demuxing is mandatory when being passed into a context that doesn't know to expect being split. However, there's that exception in both RFCs: "URL being passed into a non-HTTP/2 context, such as an HTTP/1.1 connection, or a generic HTTP server application." This text clearly supposes that anything version-specific which comes after RFC 7540 will know that Cookies may have been split; perhaps this document should prescribe tolerance of receiving that on the server side. It's then an implementation concern whether that tolerance takes the form of recombining them before processing.
Which document specifically?
Code change:
ua-requirements), the user agent will send a Cookie header field that conforms to the following grammar: <ins> Servers MUST be tolerant of multiple cookie headers.  For example, an HTTP/2 RFC9113 or HTTP/3 RFC9114 connection might split a cookie header to improve compression. </ins> 4.2.2. Each cookie-pair represents a cookie stored by the user agent.  The

Related discussion:
text: Sorry, let me clarify antecedents: >This text [found in RFCs 7540, 9113, and 9114] clearly supposes that anything version-specific which comes after RFC 7540 will know that Cookies may have been split; perhaps [6265bis] should prescribe tolerance of receiving that on the server side. That is, perhaps the Cookie spec should require that servers be able to handle Cookie fragments having been split into multiple Cookie headers, since this document has the opportunity to be aware of HTTP/2+ behavior.
Thanks for clarifying, that makes sense.
LGTM % tiny nits.
Code change:
2.2. A JSON object created by the issuer that contains mapping between raw <del> claim values that contained in the SD-JWT and the salts for each claim value. </del> <ins> claim values contained in the SD-JWT and the salts for each claim value. </ins> 2.3.

Related discussion:
text: Based on the feedback from NAME
This review identifies three minor syntax issues. Once they are addressed, I'll approve.
Code change:
The client requests a digest, preferring sha.  The server is free to reply with sha-256 anyway. <ins> Request: Response: </ins> 7.2.2. The client requests a sha digest only.  The server is currently free to reply with a Digest containing an unsupported algorithm <ins> Request: Response: </ins> 7.2.3. The client requests a sha Digest, the server advises for sha-256 and sha-512 <ins> Request: Response: </ins> ... 8.

Related discussion:
text: Fixes artwork formatting.
[x] requests and responses to use different artworks [x] artworks not containing trailing/heading carriages
Code change:
A string for identifying HTTP/2 is entered into the "Application Layer Protocol Negotiation (ALPN) Protocol IDs" registry established <del> in TLSALPN. </del> <ins> in TLS-ALPN. </ins> This document establishes a registry for frame types, settings, and error codes.  These new registries are entered into a new "Hypertext

Related discussion:
text: Note: adds downref to Informational spec.
It has been noted that there is an opportunity for interoperability failure with the rules we have regarding ephemeral key exchange. e.g., client has only DHE, server has only ECDHE, can't use HTTP/2 Do we want to specify a mandatory to implement cipher suite so that we can avoid this?
Yes, I think you do. TLS 1.3 will be mandating ephemeral key exchange, so I think you just want to use whatever their MTI is (presumably either DHE or ECDHE with AES-GCM). I expect to have a preliminary answer to this in YVR. Will that be soon enough?
TOR, I hope. But I think that should suffice. We can discuss whether we try to preempt that decision or leave a placeholder.
Sorry, I meant YYZ.
Discussed in NYC; will make a decision about it in Toronto. Under discussion - ECDHE / DHE + RSA + AES-GCM + SHA256. Maybe another too.
We need to settle this for WGLC. NAME any chance of getting a decision earlier?
is editor-ready.
Code change:
video is being produced "live" and sent to a platform for syndication and distribution. <del> 4.3.1. </del> <ins> 3.3.1. </ins> Where media is received from a source for onwards handling into a distribution platform.  The media may comprise of multiple audio and/ or video sources.  Bitrates may either be static or set dynamically <del> by signalling of connection inforation (bandwidth, latency) based on </del> <ins> by signaling of connection information (bandwidth, latency) based on </ins> data sent by the receiver. <del> 4.3.2. </del> <ins> 3.3.2. </ins> Where media is sent onwards to another platform for further distribution.  The media may be compressed down to a bitrate lower than source, but larger than final distribution output.  Streams may be redundant with failover mechanisms in place. <del> 4.3.3. </del> <ins> 3.3.3. </ins> Where media is received from a live broadcast or stream.  This may comprise of multiple audio or video outputs with different codecs or

Related discussion:
text: NAME - I think this version is ready for submission as -03, when the submission window reopens during IETF 115. Please let me know what you think.
It would help people contribute to this document if there are blank sections in outline form, and we will be less likely to miss critical stuff.
The IETF 115 proposal to the working group is to use the approved charter as the high level outline for the Requirements section.
Code change:
Claim Key: TBD (requested assignment 65533) Claim Description: A status list containing up-to-date status <del> information on multiple other CWTs encoded as a bitarray. </del> <ins> information on multiple tokens. </ins> Change Controller: IETF

Related discussion:
text: fixes the list rendering (missing newline) clarifies IANA text to just reference other tokens Rendered version: URL
I did further fixes on media types
Code change:
reject any RSA signatures, or a server expecting asymmetric cryptography should know to reject any symmetric cryptography. <ins> An application using signatures also has to ensure that the verifier will have access to all required information to re-create the signature input string.  For example, a server behind a reverse proxy would need to know the original request URI to make use of identifiers like "@target-uri".  Additionally, an application using signatures in responses would need to ensure that clients receiving signed responses have access to all the signed portions, including any portions of the request that were signed by the server. </ins> The details of this kind of profiling are the purview of the application and outside the scope of this specification.

Related discussion:
text: This adds several new specialty identifiers for requests and responses to cover the method, authority, scheme, origin, path, query, and status code values of the HTTP message. It also edits the identifier's associated value to remove the verb and the string construction rules and instead align with HTTP Semantics.
NAME I haven't added references in yet but I tried to move the language in the direction you are suggesting. NAME I added the target-uri field we discussed, please review the text.
Responded to comments and updated normalization rules, please re-review.
Folding in this PR to the main document, discussion can continue on specifics of identifiers and their values as needed.
Code change:
required. Certificates - Applications using HTTP should specify that TLS <del> certificates are to be checked according to I-D.ietf-httpbis- semantics, Section 4.3.4 when HTTPS is used. </del> <ins> certificates are to be checked according to Section 4.3.4 of I- D.ietf-httpbis-semantics when HTTPS is used. </ins> Applications using HTTP should not statically require HTTP features that are usually negotiated to be supported by clients.  For example,

Related discussion:
text: I think this is a matter of taste, so I'm inclined to leave it as is. Could you please update your PRs to make the style consistent and back out these changes?
Consistent with what? There are two suggested forms of references ("Section x of [FOO]" and "[FOO], Section x"). Both have their legitimate uses. What doesn't work for me is using the second form inside a sentence without any delimitation, because it introduces a comma in the sentence structure where it does not be belong.
Code change:
In environments with multiple competing flows all using the same alternate congestion control algorithm, the proposal should <del> explore how bandwidth is shared among the competing flows. </del> <ins> explore how the capacity is shared among the competing flows. </ins> Performance with Misbehaving Nodes and Outside Attackers.

Related discussion:
text: at the time 5033 was written, only TCP, DCCP and SCTP were around, using CC; nowadays, many more protocols use CC - with QUIC standing out as a here, probably warranting it's explicit mentioning.
Yes. Note that there is a bit of sadness here, because QUIC was forced to describe use of Reno in RFC 9002, while most deployments use Cubic or BBR. But the WG could not go beyond Reno... because of RFC 5033!
This one seems simple, but is not. The introduction text says: This formulation, "Impact on standard TCP", assumes that the congestion control algorithm is an integral part of the TCP specification. The situation has changed, and I think this part should be rewritten as: The reference here should be RFC9000, the specification of the transport protocol, rather than RFC9002, the specification of default loss recovery and congestion control algorithms. And the text should then be modified to mention that our goal is to not wantonly disrupt existing deployments -- whether they use Reno, Cubic or BBR. The point is "don't disrupt the Internet", not "don't offend the pride of the IETF".
Looks good.
Code change:
In environments with multiple competing flows all using the same alternate congestion control algorithm, the proposal should <del> explore how bandwidth is shared among the competing flows. </del> <ins> explore how the capacity is shared among the competing flows. </ins> Performance with Misbehaving Nodes and Outside Attackers.

Related discussion:
text: The guidelines section as discussion of "Difficult Environments", starting with "The proposed algorithms should be assessed in difficult environments such as paths containing wireless links." Opinion may vary, but wireless links are probably now part of something between "a vast majority" and "a plurality" of the paths on the Internet.
I agree. Wireless serves the vast majority and are still increasing.
Gorry and Martin: wireless constraints deserve their own section. Three different phenomena to discuss Non-congestion loss Variable bandwidth on the path Jitter due to media access and link-layer retransmission
I changed based on the thread with Christian, and agreed to these insights. I think this ready.
Code change:
proposals in this space. This document is meant to reduce the barriers to entry for new <del> congestion control work to the IETF.  As such, proponents ought not to interpret these criteria as a checklist of requirements before approaching the IETF.  Instead, proponents are encouraged to think about these issues beforehand, and have the willingness to do the work implied by the remainder of this document. </del> <ins> congestion control work to the IETF.  As such, proponents of new congestion control algorithms ought not to interpret these criteria as a checklist of requirements before approaching the IETF.  Instead, proponents are encouraged to think about these issues beforehand, and have the willingness to do the work implied by the remainder of this document. </ins> 2.

Related discussion:
text: Please do not merge yet, I will tray to update to include a few sentences to address the issue related to in-network Circuit breakers.
From NAME review: I do wonder if this document needs to bring up the circuit breaker specifications (RFC 8083, RFC 8084) we do have and potential interaction with them. I would expect a congestion control algorithm to work well within the envelope which would trigger them. The question is if one needs to take them into account when dealing with them. I will note that traffic applying a circuit breaker can be dynamic in transmission pattern and rates and otherwise be very non-responsive in relation to congestion signals. Only if they exceed the circuit breaker threshold will something happen.
This looks good, but please don't mangle my name, or that of Lisong Xu, or ACM Queue reference. Minor edit suggestion on the wording of the last paragraph in "## Paths with Varying Delay {#delay}"
Code change:
verify that requested scopes are not higher priveleged than the scopes of presented subject_token. <del> 2.3.5. </del> <ins> 2.4.5. </ins> All of section 2.2 of RFC8693 applies.  In addition, the following applies to specification that conform to this specification.

Related discussion:
text: Added use cases. We may want to refine these, or move them into a non-normative section later.
Code change:
original signature was made using the key id of "test-key-rsa-pss" and an RSA PSS signature algorithm. <del> The proxy's signature and the client's original signature can be verified independently for the same message, based on the needs of the application.  Since the proxy's signature covers the client signature, the backend service fronted by the proxy can trust that the proxy has validated the incoming signature. </del> 5. While a signer is free to attach a signature to a request or response

Related discussion:
text: A signature over another signature does not provide the transitive protection that it seems it should. The examples and advice have been updated to accomodate this.
NAME NAME can you please verify the signatures on the updated examples in this PR?
Code change:
statement-edn.  The Receipt contains inclusion proofs for verifiable data structures.  The unprotected header contains verifiable data structure proofs.  See the protected header for details regarding the <del> specific verifiable data structure used.  Referencing the COSE Verifiable Data Structure Registry, RFC9162_SHA256 is value "1", which supports "-1" (inclusion proofs) and "-2" (consistency proofs). </del> <ins> specific verifiable data structure used.  Per the COSE Verifiable Data Structure Registry documented in I-D.draft-ietf-cose-merkle- tree-proofs, the COSE key type RFC9162_SHA256 is value "1".  Labels identify inclusion proofs ("-1") and consistency proofs ("-2"). </ins> fig-receipt-protected-header-edn illustrates the decoded protected header of the Transparent Statement in fig-transparent-statement-edn.

Related discussion:
text: Address feedback from Hannes in .
Registry, RFC9162_SHA256 is value 1, which supports -1 (inclusion proofs) and -2 (consistency proofs). I believe this registry is defined in another document. The sentence needs to be changed to make the meaning clear.
Breaks circular relationship until one is completed.LGTM
Code change:
The JWT Issuer Metadata configuration MUST be a JSON document compliant with this specification and MUST be returned using the <del> application/json content type. </del> <ins> content type. </ins> This specification defines the following JWT Issuer Metadata parameters: <ins> JWT Issuer Metadata MUST include either or in their JWT Issuer Metadata, but not both. </ins> It is RECOMMENDED that the JWT contains a JWT header parameter that can be used to lookup the public key in the

Related discussion:
text: NAME do you know how to fix the build errors?
let's fix references later and create a new issue for that
Code change:
Response: <del> 2.2.6. This endpoint in inspired by I-D.draft-demarco-oauth-nonce-endpoint. Authentication SHOULD NOT be implemented for this endpoint.  This endpoint is used to demonstrate proof of possession, which is the reason that authentication is not required.  Client holding signed statements that require demonstrating proof of possession MUST use this endpoint to obtain a nonce. Request: Response: </del> 3. TODO

Related discussion:
text: It's not clear why this would be needed, and it doesn't reflect any patterns in the Architecture. Remove?
NAME there's a reference to "proof of possession", so my guess it that this is meant to enable a flow where the client requests a nonce, includes it in the signed statement (protected header or payload) before signing and submission, to "prove" that they held the key at the time of submission, if it is substantially different from the time of signing. I agree that this should be removed because: It's poorly specified for its stated purpose, without mandatory transport-level security, it's possible to effectively DoS a client by using the nonce they requested quicker than they can. Without authentication, a malicious client can also spam the service for fresh nonce values, causing legitimate ones to fall out of the expiry window before they can be used. There is no mention of a scenario where this is helpful or necessary. If such a scenario emerges, where an issuer signs or has signed indiscriminately in advance, and it is desirable to be stricter about what can be made transparent, there are two easier mechanisms the registration policy can use that don't require an awkward stateful API extension such as this: in the signed statement a counter-signature with a submission control key (which may or may not be the same as one of the issuer keys) Neither requires additional API surface, nor creates additional DoS opportunities. Opened
agree to remove. I believe the intent for including that was the cnf claim in a cwt. But per URL it is for the protocol to define if and how a nonce should be used. Removing this does not preclude the use of cnf. And, at the same time, avoids under (or over) specifying in the wrong place.
Agree I don't believe this endpoint is necessaryLGTM