jiebi/CodeConvo huggingface dataset:
Code change:
A recipient MAY combine multiple field lines with the same field name into one field line, without changing the semantics of the message, by appending each subsequent field line value to the initial field <del> line value in order, separated by a comma.  The order in which field lines with the same name are received is therefore significant to the interpretation of the field value; a proxy MUST NOT change the order of these field line values when forwarding a message. </del> <ins> line value in order, separated by a comma and optional whitespace. For consistency, use comma SP. The order in which field lines with the same name are received is therefore significant to the interpretation of the field value; a proxy MUST NOT change the order of these field line values when forwarding a message. </ins> This means that, aside from the well-known exception noted below, a sender MUST NOT generate multiple field lines with the same name in a

Related discussion:
text: So becomes (or maybe they'd reject it, depending on how the header was defined), but a basic intermediary would turn it into . The final recipient in that case cannot figure out what the sender meant. It seems to me that URL should only ever apply after combining header values, including empty ones, not before.
FWIW, the message was invalid wrt that header field already, so "figure out what the sender meant" doesn't make a lot of sense to me.
The problem is that "invalid" depends on whether the recipient knows the syntax, which is just broken if the recipient is allowed to combine before forwarding (which makes it "valid").
The only sensible thing to do is to always combine before determining validity.
See PR. NAME I haven't done anything to address your later comments; how do folks feel about adding a statement spelling out that consequence, either here, or in Considerations for New Fields?
I think explaining the issue would indeed be good.
NAME NAME - Are we sure what we really want to say "optional whitespace" here? Are CR LF or VTAB allowed?
Code change:
supported by the token request.  The details of those grant types are defined below. <del> Confidential or credentialed clients MUST authenticate with the authorization server as described in token-endpoint-client- authentication. </del> <ins> Confidential clients MUST authenticate with the authorization server as described in token-endpoint-client-authentication. </ins> For example, the client makes the following HTTP request (with extra line breaks for display purposes only): The authorization server MUST: <del> require client authentication for confidential and credentialed clients (or clients with other authentication requirements), </del> <ins> require client authentication for confidential clients (or clients with other authentication requirements), </ins> authenticate the client if client authentication is included

Related discussion:
text: OAuth 2 gives a clear definition of public clients, which is where OAuth 2.1 says isn't one of the forms / attributes that could be referred to as credentials? Public clients do have them, they didn't go away, right? ... while they don't have clientsecret of course.
A is not a credential, it is an identifier, and it is always public.
Code change:
1.2. <del> TBD 1.3. TBD </del> 2. TBD

Related discussion:
text: Added terms and definitions section; made some changes data formats based on terms and definitions section -
I think we need to define what the following "things" are. What is the Verifiable Credential based on SD-JWTs? I believe it is the JWT that contains the s. It is not any of the combined formats. This means that the Verifiable Credential MAY NOT contain any disclosable claims, e.g., . Would you agree NAME NAME Daniel? The VC based on SD-JWT will have the media type . What is the Verifiable Presentation based on SD-JWTs? It makes sense to define that since the HB JWT has some specific requirements. It also makes sense because protocol developers will need to refer to one term when they exchange presentations or verifiable presentations between issuer holder verifier. Can we call the Combined Format for Issuance AND Presentation the Presentation based on SD-JWTs, and if there is HB, then it is a Verifiable Presentation? The VP based SD-JWT will have the media type altough I'm not sure if this makes sense. Wouldn't it better to have ? Any thoughts on that?
Also it is important to note that for OIDC4VP we use Verifiable Presentations in vptoken and we use Verifiable Credentials in OIDC4VCI in the credential response. It probably has the implication that for OIDC4VCI, we will put the VC based on SD-JWT into the credential response, or we define a format identifier for something else. Keep in mind we need to send the disclosures to the client as well. In that regards is the SD-JWT itself the SD-JWT-VC without disclosures, or is the combined format including disclosures the SD-JWT-VC? Or we follow the approach above and we return a combined presentation (no HB) in the credential response and define a credential identifier for that. It probably also means that we would put the VP based on SD-JWT into the OIDC4VP vptoken.
We (IDunion) put the combined presentation (+hb jwt) in the vp_token. What else would you expect?
That makes sense, so the VP based on SD-JWT is the combined format for presentation including HB JWT. Then, there is the question what would the OIDC4VCI credential response return?
Code change:
1.2. <del> TBD 1.3. TBD </del> 2. TBD

Related discussion:
text: And what would be a format identifier? I know that this doesn't have to be answered in this spec but it helps with answering the terminology question.
Suggest we not overcomplicate things and say: what is returned in a VP Token in OID4VP is a combined Format for presentation with HB-JWT. what is returned in Credential Response in Credential Response in VCI is combined format for issuance. credential format identifier is 'vc+sd-jwt' for both. Terminology-wise, SD-JWT in the IETF spec is defined as an issuer signed JWS without disclosures. For this profile, the payload of SD-JWT, can be mapped back to a VCDM2.0
This is potentially fixed by PR
Code change:
guarantee out of the registration policies regardless of where it is registered. <del> 6.4. </del> <ins> 6.5. </ins> The same Signed Statement may be independently registered in multiple Transparency Services.  To register a Signed Statement, the service

Related discussion:
text: As proposed in at the WG meeting in Tokyo, we would like to move receipts as a generic primitive in COSE. (see issue ) This PR removes all explicit references to the SCITT receipt ID and instead defines Receipts based on . Note that I also incorporated 2 proposed changes to make SCITT statement and receipt signature more symmetrical: Receipts now include the DID of the transparency service. This can be optionally used to discover the receipt signing key. This change was originally proposed at the IETF WG meeting in London. It simplifies statement authorization, as verifiers can only trust the stable DID of the TS instead of worry about keys or certificate that may be rotated Transparency services can now indicate the registration policies that were actually applied. This is very helpful for verifier, for instance to check the freshness of claims. This was proposed in Tokyo
LGTM, see this implementation: URL and demo: URL
NAME can you help resolve the errors?
Hi, Does this change mean that implementations based on native merkle tries (eg will have to translate proofs to this format ? And if that is so, what is the basis for trusting the service that does that ? Or is there scope for registering trie algorithms based on native proofs like ERC 1186 ?
As we're working to complete for 116, I'm assigning to 116
See for a proposed implementation
Closing as has been merged
I'd like to more generally discuss additional information provided by the TS as it issues receipts: Some information "at the root" refers to its signing (timestamp, keying, ID, etc) but implicitly applies to every statement recorded so far. As discussed at the last hackathon, some information "at the leaf" is the outcome of applying the TS registration policy to each signed statement, including e.g. the configuration of the TS at that point (timestamp, authorized keys, DID resolution results, etc) LGTM
Code change:
what happens to objects that have already been received and possibly scheduled. <del> is a priority number associated with an indiviaul schedulable object. It is specified in the header of the respective peep or datagram, and is the same for all objects in a single peep. </del> <ins> is a priority number associated with an individual schedulable object.  It is specified in the header of the respective subgroup or datagram, and is the same for all objects in a single subgroup. </ins> is a property of an invidual subscription.  It can be either 'Ascending' (groups with lower group ID are sent first), or

Related discussion:
text: (recently merged) uses "Peep" where the rest of the draft now uses "SubGroup" Personally, I wouldn't mind going back to "Peep" since we seem to keep using that term conversationally, but either way, the draft should use one name or the other, not both.
Chairs do you want to reopen this ?
Chair Comment: The working group has aligned on subgroup as the nomenclature in the document. Of course mistakes happen but let's just correct them and move on.
Oops, that was an error.
LGTM
Code change:
TODO: Describe overall, high level requirements that we previously stated in earlier versions of this document. <del> 4.1. </del> <ins> 4.2. </ins> Many of the use cases have bi-directional flows of media, with clients both sending and receiving media concurrently, thus the

Related discussion:
text: This is short, but we should say something about why we're working on this section. Comments are, of course, encouraged.
NAME is hoping that discussion of some requirements at a level that is not protocol-specific would be helpful. It's not helpful to include protocol-specific requirements in this document. This document should explain that.
Code change:
eventually be available for the Signed Statement. If 202 is returned, then clients should wait until Registration <del> succeeded or failed by polling the receipt endpoint using the receipt </del> <ins> succeeded or failed by polling the Resolve Receipt endpoint using the </ins> identifier returned in the response. 2.1.2.3.

Related discussion:
text: Issue Exposes another issue with signed statement identifiers which is being fixed in a different PR.
LGTM
Code change:
It is RECOMMENDED that the JWT contains a <del> JWT header parameter that can be used to lookup the public key in the JWK Set included by value or referenced in the JWT VC Issuer </del> <ins> JWT header parameter that can be used to look up the public key in the JWK Set included by value or referenced in the JWT VC Issuer </ins> Metadata. The following is a non-normative example of a JWT VC Issuer Metadata

Related discussion:
text: also fix a typo or two for Issue
URL has "Combined Format for Presentation", which isn't used in SD-JWT anymore.
I assigned you NAME since you are one of the SD-JWT editor's.
Gotta start somewhere... hopefully I can handle this one. PR has proposed changes.
Code change:
6.1. <del> In PATCH requests the representation digest MUST be computed on the </del> <ins> In PATCH requests, the representation digest MUST be computed on the </ins> patch document because the representation metadata refers to the patch document and not to the target resource (see Section 2 of PATCH). <del> In PATCH responses the representation digest MUST be computed on the </del> <ins> In PATCH responses, the representation digest MUST be computed on the </ins> selected representation of the patched resource. <del> "Digest" usage with PATCH is thus very similar to the POST one, but with the resource's own semantic partly implied by the method and by the patch document. </del> <ins> "Digest" usage with PATCH is thus very similar to POST, but with the resource's own semantic partly implied by the method and by the patch document. </ins> 7.

Related discussion:
text: This ended up being more changes than I first intended but I think most of them are uncontroversial and simply improve consistency through the document.
LGTM. Thanks NAME and Happy New Year!
Code change:
2.1.2.3. <del> One of the following errors: TODO: other error codes </del> <ins> The following expected errors are defined.  Implementations MAY return other errors, so long as they are valid RFC9290 objects. </ins> 2.2.

Related discussion:
text: Updated error returns to be CBOR, and a couple of other things. Still more to do
Since we are talking about , does this mean we must refactor this API endpoint's response with minimally viable CBOR and a CDDL spec in place of JSON?
Yes. Discussed at the hackathon and will make a proposal as part of URL
Added to PR - LMK if you like it
I will have to experiment with it more, but so far I like it. You can link this issue to close it once you merge . Thanks.
Merged.
It's sufficient/better to just ResolveSignedStatement (meaning you get back what was put in) and then the client can pull the Statement out if they want it. Reduces complexity for no loss of functionality
So no separate endpoint, you mean?
Reviewed and merged in
Showing keys without saying what they're for is unhelpful Cedric suggests it might be even better to remove the specifics and just include a standard key discovery locator (which also helps avoid format/types arguments in this doc)
I have attempted to resolve this by removing it in the translation to CBOR in PR - will this suffice?
Reviewed and addressed in
LGTM
Code change:
writing, there are no IETF standards for concurrent multipath congestion control in the general Internet. <ins> 5.9. Data centers are characterized by very low latencies (< 2 ms).  Many workloads involve bursty traffic where many nodes complete a task at the same time.  As a controlled environment, data centers often deploy fabrics that employ rich signalling from switches to endpoints.  Furthermore, the operator can often limit the number of operating congestion controls. For these reasons, data center congestion controls are often distinct from those running elsewhere on the Interenet.  A proposed congestion control need not coexist well with all other algorithms if it is intended for data centers, but the proposal SHOULD indicate which are expected to safely coexist with it. </ins> 6. This document does not represent a change to any aspect of the TCP/IP

Related discussion:
text: I think this is the tip of a larger iceberg, and I'd suggest we'd need to go deeper, if the IETF now thinks they may produce specs in this space. As I recall (others may add to the list), there are challenges to be considered by a proponent/IETF, which include: 1. Does the proposal rely on technologies specified by other Forums/SDOs? 2. Does the IETF have sufficient experience of the DC requirements and to review the proposals? 3. Does the proposal include experience of interoperability between different implementations? or a plan for this? 4. Does the DC traffic share resources with Internet traffic? 5. Specifically: does the method to be used between DCs or only within DCs? - How is this usage scoped? And what happens when the protocol is bridged across an Internet path? One or more of these has in the past thwarted progress towards adoption in the IETF, can we say something about this?
Do you want to take a shot at it? Do we need a completely different section about DC algorithms?
OK, it might be good to keep some version of this as a guidance for evaluating general-purpose protocols in datacenters, AND have a totally different section for DC-specific algorithms.
From IETF 119: Data centers with really small RTTs should be discussed as a special case
NAME We need to be specific about what we mean by datacenter (e.g. Hadoop queries), please give some details about the data center scenarios that we want to take into account NAME Typically you see proposals that rely on the fabric doing non-internet-y things, often there's combined implementation with the data plane, so we need to be specific there. Also saw some presentations this week about non-ethernet fabrics, need to describe what you see from your fabric and what you can then do from a congestion control perspective. NAME Some spillover from IPPM, doesn't work on public internet and not intended to. Number of things being deployed today, massive clusters, 100,000 endpoints constantly talking to each other. Special congestion controllers are very much needed. Trying to keep CPU/GPU non-idle all the time. We need something that is fast within 1-2 RTTs, doesn't matter if done on endpoints, NICs, switches.
Code change:
writing, there are no IETF standards for concurrent multipath congestion control in the general Internet. <ins> 5.9. Data centers are characterized by very low latencies (< 2 ms).  Many workloads involve bursty traffic where many nodes complete a task at the same time.  As a controlled environment, data centers often deploy fabrics that employ rich signalling from switches to endpoints.  Furthermore, the operator can often limit the number of operating congestion controls. For these reasons, data center congestion controls are often distinct from those running elsewhere on the Interenet.  A proposed congestion control need not coexist well with all other algorithms if it is intended for data centers, but the proposal SHOULD indicate which are expected to safely coexist with it. </ins> 6. This document does not represent a change to any aspect of the TCP/IP

Related discussion:
text: There are sets of specific network characteristics; some of this relies on non-IETF specs and it would help to know the interop requirements between implementations and also what the coexistence requirements are for other flows.
Approving this text - LGTM, I propose to move the additional context on data centres to a separate issue, and resolve in a small separate PR against Section 2 & 3.
Code change:
The QUERY method is subject to the same general security considerations as all HTTP methods as described in HTTP. <del> The QUERY method can be used as an alternative to passing query information in the query portion of a URI.  This is preferred in some cases, as the URI is more likely to be logged than the request content.  If a server creates a temporary resource to represent the results of a QUERY request (e.g., for use in the Location or Content- Location field) and the request contains sensitive information that cannot be logged, then the URI of this resource SHOULD be chosen such that it does not include any sensitive portions of the original request content. </del> <ins> The QUERY method can be used as an alternative to passing request information in the URI (e.g., in the query section).  This is preferred in some cases, as the URI is more likely to be logged or otherwise processed by intermediaries than the request content.  If a server creates a temporary resource to represent the results of a QUERY request (e.g., for use in the Location or Content-Location field) and the request contains sensitive information that cannot be logged, then the URI of this resource SHOULD be chosen such that it does not include any sensitive portions of the original request content. </ins> 6.

Related discussion:
text: briefly mentions security advantages See
Moved little changes into sec-: sensitive information can be in both and ; mention intermediaries.
Code change:
or catalog object.  A namespace declared in a track object or catalog object overwrites any inherited name space. <del> 3.2.9. </del> <ins> 3.2.10. </ins> A string defining the name of the track.  See section 2.3 of MoQTransport.  Within the catalog, track names MUST be unique per namespace. <del> 3.2.10. </del> <ins> 3.2.11. </ins> A string defining the type of payload encapsulation.  Allowed values are strings as defined in Table 2. Table 2: Allowed packaging values <del> 3.2.11. </del> <ins> 3.2.12. </ins> Each track description can specify an optional operation value that identifies the catalog producer's intent.  Track operation is a

Related discussion:
text: We need the following Add Catalog Seq Number and explain how it is related to Parent Seq Num Make parent seq num independent of MoQT object number
Proposal is to add two fields: Catalog sequence number (CSN)- a required integer starting at 0 and monotonically increasing with each successive catalog update. Parent sequence number (PSN) - an optional reference pointing at a prior (not necessarily previous) catalog sequence number. If the PSN is absent, then the catalog is an independent catalog. If it is present, then the catalog represents a delta update. Having a sequence number independent of the transport sequencing allows catalogs to be distributed over moq-transport, or http or another transport and still be interpreted correctly.
Code change:
The "SameSite" attribute limits the scope of the cookie such that it will only be attached to requests if those requests are same-site, as defined by the algorithm in same-site-requests.  For example, <del> requests for "https://example.com/sekrit-image" will attach same-site cookies if and only if initiated from a context whose "site for cookies" is "example.com". </del> <ins> requests for "https://site.example/sekrit-image" will attach same- site cookies if and only if initiated from a context whose "site for cookies" is "site.example". </ins> If the "SameSite" attribute's value is "Strict", the cookie will only be sent along with "same-site" requests.  If the value is "Lax", the

Related discussion:
text: This patch replaces with , and corrects inadvertant usage of non-example domains in the hopes of avoiding confusion. Closes httpwg/http-extensions.
NAME mind taking a look?
Landing this. NAME if you object, let me know.
There are still com TLD remaining: and
is real domain. (currently not owned) seems better to use example domain in rfc.
Should we use the .example TLD or stay with URL It's easier to contextualize with .example, in this case webmail.example and projects.example.
SGTM in projects.example, webmail.example etc also URL are fine too.