jiebi/CodeConvo huggingface dataset:
Code change:
credentials are displayed. This section defines Type Metadata that can be associated with a type <del> of a SD-JWT VC, as well as a method for retrieving the Type Metadata </del> <ins> of an SD-JWT VC, as well as a method for retrieving the Type Metadata </ins> and processing rules.  This Type Metadata is intended to be used, among other things, for the following purposes:

Related discussion:
text: Also note that .well-known has well-known issues with multi-tenancy. Most use cases will delegate the hosting of the information to registries. Also Questions: if schema is https, should the full URL be provided? (no ambiguity with .well-known, you can host schema on github, ...) metadata retrieval category re-consideration: 1) Fetch vct from a remote source: a) URL: HTTPS schema -> full URL that points to a schema b) URN: domain-defined URN that MUST be understood by the wallet; The URN method defines how to map the URN to URL and retrieve the data 2) Fetch vct the metadata locally a) local cache b) Signature (signed or unsigned header); Whether or not metadata is shared in the (un)protected header is defined by the signature format, hence out of scope of this document. 2b: point to consider for the OID4VP: should there be a flag: "archival mode" or similar, that would flag that the wallet needs to provide all the referenced content in an unprotected JWS header?
removes the requirement to insert .well-known (discussion in )
Type Metadata introduced new well-known URI /.well-known/vct/ in "6.3.1. From a URL in the vct" , but this is not reflected in appendix-A.3 Well-Known URI Registry. Additionally, using in sentence "Metadata can be retrieved from the URL URL, i.e., by inserting /.well-known/vct after the authority part of the URL." seems to me a little bit confusing as type is considered to refer to whole URI. Maybe use or (to include also query and fragment URI components)?
Thank you and yes, the registration request is missing and needs to be added. And that sentence could also be improved.
Although the use of .well-known for type metadata is being reconsidered
Current text: Since well-known only applies to HTTPS URLs, we should limit the section to HTTPS URLs although other URLs would be still possible, e.g., . Additionally, also the in is probably not correct since the type refers to the value itself which would not make sense to the full value here which would also include the scheme for instance. I suggest we update the title to "From an HTTPS URL in the claim" and update the language to something like this:
Code change:
6.11. <del> The subscriber sends the SUBSCRIBE_NAMESPACE control message to a </del> <ins> The subscriber sends the SUBSCRIBE_ANNOUNCES control message to a </ins> publisher to request the current set of matching announcements, as well as future updates to the set.

Related discussion:
text: On the call today, people favored renaming to ANNOUNCES over ANNOUNCEMENTS, so I'll do that.
I call it . Because the subscriber is interested in any messages that match the prefix.
I agree with this. It is counterintuitive that SUBSCRIBE_NAMESPACE results in an ANNOUNCE request being sent to RELAY.
Speaking as an individual that came up with the name: It's terrible and anything the group comes up with is better. #sorry I'm fine with ANNOUNCEINTEREST. My suggestion is SUBSCRIBEANNOUNCEMENTS.
I like both ANNOUNCEINTEREST and SUBSCRIBEANNOUNCEMENTS. They are both long by the time we add OK and error to them. I wonder about just calling it INTEREST. I don't feel strongly about any of these names but I do like the idea of improving the name.
+1 This is clearer than ANNOUNCE-INTEREST, which is an ambiguous term for the uninitiated.
Code change:
The HEADERS frame payload has the following fields: <ins> Padding size high bits.  This field is only present if the PAD_HIGH flag is set. Padding size low bits.  This field is only present if the PAD_LOW flag is set. </ins> A single reserved bit.  This field is optional and is only present if the PRIORITY flag is set.

