jiebi/CodeConvo huggingface dataset:
Code change:
3. HTTP authentication schemes can use the Authentication-Info response <del> header field to communicate additional information regarding the successful authentication. </del> <ins> header field to communicate information after the client's authentication credentials have been accepted.  This information can include a finalization message from the server (e.g., it can contain the server authentication). </ins> The field value is a list of parameters (name/value pairs), using the "auth-param" syntax defined in RFC7235.  This specification only

Related discussion:
text: Herve, could you please open an issue for this, so that we can assure that we track the underlying issue? It's OK to merge the proposal if the editor feels that it's helpful, but we need to make sure the WG gets consensus here. Thanks,
Linked to issue .
Code change:
header field.  The s-maxage directive also implies the semantics of the proxy-revalidate response directive. <del> The must-revalidate directive also has the effect of allowing a stored response to be used to satisfy a request with an Authorization header field; see caching.authenticated.responses. </del> <ins> The s-maxage directive also has the effect of allowing a stored response to be used to satisfy a request with an Authorization header field; see caching.authenticated.responses. </ins> This directive uses the token form of the argument syntax: e.g., 's-maxage=10' not 's-maxage="10"'.  A sender SHOULD NOT generate the

Related discussion:
text: pasted twice, second should have been s-maxage
The commit d4695a3e422f677d880dc64504c492bf71b6039d for added a paragraph to s-maxage that contains the directive must-revalidate. I think this was supposed to say s-maxage and worded for shared caches?
Sorry, been travelling. This was intentional (although I forgot to update the directive name). implies , which implies . That seems like a lot of indirection in the definition. I agree this wasn't a great way to do it, though. I think the options are: Leave it as is (i.e., two levels of indirection). Leave it as is, but use linking more explicitly so that the indirections can be followed more easily (at least in HTML renderings). Inline the appropriate text from into both and . I think those are ordered according to my preferences, least to most. (I strongly suspect many people don't realise has these semantics, because of it having a name similar to . Making them inline rather than referenced might help)
I agree with the conclusion, but am pretty sure that you meant to say s-maxage in that section defining s-maxage. That's all I changed, so it should be fine unless you wanted to add more text to explain why. I don't think it is necessary to explain more because adding s-maxage implies the server wants shared caches to reuse the response.
I agree with NAME that the additional semantics of are surprising. In particular due to section 4.2.1, comes disguised as the "different value for shared caches". So , and the difference is the handling of error cases like with ? Could you please try to explain why the additional semantics of make sense – that is, why did you not just make it the alternative TTL for shred caches? Thank you!
Ah, okay, so the added paragraph had the right directive before but simply doesn’t make any sense given the context.
Code change:
This document establishes a registry for HTTP/2 frame type codes. The "HTTP/2 Frame Type" registry manages an 8-bit space.  The "HTTP/2 <del> Frame Type" registry operates under either of the RFC8126 or RFC8126 policies. </del> <ins> Frame Type" registry operates under either of the "IETF Review" (RFC8126) or "IESG Approval" (RFC8126) policies. </ins> New entries in this registry require the following information:

Related discussion:
text: The code for the IANA policies in Section 11.1 looks like this: This document establishes a registry for HTTP/2 frame type codes. The "HTTP/2 Frame Type" registry manages an 8-bit space. The "HTTP/2 Frame Type" registry operates under either of the "IETF Review" or "IESG Approval" policies. That would be fine if that rendered as I would expect, as: Instead, it renders this way: That word ordering doesn't make sense. I'm not sure exactly what XML magic would be needed to produce the expected sentence order. Same thing occurs in Sections 11.2-4.
appears to fix only Section 11.1.
Code change:
the transport port in use is 80 or 443, <del> the URL scheme "http" or "https" is used, </del> <ins> the URI scheme "http" or "https" is used, </ins> the ALPN protocol ID RFC7301 generically identifies HTTP (e.g., "http/1.1", "h2", "h2c"), or

