jiebi/CodeConvo huggingface dataset:
Code change:
different structure; see informational. Fields in the header and trailer sections consist of a length- <del> prefixed name and length-prefixed value.  Both name and value are sequences of bytes that cannot be zero length. </del> <ins> prefixed name and length-prefixed value; see fields. </ins> The format allows for the message to be truncated before any of the length prefixes that precede the field sections or content.  This

Related discussion:
text: by using a citation rather than a redundant and wrong statement. by removing the minimum length (zero is totally fine).
The Known-Length Messages section states that whereas the Header and Trailer Field Lines section allows empty field values. Which is it?
Editorial error on my part. Someone pointed out that fields can have empty values (yet another feature of the protocol that is weird and unnecessary). I fixed it one place, but not the other. Thanks for noticing.
The draft currently shows: This Length field isn't well defined. Is it the length of the Known-Length Field Section in bytes or in lines? If in bytes, does it include or exclude the length of the Length field itself? Either way, I don't understand why Length is at least 2. Either it's possible for there to not be any field lines, in which case maybe it should be zero. And if there needs to be at least one field line, then (we should say so, and) the minimum number should be 3, because a field line is two lengths and at least one byte of field name.
To pile on here, the spec also says in one place and in another It's a little ambiguous but f the value also can't be zero-length, then the minimum should be 4? (by David's second interpretation)
NAME see
Yeah saw that after hitting the button. Didn't intend to derail
Thanks!
Code change:
Response: <ins> 2.2.4.1. </ins> If the Signed Statement requested is already included in the Append- Only Log: <del> If the Signed Statement requested is not yet included in the Append- Only Log: </del> <ins> 2.2.4.2. If registration of the Signed Statement requested is in progress but not yet included in the Append-Only Log: 2.2.4.3. If the Signed Statement requested is neither registered in the log nor subject to an in-progress registration: 2.2.4.4. If a client is polling for an in-progress registration too frequently then the Transparency Service MAY, in addition to implementing rate- limiting, return a 429 response: 2.2.4.5. </ins> <del> Additional eventually consistent operation details MAY be present. Support for eventually consistent Receipts is implementation specific, and out of scope for this specification. </del> <ins> For all responses additional eventually consistent operation details MAY be present.  Support for eventually consistent Receipts is implementation specific, and out of scope for this specification. </ins> 2.2.5.

Related discussion:
text: Issue Exposes another issue with signed statement identifiers which is being fixed in a different PR.
LGTM
Code change:
This can be expressed as a binary message (type "message/bhttp") using a known-length encoding as shown in hexadecimal in ex-bink- <del> request.  ex-bink-request view includes some of the text alongside to show that most of the content is not modified. </del> <ins> request.  ex-bink-request includes text alongside to show that most of the content is not modified. </ins> This example shows that the Host header field is not replicated in <del> the :authority field, as is required for ensuring that the request is reproduced accurately; see H2. </del> <ins> the ":authority" field, as is required for ensuring that the request is reproduced accurately; see H2. </ins> The same message can be truncated with no effect on interpretation. In this case, the last two bytes - corresponding to content and a

Related discussion:
text: Moving normative language from Section 6 is the most useful, but there are a bunch of other stuff I noticed as I was reading through trying to implement James' other suggestion.
lgtm
Code change:
5.2.3. If DHCPv6 PD is available on the link, it is preferable to acquire a <del> prefix using DHCPv6 PD rather than generating a ULA prefix, because the DHCPv6-PD-provided prefix is routable at least on the local infrastructure.  Therefore, when DHCPv6-PD is available, the stub router MUST use DHCPv6 PD rather than its own prefix. </del> <ins> prefix using DHCPv6 PD rather than generating a ULA prefix.  Using a prefix provided by the infrastructure DHCPv6 prefix delegation service means (assuming the infrastructure is configured correctly) that routing is possible between the stub network links and all links on the infrastructure network, and possibly to the general internet. By contrast, if the prefix generated by the stub router is used, reachability is only possible between the stub network and the adjacent infrastructure link, because the OSNR prefix in this case is not known to the infrastructure network routing fabric.  So when the only prefix that is available is the one provided by the stub router, cloud services will not be reachable via IPv6, and infrastructure- provided NAT64 will not work.  Therefore, when DHCPv6-PD is available, the stub router MUST use DHCPv6 PD rather than its own prefix. </ins> 5.3.

Related discussion:
text: Added a bunch of clarifying text about why to use the DHCPv6 PD prefix, and also clarified the bits about NAT64 with respect to when to use Infrastructure-provided versus stub-router-provided NAT64.
See URL in the working group meeting in London, and in both cases, it seemed that the argument that without NAT64 we can't deliver on "device must always be able to connect to the internet if it is available" overrode the objections that were raised. So despite some folks really not loving it, I think it's required. Michael (IIRC) also pointed out that we need DHCPv6 PD to get infrastructure-provided NAT64 to work, which I guess means that if we have IPv4 and infrastructure-provided NAT64, but no DHCPv6 PD, we have to do NAT64 in the stub router. If we have v6-only, infrastructure-provided NAT64, and no DHCPv6 PD, then in order to reach the internet, we'd need NAT66. I'm inclined to declare this situation out of scope, because (A) I really don't want to do NAT66, and (B) I think it's not a likely scenario at the moment, and the more devices out in the field that would break in this situation, the better.
Code change:
I-D.ietf-oauth-selective-disclosure-jwt. The three-party-model, i.e., actors, Verifiable Credentials and <del> Verifiable Presentations, are further described in VC-DATA.  However, this specification focuses on a specific version of the three-party- model which can have different features but will provide a representation of the model described in VC-DATA. </del> <ins> Verifiable Presentations, is also described in VC-DATA.  However, this specification provides a specific format of Verifiable Credentials which deviates from the format described in VC-DATA to create Verifiable Credentials based on SD-JWT and JSON payloads but a translation algorithm is provided in this specification. </ins> 1.2.

Related discussion:
text: As agreed on the editor's call (5/23), the following ... should become ...
I'm still confused why we need this text at all. What people will basically get is "this spec deviates from the VCDM 2.0".
Code change:
A response that contained a response header: Would specify matching any document request for a URL with a path <del> prefix of /product/ on the same Origin as the original request. </del> <ins> prefix of /product/ on the same Origin RFC6454 as the original request. </ins> 2.1.5.2.

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:
9. <del> Browser-based apps are are clients that run in a web browser, typically written in JavaScript, also known as "single-page apps". These types of apps have particular security considerations similar to native apps. </del> <ins> Browser-based apps are clients that run in a web browser, typically written in JavaScript, also known as "single-page apps".  These types of apps have particular security considerations similar to native apps. </ins> TODO: Bring in the normative text of the browser-based apps BCP when it is finalized.

Related discussion:
text: cb2616f30c91b68b99f8eb492cce400bf394bc08 - Removes a duplicate "are".
Code change:
The unauthenticated channel between the Initiating Device and Authorization Device allows attackers to obtain a QR code or user <del> code in one location and display in another location.  Establishing proximity between the location of the Initiating Device and the Authorization Device limits an attacker's ability to launch attacks by sending the user or QR codes to large numbers of users across the globe.  There are a couple of ways to establish proximity: </del> <ins> code in one location and display it in another location. Consequently, proximity-enforced cross-device flows are more resistant to Cross-Device Consent Phishing attacks than proximity- less cross-device flows.  Establishing proximity between the location of the Initiating Device and the Authorization Device limits an attacker's ability to launch attacks by sending the user or QR codes to large numbers of users that are geographically distributed.  There are a couple of ways to establish proximity: </ins> Depending on the risk profile and the threat model in which a system is operating, it may be necessary to use more than one mechanism to

Related discussion:
text: See
I have trouble explaining why scanning a QR code is dangerous to initialize authentication flows to gain access because sometimes it is less dangerous. When using a device which is close proximity to the second device and forcing this through a protocol, the danger is reduced. I think introducing a new wording context would help (especially if this was used in the corresponding protocols, for example FIDO2 passkeys) Near device A device which is in close proximity to the second device and uses a protocol which forces a close proximity communication channel for the authentication steps. Cross device A device which communicates to a separate device and uses a protocol which does not force proximity to the second device. Then it would be easy to explain attacks and mitigations: Using a near device communication, the attack X is not possible etc. Not sure this is the right place to add this, but it would help I think.
That's and interesting idea. To me it is more about cross-device protocol properties. Some of them have strong proximity assurance properties, and some don't. Perhaps terminology like "proximity verified cross-device flows" or "proximity enforced cross device flows" vs "proximity-less cross device flows" works better? It is also somewhat protocol neutral.
I like these two: "proximity enforced cross device flows" vs "proximity-less cross device flows"
Let me think about how to work that terminology into the text at the right places.
Code change:
guess.  The salt value MUST then be encoded as a string.  It is RECOMMENDED to base64url-encode the salt value. <del> The issuer MUST build the digests by hashing over a string that is formed by JSON-encoding an ordered array containing the salt and the claim value, e.g.: </del> <ins> The issuer MUST build the digests by hashing over a JSON literal according to RFC8259 that is formed by JSON-encoding an object with the following contents: The following is an example for a JSON literal without claim name blinding: </ins> <del> . The digest value is then base64url-encoded.  Note that the precise JSON encoding can vary, and therefore, the JSON encodings MUST be sent to the holder along with the SD-JWT, as described below. </del> <ins> The following is an example for a JSON literal with claim name blinding: IMPORTANT: JSON encoding according to RFC8259 allows for white space characters and other variations in the encoded representation.  To ensure that issuer and verifier produce the same hash digest, the issuer therefore sends the JSON literal to the holder along with the SD-JWT, as described below. The claim contains an object where claim names are mapped to the respective digests.  If a claim name is to be blinded, the digests MUST contain the key as described above and the claim name in MUST be replaced by a placeholder value that does not leak information about the claim's original name.  The same placeholder value is to be used in the SVC and SD-JWT-R described below. </ins> 5.1.1.1.

Related discussion:
text: Spec text updated, please review!
George during OAuth side mtg pointed out that it is important for the verifier not to change anything in the JSON object in the Release (ie SVC )that is being hashed so that the hash output is the same from the one in SD-JWT
Code change:
A cache that implements partial responses to range requests, as defined in field.range, also needs to evaluate a received <del> header field (field.if-range) regarding its selected stored response. </del> <ins> header field (field.if-range) with respect to the cache's chosen response. </ins> When a cache decides to forward a request to revalidate its own stored responses for a request that contains an

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:
4.3.2. <del> The Verifier MUST ensure that the key with which it validates the signature on the Key Binding JWT is the key specified in the SD-JWT as the Holder's public key.  For example, if the SD-JWT contains a </del> <ins> Whether to require Key Binding is up to the Verifier's policy, based on the set of trust requirements such as trust frameworks it belongs to.  See key_binding_security for security considerations. If the Verifier requires Key Binding, the Verifier MUST ensure that the key with which it validates the signature on the Key Binding JWT is the key specified in the SD-JWT as the Holder's public key.  For example, if the SD-JWT contains a </ins> value with a member, the Verifier would parse the provided JWK and use it to verify the Key Binding JWT. <del> Whether to require Key Binding is up to the Verifier's policy, based on the set of trust requirements such as trust frameworks it belongs to.  See key_binding_security for security considerations. </del> <ins> Details of the Validation process are defined in verifier_verification. </ins> 5.

Related discussion:
text: should prob add something in history just for posterity - even just a -14 with a "stuff from WGLC part deux"
Code change:
defining new methods, status codes, or fields (see HTTP). Extensions are permitted to use new FrameHeader, new SETTINGS, or new <del> ErrorCodes.  Registries are established for managing these extension points: iana-frames, iana-settings, and iana-errors. </del> <ins> ErrorCodes.  Registries for managing these extension points are defined in RFC7540. </ins> Implementations MUST ignore unknown or unsupported values in all extensible protocol elements.  Implementations MUST discard frames

Related discussion:
text: As noted in , we don't need to redo these. A backward reference will do. This cuts quite a bit of XML out of the document, which I'm happy about.
NAME I disagree; IANA hold the registration data, not the document. My understanding is that templates need only appear in the originally registering documents; if there's doubt about that, we should check with the IESG and IANA.
That is true, but the registrations point to specs. The IANA Considerations need to take care of updating these references.
That's a good point; I will shelve that and change to adding a note that says "references to RFC 7540 for X, Y, and Z are updated to point to this document".
Absolutely. It just doesn't need to list them individually; a simple statements such as "update the references to RFCxxxx to this document in Registry Foo" will suffice.
If that's all which is necessary, yes. Hint: section numbers might change, and you don't want to handle that during AUTH48.
The current IANA Considerations for H2 bis has several requests to IANA that seem to be appropriate for the original document, but not a bis now that the registries are already filled out. Shouldn't these be reworded to say "this document updates..." or explain that the references for registries should point to this document, rather than the old RFC?
I don't think this is a good idea. At the end of the day, the IANA registry should point to the updated document.
Code change:
Note: Examples in this document use the <del> Claim defined in RFC7800 to include the raw public key by value in </del> <ins> claim defined in RFC7800 to include the raw public key by value in </ins> SD-JWT. 5.10.

Related discussion:
text: update: agreed to replace SD-JWT VC example with PID. agreed to have only one sd-jwt vc example, so this will also address and
The and the editor's draft didn't get generated - URL 404s
fixed - thank you, Brian!
NAME Binding design and the usage of biometrics data is based on your original PR 210. Shall we replace 4a example with this one? But if you don’t see the need for this example anymore, I am not going to die on this hill.
Thinking about this just a little more NAME does this warrant a doc history bullet? Something like: Replaced the general SD-JWT VC example with one based on Person Identification Data (PID) from the European Digital Identity Wallet Architecture and Reference Framework The history is nice to have and I often use it as a starting place when making "what's changed from last time" type slides for f2f meetings.
I'm just gonna add the doc history to keep things moving here... and done w/ 08d70d2fbfcb1afce5e2d088cb97934b91ce83a1
relevant section in the editor's copy preview: URL should anyone want to take a look before the coming soon merge NAME NAME @ etc
I think this is ready to merge (for real this time). It's kinda awkward process and numbers wise with Dr. out. And peppelinux is still listed as requesting changes but I think his comments were addressed. But I think it's good to go. Approved with two pendings suggestioni/change request and a general comment that's not relevant for the revision but Just informative
Code change:
transfers to only those changed during the specified window. An origin server that receives an If-Modified-Since header field <del> SHOULD evaluate the condition prior to performing the method (evaluation).  The origin server SHOULD NOT perform the requested </del> <ins> SHOULD evaluate the condition as per evaluation prior to performing the method.  The origin server SHOULD NOT perform the requested </ins> method if the selected representation's last modification date is earlier than or equal to the date provided in the field value; instead, the origin server SHOULD generate a

Related discussion:
text: this is the part of URL related to -semantics
Continueing the discussion from URL Looking at the next text in context: To me it's unclear why we are calling out bare CR here, isn't the situation the same for LF and CRLF?? This also is not a new requirement, the ABNF does not allow CR and friends in field-value, and in 3.2 we say "A sender MUST NOT generate protocol elements that do not match the grammar defined by the corresponding ABNF rules." The subsequent paragraph talks about whitespace, and it may not be clear to everyone which characters we are referring to here (not the ones listed in Section 1.2.1 "Whitespace", correct?)
Proposal:
NAME ?
(forked from )
A bit iffy given the sentence above it, but okay.
Code change:
1. "Bootstrapping WebSockets with HTTP/2" RFC8441 defines an extension <del> to HTTP/2 HTTP/2 that is also useful in HTTP/3 HTTP/3.  This extension makes use of an HTTP/2 setting.  HTTP/3 gives some guidance on what changes (if any) are appropriate when porting settings from HTTP/2 to HTTP/3. </del> <ins> to HTTP/2 HTTP2 that is also useful in HTTP/3 HTTP3.  This extension makes use of an HTTP/2 setting.  HTTP3 gives some guidance on what changes (if any) are appropriate when porting settings from HTTP/2 to HTTP/3. </ins> 2.

Related discussion:
text: NAME I think I did the needful here by cargo-culting . Does this look good to you?
Thanks for the suggestions!
(not tested, but if it ends generating the desired output...)
Code change:
changes that were partially applied, and then automatically retrying the requests that failed. <del> Some clients use weaker signals to initiate automatic retries.  For example, when a POST request is sent, but the underlying transport connection is closed before any part of the response is received. Although this is commonly implemented, it is not recommended. </del> <ins> Some clients take a riskier approach and attempt to guess when an automatic retry is possible.  For example, a client might automatically retry a POST request if the underlying transport connection closed before any part of a response is received, particularly if an idle persistent connection was used. </ins> A proxy MUST NOT automatically retry non-idempotent requests.  A client SHOULD NOT automatically retry a failed automatic retry.

Related discussion:
text: to clients that attempt to guess (editorial)
I have no idea what this is trying to say and it is 1.1-specific. I suggest we delete it.
It was added as part of URL, adressing .
How about
May end up encouraging this kind of implementation, by providing an example here ... ? Maybe just leave this as "Some clients take a riskier approach and attempt to guess when an automatic retry is possible because the original request may not have been received by the server." ....
I don't see any problem with the original text, but NAME your replacement is fine too (although the second sentence is a fragment).
How about