jiebi/CodeConvo huggingface dataset:
Code change:
times.  See RFC3819 and Section 16 of Tools for further discussion of wireless properties. <ins> 4.3. Congestion control performance is affected by the queue discipline applied at the bottleneck link.  The default queue discipline that MUST be evaluated is drop-tail, First In First Out (FIFO).  See aqm for evaluation of other queue disciplines. </ins> 5. The criteria in evaluation-criteria will be evaluated in the

Related discussion:
text: and .
Also
The text currently reads: "The community should also consider other non-standard congestion controls known to be widely deployed," This is a compromise to land a mostly unrelated PR. NAME doesn't think it's fair to expect participants to test algorithms that aren't fully specified. I would argue that if such specifications exist and the algorithm is systemically important, it absolutely should be modeled. Moreover, if the algorithm is rather loosely described, in many cases there is open source code (often in a Linux fork!) that can be tested on a host, or in simulation frameworks like ns3. If an algorithm is a true black box, with no description besides marketing material, and no open-source code, I agree there is not much to be done. I also believe that while algorithms like this exist, they are not systemically important to the internet.
gorry: ns3 code is not super high fidelity.
Discussed at IETF 118: There's a danger if you see a realtime flow that goes faster than a best effort flow, since realtime is usually constrained by other factors (potentially needing time to move forwards to generate more data) Seems hard to imagine that something not specified is able to place a burden on anybody else. If you want others to do a thing, write it down and document it. Of course, there is no protocol police: we cannot prevent people from deploying whatever they want. Can we provide a carrot for people to play by the rules: Could be a SHOULD consider requirements and how to interact We have: Guidance for people who are writing specs that aren't yet part of the community How do we evaluate those protocols How do we ensure that fairness can exist with these Need to have a commitment from this WG to help and not just throw up new requirements for data and for those bringing new CCs to engage positively. Perhaps spelling this out clearly NAME to file issue to write something encouraging for people early on in the document Christian notes that separate queues between realtime and best effort are not actually a strong requirement To measure capacity you do need some sort of queue, or else you cannot measure
This info RFC has some sensible guidelines on RTP feedback frequency, if we need this: "Sending RTP Control Protocol (RTCP) Feedback for Congestion Control in Interactive Multimedia Conferences".
Related to
Condition (1) is concerned with the behavior with respect to Reno and, thanks to our edits, Cubic.
Code change:
times.  See RFC3819 and Section 16 of Tools for further discussion of wireless properties. <ins> 4.3. Congestion control performance is affected by the queue discipline applied at the bottleneck link.  The default queue discipline that MUST be evaluated is drop-tail, First In First Out (FIFO).  See aqm for evaluation of other queue disciplines. </ins> 5. The criteria in evaluation-criteria will be evaluated in the

Related discussion:
text: But there are of course other congestion controls out there, both standard and non-standard, in support of real-time and other non-greedy applications. Should we mention those as a class? Namecheck some examples?
editors meeting 8836 requirements document 8867 and 8868 are test cases, but informational. Reese: standard stuff is not widely deployed, widely deployed stuff is not standardized. But RMCAT is new. Maybe there aren't well-documented protocols to evaluate vs., so it's hard to require anything here. I'll take a look, will probably have to go to the community.
Editors: We need to consider the interaction between real time and not-real time is evaluating real-time in scope? See 8836, 8867, 8868.
Looks good enough.Thanks for the changes.
Code change:
5.2.1.4. An SD-JWT is a JWT that MUST be signed using the Issuer's private <del> key. </del> <ins> key.  It MUST use a JWS asymmetric digital signature algorithm and MUST NOT use or an identifier for a symmetric algorithm (MAC). </ins> An SD-JWT MAY contain both selectively disclosable claims and non- selectively disclosable claims, i.e., claims that are always

