jiebi/CodeConvo huggingface dataset:
Code change:
need to be signed, avoiding problematic components.  For example, a web application framework that relies on rewriting query parameters might avoid use of the "@query" content identifier in favor of sub- <del> indexing the query value using "@query-params" content identifier </del> <ins> indexing the query value using "@query-param" content identifier </ins> instead. Some components are expected to be changed by intermediaries and

Related discussion:
text: If it wasn't your thinking already, I'd like to suggest that the derived component be the singular instead. When canonicalizing individual query parameters, each component identifier references a single query parameter name/value pair. The use of singular feels more appropriate to me: In the rare case where there are multiple query parameters with the same name, each one's canonical representation is still referring to a single name/value pair, so the singular still feels more appropriate: When used in the list of covered components, we still include the parameter, so each component identifier is usually [1] referring to a single query parameter name/value pair: [1]: However, in that rare case of multiple query parameters having the same name, one instance of would cover all instances of that repeated query parameter named . Perhaps the plural does make more sense for this scenario. But if there must be a singular/plural mismatch somewhere, I'd rather see it in the more rare and exceptional case. So I would propose using the name instead of . In , I see that a recent addition implemented it as the singular . I wonder if drafters already had this change in mind or if it might have been an oversight that organically tended toward what feels more natural.
Thank you for bringing this up, I think this is a valid point. I don't think there's wide support for this derived component yet so now's a good time to change it for all the good reasons you mention.
Looks good to me, will leave for a beat to get feedback from others.
Code change:
This document aspires to standardize an HTTP header field named "Client-Cert" that a TLS terminating reverse proxy (TTRP) adds to <del> requests that it sends to the backend origin servers.  The header </del> <ins> requests that it sends to the backend origin servers.  The field </ins> value contains the client certificate from the mutually-authenticated TLS connection between the originating client and the TTRP.  This enables the backend origin server to utilize the client certificate information in its application logic.  While there may be additional proxies or hops between the TTRP and the origin server (potentially even with mutually-authenticated TLS connections between them), the <del> scope of the "Client-Cert" header is intentionally limited to </del> <ins> scope of the "Client-Cert" header field is intentionally limited to </ins> exposing to the origin server the certificate that was presented by the originating client in its connection to the TTRP.

Related discussion:
text: This was languishing in a PR within my repo, but since we've merged the actual draft, we can promote this to a PR in the main repo as well. (Yes, I'll rename the tag if we merge this as-is.)
Code change:
the presenter has access to the private key that corresponds to the public key in the certificate. <del> 3.4. </del> <ins> 3.6. </ins> One of the most basic use cases for workload identity is for authenticating one workload to another such as in the case where one

Related discussion:
text: added Attestation as a function performed within the Server box. defined Agent. defined Attestation.
Thanks I think this helps my understanding, I'm sure we'll have more refining to do, but thanks for providing the text to get started.
Code change:
Additional validation rules MAY apply, but their use is out of the scope of this specification. <ins> 3.5. A recipient of the SD-JWT VC MUST apply the following rules to verify the Issuer-signed JWT corresponds to the Issuer: - JWT Issuer Metadata: If the value contains a HTTPS URI, the recipient MUST obtain the public key using JWT Issuer Metadata as defined in jwt-issuer-metadata.  - DID Document Resolution: If the value contains a DID, the recipient MUST retrieve the public key from the DID Document resolved from the DID in the value.  If the JWT header parameter is present, the MUST be a relative or absolute DID URL of the DID in the value, identifying the public key.  - X.509 Certificates: The recipient MUST obtain the public key from the leaf X.509 certificate defined by the , , or JWT header parameters of the Issuer-signed JWT and validate the X.509 certificate chain in the following cases: - If the value contains a DNS name encoded as a URI using the DNS URI scheme RFC4501.  The DNS name MUST matche a Subject Alternative Name (SAN) RFC5280 entry of the leaf certificate. - If the value contains a URN using the URN URI scheme RFC2141.  The URN MUST match a SAN entry of the leaf certificate. Additional rules for verifying the public key belongs to the Issuer MAY be used but are out of scope of this specification. </ins> 4. This specification defines the JWT Issuer Metadata to retrieve the

