jiebi/CodeConvo huggingface dataset:
Code change:
6.3.2. A Consumer MAY use a registry to retrieve Type Metadata for a SD-JWT <del> VC type, e.g., if the type is not a HTTPS URL or if the Consumer does not have access to the URL.  The registry MUST be a trusted registry, i.e., the Consumer MUST trust the registry to provide correct Type Metadata for the type. </del> <ins> VC type, e.g., if the type is not an HTTPS URL or if the Consumer does not have access to the URL.  The registry MUST be a trusted registry, i.e., the Consumer MUST trust the registry to provide correct Type Metadata for the type. </ins> The registry MUST provide the Type Metadata in the same format as described in type-metadata-format.

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:
token endpoint with the following parameters: "grant_type" REQUIRED.  The value MUST be set to <del> "urn:ietf:params:oauth:grant-type:token-exchange" </del> <ins> "urn:ietf:params:oauth:grant-type:token-exchange". </ins> <del> "audience" REQUIRED.  The value MUST be set to the Trust Domain name </del> <ins> "audience" REQUIRED.  The value MUST be set to the trust domain name. </ins> "scope" REQUIRED.  A space-delimited list of case-sensitive strings where the value(s) MUST represent the specific purpose or

Related discussion:
text: See issue
Good practice is to explain why something is a MUST. Suggestion: From: The value of the aud claim MUST remain unchanged in a replacement Txn-Token. To: The value of the aud claim MUST remain unchanged in a replacement Txn-Token to prevent the Txn-Token from being accepted outside it's current Trust Domain. Alternatively, we cann add security considerations for the draft as well.
I'm good with that text.
I think the current PR is making the change in the wrong place (unless I'm horribly mistaken)
Looks good
Code change:
When a message does not have a <del> header field, a Content-Length header field can provide the anticipated size, as a decimal number of octets, for potential content.  For messages that do include content, the Content-Length field value provides the framing information necessary for determining where the data (and message) ends.  For messages that do not include content, the Content-Length indicates the size of the </del> <ins> header field, a Content-Length header field (field.content-length) can provide the anticipated size, as a decimal number of octets, for potential content.  For messages that do include content, the Content-Length field value provides the framing information necessary for determining where the data (and message) ends.  For messages that do not include content, the Content-Length indicates the size of the </ins> selected representation (field.content-length). A sender MUST NOT send a Content-Length header field in any message

Related discussion:
text: ... components, depending on the form of request-target, and when authority might be empty. This is an alternative to
In determining the request target, the following text is included after failing to find an authority in configuration, the authority form target, or the Host header: This is a security risk because it means that servers might not agree with clients about the identity of the resource that the request is directed to. This is especially bad as a TLS certificate is good for every port and often good for multiple names, which can mean a fairly large scope over which an attacker can exploit this confusion. The origin form description doesn't use 2119 language, it says "A Host header field is also sent", citing . And that section is a bit weaselly in that regard, using a "URL". If this were a "MUST ... unless" in -semantics, this problem would not exist (at least in theory). Just to confuse things, the absolute-form says , which might be read to imply that Host truly is mandatory: The asterisk-form is the only other option that naturally lacks an authority, and that says nothing, so that might be fixed up similarly.
Keep in mind that the first text is what to do when receiving a message without Host or absolute-form, whereas the other texts are requirements on generation. Yes, it is a security risk to not send Host, and I assume it would be one to provide service for an https resource without verifying that the client's request indicates one of the server's host (somehow). So, PR welcome, but the final text still needs to accept non-TLS HTTP/1.0 requests without a Host (for ass-backwards reasons).
BTW, the reason it says SHOULD here instead of MUST is because this requirement about the ordering of fields in the header section, not about whether or not Host needs to be sent.
OK, that's good. It's not a genuine problem, we just need to be clearer about generation requirements (and we might be able to carefully condition the inclusion of a default).
better again
Code change:
applications and to ensure the user experience is identical for all first-party apps. <ins> 9.7. Single Page Applications (SPA) run inside the context of a browser instance.  Due to the inability to securely attest to the first- partyness of a browser based application, it is NOT RECOMMENDED to use this specification in a browser-based application. </ins> 10. IANA has (TBD) registered the following values in the IANA "OAuth

Related discussion:
text: Added text to address assigned issues: URL URL URL
tbd: "Due to the inability to securely attest to the first-partyness of a browser based application, it is NOT RECOMMENDED to use this application in a browser-based application."
Thinking out loud, would the hypothetic "SPA attestation" be possible in principle / make sense at all?
Yes, Chrome has a proposal for the "Web Integrity API", but it has received a lot of pushback: URL Safari already shipped Private Access Tokens which are similar: URL
There was some discussion at OSW about enforcing client auth first, before invoking the native flow to further build trust. It may be a good idea to add additional information, perhaps in the security considerations, about ways in which the server can have confidence that the first party app is a "real" first party app.
Yes, I agree. There are couple of ways the server can determine trust in the mobile app. We shouldn't be prescriptive but maybe putting some options in the security considerations would help make it more clear how to do this. Maybe there is best practice guidance that could be put in a doc like for single-page-apps.
NAME to update First-Party Applications section
in Section 9.1 URL
Add new normative requirement for authorization server to verify that the application is a first party application.
One of the participants in the OSW workshop suggested adding a content type parameter to allow them to specify for example a JSON structure or some other data format to control the native app experience. We have been deliberately avoiding defining a new language or re-inventing HTML, but allowing implementors to return complex content types of their own definition may be worth considering if this is a common enough use case.
Make it more clear in 5.2 that this spec expects the response to always be either the authorization code or an error URL Section 5.2.2 needs to make it clear that the authorization server has to define its own error codes URL Section 5.2.2 should explicitly allow more specific JSON content types
Code change:
associated with the Holder, or a reference thereto. It is out of the scope of this document to describe how the Holder <del> key pair is established.  For example, the Holder MAY provide a key pair to the Issuer, the Issuer MAY create the key pair for the Holder, or Holder and Issuer MAY use pre-established key material. </del> <ins> key pair is established.  For example, the Holder MAY create a key pair and provide a public key to the Issuer, the Issuer MAY create the key pair for the Holder, or Holder and Issuer MAY use pre- established key material. </ins> Note: The examples in this document use the

Related discussion:
text: first pass at addressing Issue and .
Does this touch all the mentions of random in URL and convey what the feedback was looking for? I'm honestly not sure. But I also think it doesn't really need changes in that area so I'm not too worried about it. So why am I writing this note? Good question. Just trying to "contribute" I guess.
Approved with the proposed changes.
Code change:
http-only-flag is true, abort these steps and ignore the cookie entirely. <del> If the cookie's secure-only-flag is not set, and the scheme </del> <ins> If the cookie's secure-only-flag is false, and the scheme </ins> component of request-uri does not denote a "secure" protocol, then abort these steps and ignore the cookie entirely if the cookie store contains one or more cookies that meet all of the following

Related discussion:
text: The 'secure-only-flag' is never "not set". It is either "true" or "false". This patch fixes two places where we should have been checking for falsity. Closes URL
NAME / NAME WDYT?
Good. I should have sent a PR. :-)
URL Step 8 says: But then Step 12 says: It's impossible to reach step 12 with the not set because it's always set in step 8. I believe a better wording would be .
Code change:
method, and trailer fields for metadata collected while sending the payload. <del> A server responds to a client's request by sending one or more HTTP </del> <ins> A server responds to a client's request by sending one or more </ins> <del> messages, each including a success or error code (status.codes).  The response might also contain header fields for server information, resource metadata, and representation metadata (header.and.trailer.fields), a payload body (payload.body) to be interpreted in accordance with the status code, and trailer fields for metadata collected while sending the payload. </del> <ins> messages, each including a status code (status.codes).  The response might also contain header fields for server information, resource metadata, and representation metadata (header.and.trailer.fields), a payload body (payload.body) to be interpreted in accordance with the status code, and trailer fields for metadata collected while sending the payload. </ins> <del> One of the functions of the message framing mechanism is to assure that messages are </del> <ins> One of the functions of message framing is to assure that messages are </ins> . A message is considered complete when all of the octets indicated by its framing are available.  Note that, when no explicit framing is

