jiebi/CodeConvo huggingface dataset:
Code change:
This document describes the uses cases, requirements, and considerations that should guide the design of the encapsulation of a <del> real-time media transport protocol as a payload in the the QUIC protocol RFC9000. </del> <ins> real-time media transport protocol as a payload in the QUIC protocol RFC9000. </ins> Protocol developers have been considering the implications of the QUIC protocol (RFC9000) on media transport for several years, but the

Related discussion:
text: One more use case "Distribution withing a platform" is suggested. It does not seem to be covered by other use cases, but might be worth describing it as well. Some minor suggestions like UDP multicast instead of QUIC as the last mile transport, etc.
Thanks!
Code change:
(see be-consistent for details). An intermediary MUST NOT remove this header field if it is present in <del> a request. </del> <ins> a request.  "Early-Data" MUST NOT appear in a "Connection" header field. </ins> The "Early-Data" header field is not intended for use by user agents (that is, the original initiator of a request).  Sending a request in

Related discussion:
text: According to RFC 7231, Section 8.3.1. I didn't include anything here about Vary because I wanted to discuss that first and these seemed uncontroversial. It seems OK to say that Vary is permitted here because we expressly talk about varied reactions based on the presence of Early-Data. If that's right, I will amend this with a second commit. (I'm jetlagged, so being a little cautious.)
Your proposal looks very clear to me, despite your jetlag :-) I agree with you that Vary should be OK. I don't even think we need to say anything about it then.
Code change:
5. The SEARCH method is subject to the same general security <del> considerations as all HTTP methods as described in RFC7231. </del> <ins> considerations as all HTTP methods as described in RFCHTTP. </ins> 6. IANA is requested to update the registration of the SEARCH method in the permanent registry at <http://www.iana.org/assignments/http- <del> methods> (see RFC7231). </del> <ins> methods> (see RFCHTTP). </ins>

Related discussion:
text: content-type / media type header / header field
This should include updating the core spec references; I will update this PR accordingly unless you get to that before me.
See
Code change:
general, these algorithms are expected to be less mature than ones that follow the procedures in this document.  Authors documenting deployed congestion control algorithms that cannot be changed by IETF <del> or IRTF review are invited to publish as an Informational RFC via the Independent Stream Editor (ISE). </del> <ins> or IRTF review are invited to seek publication as an Informational RFC via the Independent Stream Editor (ISE). </ins> 4.

Related discussion:
text: A few clarifying nits, as resolving the tension between a global "MUST evaluate" and some local "SHOULD evaluate"s.
Merge!
Code change:
The SNAC router MAY advertise itself as a default router on the stub network, if it itself has a default route on the AIL.  In some cases it may not be desirable to advertise reachability to the Internet as <del> a whole; in this case the stub router is not required to advertise </del> <ins> a whole; in this case the SNAC router is not required to advertise </ins> itself as a default router. If the SNAC router is not advertising itself as a default router on

