jiebi/CodeConvo huggingface dataset:
Code change:
Hence, the server processing logic SHOULD be: <del> 7.2.1. </del> It is RECOMMENDED that the server uses the following HTTP codes to indicate errors, with the media type "application/alto-error+json", regarding update item requests.

Related discussion:
text: NAME Med, I have migrated the draft to markdown format (see ). The changes are merged as well. I am taking a complete pass of the markdown before merging it to the main branch.
Thank you, NAME Looking forward merging the new branch into the main.
Code change:
Abstract <del> This document defines the core behavior for MoQTransport, a live media transport protocol over QUIC.  The application fragments a live stream into objects, including a header that describes the basic relationship between objects.  Objects are starved/dropped during congestion based on priorities in order to minimize latency. </del> <ins> This document defines the core behavior for MoQTransport, a media transport protocol over QUIC.  MoQTransport allows a producer of media to publish data and have it consumed via subscription by a multiplicity of endpoints.  It supports intermediate content distribution networks and is designed for high scale and low latency distribution. </ins> 1. <del> MoQTransport is a live media transport protocol that utilizes the QUIC network protocol QUIC, either directly or via WebTransport WebTransport.  It was originally developed for live media, but has been generalized for similar use-cases. </del> <ins> MoQTransport (MoQT) is a transport protocol that utilizes the QUIC network protocol QUIC, either directly or via WebTransport WebTransport, for the dissemination of media.  MoQT utilizes a publish/subscribe workflow in which producers of media publish data in response to subscription requests from a multiplicity of endpoints.  MoQT supports wide range of use-cases with different resiliency and latency (live, interactive) needs without compromising the scalability and cost effectiveness associated with content delivery networks. MoQTransport is a generic protocol is designed to work in concert with multiple MoQ Streaming Formats.  These MoQ Streaming Formats define how content is encoded, packaged, and mapped to MoQT objects, along with policies for discovery and subscription. </ins> motivation covers the background and rationale behind MoQ transport.

Related discussion:
text: NAME does the latest commit address your feedback? thanks
lgtm modulo addressing Luke's comment.
Code change:
Abstract <del> This document defines the core behavior for MoQTransport, a live media transport protocol over QUIC.  The application fragments a live stream into objects, including a header that describes the basic relationship between objects.  Objects are starved/dropped during congestion based on priorities in order to minimize latency. </del> <ins> This document defines the core behavior for MoQTransport, a media transport protocol over QUIC.  MoQTransport allows a producer of media to publish data and have it consumed via subscription by a multiplicity of endpoints.  It supports intermediate content distribution networks and is designed for high scale and low latency distribution. </ins> 1. <del> MoQTransport is a live media transport protocol that utilizes the QUIC network protocol QUIC, either directly or via WebTransport WebTransport.  It was originally developed for live media, but has been generalized for similar use-cases. </del> <ins> MoQTransport (MoQT) is a transport protocol that utilizes the QUIC network protocol QUIC, either directly or via WebTransport WebTransport, for the dissemination of media.  MoQT utilizes a publish/subscribe workflow in which producers of media publish data in response to subscription requests from a multiplicity of endpoints.  MoQT supports wide range of use-cases with different resiliency and latency (live, interactive) needs without compromising the scalability and cost effectiveness associated with content delivery networks. MoQTransport is a generic protocol is designed to work in concert with multiple MoQ Streaming Formats.  These MoQ Streaming Formats define how content is encoded, packaged, and mapped to MoQT objects, along with policies for discovery and subscription. </ins> motivation covers the background and rationale behind MoQ transport.

Related discussion:
text: NAME does the updated text with OPEN ISSUE looks about right to you. I personally feel we should revisit all the terms and get to a common understaning across the documents. For -05 an OPEN ISSUE seems like OK. thoughts ?
LGTM
Code change:
Abstract <del> This document defines the core behavior for MoQTransport, a live media transport protocol over QUIC.  The application fragments a live stream into objects, including a header that describes the basic relationship between objects.  Objects are starved/dropped during congestion based on priorities in order to minimize latency. </del> <ins> This document defines the core behavior for MoQTransport, a media transport protocol over QUIC.  MoQTransport allows a producer of media to publish data and have it consumed via subscription by a multiplicity of endpoints.  It supports intermediate content distribution networks and is designed for high scale and low latency distribution. </ins> 1. <del> MoQTransport is a live media transport protocol that utilizes the QUIC network protocol QUIC, either directly or via WebTransport WebTransport.  It was originally developed for live media, but has been generalized for similar use-cases. </del> <ins> MoQTransport (MoQT) is a transport protocol that utilizes the QUIC network protocol QUIC, either directly or via WebTransport WebTransport, for the dissemination of media.  MoQT utilizes a publish/subscribe workflow in which producers of media publish data in response to subscription requests from a multiplicity of endpoints.  MoQT supports wide range of use-cases with different resiliency and latency (live, interactive) needs without compromising the scalability and cost effectiveness associated with content delivery networks. MoQTransport is a generic protocol is designed to work in concert with multiple MoQ Streaming Formats.  These MoQ Streaming Formats define how content is encoded, packaged, and mapped to MoQT objects, along with policies for discovery and subscription. </ins> motivation covers the background and rationale behind MoQ transport.