Related discussion:
text: More explicitly state that SD-JWTs have to be signed asymmetrically (no MAC and no ) One item out of John Mattsson's review: URL Thanks for the review John. I've tried to reply to the comments inline below. MUST be signed using the Issuer's private key" in sec 5.2 .) but I think you're right that it should be explicit. I assume it would be a claim. Is there something that suggests otherwise to you? That "HOLDER-PUBLIC-KEY" only shows up in section 4.3 , which is supposed to be a somewhat abstract discussion about it. And I think it's separate from SD-CLAIMS and NON-SD-CLAIMS there to call attention to it. But not to suggest that it's not a claim. More generally (as sec 5.2.3. Holder Public Key Claim tries to describe) the specific way that holder public key binding is established by the issuer and represented in the JWT is out of scope. A "cnf" claim is used in examples for what it's worth. But the specific details of a holder public key binding claim are left to applications using or profiling SD-JWT. the hash input so as to make it infeasible to "reverse" the hash value by enumerating potential claim name/values into the hash function. Correspondingly a salt value is included in the disclosure structure directly alongside a claim name and value. I think using the word secret to talk about salt values would be problematic and potentially confusing. The salt values of undisclosed claims need to be hidden from parties to whom the claim isn't being disclosed. But the salts are sent from the issuer to the holder. And salts of disclosed claims are sent from the holder to the verifier. That's different from a typical secret (as I think of a secret anyway). We can look to add text or clarify text about not revealing salt values to unintended parties. that the "Issuer MUST ensure that a new salt value is chosen for each claim" and a "new salt MUST be chosen for each claim" in section 8.4 . I think that's what you mean by salts being independent of each other? Sec 8.5 has a 128-bit minimum length as RECOMMENDED.
Code change:
5.2.1.4. An SD-JWT is a JWT that MUST be signed using the Issuer's private <del> key. </del> <ins> key.  It MUST use a JWS asymmetric digital signature algorithm and MUST NOT use or an identifier for a symmetric algorithm (MAC). </ins> An SD-JWT MAY contain both selectively disclosable claims and non- selectively disclosable claims, i.e., claims that are always

Related discussion:
text: As I recall, there was some desire to allow for shorter salts when used with a more computationally expensive digest function and the RECOMMENDED would allow for that situation by basically saying to use at least 128 unless you have a good reason to do otherwise and understand the implications. I think "key" or "secret" are definitely not the right name and would be more prone to mislead or confuse. It's a random value that's included in the hash input (that otherwise has a more predictable value space) to make it infeasible to guess/confirm the claim name and value from the hash value. And ensure that the hash output will vary when hashing the same claim name/value more than once. disclosure structure (containing the claim name & value as well as the salt) is hashed and the digest value is placed in the "sd" claim of the signed JWT. Each (signed via inclusion in the JWT) digest value is an integrity check on, and reference to, the corresponding disclosure. Length extension attacks aren't applicable to this kind of use of the hash value. Any change to the disclosure content breaks the integrity check and any change to the hash value breaks the signature. Cheers, CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
Code change:
sent the corresponding HTTP request). The term request-uri refers to "target URI" as defined in Section 7.1 <del> of HTTPSEM. </del> <ins> of RFC9110. </ins> Two sequences of octets are said to case-insensitively match each other if and only if they are equivalent under the i;ascii-casemap

Related discussion:
text: Updates some out of date portions of the IANA considerations section. See for more info
NAME Ping
NAME Ping
Some aspects of the IANA considerations section are outdated and should be updated: The “Cookie” and “Set-Cookie” registrations from RFC 6265 have been moved from the “Permanent Message Header Field Names” registry to the “HTTP Field Name Registry” Update Sections 9.1 (Cookie) and 9.2 (Set-Cookie)The word "Registry" should be omitted from registry names. Update Section 9.3 (Cookie Attribute Registry)
LGTM. Apologies I missed this.
Code change:
sent the corresponding HTTP request). The term request-uri refers to "target URI" as defined in Section 7.1 <del> of HTTPSEM. </del> <ins> of RFC9110. </ins> Two sequences of octets are said to case-insensitively match each other if and only if they are equivalent under the i;ascii-casemap

Related discussion:
text: HTTPSEM has been published as RFC9110, update all reference to reflect this.
NAME Can you PTAL? I spot checked that existing section #s still matched up, but I would appreciate another look.
The sections should be stable, see . I'd also change "HTTPSEM" to just "HTTP2".
Sorry, not sure I understand.
Oops. I meant to say: I'd also change "HTTPSEM" to just "HTTP". See URL
Thanks, the latest commit should fix that.
Still LGTM. Thanks!
Code change:
The CONNECT method requests that the recipient establish a tunnel to the destination origin server identified by the request-target and, if successful, thereafter restrict its behavior to blind forwarding <del> of packets, in both directions, until the tunnel is closed.  Tunnels are commonly used to create an end-to-end virtual connection, through one or more proxies, which can then be secured using TLS (Transport Layer Security, RFC8446). </del> <ins> of data, in both directions, until the tunnel is closed.  Tunnels are commonly used to create an end-to-end virtual connection, through one or more proxies, which can then be secured using TLS (Transport Layer Security, RFC8446). </ins> CONNECT is intended only for use in requests to a proxy.  An origin server that receives a CONNECT request for itself MAY respond with a

