jiebi/CodeConvo huggingface dataset:
Code change:
There are thousands of different devices accessing the web, each with different device capabilities and preference information.  These device capabilities include hardware and software characteristics, as <del> well as dynamic user and client preferences. One way to infer some of these capabilities is through User-Agent (Section 5.5.3 of RFC7231) header field detection against an established database of client signatures.  However, this technique requires acquiring such a database, integrating it into the serving path, and keeping it up to date.  However, even once this infrastructure is deployed, user agent sniffing has numerous limitations: User agent detection cannot reliably identify all static variables User agent detection cannot infer any dynamic client preferences User agent detection requires an external device database User agent detection is not cache friendly A popular alternative strategy is to use HTTP cookies (RFC6265) to communicate some information about the user agent.  However, this approach is also not cache friendly, bound by same origin policy, and often imposes additional client-side latency by requiring JavaScript execution to create and manage HTTP cookies. </del> <ins> well as dynamic user and client preferences.  Applications that want to allow the server to optimize content delivery and user experience based on such capabilities have, historically, had to rely on passive identification (e.g., by matching User-Agent (Section 5.5.3 of RFC7231) header field against an established database of client signatures), used HTTP cookies and URL parameters, or use some combination of these and similar mechanisms to enable ad hoc content negotiation. Such techniques are expensive to setup and maintain, are not portable across both applications and servers, and make it hard to reason for both client and server about which data is required and is in use during the negotiation: User agent detection cannot reliably identify all static variables, cannot infer dynamic client preferences, requires external device database, is not cache friendly, and is reliant on a passive fingerprinting surface. Cookie based approaches are not portable across applications and servers, impose additional client-side latency by requiring JavaScript execution, and are not cache friendly. URL parameters, similar to cookie based approaches, suffer from lack of portability, and are hard to deploy due to a requirement to encode content negotiation data inside of the URL of each resource. </ins> Proactive content negotiation (Section 3.4.1 of RFC7231) offers an alternative approach; user agents use specified, well-defined request

Related discussion:
text: Based on discussion at IETF 105, removing explicit lifetime in favor of implicit opt-in registration and persistence. NAME can you please take a look? In particular, current language states the preference should be persisted but doesn't explicitly state for what the lifetime is.. Modulo, in privacy section we do talk about MUST criteria for clearing it. Any suggestions or recommendations for how to best approach this?
LGTM
Code change:
objects from the group ID and object ID described above. If a publisher cannot satisfy the requested start or end for the <del> subscription it MAY send a SUBSCRIBE_ERROR with code TBD.  A publisher MUST NOT send objects from outside the requested start and end. </del> <ins> subscription it MAY send a SUBSCRIBE_ERROR with code 'Invalid Range'. A publisher MUST NOT send objects from outside the requested start and end. </ins> TODO: Define the flow where subscribe request matches an existing subscribe id (subscription updates.)

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:
objects from the group ID and object ID described above. If a publisher cannot satisfy the requested start or end for the <del> subscription it MAY send a SUBSCRIBE_ERROR with code TBD.  A publisher MUST NOT send objects from outside the requested start and end. </del> <ins> subscription it MAY send a SUBSCRIBE_ERROR with code 'Invalid Range'. A publisher MUST NOT send objects from outside the requested start and end. </ins> TODO: Define the flow where subscribe request matches an existing subscribe id (subscription updates.)

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:
We would like to thank Alen Horvat, Anders Rundgren, Arjan Geluk, Christian Bormann, Christian Paquin, David Bakker, David Waite, <del> Fabian Hauck, Filip Skokan, Giuseppe De Marco, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Mike Prorock, Nat Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard Barnes, Ryosuke Abe, Sami Rosendahl, 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> Fabian Hauck, Filip Skokan, Giuseppe De Marco, Jacob Ward, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Mike Prorock, Nat Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard Barnes, Ryosuke Abe, Sami Rosendahl, 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: Because of the trickiness of language, I'm not sure if we disagree or not about the intent... CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
Code change:
15.3.2. <del> There is no limit on the introduction of new field names, each presumably defining new semantics. New fields can be defined such that, when they are understood by a recipient, they might override or enhance the interpretation of previously defined fields, define preconditions on request evaluation, or refine the meaning of responses. </del> Authors of specifications defining new fields are advised to choose a short but descriptive field name.  Short names avoid needless data transmission; descriptive names avoid confusion and "squatting" on