Related discussion:
text: NAME please check the latest commit . thanks
Something is wrong, this PR appears blank
editorial nit if it can be addressed, otherwise LGTM
Code change:
Abstract <del> This document defines the core behavior for MoQTransport, a live media transport protocol over QUIC.  The application fragments a live stream into objects, including a header that describes the basic relationship between objects.  Objects are starved/dropped during congestion based on priorities in order to minimize latency. </del> <ins> This document defines the core behavior for MoQTransport, a media transport protocol over QUIC.  MoQTransport allows a producer of media to publish data and have it consumed via subscription by a multiplicity of endpoints.  It supports intermediate content distribution networks and is designed for high scale and low latency distribution. </ins> 1. <del> MoQTransport is a live media transport protocol that utilizes the QUIC network protocol QUIC, either directly or via WebTransport WebTransport.  It was originally developed for live media, but has been generalized for similar use-cases. </del> <ins> MoQTransport (MoQT) is a transport protocol that utilizes the QUIC network protocol QUIC, either directly or via WebTransport WebTransport, for the dissemination of media.  MoQT utilizes a publish/subscribe workflow in which producers of media publish data in response to subscription requests from a multiplicity of endpoints.  MoQT supports wide range of use-cases with different resiliency and latency (live, interactive) needs without compromising the scalability and cost effectiveness associated with content delivery networks. MoQTransport is a generic protocol is designed to work in concert with multiple MoQ Streaming Formats.  These MoQ Streaming Formats define how content is encoded, packaged, and mapped to MoQT objects, along with policies for discovery and subscription. </ins> motivation covers the background and rationale behind MoQ transport.

Related discussion:
text: NAME I think you added this TODO but it got removed in the editorial pass, are you good with that?
Yes, we can remove this. We will certainly revisit the issue later, because this is a thorny subject. For example, we assume that "objects MUST not depend from objects in the group that have a higher priority code or a higher object ID" -- object at P2 does not depend on another object at P3, object number 1000 cannot depend on object number 2001. That much has consensus, but it is a negative statement.
Code change:
6. To evaluate whether an access token meets the protected resource's <del> requirements, the resource servers needs a way of accessing </del> <ins> requirements, the resource server needs a way of accessing </ins> information about the authentication event by which that access token was obtained.  This specification provides guidance on how to convey that information in conjunction with two common access token

Related discussion:
text: updates from Lars Eggert's IESG review/ballot URL Lars Eggert has entered the following ballot position for draft-ietf-oauth-step-up-authn-challenge-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: CC NAME Thanks to Christer Holmberg for the General Area Review Team (Gen-ART) review (URL). Found terminology that should be reviewed for inclusivity; see URL for background and more guidance: Term ; alternatives might be , , , , , , , , , , , , , , , , All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via URL), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. These URLs in the document can probably be converted to HTTPS: URL This word seems to be formatted incorrectly. Consider fixing the spacing or removing the hyphen completely. Consider using "after". The verb form "needs" does not seem to match the subject "servers". An apostrophe may be missing. This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [ tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [][IRT]. [ICMF]: URL [ICT]: URL [IRT]: URL
Code change:
Response: <del> Note that a "204 No Content" response without payload data but with the same "Digest" field-value would have been legitimate too. </del> <ins> Note that a "204 No Content" response without content but with the same "Digest" field-value would have been legitimate too. </ins> 10.8.

