jiebi/CodeConvo huggingface dataset:
Code change:
An endpoint might choose to close a connection without sending GOAWAY for misbehaving peers. <ins> A GOAWAY frame might not immediately precede closing of the connection; a receiver of a GOAWAY that has no more use for the connection SHOULD still send a GOAWAY frame before terminating the connection. </ins> The GOAWAY frame does not define any flags. The GOAWAY frame applies to the connection, not a specific stream.

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:
This draft only specifies a single use of bidirectional streams. Objects are sent on unidirectional streams.  Because there are no other uses of bidirectional streams, a peer MAY currently close the <del> connection if it receives a second bidirectional stream. </del> <ins> session as a 'Protocol Violation' if it receives a second bidirectional stream. </ins> The control stream MUST NOT be abruptly closed at the underlying transport layer.  Doing so results in the session being closed as a

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:
header field value containing a member "*" always fails to match. <del> The stored response with matching selecting header fields is known as the . If multiple selected responses are available (potentially including responses without a Vary header field), the cache will need to choose one to use.  When a selecting header field has a known mechanism for doing so (e.g., qvalues on </del> <ins> If multiple stored responses match the selecting header fields (potentially including responses without a Vary header field), the cache will need to choose one to use.  When a selecting header field has a known mechanism for ranking preference (e.g., qvalues on </ins> and similar request header fields), that mechanism MAY be used to <del> select a preferred response.  If such a mechanism is not available, </del> <ins> choose a preferred response.  If such a mechanism is not available, </ins> or leads to equally preferred responses, the most recent response (as determined by the <del> header field) is used, as per constructing.responses.from.caches. </del> <ins> header field) is chosen, as per constructing.responses.from.caches. </ins> Some resources mistakenly omit the Vary header field from their default response (i.e., the one sent when no more preferable response is available), with the effect of selecting it for requests to that resource even when more preferable responses are available.  When a <del> cache has multiple responses for a target URI and one or more omits the Vary header field, it SHOULD use the most recent (see age.calculations) valid Vary field value available to select an appropriate response for the request. </del> <ins> cache has multiple stored responses for a target URI and one or more omits the Vary header field, the cache SHOULD choose the most recent see age.calculations) stored response with a valid Vary field value. </ins> <del> If no selected response is available, the cache cannot satisfy the presented request.  Typically, it is forwarded to the origin server in a (possibly conditional; see validation.model) request. </del> <ins> If no stored response matches, the cache cannot satisfy the presented request.  Typically, the request is forwarded to the origin server, potentially with preconditions added to describe what responses the cache has already stored (validation.model). </ins> 4.2.

Related discussion:
text: Me confused. Which PR is relevant now? Both?
The other one is an evolution of this one.
We use the phrases 'selected representation' and 'selected response' in Semantics and Caching (respectively) to refer to two completely different concepts. Can we do better?
No
I think the two concepts match pretty well (and are used correctly in the four sentences). However, I also think that "chosen response" would be okay given it is only used in four places. I really don't think it needs a separate definition, since it means what the two words mean. So, maybe.
It was actually used in a few more places as the response selected. I think I found all of them.
See .
Code change:
This document, if approved, requests IANA to register the following entry in the "TLS Exporter Labels" registry maintained at <<https://www.iana.org/assignments/tls-parameters#exporter-labels>>: <ins> 10.3. This document, if approved, requests IANA to register the following entry in the "Hypertext Transfer Protocol (HTTP) Field Name" registry maintained at <<https://www.iana.org/assignments/http-fields/http- fields.xhtml>>: </ins>

Related discussion:
text: Please correct me if I'm wrong, but IIUC, the crux of this PR is that to allow any client that can present a valid pair of Authorization and Signature-Auth-Context header fields to obtain a protected resource. Assuming that if we would be allowing such behavior, I wonder why we need to require clients to export keys from TLS session, rather than just coming up with some arbitrary authentication context and present it to the server? Or if it is the case that there are situations in which we have to require clients to use keys exported from TLS session, doesn't it mean that there are cases where servers must ignore Signature-Authentication-Context header field or drop it?
NAME no this is only for trusted intermediaries. If a server receives a Signature-Auth-Context header from an untrusted source then it drops it. That's somewhat mentioned on line 470, but I'll add normative text.
Code change:
Implementations MUST support ephemeral key exchange sizes of at least 2048 bits for cipher suites that use ephemeral finite field Diffie- <del> Hellman (DHE) TLS12 and 224 bits for cipher suites that use ephemeral </del> <ins> Hellman (DHE) TLS13 and 224 bits for cipher suites that use ephemeral </ins> elliptic curve Diffie-Hellman (ECDHE) RFC4492.  Clients MUST accept DHE sizes of up to 4096 bits.  Endpoints MAY treat negotiation of key sizes smaller than the lower limits as a ConnectionErrorHandler of

