jiebi/CodeConvo huggingface dataset:
Code change:
7.2. <del> The creation of new media transport protocols should be avoided, and instead we should make use of RTP RFC3550 and the existing ecosystem of payload formats and methods of signalling where possible.  Work on QUIC encapsulation may reveal a need to extend these specificiations; in which case we should work with the relevant working groups and present our use-cases. 7.3. </del> Even if multicast and other network broadcasting capabilities are often used in delivering media in our use cases, QUIC doesn't yet support multicast, and would require a QUIC protocol extension to do

Related discussion:
text: The section "Moving Beyond RTP over QUIC" should cover the position of assessing the feasibility of the RTP family of protocols, and the size of work of any possible changes that may be required for them to be incorporated.
This We're going to need more work on RTP versus other transport protocols, but we definitely need to make this change!
I've already ranted enough about this section but I figured I'd file a ticket so it doesn't get forgotten. :)
I think what needs changing is that this is removed as a non-requirement, however I still think that we have to make it clear that a consideration "to RTP or not to RTP" must be described in the document.
I think we've now covered this, please chime up if there was anything missed.
Code change:
Verifiable Credentials in a way that is easy to understand and process as it builds upon established web primitives.  However, JWT- based credentials do not support selective disclosure, i.e., the <del> ability for a holder to disclose only a subset of the claims </del> <ins> ability for a Holder to disclose only a subset of the claims </ins> contained in the JWT, which is a requirement to implement the three- party-model efficiently.

Related discussion:
text: Removes VP terms; changes language around VPs and presentation of VCs; -
NAME gave verbal approval.
Discuss better term than VP-SD-JWTs. VP-SD-JWTs could be an acronym for the above.
I think the term VP-SD-JWT and especially the media type vp+sd-jwt are not appropriate there is no distinct element in SD-JWT that is "THE" VP. I suggest to change the wording to "presentation of a vc-sd-jwt" and drop the media type.
The OpenID4VP spec refers to Verifiable Presentations in the vp_token. Wouldn't it make sense to stick to that terminology? This will allow us to use VP-SD-JWTs more seamlessly with other specs. Would you agree?
That's a good question. I just checked and we don't use the term Verifiable Presentation in conjunction with mdoc. So I think we don't need to use it here either.
Perhaps we should create an issue in OpenID4VP to make it more clear what can be included in the vp_token?
So, this means we will not focus on verifiable presentations at all. We would only speak about presentations of VCs. Is this correct?
Code change:
4. <del> Section 9.2.1 of RFC7540 does not extend to TLS 1.3 KeyUpdate messages.  HTTP/2 implementations MUST support key updates when TLS 1.3 is negotiated. </del> <ins> RFC8446 defines two other messages that are exchanged after the handshake is complete, KeyUpdate and NewSessionTicket. KeyUpdate messages only affect TLS itself and do not require any interaction with the application protocol.  HTTP/2 implementations MUST support key updates when TLS 1.3 is negotiated. NewSessionTicket messages are also permitted.  Though these interact with HTTP when early data is enabled, these interactions are defined in RFC8470 and allowed for in the design of HTTP/2. Unless the use of a new type of TLS message depends on an interaction with the application layer protocol, that TLS message can be sent after the handshake completes. </ins> 5. <del> This document clarifies how to use HTTP/2 with TLS 1.3 and resolves a compatibility concern when supporting post-handshake authentication with HTTP/1.1.  This lowers the barrier for deploying TLS 1.3, a major security improvement over TLS 1.2.  Permitting key updates allows key material to be refreshed in long-lived HTTP/2 connections. </del> <ins> This document resolves a compatibility concern between HTTP/2 and TLS 1.3 when supporting post-handshake authentication with HTTP/1.1. This lowers the barrier for deploying TLS 1.3, a major security improvement over TLS 1.2. </ins> 6.