Related discussion:
text: The current section on CONNECT (7.3.6) in the semantics document refers to the proxy forwarding packets: Since the proxy terminates TCP, there is no forwarding of IP packets, but rather the contents of the TCP streams.
Well spotted! I'd even suggest "to blindly forward bytes in both directions ...". Too often I see people who imagine that packet delimitation is respected on both sides of a proxy and I have to tell them that it's just a uninterrupted stream of bytes that each layer decides to delimit wherever it wants.
I'd say that 7231 is self-consistent with the use of packet in 7230. If a change is needed, we should change wording consistently. Or, was this issue raised on the WIP core doc?
NAME this issue is being raised on the WIP core doc. The same text does also exist in 7231, but I consider them to both be in error. While we're updating the text for the core doc, let's fix the text to be clearer.
Thanks for the clarification NAME that sounds good to me.
Fwiw, the HiNT draft uses the terminology: blind forwarding of IP payloads, UDP datagram payloads and TCP/IP packet payload.
HTTP/3 says:
NAME that text looks good. Something along those lines, but that also works for HTTP/1.1, would be right for this core doc text.
Maybe just replace "packets" with "data"?
So as mentioned above in , while having a look at the latest draft I was struck again by this "packets" there, and even forgot about this old issue. Pinging again. I suggest that we change "forwarding of packets" with "forwarding of the byte stream" so that we can close these issues.
Code change:
intervening caches are required to invalidate stored responses to keep their contents up to date. <del> means that the cache will either remove all stored responses whose target URI matches the given URI, or will mark them as "invalid" and in need of a mandatory validation before they can be sent in response to a subsequent request. Note that this does not guarantee that all appropriate responses are invalidated globally; a state-changing request would only invalidate responses in the caches it travels through. </del> A cache MUST invalidate the target URI (target.resource) and the URI(s) in the

Related discussion:
text: : I think that MAY should be prose, and should also list retrying the request as an option.
Code change:
5. <del> The security considerations made in RFC3161 as well as those of RFC9338 apply. </del> <ins> Please review the Security Considerations section in RFC3161; these considerations apply to this document as well. Also review the Security Considerations section in STD96; these considerations apply to this document as well, especially the need for implementations to protect private key material. </ins> In the "Timestamp, then COSE" (TTC) sequence of operation, the TSA is given an opaque identifier (a cryptographic hash value) for the

Related discussion:
text: In , Orie commented that: The answer is obviously "no", but the fact that the question was raised seems to indicate that the reference to 9338 is potentially confusing. Note that if we removed it, nothing would change, which is an incentive to drop. Authors might consider providing some guidance regarding validation of CTT where the COSE claims appear (iat, nbf) to have happened after the timestamp ( time travel ). IIRC cose counter signatures apply to the protected header, payload and signature, whereas CTT only applies to the signatures. This means that the TSA does not countersign any protected information in the header? Some use cases for the 2 modes might improve the document. Security considerations seem light. OS >
Code change:
representation digest on an empty string (see usage-in-signatures). The checksum is computed using one of the digest-algorithms listed in <del> algorithms and then encoded in the associated format. </del> <ins> the HTTP Digest Algorithm Values Registry (see algorithms) and then encoded in the associated format. </ins> 3.