Related discussion:
text: This PR does the following: make verification that the public key of the Issuer-signed JWT belongs to the Issuer mandatory introduce methods to perform this verification based on JWT Issuer Metadata, X.509 Certificates and DIDs Potentially . Partially Out-of-scope: Renaming and moving JWT Issuer Metadata Section
Addressed all suggestions, please review again NAME
I had to rename the section. I think now it is more precise.
Show possible options like JWT Issuer Metadata, being a DID URL etc.
We introduced a new section that talks about different key discovery methods during the verification process in PR
Code change:
, etc. as defined or required by the application using SD-JWTs. <ins> Applications of SD-JWT SHOULD be explicitly typed using the header parameter.  See explicit_typing for more details. </ins> 5.1.1. For each claim that is to be selectively disclosed, the Issuer

Related discussion:
text: Thanks, editorial comments taken.
Whether this format is JWT or JWT-like, the considerations in the still apply. Please consider adding a claim. cc NAME
Explicit typing via the header can and should be done by specific applications or types of SD-JWT. But this SD-JWT draft is defining the general JWT-like construct and explicit typing of the generic thing isn't particularly useful or meaningful.
The The next draft will have a media type and structured suffix that can help with specific applications or types of SD-JWT doing explicit typing FWIW URL
I would be open to adding one sentence in the draft saying "applications of SD-JWT SHOULD be explicitly typed". I agree there cannot be only one type for all SD-JWTs.
I'm not quite sure where to add that one sentence. And a bit more context might be needed with it. I'll see what I can figure out. Maybe a small section like 3.11 in rfc8725. But (helpful) suggestions/ideas would be welcome in the meantime.
Add this sentence at the end of 5.1: The header parameter is RECOMMENDED, see Sec. 5.1.4 for more details. And as a new Sec. 5.1.4, "Explicit Typing": A commonly seen attack is for one kind of JWT to be confused for another. Both regular JWTs as well as SD-JWTs are vulnerable to confusion attacks. To prevent these attacks, it is RECOMMENDED to specify an explicit type by including the header parameter when the token is issued, and for Verifiers to check this value. The relevant token's content type can be used, e.g. , but often a more application-specific value is preferred. See Sec. 3.11 of RFC 8725 for more details.
Thanks NAME I took some inspiration from you words in creating PR .
merged PR to close this one
Thanks for preparing this! LGTM, just two small editorial comments.
Code change:
between the authorization servers.  To achieve a maintainable and flexible systems clients SHOULD NOT request a specific "requested_token_type" during the token exchange and SHOULD NOT <del> require a certain format or parse the authorization grant (for instance in caes of JWT).  The "issued_token_type" parameter in the response indicates the type and SHOULD be passed into the assertion request.  This allows flexibility for authorization servers to change format and content. </del> <ins> require a certain format or parse the authorization grant (e.g., if the token is encoded as a JWT).  The "issued_token_type" parameter in the response indicates the type and SHOULD be passed into the assertion request.  This allows flexibility for authorization servers to change format and content. </ins> Authorization servers MAY use an existing grant type such us "urn:ietf:params:oauth:grant-type:jwt-bearer" to indicate a JWT or

Related discussion:
text: Includes updates based on
Original: URL Kelly's editorial changes: identity-chaining-draft-URL
Code change:
Append a comma (",") to this-key. <del> Append sorted-value to this-key. </del> <ins> Append value to this-key. </ins> <del> Let remaining-variants be a copy of all of the members of sorted-variants except the first. </del> <ins> Let remaining-facets be a copy of all of the members of key- facets except the first. </ins> <del> If remaining-variants is empty, append this-key to possible- keys. </del> <ins> If remaining-facets is empty, append this-key to possible-keys. </ins> <del> Otherwise, run Find Available Keys on remaining-variants, this- </del> <ins> Otherwise, run Find Available Keys on remaining-facets, this- </ins> key and possible-keys. Return possible-keys.