Related discussion:
text: I believe that we said this could be merged when Julian's issue was addressed, which Roy's suggestion did, so merging.
Some guidance about how and if new preconditions can be defined would be helpful. See .
Code change:
3.1. <del> The protocol defined in this document has two identifiers. Negotiating "h2" or "h2c" implies the use of the transport, security, </del> <ins> The protocol defined in this document has two identifiers.  Creating a connection based on either implies the use of the transport, </ins> framing, and message semantics described in this document. 3.2.

Related discussion:
text: ... or the analysis in the security considerations. We had to walk a more careful path when RFC 7540 was published, so we were careful to legitimize h2c. In the years since, things have changed and we can be more direct. This isn't a "don't use h2c", but more of a disclaimer as far as security goes.
Maybe a hangover from trying to tear up the photos of the "http" URI and upgrade dance. But this seems to read oddly. On one hand: on the other: I don't have a solid suggestion to improve things.
How about we just remove "h2c" from the latter statement.
OK, that isn't going to fly. I just tried it. Pulling that string is unwise. We agreed to keep "prior knowledge" in the document, and the "h2c" ALPN token is part of that. The "h2c" upgrade token has been removed already. (Too subtle? Probably.)
Code change:
string of URIs as per Section 4.3.2 of Refresh tokens for public clients must either be sender- <del> constrained or one-time use as per Section 4.12.2 of </del> <ins> constrained or one-time use as per Section 4.13.2 of </ins> 10.1.

Related discussion:
text: An invalid link to the OpenID core spec has been fixed, as well as a section number referencing the draft.
Code change:
indicated by the "Upload-Offset" field value does not equal the total of begin offset plus the number of bytes uploaded in the request. <ins> If the upload is already complete, the server MUST NOT modify the upload resource and MUST respond with a "400 (Bad Request)" status code.  The server MAY use the problem type PROBLEM of "https://iana.org/assignments/http-problem-types#completed-upload" in the response; see completed-upload. </ins> If the request completes successfully and the entire upload is complete, the server MUST acknowledge it by responding with a 2xx (Successful) status code.  Servers are RECOMMENDED to use a "201

Related discussion:
text: This is a follow-up to , which defined a problem type for when the server rejects modification for an completed upload. However, the draft didn't specify that such modifications are not allowed. This PR adds this requirement. The section for offset retrieval already includes a definition for when an upload is complete, so this is not repeated in this PR's changes:
Code change:
The ABNF for a byte sequence in HTTP headers is: <del> In HTTP headers, a byte sequence is delimited with asterisks and encoded using base64 (RFC4648, Section 4).  For example: </del> <ins> In HTTP headers, a byte sequence is delimited with colons and encoded using base64 (RFC4648, Section 4).  For example: </ins> Parsers MUST support byte sequences with at least 16384 octets after decoding.

