jiebi/CodeConvo huggingface dataset:
Code change:
Claim Description: The requester context <del> Change Controller: IESG </del> <ins> Change Controller: IETF </ins> Specification Document: Section requester-context 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:
The message imprint sent in the request to the TSA MUST be either: <del> the hash of the signature field of the COSE_Sign1 message. </del> <ins> the hash of the signature field of the "COSE_Sign1" message. </ins> <del> the hash of the signatures field of the COSE_Sign message. </del> <ins> the hash of the signatures field of the "COSE_Sign" message. </ins> In either case, to minimize dependencies, the hash algorithm SHOULD be the same as the algorithm used for signing the COSE message.  This

Related discussion:
text: https://ietf-URL
NAME NAME please have a look
TSA is good enough
Code change:
It is up to the user to decide whether they should trust the QR code or user code.  In effect the user is asked to compensate for the absence of an authenticated channel between the Initiating Device <del> (e.g., smart TV) and the Authorizing Device (e.g., the mobile phone). </del> <ins> (e.g., smart TV) and the Authorization Device (e.g., the mobile phone). </ins> Attackers exploit this absence of an authenticated channel between the two devices by obtaining QR codes or user codes (e.g., by

Related discussion:
text: The "Authorization Device" was sometimes referred to as "Authorizing Device".
NAME Looks good to me, please merge if you approve as well.
Agreed.
Code change:
algorithm, or even knowing that the recipient will ignore it. "Digest" can be sent in a trailer section.  In this case, "Digest" <del> MAY be merged in the header section (See Section 6.5.1 of SEMANTICS). </del> <ins> MAY be merged in to the header section (See Section 6.5.1 of SEMANTICS). </ins> When an incremental digest-algorithm is used, the sender and the receiver can dynamically compute the digest value while streaming the

Related discussion:
text: moved normative parts in warn that trailers can be dropped by intermediaries.
[x] 12.7. If this is mergeable into headers when it occurs as a trailer, that needs to be said earlier in the spec, not in security considerations. [x] Also, you can't prohibit intermediaries from dropping the trailer; they're explicitly allowed to do so for all trailers.
Code change:
11. <del> We would like to thank Alen Horvat, Arjan Geluk, 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 Sakimura, Oliver Terbu, Orie Steele, Paul Bastian, Pieter Kasselman, 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> We would like to thank Alen Horvat, Anders Rundgren, Arjan Geluk, 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 Sakimura, Oliver Terbu, Orie Steele, Paul Bastian, Pieter Kasselman, 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: based roughly on feedback from Anders to draft-ietf-oauth-selective-disclosure-jwt at URL
Code change:
the scope of this specification). The client credentials grant type MUST only be used by confidential <del> or credentialed clients. </del> <ins> clients. </ins> The use of the client credentials grant illustrated in fig-client- credentials-grant includes the following steps:

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:
2.7. <del> An entity that entity that requests, checks and extracts the claims from SD-JWT-R (2.2) </del> <ins> An entity that requests, checks and extracts the claims from SSD- JWT-R (2.2) </ins> Note: discuss if we want to include Client, Authorization Server for the purpose of ensuring continuity and separating the entity from the

Related discussion:
text: Based on the feedback from NAME
This review identifies three minor syntax issues. Once they are addressed, I'll approve.
Code change:
on a specific proposed congestion control algorithm - is out of scope of this document.  RFC7567 describes design considerations for AQMs. <ins> 6.1.1. Some equipment in the network use an automatic mechanism to continuously monitor the use of resources by a flow or aggregate set of flows RFC8084.  Such a network transport circuit breaker can automatically detect excessive congestion, and when detected, it can terminate (or significantly reduce the rate of) the flow(s).  A well- designed congestion control algorithm ought to react before the flow uses excessive resources and therefore will operate within the envelope set by network transport circuit breaker algorithms. </ins> 6.2. An Internet Path can include simple links, where the minimum delay is