Related discussion:
text: This change switches from "URL" to "URI" specifically for two contexts: URI schemes URI syntax (It might be good to also add an explanation somewhere in the Introduction; I can make a proposal if needed)
It is a PR, no?
Weird, it didn't show the UX for PRs before, but does now. shrug
See URL
Code change:
other variants.  The Transparency Service is only required to support concise Receipts (i.e., whose size grows at most logarithmically in the number of entries in the Append-only Log) that can be encoded as <del> a COSE Signed Merkle Tree Proof. </del> <ins> a Signed Inclusion Proof. </ins> It is possible to offer multiple signature algorithms for the COSE <del> signature of receipts' Signed Merkle Tree, or to change the signing algorithm at later points.  However, the Merkle Tree algorithm (including its internal hash function) cannot easily be changed without breaking the consistency of the Append-only Log.  It is possible to maintain separate Registries for each algorithm in parallel but the Transparency Service is then responsible for proving their mutual consistency. </del> <ins> signature of receipts' Signed Inclusion Proofs, or to change the signing algorithm at later points.  However, the verifiable data structure cannot easily be changed without breaking the consistency of the Append-only Log.  It is possible to maintain separate Registries for each algorithm in parallel but the Transparency Service is then responsible for proving their mutual consistency. </ins> 5.2.3.1.

Related discussion:
text: This PR makes it clearer that merkle trees are not required, and what the structure of a receipt is.
Just to be clear, we very much appreciate the work on the cose merkle proof format and intend to use that by default where we can.
And also of course, LGTM
If you approved this PR, you should probably review and approve URL
NAME I added the changes from the IETF Hackathon, including the new statement-specific registration information in the receipt and the description of transparent statement verification algorithm. The examples will have to be aligned to the new CDDL
These improvements seem excellent... I would approve them, if I could, but I opened the PR.
NAME , can you please re-review your "requested changes" review
Merging as Henks comment was resolved
I also suggest we merge then work on the details. LGTM:+1:
Code change:
7.2.3. A literal header field never indexed representation causes the <del> emission of a header field without altering the header table.  It requires intermediaries to use the same representation for encoding this header field. </del> <ins> emission of a header field without altering the header table. Intermediaries MUST use the same representation for encoding this header field. </ins> A literal header field never indexed representation starts with the '0001' 4-bit pattern.

Related discussion:
text: I have written what I think is a slightly more robust Security Consideration for HPACK. This covers: the attack in the general sense, how the attack might apply in HPACK and HTTP, particular areas of concern, how HPACK inherently mitigates these attacks, what environments might need additional mitigation, and some suggested mitigation strategies. Mitigation strategies that I have described are: actor-based isolation (a generalized application of the origin isolation principle) destroy values on failed guesses (thanks here to Adam Barth for the idea), either probabilistically, or based on a count, with a recommendation that shorter values be made harder to guess specific protection for "special" header fields There are a few formatting changes in the first commit, sorry.
Code change:
This document establishes a registry for HTTP/2 error codes.  The "HTTP/2 Error Code" registry manages a 32-bit space.  The "HTTP/2 <del> Error Code" registry operates under the RFC5226. </del> <ins> Error Code" registry operates under the RFC8126. </ins> Registrations for error codes are required to include a description of the error code.  An expert reviewer is advised to examine new

Related discussion:
text: This is part of the fix for . This part removes the experimental range for frame types and settings. Also updates to use section references to RFC 8126, which replaces RFC 5226.
Nice clean change. No notes.
Code change:
6.2. There are many types of statements (such as SBOMs, malware scans, <del> audit reports, policy definitions) that issuers may want to turn into claims.  The issuer must first decide on a suitable format to </del> <ins> audit reports, policy definitions) that Issuers may want to turn into Claims.  The Issuer must first decide on a suitable format to </ins> serialize the statement, such as: - JSON-SPDX - CBOR-SPDX - SWID - CoSWID - CycloneDX - in-toto - SLSA

Related discussion:
text: NAME added security considerations and architecture picture
Thanks for the diagram, the sec-sec and all the other additional polish! I thought about tinkering with the diagram, but am in doubt that I'll improve it significantly. LGTM!
Code change:
verifiable cryptographic proof of endorsement of the signed envelope by the countersigner. <del> Compared with countersignatures on single COSE envelopes, - Receipts countersign the envelope in context, providing authentication both of the envelope and of its logical position in the authenticated data structure.  - Receipts are proof of commitment to the whole contents of the data structure, even if the Verifier knows only some of its contents.  - Receipts can be issued in bulk, using a single public- key signature for issuing a large number of Receipts. </del> <ins> Compared with countersignatures on single COSE envelopes, Receipts countersign the envelope in context, providing authentication both of the envelope and of its logical position in the authenticated data structure. Receipts are proof of commitment to the whole contents of the data structure, even if the Verifier knows only some of its contents. Receipts can be issued in bulk, using a single public-key signature for issuing a large number of Receipts. </ins> 1.1.