Related discussion:
text: Update draft version "stub router flag" -> SNAC router flag fix a few cases where Esko (I think!) missed changing stub router to SNAC router but should have (there are some cases where "stub router" is correct and I hope I did not change any of those.
In the update to the 'SNAC router' name () the flag name was not yet taken along in the update. This issue is to decide on that change also, and if needed make the change. (The 6man document would also need to change the flag name then, first.)
Code change:
3.1. <del> A response message is considered complete when all of the octets indicated by its framing are available.  Note that, when no explicit framing is provided, a response message that is ended by the connection's close is considered complete even though it might be indistinguishable from an incomplete response (see Messaging).  A cache SHOULD consider a close-terminated response incomplete if the connection termination is detected to be an error.  A server that wishes to avoid premature termination resulting in an incorrect cached response SHOULD send the response with explicit framing. </del> If the request method is GET, the response status code is , and the entire response header section has been received, a cache <del> MAY store an incomplete response message body if the stored response is recorded as incomplete.  Likewise, a </del> <ins> MAY store a response body that is not complete (operation) if the stored response is recorded as being incomplete.  Likewise, a </ins> response MAY be stored as if it were an incomplete

Related discussion:
text: NAME please review.
Roy noticed that we use a special meaning of "invalidate" and then define it pretty casually below. This can be improved.
Code change:
2.1.2. <del> Authentication MUST be implemented for this endpoint. </del> <ins> Authentication MAY be implemented for this endpoint.  See notes on detached payloads below. </ins> The following is a non-normative example of a HTTP request to register a Signed Statement:

Related discussion:
text: Issue Also harmonize title with other endpoints
In the case of a government end point, why must client authentication be implemented. The signature on the statement is the authentication for the content and is ultimately who is making a reputation statement.
Agreed. In addition to this I think there are several places where we need to clean up seemingly helpful implementation comments which are actually harmful. For instance the mention of using auth for rate limiting is a fine thing to say but it's nothing to do with SCITT and will be done in other layers by any sensible implementation.
Resolved by
On internal or truly public instances this could be MAY
Code change:
REQUIRED Expiry time of the Txn-Token as defined in REQUIRED A unique transaction identifier as defined in Section 2.2 <del> of RFC8417.  When used in the transaction token, it identifies the entire call chain.  It is strongly RECOMMENDED to provide an identifier unique within the trust domain.  If providing such an identifier is not possible, then a fixed value of "N_A" MAY be supplied. </del> <ins> of RFC8417. </ins> REQUIRED A unique identifier for the subject within the context of the "aud" trust domain.  Unlike OpenID Connect, the "sub" claim is

Related discussion:
text: The following issue came up during the IETF 120 session on TraTs: There was a comment about some of the processing rules that was the equivalent of NULL with extra processing steps (N_A)
George and Atul recommend that we should drop the sentences after "REQUIRED A unique transaction identifier as defined in Section 2.2 of ]." Since this is a normative section, it need not have any usage guidance in there. If required we can add non-normative usage guidance such as "The txn value MAY be used to identify the call chain"
Code change:
WPTs with an expiration time unreasonably far in the future SHOULD be rejected. <ins> The "wth" claim is present and matches the hash of the token value conveyed in the "Workload-Identity-Token" header. </ins> Optionally, check that the value of the "jti" claim has not been used before in the time window in which the respective WPT would be considered valid.

Related discussion:
text: Adds 'wth' claim to WPT to bind WPT to WITs.
NAME please also update the relevant IANA section so we don't forget.
I realize I missed a meeting but why did we add this?
What's the threat? Different WITs with the same cnf key and a compromised middle thing?
I just don't see it...
Iss in the WPT is even less useful with this too.
Yes, currently we don't have strong binding between WPT and WIT. Only the fact that . I don't understand the "even less" part but I see that this is somewhat duplicated now.
Should be: WIT sub == WPT iss. And just to state it explicitly: people are likely to extend the WIT with various "junk" (i.e., policy) and that wouldn't be covered otherwise.
Code change:
authorization server during the client registration process. The redirect URI MUST be an absolute URI as defined by RFC3986 <del> Section 4.3.  The redirect URI MAY include an "application/x-www- form-urlencoded" formatted query component (WHATWG.URL), which MUST be retained when adding additional query parameters.  The redirect URI MUST NOT include a fragment component. </del> <ins> Section 4.3.  The redirect URI MAY include an query string component (query-string-serialization), which MUST be retained when adding additional query parameters.  The redirect URI MUST NOT include a fragment component. </ins> 2.3.1.

Related discussion:
text: This moves the description of serializations to the appendix part of
Though i wonder whether the Authorization Response () section should account for the extension - URL with text like "unless specified otherwise by an extension".
yeah I can add that, sounds reasonable
added a lot of text around how clients form authorization requests, the language does not however account for the optional POST binding at the authorization endpoint. Sections and do not account for the optional POST binding which uses the request body to carry the encoded parameters. In OIDC there's the request parameters.
This has been resolved in , there is now a section that describes the serialization methods in an appendix, which is referenced elsewhere in the spec: URL
LGTM
Code change:
Common Name: Token type for Self-signed JWT <del> Change Controller: IESG </del> <ins> Change Controller: IETF </ins> Specification Document: Section self-signed-subject-token-type of this specification

Related discussion:
text: We received the following email from IANA: Before the IETF meeting, we check working group agendas for documents with IANA-related issues. We have notes about the current version of this document: URL 1) We haven’t been asked to update the change controller field for existing registrations, but the IESG prefers that the IETF be listed as the change controller for new registrations. 2) A few minor editorial notes about the media type registration: The applicant name and email field should be omitted. Where those fields appear on the IANA website, they’re an artifact of the web form, and not officially part of the template. We’re gradually removing those fields from existing registrations.The media type registrations don’t appear to include a change controller field.The quotation marks around type, subtype, and required and optional parameters can be removed, as should the “(RFC 2046)” after “application.” Finally, please note that RFC 6838 recommends asking the mailing list for an informal review. If you have any questions, just let us know. If you'd like to talk in person, you can find us next to the RFC Editor's table from Monday through Thursday. You can also request another review at any time by contacting us at . For more information about IANA Considerations section requirements, please see URL Best regards, Amanda Baber IANA Operations Manager
Code change:
9. <ins> The privacy principles of ISO.29100 should be adhered to. </ins> 9.1. Wherever End-User data is stored, it represents a potential target