Related discussion:
text: Please do not merge yet, I will tray to update to include a few sentences to address the issue related to in-network Circuit breakers.
From NAME review: I do wonder if this document needs to bring up the circuit breaker specifications (RFC 8083, RFC 8084) we do have and potential interaction with them. I would expect a congestion control algorithm to work well within the envelope which would trigger them. The question is if one needs to take them into account when dealing with them. I will note that traffic applying a circuit breaker can be dynamic in transmission pattern and rates and otherwise be very non-responsive in relation to congestion signals. Only if they exceed the circuit breaker threshold will something happen.
This looks good, but please don't mangle my name, or that of Lisong Xu, or ACM Queue reference. Minor edit suggestion on the wording of the last paragraph in "## Paths with Varying Delay {#delay}"
Code change:
Table 3: Allowed track operations <del> The default track operation is 'Add'.  This value does not need to be </del> <ins> The default track operation is 'add'.  This value does not need to be </ins> declared in the track object. 3.2.13.

Related discussion:
text: There was a feedback from Victor on making track operation string enumeration to enhance readability. It feels like a fine suggestion
Code change:
If input_string is empty, return dictionary. <del> Consume the first character of input_string; if it is not COMMA, fail parsing. </del> <ins> Consume the first character of input_string; if it is not ",", fail parsing. </ins> Discard any leading SP characters from input_string.

Related discussion:
text: The term COMMA is not defined anywhere in this document, or in any of the documents it imports. But we can just use the literal instead.
Thanks.
The structured headers draft imports and uses a number of productions from RFC 5234 for typographically awkward characters and character classes (, , etc), but there is no definition of provided anywhere. Similar to the way that , , , , and are used without special treatment, can probably be replaced with wherever it occurs.
Code change:
Abstract <del> This document describes use cases that have been discussed in the IETF community under the banner of "Media Over QUIC", provides analysis about those use cases, recommends a subset of use cases that cover live media ingest, syndication, and streaming for further exploration, and describes requirements that should guide the design of protocols to satisfy these use cases. </del> <ins> This document describes use cases and requirements that guide the specification of a simple, low-latency media delivery solution for ingest and distribution of media, using either the QUIC protocol or WebTransport. </ins> Note to Readers

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:
individual Items and the Inner List itself can be Parameterized (param). <del> When serialised in a textual HTTP field, Inner Lists are denoted by </del> <ins> When serialized in a textual HTTP field, Inner Lists are denoted by </ins> surrounding parenthesis, and their values are delimited by one or more spaces.  A field whose value is defined as a List of Inner Lists of Strings could look like:

Related discussion:
text: There are currently some uses of "serialise" in place of the far more common "serialize", including one case that breaks the pattern of header names ("Serializing a List", "Serializing a Dictionary", "Serializing an Item", …, "Serialising a Date"). This PR also includes an analogous update of "summarises" to "summarizes" to increase the general pattern of American spellings.
Speaking Danglish myself, I am disqualified from having an opinion on this subject matter :-)
Despite my Australianised sensibilities, I see that 8941 was normalised to American spelling by the RFC Editor, and changing things now would introduce more diffs. Thanks for the PR.
Code change:
match the offset provided by the immediate previous offset retrieval (offset-retrieving), or the end offset of the immediate previous incomplete successful transfer, the server MUST respond with a "409 <del> (Conflict)" status code. </del> <ins> (Conflict)" status code.  The server MAY use the problem type PROBLEM of "https://iana.org/assignments/http-problem-types#mismatching- upload-offset" in the response; see mismatching-offset. </ins> The server applies the patch document of the "application/partial- upload" media type by appending the request content to the targeted

Related discussion:
text: defines a framework for problem types, which can be used as a standardized response format when errors occurs. With resumable uploads, we have a few cases where such problem types could be useful, but usage remains entirely optional. The text in this PR has been inspired by similar sections from .
Thank you very much for quick feedback, Lucas!
Code change:
making preparations for processing the final response, and then run time-consuming operations to generate the final response.  The informational response can also be used by an origin server to <del> trigger HTTP/2 push at an caching intermediary. </del> <ins> trigger HTTP/2 server push at a caching intermediary. </ins> 1.1.