Related discussion:
text: For
Allow a response to associate itself with more than one variant. (moved from mnot/I-D)
Code change:
TLS handshake completes, then all instances of the server need to agree and either reject the request or delay processing. <ins> A server MUST NOT act on early data before the handshake completes if it and any other server instance could make a different decision about how to handle the same data. </ins> 6.3. Accepting early data exposes a server to potential denial of service

Related discussion:
text: This text from Kyle Rose highlights the decision process. If any node might make a different decision about processing early data, then this node has to wait.
I like it, +1
Code change:
5.1. <del> The "HEADERS" message contains information required to deliver, cache, and forward a stream.  This message SHOULD be parsed and obeyed by any Warp relays. </del> <ins> A SEGMENT message contains a single segment associated with a specified track, as well as associated metadata required to deliver, cache, and forward it. The header of the SEGMENT message is as follows: </ins> "id".  An unique identifier for the stream.  This field is optional and MUST be unique if set.

Related discussion:
text: Shared between and
Merging because I don't think this is controversial, and we have two PRs doing the same thing.
This sounds a bit like an extension that just gets forwarded when not understood by a relay? How does APP interact with caches, for example? Can a single QUIC stream have SEGMENT and APP data interleaved? Might be too vague to leave in
The intention was to cache/forward it the same way as media. It's just meant for arbitrary metadata and as a replacement for the current approach of shoving metadata into the media bitstream. For example, in h.264 land it's common to put arbitrary content (non-standardized) in SEI messages. Even if we don't cache/forward the stream, it would still be nice to let the application use unidirectional streams. This basically says prefix the stream with a 2 if it's used by the application instead of Warp. This wouldn't work with relays which is why I had the idea of reusing HEADERS to tell the relay which application streams should be forwarded/cached and how.
Oh and it's missing because there's no encoding yet, but I was envisioning that SEGMENT and APP frames do not specify a length. They would consume the remainder of the stream so there's no way to use them in conjunction.
Is there an MP4 box that we can just use as a part of the layer? That would provide some form of uniformity.
That was my thought too, although it means every container will need some way of specifying application data. MP4 atoms require a length up-front so they would be limited to messages instead of unbounded streams.
the RTCP APP message never turned out to be as useful in RTP as people thought it would be ... that said, fan of being able to send whatever data in the payload. If it happens to be a protobuf app message instead of media, seem like MOQ shoudl not care, it should just deliver the bytes with not much care if they are audio, vidie, haptics, or an app custom media
We need to define the difference of APP message and Media data in terms of what is inside and how it is interacted with caching and dropping. Otherwise there is a risk that the APP message becomes the container for “whatever does not fit in the current RFC“ which renders the standard useless.
Code change:
of mandatory header fields, or the inclusion of uppercase header field names. <del> A request or response that includes an entity body can include a </del> <ins> A request or response that includes an payload body can include a </ins> "content-length" header field.  A request or response is also malformed if the value of a "content-length" header field does not equal the sum of the

Related discussion:
text: There were lots of small changes as a result of . The only change of note is URL, which adds text on what a receiver should expect and what they are obligated to do for streams in the "half closed (local)" state.
Code change:
attribute-name of "Domain": Let the domain-attribute be the attribute-value of the last <del> attribute in the cookie-attribute-list with an attribute-name of "Domain". </del> <ins> attribute in the cookie-attribute-list with both an attribute- name of "Domain" and an attribute-value whose length is no more than 1024 octets. </ins> Otherwise:

