jiebi/CodeConvo huggingface dataset:
Code change:
All examples in this section are non-normative. <del> Type Metadata about the value of a </del> <ins> The following is an example of an SD-JWT VC payload, containing a </ins> <del> claim value can be retrieved as described in retrieving-type- metadata. </del> <ins> claim with the value </ins> <del> Here, the type is </del> <ins> : </ins> <del> . The Type Metadata is retrieved from the URL </del> <ins> Type Metadata for the type </ins> <del> . </del> <ins> can be retrieved using various mechanisms as described in retrieving- type-metadata.  For this example, the well-known URL as defined in retrieval-from-vct-claim is used and the following Type Metadata Document is retrieved from the URL : </ins> <del> The following is an example for a Type Metadata document: </del> <ins> Note: The hash of the Type Metadata document shown in the second example must be equal to the one in the claim in the SD-JWT VC payload, . </ins> 6.2.

Related discussion:
text: The first example in Section 6.1 shows a credential, not a type metadata document, but is not labelled as such. The example in question:
Code change:
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information <del> systems.  This document defines the semantics shared by all versions of HTTP, including its architecture, terminology, core protocol elements, and extensibility mechanisms, along with the "http" and </del> <ins> systems.  This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions.  In this definition are core protocol elements, extensibility mechanisms, and the "http" and </ins> "https" Uniform Resource Identifier (URI) schemes. This document obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC

Related discussion:
text: For
In the abstract: "semantics... including its architecture, terminology..." seems incorrect; suggest "semantics... and its architecture..."
I always find possessive for "HTTP" a little hard to handle.
Code change:
2. This specification describes a combination of OAuth 2.0 Token <del> Exchange RFC8693 and Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants RFC7521 to achieve identity chaining across trust domains. </del> <ins> Exchange RFC8693 and JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants RFC7523 to achieve identity chaining across trust domains. </ins> A client in trust domain A that needs to access a resource server in trust domain B requests an authorization grant from the authorization

Related discussion:
text: and minor other little fixes to fix issues , , an editor's draft preview of these changes here: URL
says this: However, if the authorization grant is a JWT (which it always should be, but see for details), then defines the grant type of the request to be: The other implication of this is that the only way to distinguish the type of JWT assertion is in the JWT itself, which can be done using the field in the JWT header.
Per is an "identifier [...] for the representation of the issued security token" and I think it's admittedly a bit odd but perfectly reasonable to use the URN of the grant type that the token is intended for as the value conveying the representation that token.
With that said however, I do kinda think that'd it be better to limit to JWT authz grant only (a la ) and not tie the issuedtokentype to the grant type.
My point was more about the grant type of the request as described by RFC7523. access token request as defined in of the OAuth Assertion Framework ] with the following specific parameter values and encodings. So if the request contains a JWT, then the grant type value has to be . Which means according to Section 2.4.3 of this spec the issuedtokentype "SHOULD" be , which is silly. So my proposal is to remove the "and SHOULD be passed into the assertion request" part, so that issuedtokentype can be a value that makes sense, and use as the grant type. As I said in the original comment, the implication is then that the JWT header itself would need to include something that indicates the type of JWT it is, otherwise all token exchange requests look the same.
I might argue that it's not actually silly but I won't b/c it'll be moot as PR addresses this with the removal of the "issuedtokentype parameter in the response indicates the type and SHOULD be passed into the assertion request" URL
issuedtokentype (a required parameter of a token exchange response URL) is missing from the example response at URL
NAME can you prepare a PR with an updated example?
Code change:
2. This specification describes a combination of OAuth 2.0 Token <del> Exchange RFC8693 and Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants RFC7521 to achieve identity chaining across trust domains. </del> <ins> Exchange RFC8693 and JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants RFC7523 to achieve identity chaining across trust domains. </ins> A client in trust domain A that needs to access a resource server in trust domain B requests an authorization grant from the authorization