Related discussion:
text: This addresses feedback from the list: URL URL NAME NAME does this look good to you?
Very nice, thanks. You almost managed to do this with a net reduction in total lines. The only additions here are my fault. Respect.
Code change:
"next-hop" and "next-hop-aliases" parameters, "next-hop-aliases" can be included without including "next-hop". <ins> The proxy can also include the name of the next hop as the first item in the list.  This is particularly useful for reverse proxies when clients would not otherwise know the name of the next hop, and the "next-hop" header is used to convey an IP address. For example, consider a proxy "reverseproxy.example.net" that receives the following records when performing DNS resolution for the next hop "host.example.com": The proxy could include the following proxy status in its response: </ins> The "next-hop-aliases" parameter only applies when DNS was used to resolve the next hop's name, and does not apply in all situations. Clients can use the information in this parameter to determine how to

Related discussion:
text: Allow the original name of the next hop to be the start of the list, and add an example.
NAME NAME please review!
LGTM
I understand that the current draft is specifically targeting forward proxies, but as currently described, the is missing some information when used by reverse proxies, and it's not self-contained anymore (i.e. the requested/configured next hop is not part of the field), making debugging much harder. I find the fact that is not included here a bit confusing. While operators or clients connecting directly to might know that it's a forward proxy and could infer that was the requested hostname, the clients that are a few hops away from it, won't know this, and might be surprised how the and other aliases got in there. Furthermore, in a similar scenario with a client connecting to the reverse proxy and requesting , which is configured to use as the backend, that response is missing the most critical piece of information, and instead of helping, it adds more confusion. As such, I'd suggest that the requested/configured hostname should be included as the first entry in , especially when points to the resolved IP address. cc NAME NAME
This is a good point, especially for reverse proxies. The name of the next hop could be in the next-hop parameter itself, but then there is a choice between the address and the name there. For forward proxies, the name is known and the address is interesting. For reverse proxies, i imagine the name of the next hop is more useful than the address, but I can see why both could be wanted. In such case, perhaps we can allow the aliases list to include the next hop name if it differs from the authority requested by the client.
Yes, that's unfortunate. I'm not sure how we've missed this in RFC 9209. Perhaps we could allow both and use for the configured next hop name, and for the resolved IP address... which actually matches what I'm suggesting we do here by including the requested/configured name as the first entry in . But that's only true on the first hop, right? The authority could be changed along the way by intermediaries, and then the original client wouldn't know what started the resolution which resulted in the received . How would the original client know if that happened in a long chain of proxies?
Code change:
"next-hop" and "next-hop-aliases" parameters, "next-hop-aliases" can be included without including "next-hop". <ins> The proxy can also include the name of the next hop as the first item in the list.  This is particularly useful for reverse proxies when clients would not otherwise know the name of the next hop, and the "next-hop" header is used to convey an IP address. For example, consider a proxy "reverseproxy.example.net" that receives the following records when performing DNS resolution for the next hop "host.example.com": The proxy could include the following proxy status in its response: </ins> The "next-hop-aliases" parameter only applies when DNS was used to resolve the next hop's name, and does not apply in all situations. Clients can use the information in this parameter to determine how to