Related discussion:
text: A lot has happened to TLS since we did RFC 7540. This tries to capture that succinctly. It rolls in changes from RFC 8740.It mentions early data and RFC 8470.It updates references, citing TLS 1.3 rather than 1.2 for a generic TLS reference.
A few small changes are included in , which could be integrated easily.
I won't create the pull request just yet, but here are some proposed changes: URL NAME do you think that you could review these? I've paraphrased some of RFC 8740 and I want to make sure I haven't missed anything.
(The GitHub link did something silly, but I'm assuming 837d46a5ff9e23a62cb719f69be7f1d10bf8da80 is the right commit and just looked at that.) s/the handshake// Though I wonder if this sentence can just be omitted. I needed to address it in RFC8740 because RFC7540 didn't have a TLS version dispatch. But now the TLS 1.2 features section is explicitly mentioned as being 1.2-only, so that exception already doesn't apply. Otherwise LGTM. (I think the default values in server settings is implicit from the fact that we haven't received anything from the server yet, but whatever.)
Thanks. I've updated my branch to remove the renegotiation piece. I've updated that link (which I should have checked).
Code change:
6.1. <del> A presentation of an SD-JWT VC MUST be encoded using the SD-JWT Combined Format for Presentation as defined in Section 5.4. of I- D.ietf-oauth-selective-disclosure-jwt. A presentation of an SD-JWT VC MAY contain a Key Binding JWT as described in Section 5.4.1. of I-D.ietf-oauth-selective-disclosure- jwt. When there are no selectively disclosable claims, a presentation of SD-JWT VC does not contain any Disclosures. 6.1.1. </del> If the presentation of the SD-JWT VC includes a Key Binding JWT, the following claims are used within the Key Binding JWT:

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:
2.2. Clients MUST NOT send "http" requests and "https" requests on the <del> same connection. </del> <ins> same connection.  Similarly, clients MUST NOT send "http" requests for multiple origins on the same connection. </ins> 2.3.

Related discussion:
text: This is kinda silly, but it seems like adding support for coalescing is something we could fix later. with the nuclear option.
the pull request is fine by me. I do wonder if we shouldn't make the json a tad more complicated to allow for a reasonable mixed definition in the future. But an unreasonable one is obviously possible :)
Can we coalesce http and https? The implication from everything we've said is "yes", but Erik remains reluctant.
Code change:
response also lacks a validator, then that stored response is identified for update. <del> For each stored response identified for update, the cache MUST: delete any header fields in the stored response with warn-code 1xx (see header.warning); retain any header fields in the stored response with warn-code 2xx; and, </del> <ins> For each stored response identified for update, the cache MUST use the header fields provided in the </ins> <del> use other header fields provided in the response to replace all instances of the corresponding header fields in the stored response. </del> <ins> response to replace all instances of the corresponding header fields in the stored response. </ins> 4.3.5.

Related discussion:
text: I'll have to update extract-header-URL so that it can generate entries with status "obsoleted".
NAME Go ahead and merge after you update extract-header-URL
Isn't implemented, generated, used or surfaced to users; can we deprecate?
Proposal: Replace 5.5 Warning with a section noting that the Warning header is deprecated, and should be ignored. Remove all requirements to generate Remove Warning-specific requirements in 3.3 Combining Partial Content Remove Warning-specific requirements in 4.3.4 Freshening Stored Responses upon Validation Remove Warning-specific requirements in 4.3.5 Freshening Responses via HEAD
+1, with big notes in the Changes section.
Just curious if anyone has any background, what would be a good alternative to the Warning header for cache limit warnings?
This isn't a good place for general discussion. You might want to ask the mailing list, though I am not aware of any cache limit warnings within HTTP because they are only relevant to the cache admin (who typically has an email or phone number stored for such notifications).
Code change:
a few different SD-JWT permutations, both with and without various constituent parts. <del> An SD-JWT without Disclosures and without a KB-JWT: </del> <ins> An SD-JWT without Disclosures: </ins> <del> An SD-JWT with Disclosures and without a KB-JWT: </del> <ins> An SD-JWT with Disclosures: </ins> An SD-JWT+KB without Disclosures:

