jiebi/CodeConvo huggingface dataset:
Code change:
Implementers ought to provide mechanisms and policies to control how and when such hints are advertised.  For example, they could require <del> origin opt-in; restrict delivery to same origin subrequests; limit delivery to requests that already carry indentifying information (e.g. cookies); modify delivery policy when in an "incognito" or a similar privacy mode; enable user configuration and opt in, and so on. </del> <ins> origin opt-in via Accept-CH; clear remembered opt-in, as set by Accept-CH-Lifetime, when site data, browsing history, browsing cache, or similar, are cleared; restrict delivery to same origin subrequests; limit delivery to requests that already carry identifying information (e.g. cookies); modify delivery policy when in an "incognito" or a similar privacy mode; enable user configuration and opt in, and so on. </ins> 6.

Related discussion:
text: and .
Looks good overall. changes the semantics of . Not only does it effectively put on subsequent responses from the same origin for the given lifetime, it also suggests that Client Hints should be added to requests to that origin, no matter where the requesting page has come from. Not a problem, but right now it's conveyed almost as an aside. This needs to be clearly specified so it isn't missed / misunderstood.
NAME updated, PTAL.
Thanks Mark!
This is better.
Code change:
6.1.1.1. AUTHORIZATION INFO parameter (Parameter Type 0x02) identifies a <del> track's authorization information in a SUBSCRIBE, SUBSCRIBE_ANNOUNCES or ANNOUNCE message.  This parameter is populated for cases where the authorization is required at the track level.  The value is an ASCII string. </del> <ins> track's authorization information in a SUBSCRIBE, SUBSCRIBE_ANNOUNCES, ANNOUNCE or FETCH message.  This parameter is populated for cases where the authorization is required at the track level.  The value is an ASCII string. </ins> 6.1.1.2.

Related discussion:
text: Individual Comment: lgtm
I don't have a strong opinion, but why not MAXCACHEDURATION?
Section 6.1.1 has not been updated to reflect the 2 new messages with parameters.
I don't have a strong preference. Mind writing up a PR of whatever you think is a sensible proposal?
I don't have any preference at all, but I can do a straw man.
I can think of AuthInfo as the only parameter that makes sense for now. NAME please let me know if you think of anything else. I can add it to my PR. Thanks
Thanks, this should have been added originally.
Code change:
5.1.2.2. <del> When entering this state, if the router MUST discontinue treating the interface as an Advertising Interface as described in RFC4861, if it has been doing so. </del> When a new host appears on the AIL and sends an initial router solicit, if it does not receive a suitable on-link prefix, it will not be able to communicate.  Consequently, the stub router MUST

Related discussion:
text: Closing issue This PR is not building, so need to clean it up before commit. Comments appreciated during that process.
NAME PR is still needed before anything can build ;-)
NAME NAME sorry I didn't intend to close this PR, Github did that somehow after me pushing to the branch. But it's good to have this one closed and replaced by , because the merge direction was specified here the wrong way around. The build is now fixed in the branch and also updated to make it merge-able into main. I prefer to merge rather sooner than later - nits can be corrected with future PRs easily.
Code change:
<del> Selective Disclosure for JWTs (SD-JWT) </del> <ins> SD-JWT: Selective Disclosure for JWT and JWS with JSON payloads </ins> draft-ietf-oauth-selective-disclosure-jwt-latest Abstract <del> This document specifies conventions for creating JSON Web Token (JWT) documents that support selective disclosure of JWT claims. </del> <ins> This specification defines a mechanism for selective disclosure of individual elements of a JSON object used as the payload of a JSON Web Signature (JWS) structure.  It encompasses various applications, including but not limited to the selective disclosure of JSON Web Tokens (JWT) claims. </ins> 1. <del> The JSON-based RFC8259 representation of claims in a signed JSON Web Token (JWT) RFC7519 is secured against modification using JSON Web Signature (JWS) RFC7515 digital signatures.  A consumer of a signed JWT that has checked the signature can safely assume that the </del> <ins> This document specifies conventions for creating JSON Web Signature (JWS) RFC7515 structures with JSON RFC8259 objects as the payload while supporting selective disclosure of individual elements of that JSON.  Because JSON Web Token (JWT) RFC7519 is a very prevalent application of JWS with a JSON payload, the selective disclosure of JWT claims receives primary treatment herein.  However, that does not preclude the mechanism's applicability to other or more general applications of JWS with JSON payloads. The JSON-based representation of claims in a signed JWT is secured against modification using JWS digital signatures.  A consumer of a signed JWT that has checked the signature can safely assume that the </ins> contents of the token have not been modified.  However, anyone receiving an unencrypted JWT can read all the claims.  Likewise, anyone with the decryption key receiving encrypted JWT can also read