Related discussion:
text: Padding is made to a frame and other frames (DATA and CONTINUATION) have these 2 bytes right after the frame header. It is easier for implementation to put the same constructs in the same position.
Code change:
4. <del> This document establishes a registry of Merkle tree algorithms with </del> <ins> This document establishes a registry of merkle tree algorithms with </ins> the following initial contents: <del> [FIXME] exploration table, what should go into -00? </del> Each tree algorithm defines how to compute the root node from a sequence of leaves each represented by payload and extra data.  Extra data is algorithm-specific and should be considered opaque. <del> 4.1. </del> <ins> 5. </ins> <del> The "RFC9162_SHA256" tree algorithm uses the Merkle tree definition from RFC9162 with SHA-256 hash algorithm. </del> <ins> TBD </ins> <del> For n > 1 inputs, let k be the largest power of two smaller than n. </del> <ins> 5.1. </ins> <del> where "d(0)" is the payload.  This algorithm takes no extra data. </del> <ins> In cases where a single merkle root and multiple inclusion paths are used to prove inclusion for multiple payloads.  There is a risk that an attacker may be able to learn the content of undisclosed payloads, by brute forcing the values adjacent to the disclosed payloads through application of the cryptographic hash function and comparison to the the disclosed inclusion paths.  This kind of attack can be mitigated by including a cryptographic nonce in the construction of the leaf, however this nonce must then disclosed along side an inclusion proof which increases the size of multiple payload signed inclusion proofs. </ins> <del> 5. </del> <ins> 6. </ins> TBD <del> 6. </del> <ins> 6.1. </ins> <del> TBD </del> <ins> The choice of cryptographic hash function is the primary primitive impacting the security of authenticating payload inclusion in a merkle root.  Tree algorithm designers should review the latest guidance on selecting a suitable cryptographic hash function. </ins> 7.

Related discussion:
text: Changes from IETF 116 hackathon
I'm stopping on this PR, before it gets even larger.
NAME I have made several more changes, please review when you have a chance.
I am merging, we reviewed this content together at IETF.
Code change:
string.  Key Binding MAY be achieved by signing the envelope JWT instead of including a separate Key Binding JWT in the SD-JWT. <del> The claim SHOULD be used when transporting an SD-JWT unless the application or protocol defines a different claim name. </del> The following non-normative example shows an SD-JWT Presentation enveloped in a JWT payload: <del> Here, the SD-JWT is shown where </del> <ins> Here, the SD-JWT is shown as the value of an claim where </ins> represents the Issuer-signed JWT and

Related discussion:
text: I noticed that the consolidation of SD-JWT terminology in c6a27373dee13cc7c3f70a8b7fd374e62306f5a0 introduced a mistake in the "Enveloping" section title by including the word "Presentation" while the section talks about enveloping either issued or presented SD-JWTs. While fixing that, I decided to remove the SHOULD recommending the use of an unregistered claim name . I also tried to align the example enveloping payload a bit with a move minimal set of claims similar to those used in key binding. I realize I probably should have just fixed the section title and not expanded the scope of the changes. But there I was and these few little changes were so inviting... See it here: URL
Code change:
frame has the END_HEADERS flag set. Header compression is stateful.  One compression context and one <del> decompression context is used for the entire connection.  Each header block is processed as a discrete unit.  Header blocks MUST be transmitted as a contiguous sequence of frames, with no interleaved frames of any other type or from any other stream.  The last frame in a sequence of </del> <ins> decompression context is used for the entire connection.  A decoding error in a header block MUST be treated as a ConnectionErrorHandler of type . Each header block is processed as a discrete unit.  Header blocks MUST be transmitted as a contiguous sequence of frames, with no interleaved frames of any other type or from any other stream.  The last frame in a sequence of </ins> or

Related discussion:
text: Proposal to replace . I think that this is a little clearer this way. Also, it's strange that this was not added earlier, but then sometimes the most obvious things get missed. cc NAME
So I'm not seeing how the new sentence is any different than this one two paragraphs below: A receiver MUST terminate the connection with a connection error of type COMPRESSIONERROR if it does not decompress a header block. My chief concern (merely editorial) is that HPACK consistently uses the phrase "decoding error" whereas here we are using the phrase "decompress." I think it good to make clear that any and all decoding errors MUST result in connection errors of type COMPRESSIONERROR. Picky, I know. ;-)
I think that Martin's proposal tries to specifically address your concern. The sentence two paragraphs below address the case of an endpoint deciding for whatever reason not to decompress a header block: this also has to result in a COMPRESSION_ERROR. So I think that both are useful.
Ahhh - thanks NAME Makes perfect sense and I agree.
Code change:
it is unlikely to be a practical limitation.  There is no limit to the size of content in an indeterminate length message. <del> Omitting content by truncating a message is only possible if the content is zero-length. </del> 3.8. Messages can be padded with any number of zero-valued bytes.  Non-