Related discussion:
text: add registration policy cc: NAME and NAME to URL Using RFC policy avoids the issues we had to face to refresh the current table. See
NAME now it's Specification Required :)
This specification obsoletes 3230 and updates the IANA registry to point to it, but doesn't specify what the registration policy actually is.
Related to NAME says
See
NAME do we need ? [x] 5. 'The IANA acts a registry' reads oddly; it maintains the registry. Also, saying 'the registry contains the tokens listed below' is misleading; these are initial registrations, which can be modified and added to after the RFC is published. Also, these might be better placed in IANA Considerations.[x] 5. There should not be RFC2219-MUSTs in IANA registry text. This can be addressed by having a requirement similar to "Deprecated digest algorithms MUST NOT be used."[ ] 5. The ability to have a digest algorithm that ignores content-codings is something of a surprise after reading section 2; it needs to be at least mentioned up there.
I'm sure I made this comment somewhere but I've lost it. I don't think we should mandate RFC required, that a very high bar for algorithms (and their users) that most likely developed the algoithm elsewhere already. Instead seem like a better option here
NAME imho registering new algos should be done via an RFC, this doesn't imply that those algorithms should be defined in an RFC. While it is fair to delegate the registration to an external specification, I think the approach of an RFC (eg URL ) is a lot more clean and improves the overall interoperability. It is important to note that any type of RFC is sufficient (currently Standards Track, BCP, Informational, Experimental, or Historic). In any case, I don't think this should be a game-stopper, so if there's general consensus on "Specification Required", that's ok.
I don't think running an RFC process can provide any meaningful value to the registration requirements. I mean, that's going to add like a year of overhead to something as simple as "use algorithm $foo with token , the output is encoded using base64".
The key to Specification Required is the Designated Experts. If they do they job you basically get what you need.
Code change:
representation digest on an empty string (see usage-in-signatures). The checksum is computed using one of the digest-algorithms listed in <del> algorithms and then encoded in the associated format. </del> <ins> the HTTP Digest Algorithm Values Registry (see algorithms) and then encoded in the associated format. </ins> 3.

Related discussion:
text: If there's any question from the DEs they can always kick it back out for further review.
NAME Seems that NAME is on the same page URL ;) So let it be Specification Required! Move on :)
Code change:
Status: the status of the algorithm.  The options are: <del> "standard" - for standardized algorithms without known problems, </del> <ins> "Active" - for algorithms without known problems, </ins> <del> "provisional" - for non-standard or unproven algorithms, </del> <ins> "Provisional" - for unproven algorithms, </ins> <del> "insecure" - for insecure algorithms, </del> <ins> "Deprecated" - for deprecated or insecure algorithms, </ins> Description: a short description of the algorithm

Related discussion:
text: During the SEC AD review, a DISCUSS was raised about the current status values. This change modifies the values to better align with Signatures. The guidance for registration and/or usage of an algorithm based on the status is not affected.
Code change:
request, the algorithm to be used is negotiated through the regular mechanism for negotiating content encoding in HTTP. <del> This document introduces two new content encoding algorithms: </del> The dictionary to use is negotiated separately and advertised in the "Available-Dictionary" request header. 3.1. <ins> This document introduces two new content encoding algorithms: br-d: Brotli RFC7932 using an external compression dictionary and a compression window of not more than 16 MB. zstd-d: Zstandard RFC8878 using an external compression dictionary and a compression window of not more than 8 MB. 3.2. </ins> The client adds the algorithms that it supports to the "Accept- Encoding" request header. e.g.: <del> 3.2. </del> <ins> 3.3. </ins> If a server supports one of the dictionary algorithms advertised by the client and chooses to compress the content of the response using

Related discussion:
text: This change makes it explicit that the content encoding is (same as ) and is (same as ). See the discussion in for why larger ZStandard values were not selected. This carries some nuance for what encoding to use when compressing for maximum benefit as the resource size crosses beyond 8 MB but that is more of an editorial discussion about the individual compression algorithms and probably better laid out in blog posts or explainers than in the spec.
NAME could you PTAL and make sure the language matches what you're working on for the update?
Thanks. I switched the content-encodings definitions and IANA registrations to a list with references back to the algorithm RFCs. For the IANA registrations I removed the window size from the text and linked it to this document (where the window sizes are defined) instead of to the compression algorithms directly. Let me know if a more verbose description of the need to specify the window sizes would be useful or if just being explicit about what they are is enough.
Context: URL aims to clarify the window size limit for the Content Encoding token as it wasn't clear in RFC8878. Since the Compression Dictionary Transport draft hasn't been published yet, we should also add some window size considerations to it for and to maintain interoperability. I think in Chrome we ended up using . NAME
NAME could you comment on how this impacts Brotli dictionary decode? Is the dictionary independent from the compression window (so we can adopt the same defaults as or do we need to specify something relative to the size of the dictionary? NAME NAME for ZStandard, to allow for delta-encoding large resources, is reasonable or should it be ? We have use cases for delta-encoding wasm applications where the dictionary can easily be upwards of 50 MB.
For Zstandard, the states that the entirety of the dictionary is accessible as long as the input is <= Window Size. Therefore, to give an extreme case, it's possible to have a 50 MB dictionary, and it's entirely accessible even if the Window Size is only 1 KB, but only as long as the data to de/compress is <= 1 KB. As soon as we reach 1 KB + 1, reaching the dictionary is no longer valid. For delta compression, this has consequences.