Related discussion:
text: Honestly, I'm not sure about this one. But I said I'd put together a PR for with an update to the title and some qualifying text. So this is that PR as something to discuss anyway. At least these few sentences took me an embarrassingly long time to write :/
Code change:
use is unavoidable, keys MUST NOT sign any other message that may be verified as an Envelope as part of a Signed Statement. <ins> Each of these functions MUST be carefully protected against both external attacks and internal misbehavior by some or all of the operators of the Transparency Service. For instance, the code for the Registration Policy evaluation and endorsement may be protected by running in a Trusted Execution Environment (TEE). The Transparency Service may be replicated with a consensus algorithm, such as Practical Byzantine Fault Tolerance (pBFT PBFT) and may be used to protect against malicious or vulnerable replicas. Threshold signatures may be use to protect the service key, etc. </ins> 9.1. SCITT provides the following security guarantees:

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:
VCHAR H <ins> Header Fields Age Cache-Control Expires Pragma Warning </ins> heuristic expiration time heuristically cacheable

Related discussion:
text: This is related to issue On the flight back from Switzerland, I spent time looking at the cache directives and how they differ from the descriptions in RFC2616. I worked out these problems and drafted a pull request, but I haven't checked whether we changed these deliberately for RFC7234, or if the distinctions just got lost in the rewrite. In any case, I think this is an improvement, but definitely needs reviews.
This ended up being an editorial change between drafts because the only normative changes were already noted for and , and this is just rewording what we had for .
From : Both state that a (depending on context private, shared or both types of) "cache MAY store the response and reuse it for later requests, even if the response would normally be non-cacheable". To my understanding, this does not intend to override the requirements from the "Storing Responses in Caches" section (URL) altogether. Instead, I would assume that it only refers to the condition "has a status code that is defined as heuristically cacheable" in that section (or, as it was stated in RFC7234, "has a status code that is defined as cacheable by default")? Would it make sense to amend the list of conditions in that section, appending to the "the response either..." second-level list: "contains a private response directive if the cache is not shared"?
OP here
lists some directives that allow responses with Authentication to be stored, but some of those directives' definitions do not mention this.
I think this should also be added for ; see .
I think this issue needs to be reopened and the specification text reverted to something more like what was in RFC2616. That spec specifically requires public be present to allow responses to a request with Authorization to be stored by a shared cache, regardless of must-revalidate or proxy-revalidate. This is not implied by those other directives.
Code change:
Digest coverage for either the resource's "representation data" or "selected representation data" communicated via HTTP. <del> Support for multiple digest algorithms. </del> <ins> Support for multiple digest-algorithms. </ins> Negotiation of the use of digests.

Related discussion:
text: is preliminary to Consistently use instead of . In case we need to further focus on the value, we can say or . Looking at "content-coding" vs "content coding" in URL I think that this choice makes the document more readable.
Code change:
Digest Algorithm: sha-256 Description: The SHA-256 algorithm RFC6234.  The output of this <del> algorithm is encoded using the base64 encoding RFC4648. </del> <ins> algorithm is encoded using base64 RFC4648. </ins> Reference: RFC6234, RFC4648, this document.