Related discussion:
text: Use "content" instead of "payload data".
to reference semantics-14, including "payload data" --> "content".
Code change:
user or a robotic process that requested the Transaction "authn" The authentication method used to idenitfy the requester. <del> Its value is a URN that uniquely identifies the method used. "req_wl" The requesting workload.  A URN that uniquely identifies the computational entity that requested the Txn-Token.  This entity MUST be within the Trust Domain of the Txn-Token. </del> <ins> Its value is a StringOrURI that uniquely identifies the method used. "req_wl" The requesting workload.  A StringOrURI that uniquely identifies the computational entity that requested the Txn-Token. This entity MUST be within the Trust Domain of the Txn-Token.  If a replacement Txn-Token has been requested, then this claim will be an array of StringOrURIs representing the different workloads that have requested Txn-Tokens as part of the transaction processing. 5.2.1.1. It is useful to be able to track the set of workloads that have requested a Txn-Token.  The "req_wl" claim allows for tracking this information even through requests for a replacement Txn-Token.  By default the "req_wl" is a StringOrURI representing the original workload entity that requested the Txn-Token.  However, if a workload within the path of servicing the transaction requests a replacement Txn-Token, then the Transaction Token Service will append the new requesting workload as a subsequent array element in the "req_wl" claim.  This provides a "pathing" mechanism to track which services have requested replacement Txn-Tokens.  If there is only a single value the "req_wl" will be a StringOrURI.  If there is more than a single value, then "req_wl" will be prepresented by an array of StringOrURIs. </ins> 5.2.2.

Related discussion:
text: I updated the text to require the claim remain unchanged when requesting a replacement transaction token. I also added a mechanism to allow for tracking the workloads that have requested replacement transaction tokens. This was necessary as the current text required the to remain unchanged in the replacement transaction token and the object contains the requesting workload identifier. I used a mechanisms similar to x-forwarded-for. This needs lots of review.
It would be good to show how, in a replacement txn-token, the identity of the previous subid is preserved. The replacement token may have a new subid that represent the workload that requested the replacement token. Originally posted by NAME in URL
Can we close this since it was addressed in PR ?
Code change:
7.3.7. <del> When applying content-request-response or signature-multiple to a </del> <ins> When applying the content-request-response or signature-multiple to a </ins> message, it is possible to sign the value of an existing Signature field, thereby covering the bytes of the existing signature output in the new signature's value.  While it would seem that this practice

Related discussion:
text: Reframe use cases that had previously signed signature values to avoid problems with this approach.
This looks good to me! Summary of the changes: Explicitly flagging that the application / implementer must specify how request-response binding is to be achieved (if desired). Removed all references to request-response binding in the main body. Removed all signatures of signatures from the examples Added guidance that applications SHOULD sign all signed components of a request when generating a signed response. Added guidance that generating signatures of signatures is NOT RECOMMENDED when generating responses. Added guidance that generating signatures of signatures is NOT RECOMMENDED when acting as a proxy between a request / response.
Code change:
Unreserved Characters (RFC3986, Section 2.3) MUST be percent-encoded as defined in RFC3986, Section 2.1. <del> For example, consider the DNS name "name,with,commas.example.com". This name would be encoded within a "next-hop-aliases" parameter as </del> <ins> For example, consider the DNS name "comma,name.example.com".  This name would be encoded within a "next-hop-aliases" parameter as </ins> follows: It is also possible for a DNS name to include a period character

Related discussion:
text: Update example domain names to avoid "example-URL" and too-long lines
Some examples use ; IDNITS dings you for not using . Should probably use something like .
The examples in 2.1 have lines that are too long. Because it's caused by , which is a String, I think your options are: Shorten the strings Use RFC 8792 line wrapping
Code change:
Multiple Issuers can make the same Statement about a single Artifact, affirming multiple Issuers agree. <ins> At least one identifier for an identity document MUST be included in the protected header of the COSE envelope, as one of "x5t", "x5chain" or "kid". Support for "x5t" is mandatory to implement. Support for "kid" and "x5chain" is optional. When "x5t" or "x5chain" is present, "iss" MUST be a string with a value between 1 and 8192 characters in length that fits the regular expression of a distinguished name. The mechanisms for how Transparency Services obtain identity documents is out-of-scope of this document. The "kid" header parameter MUST be present when neither "x5t" nor "x5chain" are present.  Key discovery protocols are out-of-scope of this document. The protected header of a Signed Statement and a Receipt MUST include the "CWT Claims" header parameter as specified in CWT_CLAIMS_COSE. The "CWT Claims" value MUST include the "Issuer Claim" (Claim label 1) and the "Subject Claim" (Claim label 2) IANA.cwt. A Receipt is a Signed Statement, (cose-sign1), with addition claims in its protected header related to verifying the inclusion proof in its unprotected header.  See I-D.draft-ietf-cose-merkle-tree-proofs. </ins> 4.2.1. <ins> fig-signed-statement-cddl illustrates a normative CDDL definition for of the protected header for Signed Statements and Receipts. Everything that is optional in the following CDDL can potentially be discovered out of band and Registration Policies are not assured on the presence of these optional fields.  A Registration Policy that requires an optional field to be present MUST reject any Signed Statements or Receipts that are invalid according to the policy. fig-signed-statement-edn illustrates an instance of a Signed Statement in EDN, with a payload that is detached.  Detached payloads support large artifacts, and ensure Signed Statements can integrate with existing storage systems. fig-signed-statement-protected-header-edn illustrates the decoded protected header of the Signed Statement in fig-signed-statement-edn. It indicates the Signed Statement is securing a JSON content type, and identifying the content with the "sub" claim "vendor.product.example". 4.3. </ins> To register a Signed Statement, the Transparency Service performs the following steps:

