jiebi/CodeConvo huggingface dataset:
Code change:
Let URL represent the URL of the outbound request being checked. <del> If the {Origin} of BASEURL and the {Origin} of URL are not the same, return FALSE. </del> <ins> If the Origin of BASEURL and the Origin of URL are not the same, return FALSE. </ins> Let MATCH be the value of "match" for the given dictionary.

Related discussion:
text: This addresses the reference issues, comments and nits from the AD review (see )
NAME would you mind taking a quick look before I publish a new draft?
(tried using ietf-comments but ran into issues so just tracking manually in one combined issue)... cc NAME Thank you for the work on this document. Almost all my comments are about references. I think a new version is necessary before starting IETF Last Call, to avoid process issues along the way. Francesca The boilerplate is duplicate, please remove the second occurrence. Can you please update the reference to 8941 to draft-ietf-httpbis-sfbis ? That doc is with the RFC Editor so should not be holding this document up. Also, I believe the reference to draft-ietf-httpbis-sfbis should be normative, not informative, since terminology from that doc is used. Alternatively, if you want to keep the ref informative, you can import the part of the terminology that is necessary for this doc. I think that's a uglier solution, so I highly prefer sfbis to be made normative, but won't block on it. [URLPattern] "URL Pattern Standard", March 2024, URL needs to be indicated as Living standard (see RFC 9110 or 9421 for eample of whatwg specs references). Please fix this so that the Fetch spec is properly referenced (normatively is needed, I believe). RFC 8792 should be (informatively) referenced. I agree with Mark's write up, 5861 should really be informative. There is several occurrences of {Origin}, please fix. Please add a reference. It would be good to have an informative reference to 6265 (or even 6265bis). 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. [ICMF]: URL [ICT]: URL
Code change:
to process further frames.  Note that this does not address the concerns raised in TALKING. <del> The server session header is a SETTINGS.  The server sends the server session header (i.e., a SETTINGS frame) as the first frame in a new session. </del> <ins> The server session header consists of just a SETTINGS that MUST be the first frame the server sends in the HTTP/2.0 session. </ins> <del> The client sends requests immediately after sending the session header, without waiting to receive a server session header.  This ensures that confirming session headers does not add latency. </del> <ins> In order to avoid unnecessary latency, clients are permitted to send additional frames to the server immediately after sending the client session header, without waiting to receive the server session header. However, it is important to note that the server session header SETTINGS frame might include parameters that necessarily alter how a client is expected to communicate with the server. </ins> <del> Both clients and servers MUST close the connection if it does not begin with a valid session header.  A GOAWAY MAY be omitted if it is clear that the peer is not using HTTP/2.0. </del> <ins> Clients and servers MUST terminate the TCP connection if either peer does not begin with a valid session header.  A GOAWAY MAY be omitted if it is clear that the peer is not using HTTP/2.0. </ins> 3.3. <del> Once the connection is established, clients and servers exchange HTTP/2.0 frames.  Frames are the basic unit of communication. </del> <ins> Once the HTTP/2.0 session is established, clients and servers can begin exchanging frames. </ins> 3.3.1.

