jiebi/CodeConvo huggingface dataset:
Code change:
Receipts for the software and configuration of the service, as measured in its attestation report. <del> 5.2.2. The Transparency Service records its configuration in the Append-Only Log using Transparent Statements with distinguished media type "application/scitt-configuration". The registration policy for statements with the media type suffix ("+<format>" is implementation-specific.  The implementation SHOULD document them, for example defining the Issuers authorized to register configuration Signed Statements. The Transparency Service is configured by the last Transparent Statement of this type.  The Transparency Service MUST register a Signed Statement that defines its initial configuration before registering any other Signed Statement.  The Transparency Service MAY register an additional Signed Statement that updates its configuration. The Transparency Service provides an endpoint that returns the Transparent Statement that describes its current configuration. The configuration "reg_info" SHOULD include a secure version number and a timestamp. The sample configuration payload uses the CDDL </del> 5.2.3. <del> Authorization is needed prior to registration of Signed Statements to ensure completeness of an audit.  A Transparency Service that registers valid Signed Statement offered by anonymous Issuers would provide limited to no value to Verifiers.  More advanced use case will rely on the Transparency Service performing additional domain- specific checks before a Signed Statement is accepted.  For example, some Transparency Services may validate the non-opaque content (payload) of Signed Statements. </del> Registration Policies refers to the checks that are performed before <del> a Signed Statement is registered given a set of input values.  This specification leaves the implementation of the Registration Policy to the provider of the Transparency Services and its users. A provider of a Transparency Service indicates what Registration Policy is used in a given deployment and inform its users about changes to the Registration Policy by issuing and registering configuration statements. </del> <ins> a Signed Statement is added to an append only log, and a corrosponding receipt becomes available. </ins> As a minimum, a Transparency Service MUST authenticate the Issuer of the Signed Statement, which requires some form of trust anchor.  As

Related discussion:
text: Adjustments regarding registration policies.
NAME I have made significant changes since your last review, including cutting out a lot of redundant text, and shuffling sections and section headers while eliminating the redundancy. I am dismissing your approval based on that, please give this another review.
Apologies for the scope creep of this PR ("massive"). This is all intended to be presentable on Monday.
NAME and NAME : i shall review it later today!
Subject to addressing the issues opened by this PR: This PR can be taken forward!The biggest issue now that x5t is required is that the issuer for x509-signed claims is not specified. This needs to be solved before we can merge this
Code change:
Selective Disclosure JWT (SD-JWT) <del> draft-fett-oauth-selective-disclosure-jwt-01 </del> <ins> draft-fett-oauth-selective-disclosure-jwt-02 </ins> Abstract

Related discussion:
text: Spec text updated, please review!
George during OAuth side mtg pointed out that it is important for the verifier not to change anything in the JSON object in the Release (ie SVC )that is being hashed so that the hash output is the same from the one in SD-JWT
Code change:
component. The following is a non-normative example of a HTTP request for the <del> JWT Issuer Metadata configuration when </del> <ins> JWT VC Issuer Metadata configuration when </ins> is set to : <del> 4.2. </del> <ins> 5.2. </ins> A successful response MUST use the <del> and return the JWT Issuer Metadata configuration using the </del> <ins> and return the JWT VC Issuer Metadata configuration using the </ins> content type. An error response uses the applicable HTTP status code value. <del> This specification defines the following JWT Issuer Metadata </del> <ins> This specification defines the following JWT VC Issuer Metadata </ins> configuration parameters: <del> JWT Issuer Metadata MUST include either </del> <ins> JWT VC Issuer Metadata MUST include either </ins> or <del> in their JWT Issuer Metadata, but not both. </del> <ins> in their JWT VC Issuer Metadata, but not both. </ins> It is RECOMMENDED that the JWT contains a JWT header parameter that can be used to lookup the public key in the <del> JWK Set included by value or referenced in the JWT Issuer Metadata. </del> <ins> JWK Set included by value or referenced in the JWT VC Issuer Metadata. </ins> <del> The following is a non-normative example of a JWT Issuer Metadata </del> <ins> The following is a non-normative example of a JWT VC Issuer Metadata </ins> configuration including : <del> The following is a non-normative example of a JWT Issuer Metadata </del> <ins> The following is a non-normative example of a JWT VC Issuer Metadata </ins> configuration including : <del> Additional JWT Issuer Metadata configuration parameters MAY also be used. </del> <ins> Additional JWT VC Issuer Metadata configuration parameters MAY also be used. </ins> <del> 4.3. </del> <ins> 5.3. </ins> The

Related discussion:
text: If an authorization server / OpenID provider and a credential issuer are hosted on the same server, the payload of the entity configuration published at of the server contains the following, right?
Hey NAME I'm sure that you meant The answer Is yes, even if we have used a snake case like here URL It's still an initial draft without an official release, several editorials and implementation compromises needs to be resolved but the most of the work Is there, feelfree to open issue for discussion here URL
To make progress with this. Are folks comfortable with renaming "JWT Issuer Metadata"? And if so, would folks be fine with "SD-JWT VC Issuer Metadata" or "VC Issuer Metadata"? I like "VC Issuer Metadata" better because it is more future looking. What do folks think? cc NAME NAME NAME NAME NAME After we agreed on a new name I'd ask NAME to update PR .
Agree that "jwt-issuer" is too general and am in favor of a renaming.
Code change:
The "Connection" header field allows the sender to list desired control options for the current connection. <ins> Connection options are case-insensitive. </ins> When a field aside from Connection is used to supply control information for or about the current connection, the sender MUST list the corresponding field name within the Connection header field.

Related discussion:
text: The Connection header field is oddly inconsistent with the other field definitions in how it defines the grammar late in the description. I think it is worth an editorial fix.
Code change:
associated with it.  A track name identifies an individual track within the namespace. <del> A tuple of a track name and a track namespace together is known as a full track name: </del> A MOQT scope is a set of servers (as identified by their connection <del> URIs) for which full track names are guaranteed to be unique.  This implies that within a single MOQT scope, subscribing to the same full track name would result in the subscriber receiving the data for the same track.  It is up to the application using MOQT to define how broad or narrow the scope has to be.  An application that deals with connections between devices on a local network may limit the scope to a single connection; by contrast, an application that uses multiple CDNs to serve media may require the scope to include all of those CDNs. The full track name is the only piece of information that is used to identify the track within a given MOQT scope and is used as cache key.  MOQT does not provide any in-band content negotiation methods similar to the ones defined by HTTP (RFC9110); if, at a given moment in time, two tracks within the same scope contain different data, they have to have different full track names. </del> <ins> URIs) for which the tuple of Track Name and Track Namespace are guaranteed to be unique and identify a specific track.  It is up to the application using MOQT to define how broad or narrow the scope is.  An application that deals with connections between devices on a local network may limit the scope to a single connection; by contrast, an application that uses multiple CDNs to serve media may require the scope to include all of those CDNs. Because the tuple of Track Namespace and Track Name are unique within an MOQT scope, they can be used as a cache key.  MOQT does not provide any in-band content negotiation methods similar to the ones defined by HTTP (RFC9110); if, at a given moment in time, two tracks within the same scope contain different data, they have to have different names and/or namespaces. </ins> In this specification, both the Track Namespace and the Track Name are not constrained to a specific encoding.  They carry a sequence of