Related discussion:
text: When merged, this PR replaces PR and closes Issue . I am not sure what value reference to ISO 27551 brings (+1 to remove it). Unlinkability pairs defined in ISO27551 do not really apply to Issuer-Holder-Verifier model, since they are modelled after User Agent-RP model. and anonymity of the User is out of scope for SD-JWT IMO, but adding one subsection on "User identifier should be chosen to guarantee user anonymity and not only pseudonymity". but feels redundant since SD-JWT is not only for natural persons.. Some of the notions in PR 93 were outdated since claim names are now blinded by default. "Issuer Issuing One Type of SD-JWT" section might be valuable, also confirming with Smart health card community.
the "build" for this PR isn't working URL
Code change:
status code (HTTP). The semantics of 101 (Switching Protocols) aren't applicable to a <del> multiplexed protocol.  Alternative protocols are able to use the same </del> <ins> multiplexed protocol.  Similar functionality might be enabled through the use of RFC8441 and other protocols are able to use the same </ins> mechanisms that HTTP/2 uses to negotiate their use (see starting). 8.7.

Related discussion:
text: I know that Cory beat me to it with , but I had written text. I only forgot to make the PR. Cory can decide which he likes better :)
In the aside about HTTP/2 deliberately not supporting Upgrade, it feels worth mentioning that we later partially reversed ourselves and brought back a moral equivalent of Upgrade with a less obvious name. Reference to RFC8441 appropriate here?
You put more things in your citation block, so it’s clearly better.
Code change:
the client such as microphone audio for in-game chat with other players. <del> 4.3. </del> <ins> 4.1.2. </ins> *Senders/Receivers*: One to One *Bi-directional*: Yes *Latency*: <del> Ultra-Low </del> <ins> Ull-50 </ins> Where media is received, and user inputs are sent by the client. Latency requirements with this usecase are marginally different than the gaming use case.  This may also include signalling and/or transmitting of files or devices connected to the user's computer. <del> 4.4. </del> <ins> 4.1.3. </ins> <del> *Senders/Receivers*: One to Many *Bi-directional*: No *Latency*: Low to Non-Low </del> <ins> *Senders/Receivers*: Many to Many *Bi-directional*: Yes *Latency*: Ull-200 </ins> <del> Where media is received from a live broadcast or stream.  This may comprise of multiple audio or video outputs with different codecs or bitrates.  This may also include other types of media essence such as subtitles or timing signalling information (e.g. markers to indicate change of behaviour in client such as advertisement breaks).  The use of "live rewind" where a window of media behind the live edge can be made available for clients to playback, either because the local player falls behind edge or because the viewer wishes to play back from a point in the past. </del> <ins> Where media is both sent and received; This may include audio from both microphone(s) or other inputs, or may include "screen sharing" or inclusion of other content such as slide, document, or video presentation.  This may be done as client/server, or peer to peer with a many to many relationship of both senders and receivers. 4.2. </ins> <del> 4.5. </del> <ins> 4.2.1. </ins> *Senders/Receivers*: One to One *Bi-directional*: No *Latency*: <del> Ultra-Low to Low </del> <ins> Ull-200 to Ultra-Low </ins> Where media is received from a source for onwards handling into a distribution platform.  The media may comprise of multiple audio and/