Related discussion:
text: The first change is to address the fact that the current .md renders correctly as bullet list on Github but not in other contexts such as URL
Code change:
return which service the Transparent Statement is registered on. In some scenarios, the Verifier already expects a specific Issuer and <del> Feed for the Transparent Statement, while in other cases they are not known in advance and can be an output of validation.  Verifiers MAY be configured to re-verify the Issuer's signature locally, but this requires a fresh resolution of the Issuer's DID, which MAY fail if the DID Document is not available or if the statement's signing key has been revoked.  Otherwise, the Verifier trusts the validation done by the Transparency Service during Registration. </del> <ins> Subject for the Transparent Statement, while in other cases they are not known in advance and can be an output of validation.  Verifiers MAY be configured to re-verify the Issuer's signature locally, but this requires a fresh resolution of the Issuer's DID, which MAY fail if the DID Document is not available or if the statement's signing key has been revoked.  Otherwise, the Verifier trusts the validation done by the Transparency Service during Registration. </ins> Some Verifiers MAY decide to locally re-apply some or all of the Registration Policies, if they have limited trust in the Transparency

Related discussion:
text: A note from the We'll be iterating on this a bit more, to create some use cases and examples for how feeds help producers and consumers benefit from SCITT.
See: URL There are several problems with this definition. It conflates using aggregations over an header parameter, with the header parameter. It confuses how the TS uses the attribute with how the uses the attribute (same problem as above). Suggested changes: Registration policies only apply to the feed identifier, they do not apply to the feed resource. See URL regarding the Transparency Service exposing the Feed Resource.
LGTM!LGTM
Code change:
2.7. An entity that entity that requests, checks and extracts the claims <del> from SSD-JWT-R (2.2) </del> <ins> from SD-JWT-R (2.2) </ins> Note: discuss if we want to include Client, Authorization Server for the purpose of ensuring continuity and separating the entity from the

Related discussion:
text: Some minor edits: consistency of hyphenation in base64url-encode(d) use transaction instead of use case in one place because selective might be needed or not within one use case, depending on the interaction with RP explicitly called out period character to avoid misinterpreting as missing word some typos
changed six . separated to four per Christian's separate comment
What did I miss? The presentation should be six dot separated elements. Three for the SD-JWT, three for the SD-JWT-R.
Why would you need to merge both? I don't understand the proposed flow between issuer, holder, and verifier; perhaps a data flow section would help. I would think the holder gets a 3+1 part JWS with SVC (which can be -concatenated). Then all you need to present to a verifier is the same data, along with some user proof key signature if the JWT is bound to a user key (for which a property is added in the SD-JWT-R, if I understood correctly; more details would be helpful here).
creating a separate issue on six vs four period separated elements to merge this editorial PR
LGTM
Code change:
disclosure (SD-JWT) which would enable sharing only subset of the claims included in the original JWT instead of releasing all the claims to every Verifeir.  This document also defines an optional <del> format for signatures called releases (SD-JWT-R). </del> <ins> format for signatures called SD-JWT Releases (SD-JWT-R). </ins> One of the common use cases of a signed JWT is representing a user's identity created by an issuer.  In such use case, there has been no

Related discussion:
text: Fixing the "release" in the sense of a defined term as "SD-JWT Release"
We have fixed the term and definitions but a few still appear in the main text. We need to fix them as well, hopefully before the first individual draft is uploaded. So, s/signatures called releases/signatures called SD-JWT Releases/ s/SD-JWTs and releases/SD-JWTs and SD-JWT Releases/ s/Verifying a Release/Verifying a SD-JWT Release/
Fixed with PR
Code change:
different ULA prefix each time it connects to a different infrastructure network. <del> If IPv6 prefix delegation is available, which implies that IPv6 service is also available on the infrastructure link, then the stub router MAY use IPv6 prefix delegation to acquire a prefix to advertise on the stub network, rather than allocating one out of its ULA prefix. </del> 5.2.3. <del> If DHCPv6 PD is available on the link, it is preferable to acquire a 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. </del> <ins> If IPv6 prefix delegation and IPv6 service is both available on the infrastructure link, then the stub router MUST attempt to acquire a prefix using DCHPv6 prefix delegation.  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. </ins> By contrast, if the prefix generated by the stub router is used, reachability is only possible between the stub network and the