Related discussion:
text: There's not really any reason to describe anything other than the algorithm used and the format of encoding.
From NAME WGLC review This seems like cruft. The important things for the table are clear pointers to the algorithm definition and the encoding of values created by the algorithm.
If it's not broken, don't fix it :P I think we spent too much time wrt old algorithms. I'm in favor of anyone that wants to provide a PR that has consensus.
It is broken -- let's fix it. :)
LGTM
Code change:
9.2. <del> The permanent message header field registry (see RFC3864) needs to be updated with the following registration: </del> <ins> The permanent message header field registry (see HttpFieldNameRegistry) needs to be updated with the following registration: </ins> Set-Cookie

Related discussion:
text: Updates some out of date portions of the IANA considerations section. See for more info
NAME Ping
NAME Ping
Some aspects of the IANA considerations section are outdated and should be updated: The “Cookie” and “Set-Cookie” registrations from RFC 6265 have been moved from the “Permanent Message Header Field Names” registry to the “HTTP Field Name Registry” Update Sections 9.1 (Cookie) and 9.2 (Set-Cookie)The word "Registry" should be omitted from registry names. Update Section 9.3 (Cookie Attribute Registry)
LGTM. Apologies I missed this.
Code change:
9.2. <del> The permanent message header field registry (see RFC3864) needs to be updated with the following registration: </del> <ins> The permanent message header field registry (see HttpFieldNameRegistry) needs to be updated with the following registration: </ins> Set-Cookie

Related discussion:
text: Adds suggestions for how servers could fulfill the requirement Adds suggestion that servers be mindful of the number and size of the cookies they set to avoid hitting their own header length limits. Also mention that UA should consider splitting longer fields.
If that's the case, I'd recommend punting on getting this in 6265bis - which has had a goal of documenting reality.
It is not unusual for servers to reject HTTP requests that contain individual headers longer than a certain limit. If a client sends a header longer than around 8-9K bytes, the risk is quite large that it will get a 40x response back which effectively blocks the client from continuing what it is set out to do. Because of the rather complicated results of such a "too long" cookie header, I think it could be worth mentioning this in the spec. For newcomers in cookie land, this is perhaps not completely obvious. The spec currently mentions size-limits per cookie, but a server can easily send a few large cookies and have the combined size of them outgrow 8K. I would perhaps suggest wording that says a client SHOULD keep its lines shorter than NNN bytes and servers SHOULD accept cookie lines up to at least NNN bytes. (in curl we have the limit set to 8190 bytes) HTTP related specs rarely speak of this kind of size limits, but I know my implementation could have avoided some issues if this real-world limit had been mentioned.
Seems like a worthwhile warning to me.
RFC 6265 had a requirement that a client MUST generate a single cookie header. HTTP/2 and HTTP/3 allow "cookie crumbling" that permits multiple Cookie headers. 6265bis says in URL What is tolerance really? Why are we stating MUST requirement that are immediately invalidated by two of the versions of HTTP in wide usage? Section 5 is huge, what requirement is the text in section 4.2 forward referencing to? I think there's some room for improvement in this area. An HTTP/2 or HTTP/3 is being instructed as a MUST requirement in the relevant RFCs to combine multiple cookie headers into one e.g. URL but if the server MUST be tolerant to multiple Cookies, maybe we can relax the HTTP/2 or HTTP/3 requirements?
This was the output of the discussion in URL
Thanks Mike, I missed that discussion first time around.
Code change:
9.2. <del> The permanent message header field registry (see RFC3864) needs to be updated with the following registration: </del> <ins> The permanent message header field registry (see HttpFieldNameRegistry) needs to be updated with the following registration: </ins> Set-Cookie