Related discussion:
text: Adjusts text around CDDL and EDN Adjusts text regarding Validation
LGTM, nice and clear changesLGTM
Code change:
FIN bit on the stream (HTTP3).  RST exceptions are represented with an stream error (HTTP3) of type H3_REQUEST_CANCELLED (HTTP3) <del> The semantics of the headers and SETTING are identical to those in </del> <ins> The semantics of the headers and setting are identical to those in </ins> HTTP/2 as defined RFC8441.  HTTP3 requires that HTTP/3 settings be registered separately for HTTP/3.  The SETTINGS_ENABLE_CONNECT_PROTOCOL value is 0x08 (decimal 8), as in

Related discussion:
text: To be fair, RFC 8441 says . Didn't you say you liked consistency? ;)
RFC 8441 is wrong. Consistency with wrongness should be avoided.
Code change:
scheme, host and, optionally, port number and path components, but no query or fragment components. <del> 4.1. </del> <ins> 5.1. </ins> <del> A JWT Issuer Metadata configuration MUST be queried using an HTTP </del> <ins> A JWT VC Issuer Metadata configuration MUST be queried using an HTTP </ins> <del> request at the path defined in jwt-issuer-metadata. </del> <ins> request at the path defined in jwt-vc-issuer-metadata. </ins> The following is a non-normative example of a HTTP request for the <del> JWT Issuer Metadata configuration when </del> <ins> JWT VC Issuer Metadata configuration when </ins> is set to

Related discussion:
text: This PR introduces the following changes: renamed JWT Issuer Metadata to JWT VC Issuer Metadata which - moved JWT VC Issuer Metadata to the end of the specification for editorial reasons
3 approvals, resolved merge conflicts, merging
Every entity in the OAuth/OpenID is potentially a JWT issuer, then I found the name of this endpoint misleading. Considering that this brand new specification defines a profile for SD JWT verifiable credentials, I'd propose to change the pathname to .well-known/vc-jwt-issuer
The idea is that the JWT Issuer could be used with any JWT, not necessarily VCs only.
NAME what do you think?
NAME is there a reason the JWT Issuer should not be used with something else than VCs?
There are well known endpoints like openid-configuration or openid-federation that publish entities metadata, including jwks Since this specs Is related to VC based on sd-jwt, this specs should not be in conflict to pre existing Oauth2/OpenID ecosystem SD-JWT-VC should define only the resources needed for the solution It defines
I'm ok with the proposed change. I anyway assume we will add VC issuance specific metadata in the future (it is not limited to key distribution).
I agree NAME Key attestation alone Is not enough, this endpoint deserves a proper identity with a specialized protocol metadata Also the verifiable attestations related to the entity may be available in it
To me this sounds reasonable. I will update the spec accordingly.
(As a record, I repeat my question I made elsewhere in the past.) Why is it necessary to introduce a new path, especially if the expected content is just like below (excerpt from "")? Isn't the JWS header parameter (RFC 7515 ) like below sufficient?
(For the record, I repeat my answer I gave on Slack and add more context) The jku header is not sufficient for the intended purpose. The purpose of the well-know endpoint is to establish a stable issuer identifier independent of the jwks location. This issuer identifier can be used in other structures to establish trust, e.g. it can be added to trusted lists (verifier end or trusted 3rd party). Additionally, it fits nicely with the other well-known locations, like openid-credential-issuer and oauth-authorization-server. So the issuer can distribute the role specific metadata in different location residing under the same issuer identifier.