Related discussion:
text: example would be fixed by PR
Feedback from Brian Campbell Conceptually having "flexibility for authorization servers to change format and content" sounds nice but I can't help but wonder if that flexibility is actually useful and if this document wouldn't be better served and more straightforward using just JWT authz grants from 7523 (rather than being abstract about using 7521 and the very brief mention of SAML w/out a 7522 ref).
I agree that limiting the authorization grant format to JWT is useful. In fact you've almost already done that by adding the validation to the processing rules here: URL
As discussed in the meeting with the editors and Aaron, we will make the use of JWT explicit.
PR would limit the authorization grant format to RFC7523 JWT
Code change:
uses excessive resources, and therefore will operate within the envelope set by network transport circuit breaker algorithms. <del> 7.2. </del> <ins> 7.3. </ins> An Internet Path can include simple links, where the minimum delay is the propagation delay, and any additional delay can be attributed to

Related discussion:
text: From Juergen Schoenwaelder: The document provides guidelines for the IETF when evaluating new proposed congestion control algorithms. While important, this document is not directly influencing network operations. This update grows the document from 10 pages () to 25 pages. I found the draft well structured and easy to read and all content appears to be well justified. The draft provides helpful advice to everybody involved in the development and evaluation of congestion control algorithms. I am wondering whether section 7.1.1 really should be a sub-section of 7.1, which implies that a network circuit breaker are viewed as a special kind of an active queue management technique. Keeping the sub-sections a flat list of special cases may simplify things. I also found the title of section 7.1.1 a bit longish compared to the other section titles. Perhaps turning 7.1.1 into "7.2 Interaction with Network Transport Circuit Breakers" or just "7.2 Network Transport Circuit Breakers" leads to a simpler structure. Similarly, I wonder whether sub-section 7.7.1 should be lifted up as well. Path changes are not necessarily a transient event. Perhaps 7.7.1 should become "7.X Changes in the Path" (dropping sudden as well). The point made in the text is that paths are not static, they may change. Perhaps the above two comments make no sense, then just ignore them. I just thought I share them since they came up during my first time read of the document.
The organisation could be better, but I don't see a network circuit breaker (as policing) as a kind of an active queue management technique (as a scheduling/queuing action), they are rather different in operation and design, so I'd rather keep these separate, and just move CB's up one level? If we did that, i wouldn't object to 7.7.1 being made 7.8.
Code change:
5.1. A alternative service can make this commitment by sending a "HTTP- <del> TLS" header field: </del> <ins> TLS" header field, described here using the '#' ABNF extension defined in Section 7 of RFC7230: </ins> When it appears in a HTTP response from a strongly authenticated alternative service, this header field indicates that the

Related discussion:
text: for encryption. I had these in my local repo. They weren't pushed, but I wanted to make sure that they are OK before merging them.
Code change:
When the target latency is on the order of one RTT, it is impossible to use congestion control schemes like BBR I-D.draft- cardwell-iccrg-bbr-congestion-control, since BBR has probing <del> mechanisms that rely on temporarily inducing delay and amortizing the consequences of that over multiple RTTs. </del> <ins> mechanisms that rely on temporarily inducing delay, but these mechanisms can then amortize the consequences of induced delay over multiple RTTs. </ins> <del> This may help to explain why these use cases often rely on protocols such as RTP RFC3550, which provide low-level control of packetization and transmission. </del> <ins> This may help to explain why interactive use cases have typically relied on protocols such as RTP RFC3550, which provide low-level control of packetization and transmission, and make no provision for retransmission. </ins> <del> 4.1.1. </del> <ins> 3.1.1. </ins> Where media is received, and user inputs are sent by the client. <del> This may also include the client receiving other types of signalling, </del> <ins> This may also include the client receiving other types of signaling, </ins> such as triggers for haptic feedback.  This may also carry media from the client such as microphone audio for in-game chat with other players. <del> 4.1.2. </del> <ins> 3.1.2. </ins> Where media is received, and user inputs are sent by the client. <del> Latency requirements with this usecase are marginally different than </del> <ins> Latency requirements with this use case are marginally different than </ins> the gaming use case.  This may also include signalling and/or transmitting of files or devices connected to the user's computer. <del> 4.1.3. </del> <ins> 3.1.3. </ins> Where media is both sent and received; This may include audio from both microphone(s) or other inputs, or may include "screen sharing"