Related discussion:
text: Addresses
NAME NAME PTAL
RFC6265bis mentions the cookie length constraints in relation to parsing the Set-Cookie headers but doesn't in the more general Storage Model section. From chatting with NAME about this, it'd be desirable to have these constraints be listed in that section as well. Since there are other ways cookies can come in to the cookie store (Ex: Cookie Store API), having these constraints be enforced when adding cookies from any source to the cookie store would better ensure cookie format consistency.
Code change:
Abstract This document defines an HTTP Proxy-Status Parameter that contains a <del> list of aliases received over DNS when establishing a connection to the next hop. </del> <ins> list of aliases and canonical names received over DNS when establishing a connection to the next hop. </ins> 1.

Related discussion:
text: This draft (-00) is using the term "alias" in a slightly different way than used in DNS: A CNAME record has two names, the owner name on the left-hand side or "alias", and the target name on the right-hand side or "canonical name". RFC 8499 (DNS Terminology): In other words, to use the example in the draft: Which might correspond to a DNS response that looked something like: and are DNS aliases (because there are CNAME records with those owner names) whereas is a DNS "canonical name" without an alias. But is included in the example in this draft. This might be confusing for the DNS name at the end of the CNAME chain (which is not an alias from a DNS perspective), so I might suggest changing: to something like:
Code change:
client and server have distinct interpretations of the data that flows between them. <del> If the server accepts an HTTP Upgrade, it interprets the subsequent bytes in accordance with the new protocol.  If it rejects the upgrade, it interprets those bytes as HTTP/1.1.  However, the client doesn't know which interpretation the server will take until it receives the server's response status code.  If it uses the new protocol optimistically, this creates a risk that the server will interpret attacker-controlled data in the upgraded protocol as an </del> <ins> If the server accepts a protocol transition request, it interprets the subsequent bytes in accordance with the new protocol.  If it rejects the request, it interprets those bytes as HTTP/1.1.  However, the client doesn't know which interpretation the server will take until it receives the server's response status code.  If it uses the new protocol optimistically, this creates a risk that the server will interpret attacker-controlled data in the new protocol as an </ins> additional HTTP request issued by the client. <del> As a trivial example, consider an upgraded protocol in which the entire post-upgrade content might be freely attacker-controlled (e.g., "connect-tcp" I-D.ietf-httpbis-connect-tcp).  If the client is authenticated to the server using a connection-level authentication method such as TLS Client Certificates, the attacker could send an HTTP/1.1 POST request in the post-upgrade payload.  If the client delivers this payload optimistically, and the upgrade request fails, the server would interpret the payload as a subsequent authenticated </del> <ins> As a trivial example, consider an HTTP CONNECT client providing connectivity to an untrusted application.  If the client is authenticated to the proxy server using a connection-level authentication method such as TLS Client Certificates, the attacker could send an HTTP/1.1 POST request for the proxy server at the beginning of its TCP connection.  If the client delivers this data optimistically, and the CONNECT request fails, the server would misinterpret the application's data as a subsequent authenticated </ins> request issued by the client. 3.2.

Related discussion:
text: This includes changing the title, adjusting the language to be more generic, and adding a section with guidance for HTTP CONNECT.
Most of the considerations in optimistic-upgrade, which originally emerged from consideration of "connect-tcp", also apply to HTTP CONNECT. We should consider expanding the scope of the draft to cover that topic as well. cc NAME
Code change:
Via (RFC7230, Section 5.7.1) <del> Responding to requests coming through an intermediary in a round- robin manner works well when the network bottleneck exists between the intermediary and the end client, as the intermediary would be buffering the responses and then be forwarding the chunks of those buffered responses based on the prioritization scheme it implements. A sophisticated server MAY use a weighted round-robin reflecting the urgencies expressed in the requests, so that less urgent responses would receive less bandwidth in case the bottleneck exists between the server and the intermediary. </del> 8.2. It is common for CDN infrastructure to support different HTTP