Related discussion:
text: H1-H3 currently define a way to carry only one such block, but an extension could provide more.
Code change:
12.10. This section registers the "Want-Digest" field in the "Hypertext <del> Transfer Protocol (HTTP) Field Name Registry" I-D.ietf-httpbis- semantics. </del> <ins> Transfer Protocol (HTTP) Field Name Registry" SEMANTICS. </ins> Field name: "Want-Digest"

Related discussion:
text: References I-D.httpbis-semantics using an inline referece to {{SEMANTICS}}. This will ease the transition once SEMANTICS is updated to RFC.
Code change:
token.  Such an HTTP/1.1 request MUST include exactly one Http2SettingsHeader header field. <del> Requests that contain an entity body MUST be sent in their entirety </del> <ins> Requests that contain an payload body MUST be sent in their entirety </ins> before the client can send HTTP/2 frames.  This means that a large <del> request entity can block the use of the connection until it is completely sent. </del> <ins> request can block the use of the connection until it is completely sent. </ins> If concurrency of an initial request with subsequent requests is important, an OPTIONS request can be used to perform the upgrade to

Related discussion:
text: There were lots of small changes as a result of . The only change of note is URL, which adds text on what a receiver should expect and what they are obligated to do for streams in the "half closed (local)" state.
Code change:
A publisher sends a SUBSCRIBE_ERROR control message in response to a failed SUBSCRIBE. <del> Track Namespace: Identifies the namespace of the track as defined in (track-name). Track Name: Identifies the track name as defined in (track-name). </del> <ins> Subscribe ID: Subscription Identifer as defined in message- subscribe-req. </ins> Error Code: Identifies an integer error code for subscription failure.