Related discussion:
text: My question comes about because of some HTTP/2 code I looked at that simply implements HTTP/2 and so combines the multiple fields back into one. But as NAME and NAME alluded to their comments on , the splitting could be done for some reason thst isn't purely about H2 or H3 compression optimization. It seems there are actually use cases where keeping the split is useful, and not just in a private deployment. Of course relaxing things more might have unintended consequences. I find the current text too terse to be useful. This is a cookie spec, it seems like the right place to ba adding commentary about how to handle cookies across various version and conversions. Especially some anecdotal examples about why some clients actually do it.
Mentioning why a server should be tolerant, and what shape that could take, seems reasonable to me. Especially given how nicely it dovetails with . What forward reference are you referring to? ?
In that mention, I think it's worth including that re-combining the Cookie lines before passing to the next layer is a form of tolerance from the client's perspective.
Some more text sounds good and I'm happy to review. In Section 4.2.1:
Still LGTM, thanks!
Code change:
host on a locally reachable stub network can only interoperate with hosts on the network link(s) to which it is connected. <del> It may be noted that just as you can plug several CPEs together in series to form multi-layer NATs, there is nothing preventing the owner of a stub network router from plugging it into another stub network router.  In the case of an IoT wireless network, there may be no way to do this, nor would it be desirable, but a stub router that uses ethernet on both the infrastructure and stub network sides could be connected this way.  Nothing in this document is intended to prevent this from being done, but neither do we attempt to solve the problems that this could create. </del> <ins> It may be noted that just as you can plug several Home Gateway devices together in series to form multi-layer NATs, there is nothing preventing the owner of a stub network router from plugging it into another stub network router.  In the case of an IoT wireless network, there may be no way to do this, nor would it be desirable, but a stub router that uses ethernet on both the infrastructure and stub network sides could be connected this way.  Nothing in this document is intended to prevent this from being done, but neither do we attempt to solve the problems that this could create. </ins> The goal of this document is to describe the minimal set of changes or behaviors required to use existing IETF specifications to support

Related discussion:
text: The working group didn't actually agree on the use of the term "CPE Router", and there were substantive objections to it. I've used the term Home Gateway here, and included a definition that I think includes both ISP-provided routers with integrated uplink support (cable modem or DSL modem) and also includes routers where the WAN link is an ethernet connector. Not clear that this is correct, but hopefully it's evolving in the right direction.
Code change:
name in the "next-hop-aliases" list would be the name that ultimately resolved to one or more addresses. <del> The list of DNS names in "next-hop-aliases" use a comma (",") as a separator between names.  DNS names normally just contain alphanumeric characters and hyphens ("-"), although they are allowed to contain any character RFC1035, Section 3.1, including a comma.  To prevent commas or other special characters in names leading to incorrect parsing, any characters that appear in names in this list that do not belong to the set of URI Unreserved Characters RFC3986, Section 2.3 MUST be percent-encoded as defined in RFC3986, Section 2.1. </del> <ins> The list of DNS names in "next-hop-aliases" uses a comma (",") as a separator between names.  Note that if a comma is included in a name itself, the comma must be encoded as described in encoding. </ins> For example, consider a proxy "proxy.example.net" that receives the following records when performing DNS resolution for the next hop

Related discussion:
text: The "" set includes ".", but we actually need to escape "." to avoid attacks.
Hm, my impression is that this attack is about making a period within a label look like a label separator. By the time that you have a string for a name, it would already need this kind of escaping done. Put another way, the "." characters we have in the string are indeed label separators already.
The draft doesn't specify how to construct the DNS name string (and in general there is not a great specification for this). The most common convention (noted in RFC 1035 Section 5.1) is to precede "." inside a label with a backslash. This draft would then percent-escape the backslash, but not the ".", so there would indeed be a "." character that is not a label separator in the final header field value. Whatever escaping convention you choose, this is sufficiently non-obvious that I think a very clear specification and some examples are probably in order. (This whole rigmarole is normally not a problem because URIs are restricted to contain only "hostnames", which cannot have weird characters in the labels.)
NAME can you look at URL
I realize that this is now resolved, but isn't it also possible that we could say "this field cannot be used to express names that include a literal period (".") in labels" ?
NAME yeah that’s an option, although it could theoretically incentivize using dots in labels as a way to hide the CNAME from being reported
Sure. But you can add another attribute called "this-site-is-abusing-this-mechanism" for use when that happens.
Code change:
algorithm without knowing whether the recipient supports the digest- algorithm, or even knowing that the recipient will ignore it. <ins> Examples: </ins> ... 5.