Related discussion:
text: Basically, it saves the effort of writing stuff that you know to be empty. It's not a critical feature, but it turns out to be a simple way to deal with not sending trailers or a body. In the extreme, you can also drop headers to produce the simplest and shortest HTTP message ever: 0x0140c8. CLoses .
Hey David, I've made some larger edits here to factor the truncation text better. I've included your normative language.
The draft mentions that messages can be truncated in some places, but not in others. I think it would help to explain why one would want to truncated a message.
This is really just a neat way to avoid having to write out all of the pieces of a message. So if you don't have trailers, it's OK not to say "I have 0 trailers". The decoder is required to deal with it. Before you say "that's hard", you don't need to change the parser to deal with truncation. Adding three zero-valued bytes to the end of any message you receive does the job just fine. If it isn't truncated, those will be treated as padding.
Thanks
Code change:
deployed congestion control algorithms. In contexts where differing congestion control algorithms are used, <del> it is important to understand whether a proposal can induce more harm to flows sharing a bottleneck than for the existing defined methods. The measure of harm is not restricted to the equality of capacity, but ought also to consider metrics such as the latency introduced, or an increase in packet loss.  An evaluation must assess the potential to cause starvation, including assurance that a loss of all feedback (e.g., detected by expiry of a retransmission time out) results in backoff. </del> <ins> it is important to understand whether a proposal could result in more harm than previously defined algorithms to flows sharing a common bottleneck.  The measure of harm is not restricted to the equality of capacity, but ought also to consider metrics such as the latency introduced, or an increase in packet loss.  An evaluation must assess the potential to cause starvation, including assurance that a loss of all feedback (e.g., detected by expiry of a retransmission time out) results in backoff. </ins> 3.2.1.

Related discussion:
text: Minor proposal: the leading sentence in the second paragraph of the section "Mixed algorithm" could be made a bit easier to read.
I think we can merge
Code change:
overview has normative language around congestion control which may be at odds with our potential requirements. <del> 4.6. </del> <ins> 4.7. The protocol SHOULD have capabilities beyond what QUIC provides to allow hosts to authenticate one another, this should be kept simple but robust in nature to prevent attacks like credential brute- forcing. </ins> <del> The protocol SHOULD have capabilities asides from TLS mutual authentication to allow hosts to authenticate one another, this should be kept simple but robust in nature to prevent attacks like credential brute-forcing. </del> <ins> TODO: More details are required here </ins> 5.