Related discussion:
text: ... for your consideration; feel free to take, discard, or do whatever else you like :)
Thank you so much for the improvements. This PR is a tremendous opportunity for me to improve my skills (both in terms of writing a specification and in terms of English).
Code change:
9. <del> This memo includes no request to IANA. </del> <ins> This specification registers the following claims defined in Section txn-token-header to the OAuth Access Token Types Registry defined in RFC6749, and the following claims defined in Section txn-token-claims in the IANA JSON Web Token Claims Registry defined in 9.1. Name: "txn_token" Description: JWT of type Transaction Token Additional Token Endpoint Response Parameters: none HTTP Authentication Schemes: TLS Change Controller: IESG Specification Document: Section txn-token-header of this specificaiton 9.2. Claim Name: "azc" Claim Description: The authorization context Change Controller: IESG Specification Document: Section txn-token-claims of this specification </ins> 10.

Related discussion:
text: is already registered (URL). Do we need to register it again? I'm not sure what the guidance here is.
I believe we should add an IANA consideration to propose the registration of azc claim. A list of registered claims can be found here: URL
I believe we should add an IANA consideration and propose to register .
Thanks for this email and adding the issues to GitHub. I will update the spec shortly.
Implementation feedback. The "tid" claim clashes with a claim commonly used in AAD for the tenant ID. Perhaps we can use an alternative like idt, txi, txnid, txn_id or tti?
Discussed in the identity chaining call. Recommendation is to use the 'txn' claim name as defined in RFC 8417.
Add reference to SET add RFC 8417
Looks good to me
Code change:
This document uses the conventions detailed in (RFC9000) when describing the binary encoding. <del> This document also defines an additional field type for binary data: </del> <ins> As a quick reference, the following list provides a non normative summary of the parts of RFC9000 field syntax that are used in this specification. This document extends the RFC9000 syntax and with the additional field types: To reduce unnecessary use of bandwidth, variable length integers SHOULD be encoded using the least number of bytes possible to represent the required value. </ins> 2.

Related discussion:
text: This PR cleans up some nits to make all the places we use the RFC9000 encoding syntax valid, updates our extensions to it, and add a non normative summary of parts of the syntax we use. I don't think this is making any changes to anything on the wire or normative changes to spec other than the statement SHOULD use smallest number of bytes for variable length integers which RFC9000 only requires for some fields.
I am not in love with the ABNF idea, but this is non-controversial.
Code change:
3. A Client SHOULD notify its support for CACHE_DIGEST frames by sending <del> the SENDING_CACHE_DIGEST (0xXXX) SETTINGS parameter. </del> <ins> the SETTINGS_SENDING_CACHE_DIGEST (0xXXX) SETTINGS parameter. </ins> The value of the parameter is a bit-field of which the following bits are defined:

Related discussion:
text: Aligns with other SETTINGS parameter names defined in other docs.
NAME icymi
Thank you for the fix!
Code change:
data MUST be sent again, unless the client decides to abandon those requests. <del> This automatic retry exposes the request to a potential replay attack.  An attacker sends early data to one server instance that accepts and processes the early data, but allows that connection to proceed no further.  The attacker then forwards the same messages from the client to another server instance that will reject early data.  The client then retries the request, resulting in the request being processed twice.  Replays are also possible if there are multiple server instances that will accept early data, or if the same server accepts early data multiple times (though this would be in violation of requirements in Section 8 of TLS13). </del> <ins> Automatic retry creates the potential for a replay attack.  An attacker intercepts a connection that uses early data and copies the early data to another server instance.  The second server instance accepts and processes the early data.  The attacker then allows the original connection to complete.  Even if the early data is detected as a duplicate and rejected, the first server instance might allow the connection to complete.  If the client then retries requests that were sent in early data, the request will be processed twice. Replays are also possible if there are multiple server instances that will accept early data, or if the same server accepts early data multiple times (though this would be in violation of requirements in Section 8 of TLS13). </ins> Clients that use early data MUST retry requests upon receipt of a 425 (Too Early) status code; see status.

Related discussion:
text: This was a little obtuse in the previous iteration, likely as a result of trying to be parsimonious. Expand it a little and clarify the attack.
It's indeed better like this in my opinion.
Code change:
server of Domain B.  See authorization-server-discovery. (B) The client exchanges its token at the authorization server of <del> its own domain (Domain A) for an authorization grant that can be used at the authorization server in Domain B.  See token-exchange. </del> <ins> its own domain (Domain A) for a JWT authorization grant that can be used at the authorization server in Domain B.  See token- exchange. </ins> (C) The authorization server of Domain A processes the request and <del> returns an authorization grant that the client can use with the </del> <ins> returns a JWT authorization grant that the client can use with the </ins> authorization server of Domain B.  This requires a trust relationship between Domain A and Domain B (e.g., through federation).