Related discussion:
text: It's only used a few times and now that Namespace and Name are an opaque sequence of bytes, it's even less compelling.
Take the line from your drafts that says There is no valid way to parse the right hand of this. We have things like "Full Track Name Length" and "Full Track Name". I do not think we should have ambiguous syntax for things that require precision. I think it would also be good to have things that can be directly mapped to common programming languages. This moves beyound simply editorial, or specification is underspecified and ambiguous until we fix this.
One possible solution would be use underscore or CamelCase
Oh, and the longer we leave this dumpster fire, the more painful it will be to fix.
love it
Code change:
impose requirements that are impossible for users to comply with, or leading to an undesirable user experience outcome.  The authentication prompts presented by the authorization server as a <del> result of the requirements propagation method described here might require the user to perform some specific actions such as using multiple devices, having access to devices complying with specific security requirements, and so on.  Those extra requirements, concerning more about how to comply with a particular requirement rather than indicating the identifier of the requirement itself, are out of scope for this specification. </del> <ins> result of the method of propagating authentication requirements described here might require the user to perform some specific actions such as using multiple devices, having access to devices complying with specific security requirements, and so on.  Those extra requirements, concerning more about how to comply with a particular requirement rather than indicating the identifier of the requirement itself, are out of scope for this specification. </ins> 9.

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