Related discussion:
text: to
I was not completely sure either and that's why I posted only the issue and no PR first. I still think that in chapter 5. the extra mentions are confusing as the text and the ABNF are separating the SD-JWT and SD-JWT+KB formats. In contrast, similar explicit mention in the verification section is clarifying to me.
I wasn't sure when first looking at it and actually thing it's okay either way but have come to think it's more okay this way.
The distinguishing of SD-JWT from SD-JWT+KB is a good clarifying change in -09. Some extra mentions of KB-JWT still remain that could probably removed: In : >An SD-JWT without Disclosures and without a KB-JWT and >An SD-JWT with Disclosures and without a KB-JWT The "and without a KB-JWT" could be removed as there are separate examples for SD-JWT+KB and SD-JWT is now defined not to include KB-JWT.
Thanks NAME PR does exactly what you've suggested.
approved the PR () too.
I am not sure these are actually extraneous, but ok looks good
Code change:
Support for "kid" in the protected header and "x5chain" in the unprotected header is OPTIONAL to implement. <del> When "x5t" is present, "iss" MUST be a string with a value between 1 and 8192 characters in length that fits the regular expression of a distinguished name. </del> <ins> When "x5t" is present, "iss" MUST be a string that meets URI requirements defined in RFC8392.  The "iss" value's length MUST be between 1 and 8192 characters in length. </ins> 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: with unclear definition and regex requirements with DN currently in draft.
Calling NAME for some
Perhaps I missed it, but what is the motivation of changing to a URI?
We are specifically customizing the usage of in CWT as defined in . In that document, it is a type and it seems like we shifting away from the base usage of URI to something else and with a regex spec I couldn't find in a relevant I-D, RFC, or standards doc that we can normatively cite as a reference. Is there something I am missing, and is there a valid reference we could use?
I agree the current text is not clear, as it doesn't define or reference any regex. However, stating that the must be a URI with no further specification is equally unsatisfying. How about we drop any mandate to use a particular format of if the protected header is present? The identity of the issuer will be sourced from the X.509 certificate, so the value is largely redundant.
There is a little more detail in the CWT RFC and points to the JWT RFC which in turn points to the string representation of URIs RFC. Are those definitions equally unclear? I don't mind that if others have that feedback I'll close this out and start over. That will obsolete the feedback from Hannes that triggered this PR at the same time. I can bring that on list and reference this discussion.
Ah, yes, I forgot to mention: if we want to retain the use of the string representation of the subject DN of the X.509 certificate for the value, we can reference RFC 4514.
I can also bring that up as an option on list and adjust accordingly if that is ok.
I think it’s unclear, as there is no guidance on the content of the iss, only that it is URI-shaped.
It is similarly unclear to me in the architecture requirements what one should or must do with the DN. It is implied, but left to the implementer to decide for desired X.509 use cases. It is not clear what one should do with it to correctly validate the cert use per the claim, regardless of DN or URI is chosen. Can we both agree that is part of the problem?
In any event, I apologize for the delay, I have created the following thread on list to discuss before moving forward with the PR in any significant way.
Code change:
Support for "kid" in the protected header and "x5chain" in the unprotected header is OPTIONAL to implement. <del> When "x5t" is present, "iss" MUST be a string with a value between 1 and 8192 characters in length that fits the regular expression of a distinguished name. </del> <ins> When "x5t" is present, "iss" MUST be a string that meets URI requirements defined in RFC8392.  The "iss" value's length MUST be between 1 and 8192 characters in length. </ins> 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: I may stand corrected and others will prefer your approach (which I dubbed Approach ). URL
Deferring 'till the week of 8/19 as some folks are on vacation.
I support this change on behalf of the URL project.
8192 characters in length that fits the regular expression of a distinguished name. What is the "regular expression of a distinguished name"?
I do understand the intent, but it would seem that distinguished name is not clearly going to have a specific reference we can use. That reference sets aside the regex requirement. I understand the need but there is some assorted LDAP RFCs and other attempts, but none seem to be the right kind of reference, even if about distinguished names in X.509. I am going to propose we go back to what we know and then put forward my understanding and interpretation of the requirement, that we want a StringOrURI like the underlying CWT requires, perhaps with added length requirements?
LGTMLGTM Hello, Last week I attempted to pick up some issues thanks to the many contributions by Hannes Tschofenig. One such issue requesting clarification or change is issue . For that, I made an associated PR, pull request . URL URL So far there has only really been feedback from Corey Bonnell (and that has been most appreciated!). I wanted to poll the list for feedback and understand if there is consensus on using the X.509 Distinguished Name for the issuer of the claim, whether or not there is a clear regex and length requirement. The current text reads like so. characters in length that fits the regular expression of a distinguished name. https://ietf-wg-URL I see a few ways forward. Do nothing, leave the current statement in the specification as-is, and close the issue reported by Hannes as a WONTFIX because it is good enough. Keep the Distinguished Name, and add a useful regex from a relevant LDAP specification proposed by Corey in his comment, RFC4514. Adapt the requirement to match a subset of the underlying data type of the CWT claim iss field, URI (from stringOrUri), and not add an additional requirement for DN regexes and format parsing. Be most permissive and interoperable, remove this requirement entirely. Corey appears to support 2 (please correct me if I am misrepresenting your position, Corey), whereas I prefer 3.
Code change:
Support for "kid" in the protected header and "x5chain" in the unprotected header is OPTIONAL to implement. <del> When "x5t" is present, "iss" MUST be a string with a value between 1 and 8192 characters in length that fits the regular expression of a distinguished name. </del> <ins> When "x5t" is present, "iss" MUST be a string that meets URI requirements defined in RFC8392.  The "iss" value's length MUST be between 1 and 8192 characters in length. </ins> 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: I understand the intent of further constraining iss in the presence of X.509 certains and checking against their thumbprint. It makes it more convenient and consistent for the case of Issuers creating Signed Statements with X.509 certificates as a first class solution, but at the expense of the alternatives (short-term and long-term) and resulting interoperability in the long-term. Additionally, the requirement as-is appears to adapt the CWT field to match a differing purpose from its base specification that key use in the context of SCITT. To me, that seems undesirable. Do others have support for one of these positions or related feedback that motivated the current state of the change? Given the feedback over the next week, I will modify or close PR accordingly to meet consensus of authors and WG members who respond on list to the best of my ability. Sincerely, A.J. Stein
Code change:
are associated with, and the modifications these parameters make to the component value.  Definitions of parameters MUST define the targets to which they apply (such as specific field types, derived <del> components, or contexts) and any incompatibilities with other parameters known at the time of definition.  Initial values for this registry are given in iana-component-param-contents.  Future assignments and modifications to existing assignments are to be made through the Expert Review registration policy RFC8126 and shall follow the template presented in iana-component-param-template. </del> <ins> components, or contexts).  Initial values for this registry are given in iana-component-param-contents.  Future assignments and modifications to existing assignments are to be made through the Expert Review registration policy RFC8126. The DE is expected to ensure that the name follows the template presented in iana-component-param-template, including that the length of the name is not excessive while still being unique and recognizable for its defined function.  The DE is expected to ensure that the definition of the field sufficiently defines any interactions incompatibilities with other existing parameters known at the time of the registration request.  If the parameter changes the component value, the DE is expected to ensure that the component value defined by the component identifier with the parameter applied can be deterministically derived from the target HTTP message. </ins> 6.5.1.

Related discussion:
text: Comment by NAME I would suggest being explicit about the meaning of "active" and especially "deprecated": these are terms everywhere in RFCs (I am aware), but sometimes they are open for interpretation, and we keep discussing their meaning. It would be good to avoid that situation from this doc.
Comment by NAME The new registries do not have any guidance for the designated experts as to what registrations should be accepted or denied (conformance with template, point squatting, availability of reference specification, etc). See of RFC8126: The required documentation and review criteria, giving clear guidance to the designated expert, should be provided when defining the registry. It is particularly important to lay out what should be considered when performing an evaluation and reasons for rejecting a request.