Related discussion:
text: when "authorization grant" refers to the actual JWT being passed around, it is clearer to call it "JWT authorization grant". RFC6749 uses "authorization grant" to refer to the general concept of any grant
Code change:
5.4. MOQT encodes the delivery information for a stream via OBJECT headers <del> (message-object). </del> <ins> (message-object).  A relay MUST NOT modify Object properties when forwarding. </ins> A relay MUST treat the object payload as opaque.  A relay MUST NOT combine, split, or otherwise modify object payloads.  A relay SHOULD

Related discussion:
text: This was previously part of . It allows an object to be sent in a datagram f it fits, and put on a stream if it doesn't.
Linking some feedback raised in the original PR that has not yet been addressed: URL URL
Looks like a great starting point to me.
Code change:
5.4. MOQT encodes the delivery information for a stream via OBJECT headers <del> (message-object). </del> <ins> (message-object).  A relay MUST NOT modify Object properties when forwarding. </ins> A relay MUST treat the object payload as opaque.  A relay MUST NOT combine, split, or otherwise modify object payloads.  A relay SHOULD

Related discussion:
text: Update main to reflect the tx-mode branch after was merged.
Agreed, but I'm not sure there's any normative language there. Is this a case of writing a paragraph cautioning that such limits could cause issues?
Whoa, I've missed some PRs, but LGTMIndividual Review: There was some feedback on previous iterations about this PR lacking guidance when encountering flow control limits (eg: send as datagram, relay converts to stream, but is out of streams or flow control)
Code change:
SEMANTICS. When an incremental digest-algorithm is used, the sender and the <del> receiver can dynamically compute the digest value while streaming the </del> <ins> receiver can dynamically compute a checksum while streaming the </ins> content. A non-comprehensive set of examples showing the impacts of

Related discussion:
text: Consistent use of "checksum".
From NAME WGLC review: Personally, I think the use of both terms is ok. Mainly because digest is overloaded in the document. But it wouldn't hurt us to review the document for usages and perhaps add a note in notational conventions about the use of terms.
is a generic checksum computation, should be the actual digest algoritm computation. We need to clarify this and probably introduce new terminology.
Code change:
6.3. The PRIORITY frame (type=0x2) specifies the StreamPriority.  It can <del> be sent at any time for an existing stream.  This enables reprioritization of existing streams. </del> <ins> be sent at any time for an existing stream, including closed streams. This enables reprioritization of existing streams. </ins> The payload of a PRIORITY frame contains the following fields:

Related discussion:
text: ... as new priority scheme demands and implies, but does not expressly permit. For .
Code change:
10. <ins> 10.1. This section defines the "https://iana.org/assignments/http-problem- types#mismatching-upload-offset" problem type PROBLEM.  A server MAY use this problem type when responding to an upload append request (upload-appending) to indicate that the "Upload-Offset" header field in the request does not match the upload resource's offset. Two problem type extension members are defined: the "expected-offset" and "provided-offset" members.  A response using this problem type SHOULD populate both members, with the value of "expected-offset" taken from the upload resource and the value of "provided-offset" taken from the upload append request. The following example shows an example response, where the resource's offset was 100, but the client attempted to append at offset 200: 10.2. This section defines the "https://iana.org/assignments/http-problem- types#completed-upload" problem type PROBLEM.  A server MAY use this problem type when responding to an upload append request (upload- appending) to indicate that the upload has already been completed and cannot be modified. The following example shows an example response: 11. </ins> The "301 (Moved Permanently)" and "302 (Found)" status codes MUST NOT be used in offset retrieval (offset-retrieving) and upload cancellation (upload-cancellation) responses.  For other responses,

Related discussion:
text: defines a framework for problem types, which can be used as a standardized response format when errors occurs. With resumable uploads, we have a few cases where such problem types could be useful, but usage remains entirely optional. The text in this PR has been inspired by similar sections from .
Thank you very much for quick feedback, Lucas!