Related discussion:
text: refers to a captive portal as a type of intermediary; we should make sure this aligns with the more recent CAPPORT drafts (IIRC current usage of that term is for the origin that the user is redirected to when captured; it's not an intermediary).
It is probably enough to strike "captive portal". "Interception proxy" will do, if "attacker" does not. The term was never something that RFC 7230 relied on and as you say the modern understanding of the term has evolved.
Code change:
header field (crypto-key).  The first step of HKDF is therefore: The info parameter to HKDF is set to the ASCII-encoded string <del> "Content-Encoding: aesgcm128", a single zero octet and an optional </del> <ins> "Content-Encoding: aesgcm", a single zero octet and an optional </ins> context string: Unless otherwise specified, the context is a zero length octet

Related discussion:
text: In order to allow existing applications to update from one octet of padding per record to two (PR , Issue ), this PR renames "aesgcm128" to "aesgcm" as the value for the Content-Encoding header, as well as the parameter name in the Crypto-Key header. This also affects the context used for deriving the nonce and the content encryption key. Examples have been updated. What I did not update is the JWE mapping (currently "A128GCM"). Do we wish to change that to "AGCM", which may be less descriptive?
NAME - for your consideration I updated the hashes, but would like you to verify those when you've got a moment (they include the uint8 -> uint16 change). I wasn't able to reproduce the output of the explicit example using the current spec.
Awesome. I'm still awaiting the return of my implementation (I'm annoyed that I put it on a boat), but I will verify when able. It's entirely possible that one (or more) of the examples are in error.
I still need to double-check the examples, but I won't be able to do that for a while now. Stupid travel. Might as well make progress at least. Thanks for putting this all together NAME
Each record currently includes between 1 and 256 octets of padding, while the default record size is set to 4096 octets. This is in many cases not sufficient, for example in the pad-to-next-power-of-two case. Extending the padding length to two octets will allow up to 65537 octets (65KB) of padding. I raised this on the ietf-http-wg list here: URL Martin about an upgrade path for existing users. I'll reply on the mailing list to not split the discussion.
This was fixed in and .
Code change:
split into issuance and presentation. Note: Throughout the examples in this document, line breaks had to be <del> added to JSON strings and base64-encoded strings to adhere to the 72 character limit for lines in RFCs and for readability.  JSON does not allow line breaks within strings. </del> <ins> added to JSON strings and base64-encoded strings to adhere to the 72-character limit for lines in RFCs and for readability.  JSON does not allow line breaks within strings. </ins> 6.1.

Related discussion:
text: for issue URL
The layout of these section delineations seems off. There's an "Example 1" section header, but no other numbers. Some examples are top-level, some are subordinate. Is this intended?
Kinda. has additional examples with some of those other numbers. ! And a few places refer back to "Example 1" by name. This all could probably be tidied up though.
like it
Code change:
payload.  PING responses SHOULD given higher priority than any other frame. <del> The PING frame defines one type-specific flag: </del> <ins> The PING frame defines the following flags: </ins> <del> Bit 2 being set indicates that this PING frame is a PING response. </del> <ins> Bit 1 being set indicates that this PING frame is a PING response. </ins> An endpoint MUST set this flag in PING responses.  An endpoint MUST NOT respond to PING frames containing this flag.

Related discussion:
text: Also reservers flag 0x2 in DATA and HEADERS frames and renumbers flags accordingly.
Please feel free to exercise editorial privilege with respect to wording. Reserving 0x2 at NAME requests.
Code change:
-1 and a code.  This signals to the client that a shutdown is imminent and <del> that no further requests can be initiated.  After waiting at least one round trip time, the server can send another GOAWAY frame with an updated last stream identifier.  This ensures that a connection can be cleanly shut down without losing requests. </del> <ins> that initiating further requests is prohibited.  After allowing time for any in flight stream creation - at least one round trip time - the server can send another GOAWAY frame with an updated last stream identifier.  This ensures that a connection can be cleanly shut down without causing clients to lose requests. </ins> After sending a GOAWAY frame, the sender can discard frames for <del> streams with identifiers higher than the identified last stream. However, any frames that alter connection state cannot be completely ignored.  For instance, </del> <ins> streams initiated by the receiver with identifiers higher than the identified last stream.  However, any frames that alter connection state cannot be completely ignored.  For instance, </ins> ,