Related discussion:
text: The authority requested by the client connecting to is not included in the header, and therefore it's not known to the original client. It's impossible to tell if that entry was generated by a proxy that was configured to connect to , which also happens to be the authority it received and therefore it's not included in , or if it was configured to connect to . Basically, I'm trying to avoid adding ambiguity and guesswork to the debugging process that uses this header.
Upon discussing in person: Good to add to an example The text should make it clear that the original name is allowed to be at the start of the list (but doesn't strictly need to be included)
Code change:
We would like to thank Alen Horvat, Anders Rundgren, Arjan Geluk, Christian Bormann, Christian Paquin, David Bakker, David Waite, Fabian Hauck, Filip Skokan, Giuseppe De Marco, Jacob Ward, Jeffrey <del> Yasskin, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Michael Fraser, Mike Jones, Mike Prorock, Nat Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard "fnord" Barnes, Rohan Mahy, Ryosuke Abe, Sami Rosendahl, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </del> <ins> Yasskin, John Mattsson, Joseph Heenan, Justin Richer, Kushal Das, Matthew Miller, Michael Fraser, Mike Jones, Mike Prorock, Nat Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard "fnord" Barnes, Rohan Mahy, Ryosuke Abe, Sami Rosendahl, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </ins> The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.

Related discussion:
text: Mr. Heenan suspects he should probably be listed in the SD-JWT acknowledgements section and I don't disagree
Code change:
Description: The SHA-1 algorithm RFC3174.  The output of this algorithm is encoded using the base64 encoding RFC4648.  This digest-algorithm MUST NOT be used as it's now vulnerable to <del> collision attacks IACR-2020-014. </del> <ins> collision attacks.  See NO-SHA1 and IACR-2020-014. </ins> Reference: RFC3174, RFC6234, RFC4648, this document.

Related discussion:
text: references RFC6515 and 6194 for deprecating md5 and sha1 Since there are RFCs, we could even skip explaining that those algorithms are vulnerable to collisions.
cc: NAME
NAME feel free to PR for the rest of the algorithms :P
In s12.2, should refer (informatively) to and for IETF references that deprecate the use of md5 and sha1, respectively.
Thanks for the pointers, sgtm
You beat me to the PR!
Code change:
Description: The MD5 algorithm, as specified in RFC1321.  The output of this algorithm is encoded using the base64 encoding RFC4648.  This digest-algorithm MUST NOT be used as it's now <del> vulnerable to collision attacks CMU-836068. </del> <ins> vulnerable to collision attacks.  See NO-MD5 and CMU-836068. </ins> Reference: RFC1321, RFC4648, this document.

Related discussion:
text: references RFC6515 and 6194 for deprecating md5 and sha1 Since there are RFCs, we could even skip explaining that those algorithms are vulnerable to collisions.
cc: NAME
NAME feel free to PR for the rest of the algorithms :P
In s12.2, should refer (informatively) to and for IETF references that deprecate the use of md5 and sha1, respectively.
Thanks for the pointers, sgtm
You beat me to the PR!
Code change:
the adversary can control the dictionary, the adversary can learn information about the compressed data. <del> 6.3. </del> <ins> 8.3. </ins> If any of the mitigations do not pass, the client MUST drop the response and return an error. <del> 6.3.1. </del> <ins> 8.3.1. </ins> To make sure that a dictionary can only impact content from the same origin where the dictionary was served, the URL Pattern used for matching a dictionary to requests (match) is guaranteed to be for the same origin that the dictionary is served from. <del> 6.3.2. </del> <ins> 8.3.2. </ins> For clients, like web browsers, that provide additional protection against the readability of the payload of a response and against user

Related discussion:
text: This changes the maximum ZStandard compression window to be the larger of 8 MB and the size of the dictionary. This allows for clients to limit the maximum window size to as low as 8 MB if they like (by not advertising support) while also allowing for clients to use larger dictionaries with ZStandard than they would be able to if the global limit was 8 MB.
NAME and NAME could you also take a look and see if the language looks ok?
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. Presuming the reference is ~50 MB, and the updated content is also ~50 MB, one would need a window size of ~50 MB to ensure access into the dictionary during the entire reconstruction process. But if the updated content is just a bit bigger, say ~51 MB, a ~50 MB window size would allow delta operation only during the first ~50 MB, the last ~1 MB would have to be compressed without dictionary. If follows that the size of the dictionary is irrelevant for the Window size. What matters is for how long one wants to access the dictionary while rebuilding the content.
Code change:
the adversary can control the dictionary, the adversary can learn information about the compressed data. <del> 6.3. </del> <ins> 8.3. </ins> If any of the mitigations do not pass, the client MUST drop the response and return an error. <del> 6.3.1. </del> <ins> 8.3.1. </ins> To make sure that a dictionary can only impact content from the same origin where the dictionary was served, the URL Pattern used for matching a dictionary to requests (match) is guaranteed to be for the same origin that the dictionary is served from. <del> 6.3.2. </del> <ins> 8.3.2. </ins> For clients, like web browsers, that provide additional protection against the readability of the payload of a response and against user

Related discussion:
text: And as a general approximation, one wants this dictionary during the entire reconstruction process, so the window size is effectively the size of the content to rebuild. Zstandard has a "windowless" mode which states exactly that : the size of the "window" is the size of the content. For this to work, one has to set the size of the content at the beginning of the compression process . Setting the content size is either an automatic operation when data is provided entirely upfront (), or, when data is provided in small increments (), it must be stated explicitly at the beginning (). will automatically trigger the "windowless" mode when the declared content size is smaller than the set Window size (effectively reducing the memory requirement for the decoder side). I'm not sure if there is another way to trigger it. Note that the decoder will be informed of the Window Size requirement by reading the frame header, and may decide to not proceed if this value is deemed too large. For example, has a default 128 MB limit, and will refuse to decompress payload requiring more that that, unless explicitly authorized to employ more memory (). Just for reference, offers a "large delta compression" mode with the command . It has made us somewhat familiar with some of these issues. In situations where the amount of data to compress and compare is very large, we now prefer to both the dictionary content and the destination file. It has proven useful to reduce memory pressure.
Thanks. That makes things a bit more complicated for the case where we want to require a minimum window size that the server can trust that all clients advertising content-encoding will be able to decode. For the dictionary case it might be cleanest to use the same 128MB limit for window sizes as the default zstd limit (knowing that the client won't allocate that much unless it actually gets a stream that uses it).
Hello. Shared dictionary is placed in the address space between backward reference window and static dictionary. In other words it does not interfere with normal compression window, but using it makes "static dictionary" references more expensive. We decided to order it that way, because shared dictionary works almost the same way as extra window. Sorry for the late response. Best regards, Eugene.
Extra note. As you can see brotli allows backward distances behind window.
Code change:
the adversary can control the dictionary, the adversary can learn information about the compressed data. <del> 6.3. </del> <ins> 8.3. </ins> If any of the mitigations do not pass, the client MUST drop the response and return an error. <del> 6.3.1. </del> <ins> 8.3.1. </ins> To make sure that a dictionary can only impact content from the same origin where the dictionary was served, the URL Pattern used for matching a dictionary to requests (match) is guaranteed to be for the same origin that the dictionary is served from. <del> 6.3.2. </del> <ins> 8.3.2. </ins> For clients, like web browsers, that provide additional protection against the readability of the payload of a response and against user

Related discussion:
text: IIRC, regular (as opposed to large-window) brotli allows distances up to ~56MiB, i.e. larger shared dictionaries would not be useful (== referenced)
Thanks. For the dictionaries to be usable for a broad set of apps (including large wasm bundles), I'm considering spec'ing: Brotli: Regular 16MB window, allowing for delta-compression of resources up to ~50MB. ZStandard: 128MB window, allowing for delta compression of resources up to around that size, depending on where the duplicated bytes are in the updated resource. The main difference with regular content-encoding is on the ZStandard side where the window is 8MB. For platforms that are resource constrained and are not willing to support a 128MB window they would be limited to Brotli (and then decide how large of a dictionary they are willing to keep and use). Another option on the ZStandard side would be to allow for a maximum window that is a multiple of the dictionary size (i.e. 8MB or 2 * dictionary size whichever is larger with a 128MB max). That way the client can have an upper limit that it knows in advance before advertising as being available. That adds complexity to the encoding side though. We have already seen cases where people want to delta-compress resources > 50MB (wasm apps) where they had to use ZStandard instead of Brotli because of the Brotli limits so I don't think a small limit like 8MB for ZStandard would work with this use case.
That massive resources exist is not sufficient justification to build a system that will not be available to some users. I would prefer a far smaller default. If only to encourage the use of smaller resources overall. Defining a separate codepoint for massive windows is possible, say . The scalable option also seems reasonable. Clients can then choose to offer dictionaries when they exceed available resources.
I'm ok using the same 8MB window ( I believe) that we use for for and note that the effectiveness of delta compression for responses > 8MB using may be limited. The scalable option concerns me that people are likely to get it wrong and it won't be obvious and the decompression will start to fail as the dictionary and resource size changes. NAME does that sound about right?