Related discussion:
text: ... and allow token to start with "*".
I'm running my SH implementation against the HTTP Archive dumps (400,000,000+ HTTP requests) to see how the from BSH parse in something like the real world. It looks like some headers are failing because AcceptAccess-Control-Allow-Origin`. If we were to use a different character to delimit Byte Sequences, we could include in Token (necessarily as a first character, as well as in the rest, I assume). Worthwhile? If so, what should we use for Byte Sequences?
(via ) already allows , but not as a first character. '%' is short in HPACK and unlikely to trigger funny handling, but maybe it will conflict with pct-encoding to start. '=' has the virtue of being already allowed. It has the drawback of causing byte array parameters to look funny ( for instance). Interestingly, it makes removal of padding easier (base64 padding is silly).
How about ? I don't' think is a good idea; if an implementation enforces padding (which we caution against, but do not prohibit), it's confusing.
Checking with NAME NAME - any issues changing byte sequence delimiters from to ?
(the only conflicting use that comes to mind ATM for is that if someone wants to refer to H2 pseudo-headers like in a field that uses tokens, they'll be out of luck. I think that's OK, because existing fields that take header names as a list-of-tokens don't refer to pseudo-headers, and new fields can be defined as lists of tokens-or-strings.)
is free
Code change:
The following example is the decoded header and payload of a JWT meeting the processing rules as defined above. <del> 3.1.2. </del> <ins> 4.1.2. </ins> <del> The following rules apply to validating the client key attestation PoP JWT.  Application of additional restrictions and policy are at the discretion of the authorization server. </del> <ins> The following rules apply to validating the client attestation PoP JWT.  Application of additional restrictions and policy are at the discretion of the authorization server. </ins> The JWT MUST contain an "iss" (issuer) claim with a value corresponding to the "client_id" of the OAuth client.

Related discussion:
text: Please change file/draft name and title, too.
Opened as a separate issue.
NAME please check my latest suggestion
I would like to see the description under the sequence diagram improved, but if you want to address that in another PR, that is fine too.
Code change:
Optional parameters: n/a <del> Encoding considerations: binary; A JSON-based Status List is a JSON Object. </del> <ins> Encoding considerations: See status-list-json of this specification </ins> <del> Security considerations: See (#Security) of [ this specification ] </del> <ins> Security considerations: See Security of this specification </ins> Interoperability considerations: n/a <del> Published specification: [ this specification ] </del> <ins> Published specification: this specification </ins> <del> Applications that use this media type: Applications using [ this specification ] for updated status information of tokens </del> <ins> Applications that use this media type: Applications using this specification for updated status information of tokens </ins> Fragment identifier considerations: n/a <del> Additional information: File extension(s): n/a Macintosh file type code(s): n/a </del> <ins> Additional information: n/a </ins> Person & email address to contact for further information: Paul Bastian, paul.bastian@posteo.de

Related discussion:
text: fixes the list rendering (missing newline) clarifies IANA text to just reference other tokens Rendered version: URL
I did further fixes on media types
Code change:
Abstract <del> This document defines the HTTP Digest and Want-Digest fields, thus allowing client and server to negotiate an integrity checksum of the </del> <ins> This document defines the HTTP Digest and Want-Digest fields, which allows client and server to negotiate an integrity checksum of the </ins> exchanged resource representation data. <del> This document obsoletes RFC 3230.  It replaces the term "instance" with "representation", which makes it consistent with the HTTP Semantic and Context defined in draft-ietf-httpbis-semantics. </del> <ins> This document obsoletes RFC 3230. </ins> Note to Readers

Related discussion:
text: This change is done while ignoring the fact that we might want a bigger document reshuffle when bringing in a "content-digest" header. But it helps illustrate how the abstract / intro could be editorialized to address some off-list feedback.
LGTM :)
Code change:
token request.  The authorization server validates the Client Attestation and thus authenticates the Client Instance. <del> Note that the protocol for steps (2) and (4) and how the Client Instance authenticates to the Client Backend is out of scope of this specification.  Note also that this specification can be utilized without the client having a backend server at all; in this case, each client instance will perform the functions described as being done by the backend for itself. This specification defines the format of the Client Attestation that a Client Instance uses to authenticate in its interactions with an authorization server, which is comprised of two key parts: A Client Attestation JWT - typically produced by the client backend. </del> <ins> Please note that the protocol details for steps (2) and (4), particularly how the Client Instance authenticates to the client Backend, are beyond the scope of this specification.  Furthermore, this specification is designed to be flexible and can be implemented even in scenarios where the client does not have a backend server. In such cases, each Client Instance is responsible for performing the functions typically handled by the backend on its own. </ins> <del> A Client Attestation Proof of Possession (PoP) - produced by the client instance. </del> <ins> This approach acknowledges the evolving landscape of OAuth 2.0 deployments, where the ability for public clients to authenticate securely and reliably has become increasingly important. </ins> 2.

Related discussion:
text: I do believe there should be a discussion about terminology (attestation vs assertion) as it seems to create quite a bit of confusion, but I do think a different issue/PR is better suited for that. Minor nit: Client Attestation seems to be used in lower and upper case somewhat inconsistently. Should every usage be upper case (e.g., also client attestation mechanism)?
Code change:
status mechanism method member and a reference to the specification that defines it. <ins> CWT Status Mechanism Methods are registered by Specification Required [RFC5226] after a three-week review period on the cwt-reg- review@ietf.org mailing list, on the advice of one or more Designated Experts.  However, to allow for the allocation of names prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published. Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register CWT Status Mechanism Method: example"). Within the review period, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA.  Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. IANA must only accept registry updates from the Designated Expert(s) and should direct all requests for registration to the review mailing list. </ins> 14.4.1. Status Method Value:

Related discussion:
text: We would register: CWT Status Mechanisms registry in CWT JWT Status Mechanisms registry in JWT Status Types registry in OAuth parameters Any ideas how we could simplify this?
looks good to me in general. I would extend this to more than two weeks, if I look back how the current year went by. I think this is a good start for now, so we should merge this first and then evaluate afterwards if we can merge both status registries.
JWT/CWT registries use three week periods, the OAuth Parameter one uses two weeks. Should we just align with these registries for each one?
Section 4 of RFC 8126 -> supply registration procedures for the registries Define where these registries should be placed
Editors Call: we propose to put into OAuth Parameters: URL
Code change:
It is also possible that stub routers for more than one stub network may be connected to the same adjacent infrastructure link.  In this <del> case, the stub routers will be advertising Router Information Options </del> <ins> case, the stub routers will be advertising Router Information options </ins> in their router advertisements for their OSNR prefixes.  Stub routers MUST track the presence of such routes, and MUST advertise reachability to them on interfaces connected to stub networks.

Related discussion:
text: see URL in the working group meeting in London, and in both cases, it seemed that the argument that without NAT64 we can't deliver on "device must always be able to connect to the internet if it is available" overrode the objections that were raised. So despite some folks really not loving it, I think it's required. Michael (IIRC) also pointed out that we need DHCPv6 PD to get infrastructure-provided NAT64 to work, which I guess means that if we have IPv4 and infrastructure-provided NAT64, but no DHCPv6 PD, we have to do NAT64 in the stub router. If we have v6-only, infrastructure-provided NAT64, and no DHCPv6 PD, then in order to reach the internet, we'd need NAT66. I'm inclined to declare this situation out of scope, because (A) I really don't want to do NAT66, and (B) I think it's not a likely scenario at the moment, and the more devices out in the field that would break in this situation, the better.
Code change:
4.5. <del> The SD-JWT and the SD-JWT Release can be combined into one document using </del> <ins> The SD-JWT and the SD-JWT-R can be combined into one document using </ins> as a separator (here for Example 1):

Related discussion:
text: addresses issue
The way it is written now does not look like terms and definitions. It would also be a good practice to make it possible to the definition to replace the terms that appear in the main text. With this respect, verbose explanations especially the mechanisms should be done in the "Concepts" section in the main text. In fact, much of the text in the current "terminology" mostly duplicates what is being explained in 3. Concept Also, examples etc. should be added as a note to the definition and not as part of the definition text. Proposes the following as amended text Terms and definitions 2.1 SD-JWT signed JWT ], that supports selective disclosure as defined in this document Note to entry: Signed JWT is JWS. 2.2 release (SD-JWT-R) document that contains a subset of the claim values of an SD-JWT in a verifiable way Note to entry: Holder binding is also possible. 2.3 issuer entity that create SD-JWTs (2.1) 2.4 holder entity that has control over SD-JWTs (2.1) Note to entry: If holder binding is desired, the holder also has the signing key for the verification key contained in the SD-JWT. 2.5 verifier entity that checks and extracts the claims from SSD-JWT-R (2.2)
closing with PR
Currently, it has Conventions and Terminology Terminology Having two "Terminology" as consecutive headings is not good. I propose to change 2 as follows: Terms and Definitions
closing with PR