Related discussion:
text: cc NAME since it closes your issue.
I believe this is now good to go, please approve or speak up if you disagree.
In there is a rather firm recommendation to erase priorities at servers that are served by coalescing intermediaries: This seems wrong to me. The Priority header field provides information about what the User Agent thinks of priority. This might be adjusted by intermediaries on the path, and it might not be globally consistent, but that does not mean the information should be discarded. Instead, I would prefer that we say that when an intermediary coalesces requests from multiple clients, servers need to be aware of that and account for that in their processing. The remainder of this text is fine in the sense that it identifies information the server can use to more fairly allocate resources to different requests, but - again - this is just information the server uses when making prioritization decisions. The model we operate on should not assume be that Priority is an instruction to the server, but that it provides the server (or intermediary) clues about how it might decide to allocate resources.
No one responded to this for a while, sorry. The text is mostly untouched but I did change the example to just . My read of this today, I'm concerned that the requirement is a bit specific. It's not clear if a server applying this would also discard any additional priority parameters. I don't know if NAME original point was along those lines or not, but I'll try to make a PR to address what I think needs fixing
Code change:
Here, recipients can infer that two content-codings in addition to "identity" are available, as well as two content languages.  Note <del> that, as with all HTTP header fields that use the "#" list rule (see RFC7230, Section 7), they might occur in the same header field or separately, like this: </del> <ins> that, as with all Structured Header lists, they might occur in the same header field or separately, like this: </ins> The ordering of available-values after the field-name is significant, as it might be used by the header's algorithm for selecting a

Related discussion:
text: I think this also but I might have missed something. Misc changes that aren't actually necessary to use Structured Headers: "variant-item" became "variant-axis". I defined what clients ("caches"?) MUST do when a server violates one of its MUSTs. I removed the (incorrect) definition of available-value in favor of allowing arbitrary . It wasn't clear what excluding characters like was gaining us, and the restriction would have required extra words when parsing the headers. I removed {{gen-variant-key}} entirely and had Compute Possible Keys return a list of lists that could be directly compared against the Structured Header parse of . It would be difficult to keep the old behavior of returning a list of strings without re-adding some restriction on an available-value, for example by requiring that they don't contain spaces. I simplified Compute Possible Keys a bit.
URL shows a Variant-Key of But that's now This also has implications for the URL algorithm, which currently ignores semicolons.
looks like a parameterised list is currently a list of strings, but if is adopted, its syntax will need to be changed, as it doesn't fit into parameterised list particularly well (although I guess it could).
Currently waiting on resolution of .
NAME is closed now. Any hints?
Hi NAME - getting to it. Are you planning on implementing or using?
Code change:
Senders MUST NOT repeat the same parameter type in a message. Receivers SHOULD check that there are no duplicate parameters and <del> close the connection if found. </del> <ins> close the session as a 'Protocol Violation' if found. </ins> Receivers ignore unrecognized parameters.

Related discussion:
text: I also wonder if Connection URL should be renamed to Session URL?
Part of PR has text "MUST close the connection if there are duplicates" It seems like we should be closing the session, and we should specify an error code.
I think this is editorial, but unsure because of "specify an error code"
I would prefer: instead of:
Code change:
requirements in combining.byte.ranges. When combining the new response with one or more stored responses, a <del> cache MUST use the header fields provided in the new response, aside from , to replace all instances of the corresponding header fields in the stored response. </del> <ins> cache MUST update the stored response header fields using the header fields provided in the new response, as per update. </ins> 4.

Related discussion:
text: Now that we have three different places referring to the text on updating stored headers, it deserves its own section. In the process, I noticed that the current text forgot to mention that CC: private and no-cache can have arguments that affect header storage.
says: As per other discussions, this needs to be more nuanced; either a reference to 4.3.4, or new text.
The that no one is really doing this; is either converted to a GET on the backend, or it doesn't seem to touch the cache. I think the most sane thing to do is to refer to the rules for a 304 update, but make it clear that this is optional.
Could you clarify how HEAD is relevant for "Combining Partial Content"?
Arg, sorry, wrong issue.