Related discussion:
text: and 5.2.3: | Therefore, when DHCPv6-PD is available, the stub router MUST use DHCPv6 | PD rather than its own prefix. That's contradictory, I suppose 5.2.2 should say: | If IPv6 prefix delegation is available, which implies that IPv6 | service is also available on the infrastructure link, then the stub | router MUST use IPv6 prefix delegation to acquire a prefix to | advertise on the stub network, rather than allocating one out of its | ULA prefix. Or maybe just drop the last paragraph from 5.2.2 entirely. In my defence, I have been left unsupervised.
Code change:
The <del> of request-target is only used for CONNECT requests (CONNECT). </del> <ins> of request-target is only used for CONNECT requests (CONNECT).  It consists of only the and number of the tunnel destination, separated by a colon (":"). </ins> When making a CONNECT request to establish a tunnel through one or <del> more proxies, a client MUST send only the target URI's authority component (excluding any userinfo and its "@" delimiter) as the request-target.  For example, </del> <ins> more proxies, a client MUST send only the host and port of the tunnel destination as the request-target.  The client obtains the host and port from the target URI's component, except that the scheme's default port is sent if the target URI elides the port.  For example, a CONNECT request to "http://www.example.com" looks like </ins> 3.2.4.

Related discussion:
text: ... components, depending on the form of request-target, and when authority might be empty. This is an alternative to
In determining the request target, the following text is included after failing to find an authority in configuration, the authority form target, or the Host header: This is a security risk because it means that servers might not agree with clients about the identity of the resource that the request is directed to. This is especially bad as a TLS certificate is good for every port and often good for multiple names, which can mean a fairly large scope over which an attacker can exploit this confusion. The origin form description doesn't use 2119 language, it says "A Host header field is also sent", citing . And that section is a bit weaselly in that regard, using a "URL". If this were a "MUST ... unless" in -semantics, this problem would not exist (at least in theory). Just to confuse things, the absolute-form says , which might be read to imply that Host truly is mandatory: The asterisk-form is the only other option that naturally lacks an authority, and that says nothing, so that might be fixed up similarly.
Keep in mind that the first text is what to do when receiving a message without Host or absolute-form, whereas the other texts are requirements on generation. Yes, it is a security risk to not send Host, and I assume it would be one to provide service for an https resource without verifying that the client's request indicates one of the server's host (somehow). So, PR welcome, but the final text still needs to accept non-TLS HTTP/1.0 requests without a Host (for ass-backwards reasons).
BTW, the reason it says SHOULD here instead of MUST is because this requirement about the ordering of fields in the header section, not about whether or not Host needs to be sent.
OK, that's good. It's not a genuine problem, we just need to be clearer about generation requirements (and we might be able to carefully condition the inclusion of a default).
better again
Code change:
The <del> of request-target is only used for CONNECT requests (CONNECT). </del> <ins> of request-target is only used for CONNECT requests (CONNECT).  It consists of only the and number of the tunnel destination, separated by a colon (":"). </ins> When making a CONNECT request to establish a tunnel through one or <del> more proxies, a client MUST send only the target URI's authority component (excluding any userinfo and its "@" delimiter) as the request-target.  For example, </del> <ins> more proxies, a client MUST send only the host and port of the tunnel destination as the request-target.  The client obtains the host and port from the target URI's component, except that the scheme's default port is sent if the target URI elides the port.  For example, a CONNECT request to "http://www.example.com" looks like </ins> 3.2.4.

Related discussion:
text: In 3.2.3. authority-form it says Whereas it needs to specifically require host:port, as in the definition of :
does this merit a change log entry?
Code change:
14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <ins> This specification uses the terms "access token", "authorization server", "authorization endpoint", "authorization request", "client", "protected resource", and "resource server" defined by The OAuth 2.0 Authorization Framework RFC6749. </ins> 2. The following is an end-to-end sequence of a typical step-up

Related discussion:
text: changes/clarifications from Httpdir telechat review URL Thank you for the review Mark. I've replied inline below with some context or explanation as best I can. And I'll put together a PR with corresponding changes/clarifications. mechanism. Rather the intent is to provide a new error code and two new parameters for the "Bearer" authentication scheme challenge from RFC6750 (and other OAuth schemes like "DPoP" that use the RFC6750 challenge params). for the Bearer authentication scheme challenge defined by [RFC6750] not the WWW-Authenticate response header in general. RFC6749 and used throughout the OAuth family of specs providing useful context and disambiguation for OAuth roles and functionality etc. I agree with Aaron about adding a terminology paragraph to the draft to make it more explicit. CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.