Related discussion:
text: NAME - I think this version is ready for submission as -03, when the submission window reopens during IETF 115. Please let me know what you think.
It would help people contribute to this document if there are blank sections in outline form, and we will be less likely to miss critical stuff.
The IETF 115 proposal to the working group is to use the approved charter as the high level outline for the Requirements section.
Code change:
6.2. <del> I-D.draft-ietf-mops-streaming-opcons describes these latency requirements for streaming media: 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) Support for a nominal latency in the low to ultra-low latency should be achieved, with consideration for minimum buffer a receiver playing content may need to handle congestion, packet loss, and other degradation in network quality. </del> <ins> Support for a nominal latency appropriate for the use cases that are in scope should be achieved, with consideration for the minimum buffer that a receiver playing content may need to handle congestion, packet loss, and other degradation in network quality. </ins> 6.3.

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:
6.2. <del> I-D.draft-ietf-mops-streaming-opcons describes these latency requirements for streaming media: 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) Support for a nominal latency in the low to ultra-low latency should be achieved, with consideration for minimum buffer a receiver playing content may need to handle congestion, packet loss, and other degradation in network quality. </del> <ins> Support for a nominal latency appropriate for the use cases that are in scope should be achieved, with consideration for the minimum buffer that a receiver playing content may need to handle congestion, packet loss, and other degradation in network quality. </ins> 6.3.

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:
Message types TODO: register the URI scheme and the ALPN <del> TODO: the MOQT spec should establish the IANA registration table for MoQ Streaming Formats.  Each MoQ streaming format can then register its type in that table.  The MoQ Streaming Format type MUST be carried as the leading varint in catalog track objects. </del>

Related discussion:
text: This language exists in current draft and refers to an old scheme in which MOQT registered the streaming formats and had a scheme in which the leading varint of the catalog defined the format. This has been superseded by an externalized catalog format and this TODO should be removed. The IANA table for MOQ streaming formats should be managed instead by the Catalog draft, which references those entries.
Code change:
If a DELETE method is successfully applied, the origin server SHOULD send <del> A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause some existing </del> <ins> A client SHOULD NOT generate a body in a DELETE request.  A payload received in a DELETE request has no defined semantics, cannot alter the meaning or target of the request, and might lead some </ins> implementations to reject the request. Responses to the DELETE method are not cacheable.  If a successful