Related discussion:
text: Hi, NAME I think this looks mostly fine (it looks like the abstract is a tiny bit garbled, but we can fix stuff like that in an editorial pass). Based on the changed title, I'm assuming that we aren't worrying about SRT and RUSH in this draft - that's probably a good call, because I don't think their requirements are going to look much like RTP over QUIC requirements. There will be some places that I will need to tighten up what I wrote, because they were still in scope when I was typing. I'll merge this, and see where I end up in an hour or two of typing.
I needed a bit more context for this: I'm probably confused by "The protocol". URL says it provides this authentication using TLS 1.3 handshake. Are you thinking of something in addition to the QUIC cryptographic handshake? (Assuming the definition of "Media Transport Protocol" in ), something provided by the Media Transport Protocol level? Or something else?
Something in addition to the QUIC cryptographic handshake (in which I am talking about TLS mutual authentication here, where client presents a valid certificate to server, and verifies the server certificate). Consider: Existing protocols in this space usually offer some "shared secret" of some variety as part of either/or an authentication handshake, and encryption of media: which are just secret values set in the field during connection handshake (see § 6.4) - but note they also support a cert-based approach which more closely matches TLS mutual auth where the Stream ID and user define the authorisation Before RIST Main profile there hasn't been a need for a lot of certificate-based authentication and so existing folk in field would use these types of shared secret patterns, and that having to keep PKI for devices may be problematic. Consider things like encoding hardware deployed in remote locations. Other options could be considered, like using a more SIP-like approach, but we would have to be careful not to bring the rest of the SIP kitchen sink with its round peg that might not fit in the square QUIC slot. I get this requirement presently is a bit flaky in part because the requirements are a bit unclear. Perhaps I put a little more description on the requirement, or remove it from the draft now, and leave it for a "ask later". Thoughts?
Code change:
overview has normative language around congestion control which may be at odds with our potential requirements. <del> 4.6. </del> <ins> 4.7. The protocol SHOULD have capabilities beyond what QUIC provides to allow hosts to authenticate one another, this should be kept simple but robust in nature to prevent attacks like credential brute- forcing. </ins> <del> The protocol SHOULD have capabilities asides from TLS mutual authentication to allow hosts to authenticate one another, this should be kept simple but robust in nature to prevent attacks like credential brute-forcing. </del> <ins> TODO: More details are required here </ins> 5.

Related discussion:
text: NAME I think (1) adding the explanation that this is beyond the authentication mechanism provided by QUIC, and (2) leaving it in the draft, with a note that more detail is needed, and will be added as discussion proceeds, is all that's needed for now.
Closing this as I think it has been addressed, please by all means speak up if we still should do work here.
I THINK what we are doing, is roughly Start with current "Media - Media Transport Protocol", where "Media Transport Protocol" might be RTP Encapsulate in QUIC, to give "Media - Media Transport Protocol - QUIC" If that's right, we should be using "Media Transport Protocol" to describe the first layer under "Media", and what we're doing might better be described as something like "Media Transport Protocol Encapsulation" ("in QUIC"). Whatever we choose, we should be consistent - the Abstract says which would make me believe that we're designing a replacement for existing media transport protocols, but then under "Non-requirements, we have I think that the second quote is correct, so we just need to be clearer in the first quote.
I agree with this, and it should be fixed. Would you like me to clean it up or do you want to roll it in with other changes?
Hi, NAME would it be OK if you did this cleanup? I think adding the picture of the two protocol stacks, in some form, will be super helpful for readers.
I think we can close this as our nomenclature for the document is kind of done now the -00 is out.
We have been talking about "Media Over QUIC" as a broad term that would include any media transport protocol running over QUIC, which (apparently) would include RTP over QUIC SRP over QUIC RUSH, which runs over QUIC If we are doing "Media over QUIC", all of these (and potentially others) would be in scope. If the scope of this document is "Media over RTP over QUIC", that would be fine, but we should say that. Thoughts?
I think we've fixed this one - I'll close it for now.
Code change:
are capitalized.  To ensure readability, only a core set of terms is included in this section. <del> Verifiers use the Feed to ensure completeness and Non-equivocation in supply chain evidence by identifying all Transparent Statements linked to the Artifact they are evaluating. </del> 4. In this document, the definition of transparency is intended to build

Related discussion:
text: Reverts ietf-wg-scitt/draft-ietf-scitt-architecture
Code change:
the Referenced Token. The JWT MUST contain a "sub" (subject) claim that contains an <del> unique string identifier for that Referenced Token.  The value </del> <ins> unique string identifier for that Status List Token.  The value </ins> MUST be equal to that of the "uri" claim contained in the "status" claim of the Referenced Token.