Related discussion:
text: This PR is expected to be base PR to support multi-subscribe like flows that will follow up. It adds support for SubscribeID and also renames the trackId to to avoid the confusion and make the scope clear.
NAME NAME NAME wondering if the latest commits address the feedback. thanks
The normative bits look fine. PR needs some cleanup. Recommend splitting ID -> Alias to another PR, so this subscribe ID doesn't get caught up with bikeshedding the field name.LGTM but I would like Subscribe ID to be the first field in every message for consistency.Still looks fine after the split Having reviewed some code that does subscription matching with the current draft, I strongly endorse splitting those.
Code change:
Integer, and List. The definitions "representation", "selected representation", <del> "representation data", "representation metadata", "user agent" and </del> <ins> "representation data", "representation metadata", "user agent", and </ins> "content" in this document are to be interpreted as described in RFC9110. This document uses the line folding strategies described in FOLDING. Hashing algorithm names respect the casing used in their definition <del> document (e.g.  SHA-1, CRC32c) whereas hashing algorithm keys are quoted (e.g. "sha", "crc32c"). </del> <ins> document (e.g., SHA-1, CRC32c) whereas hashing algorithm keys are quoted (e.g., "sha", "crc32c"). </ins> The term "checksum" describes the output of the application of an algorithm to a sequence of bytes, whereas "digest" is only used in

Related discussion:
text: s/ise-case/use case e.g. -> e.g., nit pass
Code change:
unnecessary delay in this case, this text is hereby updated as follows: <ins> 5.5. RFC9484 forbids clients from using optimistic upgrade, avoiding this issue. </ins> 6. There are now several good examples of designs that prevent the

Related discussion:
text: The draft says there are 4 upgrade tokens, but a fifth one has since been added: connect-ip. It already has text to avoid this issue so it should be a short section.
Code change:
3.4.3. <del> When an endpoint sends a frame for a stream with the FINAL flag set, the stream is considered to be half-closed for that endpoint. </del> <ins> When an endpoint sends a frame for a stream with the END_STREAM flag set, the stream is considered to be half-closed for that endpoint. </ins> Subsequent frames MUST NOT be sent by that endpoint for the half closed stream for the remaining duration of the HTTP/2.0 connection. <del> When both endpoints have sent frames with the FINAL flag set, the stream is considered to be fully closed. </del> <ins> When both endpoints have sent frames with the END_STREAM flag set, the stream is considered to be fully closed. </ins> If an endpoint receives additional frames for a stream that was previously half-closed by the sending peer, the recipient MUST respond with a StreamErrorHandler of type STREAM_CLOSED. An endpoint that has not yet half-closed a stream by sending the <del> FINAL flag can continue sending frames on the stream. </del> <ins> END_STREAM flag can continue sending frames on the stream. </ins> It is not necessary for an endpoint to half-close a stream for which it has not sent any frames.  This allows endpoints to use fully

Related discussion:
text: This branch also renames the FINAL flag to ENDSTREAM and the CONTINUES flag to ENDHEADERS.
Address
I'll take it, and we can continue to discuss the redundant bit.
Code change:
proceed with caution when evaluating proposals for alternate congestion control.  The goal of this document is to provide guidance for considering standardization of a proposed congestion control <del> algorithm at the IETF.  It replaces RFC5033 to reflect changes in the congestion control landscape. </del> <ins> algorithm at the IETF.  It obsoletes RFC5033 to reflect changes in the congestion control landscape. </ins> 1.