Related discussion:
text: Multiple editorial commits....
Just an fyi... I have additional pending editorial edits, some of which are a bit more extensive. I will hold off committing them until this pull request is processed.
Ok, try now...
NAME - please don't do ANY reformatting in pull requests; we need to be able to precisely identify changes and their provenance. Thanks,
Code change:
Content coding registrations MUST include the following fields: Names of content codings MUST NOT overlap with names of transfer <del> codings (transfer.codings), unless the encoding transformation is identical (as is the case for the compression codings defined in content.codings). </del> <ins> codings (as per the "HTTP Transfer Coding registry", located at <https://www.iana.org/assignments/http-parameters/>), unless the encoding transformation is identical (as is the case for the compression codings defined in content.codings). </ins> Values to be added to this namespace require IETF Review (see RFC8126) and MUST conform to the purpose of content coding defined in

Related discussion:
text: I think it would be better to separate this into the purely editorial changes (all except TRACE), and then give the change to TRACE the full treatment separately (it's a normative change after all). Will work on the former first.
Sorry for this being a question. I answered the same question for -caching by searching through and realizing that while caching might be a version-independent extension, a practical consequence of the structure of documents is that it is inextricably linked to -semantics. That's cool. Having the definition of HTTP/N rely on -caching is eminently sensible. There is a normative reference to -messaging though. Why would HTTP/3 care about that? If this were software, I'd be horrified by pulling in a dependency like that. Most of the references to -messaging are strictly examples. I could only see two cases where there was a potentially normative dependency: recommends "message/http" and . These seem like they could be broken (the second easier than the first, certainly) and the reference made normative.
I agree that this would be good.
A SHOULD-level requirement to use message/http. Moving the media type definition over is not going to help, because it essentially defines the HTTP/1.1 wire format as media type. It seems the only way to fix this would be to relax the SHOULD. That one could probably be replaced with a reference to the transfer coding registry (which is what counts here), and the pointer to the spec text would then become informative.
History in and linked issues.
Concrete recommendation for 1: a server (intermediary) responding to TRACE MUST generate a representation of the request that it received in any format. The message/http is one possible way to represent a request message, so that can be an informative reference instead.
Code change:
Content coding registrations MUST include the following fields: Names of content codings MUST NOT overlap with names of transfer <del> codings (transfer.codings), unless the encoding transformation is identical (as is the case for the compression codings defined in content.codings). </del> <ins> codings (as per the "HTTP Transfer Coding registry", located at <https://www.iana.org/assignments/http-parameters/>), unless the encoding transformation is identical (as is the case for the compression codings defined in content.codings). </ins> Values to be added to this namespace require IETF Review (see RFC8126) and MUST conform to the purpose of content coding defined in

Related discussion:
text: Make sure that all references to MESSAGING which are not normative are clearly informative. (This ticket is not about those references which right now are indeed normative, see ).
Code change:
of Supply Chain Integrity, Transparency, and Trust throughout this document.  When used in text, the corresponding terms are capitalized.  To ensure readability, only a core set of terms is <del> included in this section. </del> <ins> included in this section.[^1] </ins> 4.

Related discussion:
text: NAME added security considerations and architecture picture
Thanks for the diagram, the sec-sec and all the other additional polish! I thought about tinkering with the diagram, but am in doubt that I'll improve it significantly. LGTM!
Code change:
split into component parts and the Disclosures can be found in the respective member of the JSON object (or elsewhere). <del> Using a payload similar to that from Example 1 [1], the following is a non-normative example of a JWS JSON serialized SD-JWT from an Issuer with all the respective Disclosures. </del> <ins> Using a payload similar to that from the example in main-example, the following is a non-normative example of a JWS JSON serialized SD-JWT from an Issuer with all the respective Disclosures. </ins> Below is a non-normative example of a presentation of the JWS JSON serialized SD-JWT, where the Holder has selected to disclose

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:
1. Existing RFCs define extensions to HTTP/2 HTTP2 which remain useful <del> in HTTP/3.  Section A.2.3 of HTTP3 describes the required updates for HTTP/2 frames to be used with HTTP/3. </del> <ins> in HTTP/3.  HTTP3 describes the required updates for HTTP/2 frames to be used with HTTP/3. </ins> ORIGIN defines the HTTP/2 ORIGIN frame, which indicates what origins are available on a given connection.  It defines a single HTTP/2 frame type. <ins> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. Frame diagrams in this document use the format defined in QUIC- TRANSPORT to illustrate the order and size of fields. </ins> 2. The ORIGIN HTTP/3 frame allows a server to indicate what origin(s) (RFC6454) the server would like the client to consider as members of <del> the Origin Set (Section 2.3 of ORIGIN) for the connection within which it occurs. </del> <ins> the Origin Set (ORIGIN) for the connection within which it occurs. </ins> The semantics of the frame payload are identical to those of the HTTP/2 frame defined in ORIGIN.  Where HTTP/2 reserves Stream 0 for

Related discussion:
text: NAME Adds the BCP14 boilerplate in a Notation Conventions section. As part of that, I noticed we don't reference any explanation of the frame layout language used -- it's the same used in QUIC and HTTP/3 -- so I added an RFC 9000 ref to pick that up in the same section.
Code change:
5.1.3. <ins> An Issuer can make multiple Statements about the same Artifact.  For example, an Issuer can make amended Statements about the same Artifact as their view changes over time. Multiple Issuers can make different, even conflicting Statements, about the same Artifact.  Verifiers can choose which Issuers they trust. Multiple Issuers can make the same Statement about a single Artifact, affirming multiple Issuers agree. 5.1.4. </ins> SCITT payloads are opaque to Transparency Services.  For interoperability, Registration Policy decisions should be based on interpretation of the mandatory metadata in the protected header of a

Related discussion:
text: Looking at URL, I think a that some more diverse examples later that show how multiple statements about one Artifact using the same sub Claim can have different semantics than multiple statements about one Artifact using different sub Claims - including illustrating text when one choice can be used an when the other & pros and cons.
Covered above
LGTM
Code change:
This specification describes data formats as well as validation and processing rules to express Verifiable Credentials with JSON payloads based on the Selective Disclosure for JWTs (SD-JWT) I-D.ietf-oauth- <del> selective-disclosure-jwt format.  It can be used when there are no </del> <ins> selective-disclosure-jwt format.  It can be used without any </ins> selective disclosable claims, too. 1.

Related discussion:
text: I removed the subsection numbers where appropriate to be less dependent on changes in the SD-JWT spec. I also removed references to the issuance/presentation format, as this was unified in SD-JWT. This also meant that the section on the data formats for issuance and presentation in our spec can now be just one section, as there are no big differences any longer.
There are a number of references to specific section numbers in SD-JWT that are now out of sync and point to the wrong sections or non-existent sections. And some lingering use of terms like "Combined Format for XXXXX" that are no longer used in SD-JWT.
And there may well be other changes coming to the section layout URL so it might be prudent to avoid specific section number references (for the time being anyway).
lgtm
Code change:
and 8192 characters in length that fits the regular expression of a distinguished name. <del> The mechanisms for how Transparency Services obtain identity documents is out-of-scope of this document. </del> The "kid" header parameter MUST be present when "x5t" is not present. Key discovery protocols are out-of-scope of this document.

Related discussion:
text: Reason: Term was used only twice, not defined, and does not seem to play an important role. !
fiddled with a phrasing nit. This approval is not about the diagram picture, but the content of md that substitutes Identity Documents with URL
Code change:
syntactically, this is done only to allow parsers to be generic; as per RFC7231, Section 4.3.1, a body on a GET has no meaning, and will be either ignored or rejected by generic HTTP software.  As a result, <del> applications that use HTTP SHOULD NOT define GET to have any sde </del> <ins> applications that use HTTP SHOULD NOT define GET to have any side </ins> effects upon their resources. 4.6.

Related discussion:
text: This just fixes a typo, but this text has more problems. I'm having trouble connecting this final sentence to the text that precedes it. I think that the point is that including a body on GET is unwise because it might cause explosions. A point about side effects needs far more exposition, especially since GET is defined to be free from overt side effects (safe, idempotent, and all that business). If this were just another statement and the "As a result" is dropped, that's different.
Barg, I think that's a copy/paste error, will fix. thx.
Code change:
consider other non-standard congestion control algorithms that are known to be widely deployed. <del> We note that this guideline is not a requirement for strict Reno- or </del> <ins> Note that this guideline is not a requirement for strict Reno- or </ins> Cubic- friendliness as a prerequisite for a proposed congestion control mechanism to advance to Experimental or Standards Track status.  As an example, HighSpeed TCP is a congestion control

Related discussion:
text: Thanks for the edits. I am a big fan of losing fewer words, so I reverted changes that went in the wrong direction.
Code change:
2. <del> As illustrated in livecycle-threats, a supply chain attack may </del> <ins> Supply chain security is paramount to protecting critical infrastructure, aerospace, and defense and avoiding impacts on security, the economy, public health, and safety.  It has historically focused on risk management practices to safeguard logistics, meet compliance regulations, demand forecasts, and optimize inventory.  While these elements are foundational to a healthy supply chain, an integrated cyber security-based perspective of the software supply chains remains broadly undefined.  Recently, the global community has experienced numerous supply chain attacks by cybercriminals targeting weaknesses in software supply chains.  As illustrated in lifecycle-threats, a software supply chain attack may </ins> leverage one or more lifecycle stages and directly or indirectly target the component. <ins> DevSecOps relies on third-party and open-source solutions, expanding supply chain complexity, and reducing the visibility of the lifecycle compliance.  One solution approach is to enhance the auditability and accountability of Digital Supply Chain Artifacts (DSCA) by using an interoperable, scalable, and flexible decentralized architecture with a transparent registry.  The required software artifacts are highly variable based on community policy requirements, and the solution approach should be artifact agnostic to enable adaptation to these broad policies.  Example artifacts may include commit signatures, build environment and parameters, software bill of materials, static and dynamic application security testing results, fuzz testing results, release approvals, deployment records, vulnerability scan results, and patch logs. </ins> 3. TBD

Related discussion:
text: Introduction: Removed excess carriage returns Problem Statement: Added new text (threats + artifacts) and illustration (threats)
Please add "and is still valid" - see new proposed langauge enable the consumer to verify that software originated from a 'duly authorized signing party' on behalf of the Supplier, and is still valid
+1 to this change
Closing as been addressed now!
I have no concerns with the revised language for 3.1. One minor nit on 3.2 to be consistent with the use case title REPLACE: A consumer of released software component wants: WITH A consumer of released software product wants:
LGTM
This issue has been resolved in the above PR.
LGTM!
Code change:
2.2. The Identity Chaining flow outlined below describes how a combination <del> of OAuth 2.0 Token Exchange RFC8693 and Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants RFC7521 are used to address the use cases identified.  The appendix include two </del> <ins> of OAuth 2.0 Token Exchange RFC8693 and JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants RFC7523 are used to address the use cases identified.  The appendix include two </ins> additional examples that describe how this flow is used.  In one example, the resource server acts as the client and in the other, the authorization server acts as the client.

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.2. The Identity Chaining flow outlined below describes how a combination <del> of OAuth 2.0 Token Exchange RFC8693 and Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants RFC7521 are used to address the use cases identified.  The appendix include two </del> <ins> of OAuth 2.0 Token Exchange RFC8693 and JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants RFC7523 are used to address the use cases identified.  The appendix include two </ins> additional examples that describe how this flow is used.  In one example, the resource server acts as the client and in the other, the authorization server acts as the client.

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:
The DATA frame contains the following fields: An 8-bit field containing the length of the frame padding in units <del> of octets.  This field is optional and is only present if the </del> <ins> of octets.  This field is conditional and is only present if the </ins> PADDED flag is set. Application data.  The amount of data is the remainder of the

Related discussion:
text: Only if it makes sense to do so. It's a perfectly good word that has been spoiled by an unnecessary inclusion in some popular RFC (2119, I think).
Code change:
payload data is allowed by requiring a Content-Length header field with a value of "0". <ins> Likewise, new methods cannot use the special host:port and asterisk forms of request target that are allowed for and , respectively (target.resource).  A full URI in absolute form is needed for the target URI, which means either the request target needs to be sent in absolute form or the target URI will be reconstructed from the request context in the same way it is for other methods. </ins> A new method definition needs to indicate whether it is safe (safe.methods), idempotent (idempotent.methods), cacheable (cacheable.methods), what semantics are to be associated with the

Related discussion:
text: Considerations for new method should mention that the target URI has to be absolute. from URL
+1, thanks for filing!
We currently say: Isn't that sufficiently clear?
It wasn't clear to me because I didn't read the whole doc when I was searching for this information.
It's weird to say this because a URI is always in absolute form (part of what makes it Uniform). Only a reference can be relative, like within the request-target of 1.1 (absolute-path) or anything called a URI-reference. I think what you want to add is a reminder that new method extensions cannot use the host:port or asterisk forms of request target. Note that this only requires a request target in absolute form if the scheme or host:port are necessary to define the target, which they are for CONNECT-UDP.