Related discussion:
text: Change typo in Status List Token sub claim description URL
The in the "Status List JWT Format and Processing Requirements" section has 'The JWT MUST contain a "sub" (subject) claim that contains an unique string identifier for that Referenced Token.' but I believe it should be "... unique string identifier for that Status List Token."
that's correct, thanks for pointing this out Brian
Code change:
support the Tunnel-Protocol header field. The value of the Tunnel-Protocol header field could be falsified by a <del> client.  The use of protocols like RFC5246 make it very difficult or impossible to verify that the header field is correct even after a connection is established.  A proxy therefore cannot rely on the value of the Tunnel-Protocol header field as a policy input in all cases. </del> <ins> client.  If the data being sent through the tunnel is encrypted (for example, with RFC5246), then the proxy might not be able to directly inspect the data to verify that the claimed protocol is the one which is actually being used, though a proxy might be able to perform traffic analysis TRAFFIC.  A proxy therefore cannot rely on the value of the Tunnel-Protocol header field as a policy input in all cases. </ins>

Related discussion:
text: This adds a section regarding falsification of Tunnel-Protocol. I didn't expand this to note that WebRTC won't suffer from this problem because the application won't be able to set the header field. That seemed like too much detail.
Code change:
6.9.2. <del> When a HTTP/2 connection is first established, new streams are </del> <ins> When an HTTP/2 connection is first established, new streams are </ins> created with an initial flow control window size of 65,535 bytes. The connection flow control window is 65,535 bytes.  Both endpoints can adjust the initial window size for new streams by including a

Related discussion:
text: l.815 before: An endpoint MUST NOT send frames other than than HEADERS/x:ref or fix: An endpoint MUST NOT send frames other than HEADERS/x:ref or
Code change:
is sent right after the last object in the track.  This SHOULD be cached. <del> 0x5 := Indicates end of Subgroup.  Object ID is one greater than the largest normal object ID in the Subgroup. </del> Any other value SHOULD be treated as a protocol error and terminate the session with a Protocol Violation (session-termination).  Any object with a status code other than zero MUST have an empty payload.

Related discussion:
text: We don't discuss how to use it anyway. This was suggested in
Done
There are references to EndOfSubgroup in the FIN PR, so one of the two PRs is going to have to delete them.
Code change:
The value of the parameter is a bit-field of which the following bits are defined: <del> FRESH (0x1): When set, it indicates that the server is willing to make use of a digest of freshly-cached responses. STALE (0x2): When set, it indicates that the server is willing to make use of a digest of stale-cached responses. </del> <ins> ACCEPT (0x1): When set, it indicates that the server is willing to make use of a digest of cached responses. </ins> Rest of the bits MUST be ignored and MUST be left unset when sending.

Related discussion:
text: Resolves URL
cc NAME NAME
Hey Yoav, Thanks; will take a look. Two immediate things: You're getting a error in the markdown; . I see you've added yourself as an author. That's generally the decision of the chair - NAME in this case.
Hopefully fixed. Is there a way to test it locally? Apologies for the noobness. Removed myself.
See URL for build info.
NAME Thank you for working on the proposal. Am I correct in assuming that changes other than the switch to Cuckoo filters and the introduction are unintentional? For example, I see flag of the frame being removed. Do you have a working code that implements Cuckoo filters? I am curious to see it working. The concept of makes sense to me. Maybe we might want to adjust the codepoints and the naming in relation to .
Oh, I now understand the intent of removing the flag. The motive of the proposal is to build a digest without referring to every response object stored in cache. The fact means that it is not be easy for the client to determine the freshness of the entries that is going to be included in the digest. I am sympathetic to the idea, but I am afraid if the approach works well with the current mechanism of HTTP/2 caching. My understanding is that browsers that exist today only consume a pushed response when it fails to find a freshly cached response in its cache. Otherwise, the pushed response never lands in the browser cache. Unless we change the behavior of the browsers to respect the pushed response even if a freshly cached object already exists in its cache, there's a chance that servers would continually push responses that gets ignored by the client (due to the existence of a freshly cached response in the browser cache with the same URL). NAME Assuming that I correctly understand the motive of removing the distinction between a fresh digest and a stale digest, I would appreciate it if you could clarify your ideas on the problem.
Thanks for reviewing, NAME :) My intent was to include all stored resources in the digest, regardless of them being stale or fresh. Entries are added to the digest when a resource is added to the cache and removed from the digest when a resource is removed.