Related discussion:
text: Thanks for the edits. I am a big fan of losing fewer words, so I reverted changes that went in the wrong direction.
Code change:
for the ones that do, it seems useful to have a name for "the protocol layer immediately beneath media". <ins> Within this document, we extend the latency requirement categories for streaming media described in I-D.draft-ietf-mops-streaming- opcons: ultra low-latency (less than 1 second) low-latency live (less than 10 seconds) non-low-latency live (10 seconds to a few minutes) on-demand (hours or more) These latency bands were appropriate for streaming media, which was the target for I-D.draft-ietf-mops-streaming-opcons, but some realtime media may have requirements that are significantly less than "ultra-low latency".  Within this document, we are also using ull500 (less than 500 ms) ull100 (less than 100 ms) Obviously, these last two latency bands are the shortened form of "ultra-low latency - 500 ms" and "ultra-low-latency - 100 ms".  Also obviously, bikeshedding on better names is welcomed. </ins> 3. Note - need to edit this section to reflect new draft scope and

Related discussion:
text: NAME - Please let me know if this seems about right. One thing that's worth mentioning to you and to NAME - the latency characterizations that we wrote did not make use of the new "ultra-ultra-low latency" categories. I changed the one for gaming to ull100 ("ultra-low-latency under 100 ms") based on conversations at IETF 112, but other people would be better choices to review the characterizations of the use cases they're most interested in.
The opcons drafts uses 4 bands: ultra low-latency (less than 1 second) low-latency live (less than 10 seconds) non-low-latency live (10 seconds to a few minutes) on-demand (hours or more) I think these bands lose some granularity that is useful. For example, a functional video call or interactive game probably needs much less than 1s latency, while low latency live may span lower than 1s in some cases?
NAME - that's very true. The opcons draft was scoped for "streaming operators", and although we've talked (in MOPS) about doing a separate draft for low-latency streaming, we haven't done that yet (in MOPS). That may be for the best, if MOQ turns out to be "not ABR, less than 500 ms", or something like that. I'm also one of the opcons drafts, so I'm thinking we should add at least one, and probably two, lower-than-ultra-low(!!!) latency bands, and explain why we're doing that. I'm assigning this to me, so expect a PR soon.
The industry is terrible at naming things. "ultra-low", "low", "non-low", I mean really? It's all terrible marketing rather than an attempt to classify protocols. I like that the opcons tries to reuse and simplify the terminology but... latency is a complicated. Some protocols have artificial delays, but for the most part, protocols are defined by their ability to deal with congestion. A protocol like RTMP will be "ultra low-latency" within a datacenter or for a user with a perfect network connection, while it will be "low-latency" for somebody on a cellular connection, while it will be "non-low-latency" for somebody going through a tunnel... all of which depends on the implementation.
Code change:
for the ones that do, it seems useful to have a name for "the protocol layer immediately beneath media". <ins> Within this document, we extend the latency requirement categories for streaming media described in I-D.draft-ietf-mops-streaming- opcons: ultra low-latency (less than 1 second) low-latency live (less than 10 seconds) non-low-latency live (10 seconds to a few minutes) on-demand (hours or more) These latency bands were appropriate for streaming media, which was the target for I-D.draft-ietf-mops-streaming-opcons, but some realtime media may have requirements that are significantly less than "ultra-low latency".  Within this document, we are also using ull500 (less than 500 ms) ull100 (less than 100 ms) Obviously, these last two latency bands are the shortened form of "ultra-low latency - 500 ms" and "ultra-low-latency - 100 ms".  Also obviously, bikeshedding on better names is welcomed. </ins> 3. Note - need to edit this section to reflect new draft scope and

Related discussion:
text: At the end of the day, these lines in the sand don't add to the discussion. I would rather focus on the use-cases like "having a conversation with someone" rather than arguing over millisecond budgets.
Code change:
token and client identity whenever the client identity can be authenticated.  When client authentication is not possible, the authorization server SHOULD issue sender-constrained refresh tokens <del> or use refresh token rotation as described in (#refresh-token- endpoint-extension). </del> <ins> or use refresh token rotation as described in refresh-token-endpoint- extension. </ins> The authorization server MUST ensure that refresh tokens cannot be generated, modified, or guessed to produce valid refresh tokens by

Related discussion:
text: Fixed URL
Thank you!
The following link appears to be broken. URL I have confirmed that the link works correctly by fixing `.