Related discussion:
text: Adds id-sha-* algorithm examples throughout the document.
draft-ietf-httpbis-digest-headers includes examples of sha-256 in the Digest header value, but no examples of the two new algorithms it introduces: id-sha-256 and id-sha-512. Examples would be extremely useful to illustrate the difference between sha-256 and id-sha-256.
That sounds reasonable to me.
NAME WDYT?
Code change:
interoperability and was deprecated in a revision of HTTP/2 HTTP2. HTTP/2 retains these protocol elements in order to maintain wire compatibility (see HTTP2), which means that they might still be used <del> in the absence of alternative signaling, such as the scheme this document describes. </del> <ins> even in the presence of alternative signaling, such as the scheme this document describes. </ins> Many RFC 7540 server implementations do not act on HTTP/2 priority signals.

Related discussion:
text: Addresses Ea of Bob correctly highlights that absence of a replacement might not be the only condition under which the prior signals might be used. So lets be more accurate.
Thank you for the PR. Looks good.
Code change:
this attack since the Access Token may remain valid even after the Txn-Token has expired. <ins> 8.4. How requesting clients authenticate to the Transaction Token Service is out of scope for this specification.  However, if using the "actor_token" and "actor_token_type" parameters of the OAuth 2.0 Token Exchange specification, both parameters MUST be present in the request.  The "actor_token" MUST autenticate the identity of the requesting workload. </ins> 9. 9.1. <del> Some "req_ctx" claims may be considered personal information in some </del> <ins> Some "rctx" claims may be considered personal information in some </ins> jurisdictions and if so their values need to be obsfucated.  For example, originating IP address ("req_ip") is often considerd personal information and in that case must be protected through some

Related discussion:
text: Updated the text to more clearly profile the token exchange specification for use with Transaction Tokens.
In PR , the token exchange parameter is profiled to carry the purpose or intent of the transaction and its value is copied into the claim of the resulting Txn-Token. Is this how we want to handle the 'purp' claim?
I propose that the draft should allow value of the claim in the TraT request be independent of the claim in the TraT, because the requesting service may not know sufficient details about how the TraT is actually going to be used. For example, the requester may say the is "buy stock", whereas the claim could have a value like "equity trade"
Ok, so allow the TTS to transform the input scope to the appropriate value (if necessary). I'm ok with that.
Recommended change that the TTS MUST take the value of the parameter to determine the claim of the TraT.
Based on this feedback, the claim is being made REQUIRED.
Should we allow the use of and to be used as a means of client authentication for the Transaction Token Service? If not, should explicitly prohibit the use of these parameters in the profile of the Token Exchange spec.
Since RFC8693 (Token Exchange) refers to the as "A security token that represents the identity of the acting party", we should not use it in the TraT request. I thought we wanted to have some way to convey the inbound token to the TraT service, and that's why we were using , but that is inconsistent with RFC8693. I think we should neither require nor disallow the use of because some implementations may want that for client auth, and some implementations may want to do something else (e.g. mTLS) for client auth.
This is kind of what the spec says today. It's not required and up to the implementation. It is just referenced as an example. However, I'm fine removing the example and just being silent in the spec on the topic.
Recommendation to update example and be silent on use of and . Add a section to Security Considerations to talk about client authentication and add some non-normative examples.
Removed the additional text regarding possible client authentication methods and just left it that the client MUST authenticate itself to the Transaction Token Service and that the specific client authentication method is out of scope for this specification.