Related discussion:
text: :-(
(split from URL)
So the main question seems to be: is the situation for DELETE the same as for GET, or maybe more similar to OPTIONS. As far as I remember, the latter is what we discussed in Prague 2019 (URL)
I might be wrong, but I believe the intent of the DELETE method is to just delete the target resource. Most of the cases out there that use a request body in the DELETE method, is to use 'delete' as a sort of rpc call to delete other, unrelated resources. While I think that this use-case is valid, I think that it would be better solved with: A PATCH request on a resource that represents multiple underlying entities, some of which ought to be removed. A DELETE request (without a body) on a resource that exactly represents the full collection of resources that should be deleted. A POST request with some custom media-type with delete instructions. Given that DELETE (unlike OPTIONS) is a non-safe method, and conforming services are likely to ignore request bodies and simply delete the context resource, I believe that DELETE should get the same treatment as GET: Emphasize that the request body has no semantic meaning. Improve the prose so there's less chance of misinterpretation (like GET)
I agree that using the payload to instruct the server to delete something other than the identified resource is incorrect, and we could mention that. There are uses cases though where the payload would add additional information about the deletion (keep version history? move to waste basket? archive?). In all these cases, this would be consistent with the overall semantics.
That's very theoretical. I suspect DELETE is very much in the same bucket as GET -- i.e., many intermediaries, servers, etc. will block a DELETE request with a body.
I disagree that it's theoretical. This would be a normative change from RFC 723x, so if you think that handling of DELETE is more like GET (than for instance OPTIONS), please prove it.
The onus isn't on me to prove that we can use DELETE in a way that isn't currently countenanced by the specs; if you want to open it up, do the work.
Now I'm confused. Currently we say: That doesn't imply that you can't define semantics for it though.
Code change:
If a DELETE method is successfully applied, the origin server SHOULD send <del> A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause some existing </del> <ins> A client SHOULD NOT generate a body in a DELETE request.  A payload received in a DELETE request has no defined semantics, cannot alter the meaning or target of the request, and might lead some </ins> implementations to reject the request. Responses to the DELETE method are not cacheable.  If a successful

Related discussion:
text: Example: URL
We can sit here forever and point out individual examples where developers are trying to use a body with DELETE. That's hopeless, particularly for examples like that redhat one where they are providing control data that needs to be in the header fields. In any case, sending a body with DELETE is not interoperable. Compliant servers will read and ignore them. Non-compliant servers will treat the body as the next request, resulting in request smuggling. URL
Yes, that is exactly what it implies. If you send a body, the recipient cannot use that body to have any meaningful impact on the request semantics.
Doesn't compute for me. An intermediary that discards a DELETE body clearly is broken, right? For an origin server to support certain payloads in DELETE requests has always been ok. If the user agents knows who he's talking to, why not allow him to send the payload? Where is the harm? All I would add would be a warning that even if you provide additional information to the DELETE request, it still needs to be aligned with the base semantics.
Nope. It's only required to read and discard the body.
Says who?
For example, URL
I know we get a lot of grief from those sentences about "has no defined semantics", but I am quite certain that they are trying to forbid using a body while at the same time avoiding message parsers that are dependent on the request semantics. HEAD was a disaster and I was trying to prevent any further damage.
IMHO: at the end of the day, this ticket is about making a normative change that will break some existing use cases, so it would need a better reason than "it might not work". But let's do a proper analysis first. You said that an intermediate MUST read the payload, but MAY drop it (right?). What part of the spec supports this? And is this specific to DELETE, or does it also apply to "PATCH" or "FOO"?
Discussed in Singapore; room sense was to behave like GET (body not allowed).
Code change:
pay attention to the requested status.  The status value should reflect standardization status and the broad opinion of relevant interest groups such as the IETF or security-related SDOs.  The <del> "standard" status is not suitable for an algorithm that is known to be weak, broken, or experimental.  If a registration request attempts to register such an algorithm as "standard", the designated expert(s) should suggest an alternative status of "insecure" or "provisional". </del> <ins> "Active" status is not suitable for an algorithm that is known to be weak, broken, or experimental.  If a registration request attempts to register such an algorithm as "Active", the designated expert(s) should suggest an alternative status of "Deprecated" or "Provisional". </ins> When reviewing registration requests, the designated expert(s) cannot <del> use a status of "insecure" or "provisional" as grounds for rejection. </del> <ins> use a status of "Deprecated" or "Provisional" as grounds for rejection. </ins> Requests to update or change the fields in an existing registration are permitted.  For example, this could allow for the transition of <del> an algorithm status from "standard" to "insecure" as the security </del> <ins> an algorithm status from "Active" to "Deprecated" as the security </ins> environment evolves. 6.

Related discussion:
text: During the SEC AD review, a DISCUSS was raised about the current status values. This change modifies the values to better align with Signatures. The guidance for registration and/or usage of an algorithm based on the status is not affected.
Code change:
Christian Bormann, Christian Paquin, David Bakker, David Waite, Fabian Hauck, Filip Skokan, Giuseppe De Marco, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Mike Prorock, Nat <del> Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Pieter Kasselman, Richard Barnes, Ryosuke Abe, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </del> <ins> Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard Barnes, Ryosuke Abe, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </ins> The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.

Related discussion:
text: In an attempt at addressing URL see it live here URL
Approved with a minor editorial fix.