Related discussion:
text: It's likely that only NAME and I will care about this, but I think it matters :grin:
Code change:
Abstract <del> This document describes a tree algorithm for COSE Signed Merkle Tree Proofs specifically designed for implementations that rely on Trusted Execution Environments (TEEs) to make the tree more tamper-resistant. </del> <ins> This document defines a new verifiable data structure type for COSE Signed Merkle Tree Proofs specifically designed for implementations that rely on Trusted Execution Environments (TEEs) to provide stronger tamper-evidence guarantees. </ins> 1. The Concise Encoding of Signed Merkle Tree Proofs (CoMeTre) I- <del> D.steele-cose-merkle-tree-proofs defines a standard format for carrying COSE-encoded Merkle Tree proofs and the associated signed root value.  This is helpful to pove to a verifier that a given serializable element is recorded at a given index in the Merkle Tree, or to prove that a tree is an extension of another. In this document, we describe how to verify such CoMeTre proofs for a new type of trees associated with the Confidential Consortium Framework (CCF).  Compared to RFC9162, the leaves of CCF trees carry additional opaque infomation that is used to verify that elements are only written by the Trusted Execution Environment, which addresses the persistance of committed transactions that happen between new signatures of the Merkle Tree root. </del> <ins> D.steele-cose-merkle-tree-proofs defines a common framework for defining different types of proofs, such as proof of inclusion, about verifiable data structures (also abbreviated as "logs" in this document).  For instance, inclusion proofs guarantee to a verifier that a given serializable element is recorded at a given state of the log, while consistency proofs are used to establish that an inclusion proof is still consistent with the new state of the log at a later time. In this document, we define a new type of log, associated with the Confidential Consortium Framework (CCF) ledger.  Compared to RFC9162, the leaves of CCF trees carry additional opaque information that is used to verify that elements are only written by the Trusted Execution Environment, which addresses the persistence of committed transactions that happen between new signatures of the Merkle Tree root. </ins> 1.1.

Related discussion:
text: This uses the new proof type registry and redefines the signature type. Unlike the CT-style log algorithm the proof type is part of the trusted headers
Code change:
In this scenario, the Authorization Server and Resource Server MUST support the necessary CORS headers to enable the JavaScript code to <del> make this POST request from the domain on which the script is </del> <ins> make these POST requests from the domain on which the script is </ins> executing.  (See cors for additional details.) 7.

Related discussion:
text: reworked some architectural patterns: Javascript applications accessing resource servers directly (js = oauth client)
Code change:
referenced in the credential.  This process is further described in I-D.ietf-oauth-selective-disclosure-jwt. <del> To support revocation of credentials, an optional fourth party can be involved, a Status Provider, who delivers revocation information to Verifiers.  (The Verifier can also serve as the Status Provider.) </del> <ins> To support revocation of Verifiable Credentials, an optional fourth party can be involved, a Status Provider, who delivers revocation information to Verifiers.  (The Verifier can also serve as the Status Provider.) </ins> <del> The three-party-model, i.e., actors, Verifiable Credentials and Verifiable Presentations, is also described in VC-DATA.  This specification defines Verifiable Credentials based on the SD-JWT format and JSON payloads.  A translation algorithm between the two approaches is provided in this specification. </del> <ins> The three-party-model, i.e., actors, Verifiable Credentials, is also described in VC-DATA.  This specification defines Verifiable Credentials based on the SD-JWT format and JWT Claim Sets with JSON payloads.  A translation algorithm between the two approaches is provided in this specification. </ins> 1.2.

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:
Create an ordered list of the field values of each instance of the field in the message, in the order that they occur (or will occur) <del> in the message.  If necessary, separate individual values found in a field instance. </del> <ins> in the message. </ins> Strip leading and trailing whitespace from each item in the list. Note that since HTTP field values are not allowed to contain

Related discussion:
text: URL This does not work. It's impossible to split multiple values (be it a list-based field or not) without knowledge of the field value's grammar. For example, what is the canonicalized value for: ?
The value would be Since it was sent as two instances, you combine the instances with a comma and space. The language to split the field values was added late based on several conversations about list type fields and how they can be combined, but we can remove this. If someone needs additional armoring they can use the "sf" flag on a list formatted field.
Ok, but what the spec currently says would result in: URL that sentence really needs to go.
No, it would not result in that, because as you point out those are not separate field values that can be separated.
So what does: mean then? When is it "necessary"? How does the code know that for any given field name?
I think what is meant is that you take a list of the values of a given field (one member of the list for each header line) and then concatenate them by separating them with ", ". In scala this is or just to make it explicit
Thanks NAME - I get that, but that doesn't address the question I asked...
Ok, I see the problem is: I would not know how to do that, whereas I do know how to seperate the fields in the list.
We need to be very clear with the terminology. What do you mean by "seperate the fields in the list"? Do you have an example?
If you are talking to me, I meant what the code above showed: the list is the list of header values (for a given header name). And I meant seperating the values of that list. I don't know how to write that up well in the spec though...
Ok, AFAIU: just drop "If necessary, separate individual values found in a field instance." from the spec.
URL I don't quite get the reasoning for the second "MUST". Why does it matter? What would break if the client uses a single comma, which is also allowed by HTTP? IMHO the exact delimiter sequence here does not matter at all, as long as it is allowed per HTTP. Note that HTTP allows combining field values, it does not allow splitting them afterwards.