Related discussion:
text: The intent was to say that the receiver of a GOAWAY can't create new streams higher than the value in GOAWAY. Let me check back in tomorrow; maybe fresh eyes will add perspective.
So the intention of the change is allow receiver of GOAWAY are still allowed to create stream lower or equal to received last-stream-id, accepting the fact that those streams are ignored by peer? As the graceful shutdown process as described in draft 17, server first sending GOAWAY with (2^31) - 1 starts to ignore any new streams created by peer and after some time (this ensures that GOAWAY is reached to the client), server sends another GOAWAY with updated last-stream-id where processing has occurred already.
NAME the intent of the change is to not change anything :) The process has been unclear, but the point is that if you receive GOAWAY with a last-stream-id greater than anything you have initiated, you can use what space remains for new streams. What that means is that you can issue new requests on that connection while you take the time to create a replacement connection. This was considered critical for . That means that 2^31-1 serves only as a warning of impending closure, though in theory it need not change any behaviour for the existing connection. I'd take steps to make a replacement connection though.
Thank you for clarification!
Here is a link to NAME doc from the mailing list which provides additional clarity to this issue URL
Latest PR is much more comfortable to me. Thanks!
Code change:
to "open".  A PUSH_PROMISE frame will transition the server-initiated stream identified by the "Promised Stream ID" field in the frame payload from "idle" to "reserved".  When a stream transitions out of <del> the "idle" state, all streams that might have been initiated by that peer with a lower-valued stream identifier are implicitly transitioned to "closed".  That is, an endpoint may skip a stream identifier, with the effect being that the skipped stream is immediately closed. </del> <ins> the "idle" state, all "idle" streams that might have been opened by the peer with a lower-valued stream identifier immediately transition to "closed".  That is, an endpoint may skip a stream identifier, with the effect being that the skipped stream is immediately closed. </ins> Stream identifiers cannot be reused.  Long-lived connections can result in an endpoint exhausting the available range of stream

Related discussion:
text: I improved the text along the lines Jörg suggested. However, I realized that the transition should really be in the diagram. That's basically impossible given the nature of the diagram, but it's worth including in the description at least. For .
This is a good clarification. One note about a whitespace change but the textual changes are :+1:
Code change:
messages for namespaces ("example.com", "meeting=123", "participant=100") and ("example.com", "meeting=123", "participant=200"), a SUBSCRIBE_ANNOUNCES for ("example.com", <del> "meeting=123") would match both. </del> <ins> "meeting=123") would match both.  If an endpoint receives a Track Namespace Prefix tuple with an N of 0 or more than 32, it MUST close the session with a Protocol Violation. </ins> Parameters: The parameters are defined in version-specific-params.

Related discussion:
text: Current definition specifies namespace is an N-tuple, with 132 is it expected to return a protocol violation, or do we leave that undefined?
+1 I think we should address this as part of refactoring the tuple type
I put up a PR addressing the issue but didn't do a larger refactor of the tuple type, which seems editorial.
Editorial suggestion, but LG
Code change:
Else, if char is DQUOTE, return output_string. Else, if char is in the range %x00-1f or %x7f (i.e., is not in <del> VCHAR), fail parsing. </del> <ins> VCHAR or SP), fail parsing. </ins> Else, append char to output_string.

Related discussion:
text: Step 4.4 equates "the range %x00-1f or %x7f" to "not in VCHAR", but VCHAR doesn't include %x20; this change adds "or SP" and imports SP from RFC5234.
Thanks!
Code change:
indeterminate-length, it can only appear in response messages. Indeterminate-length messages can be truncated in a similar way as <del> known-length messages.  Truncation occurs after the control data, or after the Content Terminator field that ends a field section or sequence of content chunks.  A message that is truncated at any other point is invalid; see invalid. </del> <ins> known-length messages; see padding. </ins> Indeterminate-length messages use the same encoding for field lines as known-length messages; see fields.

Related discussion:
text: Basically, it saves the effort of writing stuff that you know to be empty. It's not a critical feature, but it turns out to be a simple way to deal with not sending trailers or a body. In the extreme, you can also drop headers to produce the simplest and shortest HTTP message ever: 0x0140c8. CLoses .
Hey David, I've made some larger edits here to factor the truncation text better. I've included your normative language.
The draft mentions that messages can be truncated in some places, but not in others. I think it would help to explain why one would want to truncated a message.
This is really just a neat way to avoid having to write out all of the pieces of a message. So if you don't have trailers, it's OK not to say "I have 0 trailers". The decoder is required to deal with it. Before you say "that's hard", you don't need to change the parser to deal with truncation. Adding three zero-valued bytes to the end of any message you receive does the job just fine. If it isn't truncated, those will be treated as padding.
Thanks