jiebi/CodeConvo huggingface dataset:
Code change:
control data rather than using pseudo-fields.  Messages are invalid (invalid) if they contain fields named ":method", ":scheme", ":authority", ":path", or ":status".  Other pseudo-fields that are <del> defined by protocol extensions MAY be included.  Field lines containing pseudo-fields MUST precede other field lines.  A message that contains a pseudo-field after any other field is invalid; see invalid. </del> <ins> defined by protocol extensions MAY be included; pseudo-fields cannot be included in trailers (see H2).  Field lines containing pseudo- fields MUST precede other field lines.  A message that contains a pseudo-field after any other field is invalid; see invalid. </ins> Note that while some messages - CONNECT or upgrade requests in particular - can be represented using this format, doing so serves no

Related discussion:
text: S 3.6 says that extension pseudo header MAY be included but they have to appear before other field lines. An easy detail to miss buried in HTTP/2 is the requirement does that also apply here?
LGTM thanks
Code change:
Statement is accepted to be registered to the Append-only Log. Transparency Services MUST maintain Registration Policies. <del> Transparency Services MUST also maintain a list of trust anchors, which SHOULD be used by Relying Parties to authenticate Issuers, and which MAY be included in a Registration Policy statement.  For </del> <ins> Transparency Services MUST maintain a list of trust anchors (see definition of trust anchor in RFC4949).  Transparency Services MUST authenticate signed statements as part of a Registration Policy.  For </ins> instance, a trust anchor could be an X.509 root certificate, a pointer to an OpenID Connect identity provider, or any other COSE- compatible trust anchor.

Related discussion:
text: Editors note: updated with a link to the referenced text: I don't understand the SHOULD. You have to be in possession of trust anchors to verify a digital signature. It is not an optional feature.
It would seem this is correct contingent on your interpretation of , particularly points 2 and 3, so good point.
It's not the use of the anchor in verifying that is optional. It is the use of issuer verification as a gate to registration that is the problem. For ts implementations that naturaly have RBAC at the edge, the "spam" problem is not really a problem. Statements about statements seem to me to be a better way to deal with use cases where strong issuer verification is necessary. Registration time checks can only ever be "point in time"
My read of the Issue and the current state of the document is: This section is under , which implies the MUST refers to enabling the registration process. Currently, a registration can not be completed unless the issuer is verified, which can't occur without trust anchors. The SHOULD refers to verifiers which are not part of the Registration Policy. I think their inclusion in this section is confusing. See for a proposal.
Code change:
3. <del> To carry RFC 3161 timestamp tokens in COSE signed messages, a new COSE header parameter, "rfc3161-tst", is defined as follows: </del> <ins> The two modes described in sec-timestamp-then-cose and sec-cose-then- timestamp use different inputs into the timestamping machinery, and consequently create different kinds of binding between COSE and TST. To clearly separate their semantics two different COSE header parameters are defined as described in the following subsections. 3.1. The "3161-ttc" COSE </ins> <del> Name: rfc3161-tst </del> <ins> header parameter MUST be used for the mode described in sec- timestamp-then-cose. The "3161-ttc" protected header is defined as follows: Name: 3161-ttc </ins> Label: TBD

Related discussion:
text: See URL Hi! Unfortunately, we couldn't submit the draft before the meeting and discuss it face-to-face. But here's a -01 fresh from the oven. We absorbed the feedback we got in SF and went ahead with one single header. However, the two modes of use ([1], [2]) define different inputs into the timestamping machinery and therefore create a different binding between COSE and TST. At present, the only way to distinguish between the two semantics is by their position in the COSE message (i.e., protected vs unprotected), which does not look like a good design :-) cheers, thanks [1] URL [2] URL ---------- Forwarded message --------- From: Date: Tue, 7 Nov 2023 at 14:36 Subject: New Version Notification for draft-ietf-cose-tsa-tst-header-parameter-URL To: Henk Birkholz , Maik Riechert , Maik Riechert , Thomas Fossati , A new version of Internet-Draft draft-ietf-cose-tsa-tst-header-parameter-URL has been successfully submitted by Thomas Fossati and posted to the IETF repository. Name: draft-ietf-cose-tsa-tst-header-parameter Revision: 01 Title: COSE Header parameter for RFC 3161 Time-Stamp Tokens Date: 2023-11-07 Group: cose Pages: 6 URL: URL Status: URL HTML: URL HTMLized: URL Diff: https://author-URL Abstract: RFC 3161 provides a method for timestamping a message digest to prove that the message was created before a given time. This document defines a CBOR Signing And Encrypted (COSE) header parameter that can be used to combine COSE message structures used for signing (i.e., COSESign and COSESign1) with existing RFC 3161-based timestamping infrastructure. The IETF Secretariat
Code change:
When a message does not have a header field, a Content-Length header field can provide the <del> anticipated size, as a decimal number of octets, for a potential payload body.  For messages that do include a payload body, the </del> <ins> anticipated size, as a decimal number of octets, for potential payload data.  For messages that do include payload data, the </ins> Content-Length field value provides the framing information necessary <del> for determining where the body (and message) ends.  For messages that do not include a payload body, the Content-Length indicates the size of the selected representation (field.content-length). </del> <ins> for determining where the data (and message) ends.  For messages that do not include payload data, the Content-Length indicates the size of the selected representation (field.content-length). </ins> 6.3.

Related discussion:
text: I think we discussed this last week and Julian has pending changes to be made before review.
This just moves the ABNF, not the definition of the transfer codings.
This is the remaining ABNF production that Semantics imports from Messaging (for the definition of "TE"). Maybe we should move the production to messaging, reversing the dependency.
Discussed on call; worth a try.
URL out that there are a few more things to consider: Semantics currently claims there are regular parameters here, but transfer-parameter is special wrt BWS should we move the special case of "trailers" in the grammar into prose? In any case, what would it mean to have a ranking on "trailers"? Invalid, thus ignore? "t-ranking" seems to duplicate "weight"
Fine to merge, but shouldn't we also move the extensibility and IANA registry sections?
Code change:
When a message does not have a header field, a Content-Length header field can provide the <del> anticipated size, as a decimal number of octets, for a potential payload body.  For messages that do include a payload body, the </del> <ins> anticipated size, as a decimal number of octets, for potential payload data.  For messages that do include payload data, the </ins> Content-Length field value provides the framing information necessary <del> for determining where the body (and message) ends.  For messages that do not include a payload body, the Content-Length indicates the size of the selected representation (field.content-length). </del> <ins> for determining where the data (and message) ends.  For messages that do not include payload data, the Content-Length indicates the size of the selected representation (field.content-length). </ins> 6.3.

Related discussion:
text: This eliminates confusion with the message body protocol element of HTTP/1.1 and other usage of multipart body parts, and should make it easier to describe HTTP/2 and HTTP/3 data frames.
except for multipart body parts or when referring specifically to HTTP/1.1 message body.
See related comment: URL
I believe this is good; but more eyes are needed :-) If we go ahead with that, we may want to call out the new terminolody in one of the "changes from 723x" sections.
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 home routers 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 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. </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: AIL is used as an acronym in multiple places but not defined. also put colons on the glossary terms
I don't think there was consensus (even close) on the use of CPE router, unfortunately. I don't really agree with s/need/needs to/, but maybe s/need take no action/does not need to take action/ for better clarity?
Code change:
The issuer MUST choose a unique salt value for each claim value. Each salt value MUST contain at least 128 bits of pseudorandom data, making it hard for an attacker to guess.  The salt value MUST then be <del> encoded as a string.  It is RECOMMENDED to base64url encode at least </del> <ins> encoded as a string.  It is RECOMMENDED to base64url-encode at least </ins> 16 pseudorandom bytes. The issuer MUST build the hashes by hashing over a string that is

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:
more than one member, or if the request method is neither GET nor HEAD. <ins> A recipient MUST ignore the If-Modified-Since header field if the resource does not have a modification date available. </ins> A recipient MUST interpret an If-Modified-Since field value's timestamp in terms of the origin server's clock.

Related discussion:
text: From : without a concept of modification time. (Section 13.1.4) I couldn't really locate which text was supposed to be providing this clarification.
Re: Appendix B.4 -- This text originally referred to the resolution of , but that was subsequently overwritten when we aligned the way we specified conditionals. It probably needs to be re-introduced (and perhaps looked at for the other conditionals).
Code change:
"urn:ietf:params:oauth:grant-type:saml2-bearer" to indicate SAML. Other grant types MAY be used to indicate other formats. <del> 2.3.4. </del> <ins> 2.4.4. </ins> Authorization servers MAY choose to:

Related discussion:
text: Added use cases. We may want to refine these, or move them into a non-normative section later.
Code change:
ultimately controls how long a client instance can re-use a single Client Attestation JWT. <ins> 4.2. Authorization servers issuing a refresh token in response to a token request using the "urn:ietf:params:oauth:client-assertion-type:jwt- key-attestation" client authentication method MUST bind the refresh token to the client instance, and NOT just the client as specified in section 6 [@!RFC6749].  To prove this binding, the client instance MUST authenticate itself to the authorization server when refreshing an access token using the "urn:ietf:params:oauth:client-assertion- type:jwt-key-attestation" authentication method.  The client MUST also use the same client attestation key that was used for authentication when the refresh token was issued. </ins> 5. TODO

Related discussion:
text: As discussed over email, this PR drafts some text to capture the requirement around refresh token binding to the client instance not just the client. The PR also addresses some broken links. Personally I'm still not convinced that the best way to do this binding is through the client attestation key, instead I think we could add a claim that identifies the client instance in the client key attestation
few suggestions
Code change:
1. WARP Streaming Format (WARP) is a media format designed to deliver <del> CMAF CMAF compliant media content over Media Over QUIC Transport (MOQT) MoQTransport.  WARP works by fragmenting the bitstream into objects that can be independently transmitted.  WARP leverages a simple prioritization strategy of assigning newer content a higher delivery order, allowing intermediaries to drop older data, and video over audio, in the face of congestion.  Either complete Groups of Pictures (GOPS) ISOBMFF or individual frames are mapped to MoQTransport Objects.  WARP is targeted at interactive levels of live latency. </del> <ins> CMAF CMAF and LOC LOC compliant media content over Media Over QUIC Transport (MOQT) MoQTransport.  WARP works by fragmenting the bitstream into objects that can be independently transmitted.  WARP leverages the Common Catalog Format COMMON-CATALOG-FORMAT to describe the output of the original publisher.  WARP specifies how content should be packaged and signaled, defines how the catalog communicates the content, specifies prioritization strategies for real-time and workflows for beginning and terminating broadcasts.  WARP also details how end-subscribers may perform adaptive bitrate switching. WARP is targeted at real-time and interactive levels of live latency. </ins> This document describes version 1 of the streaming format.

Related discussion:
text: The current version of WARP only references CMAF packaging and does not make it clear that WARP is also intended to support LOC (Low Overhaded Container) packaging. LOC is defined by URL Currently the LOC spec defines both a streaming format and a packaging format. Reference for packaging will therefore need to be made to specific subsections of that draft. In the future if LOC packaging is separated from LOC streaming format, then the WARP references can be updated.
Code change:
The claim <del> indicates the hash algorithm used by the Issuer to generate the hashes of the salted claim values.  The hash algorithm identifier MUST be a value from the "Hash Name String" column in the IANA "Named Information Hash Algorithm" registry [IANA.Hash.Algorithms].  SD-JWTs with hash algorithm identifiers not found in this registry are not considered valid and MUST NOT be accepted by verifiers. </del> <ins> indicates the hash algorithm function used by the Issuer to generate the hashes over the random values and the claim values. The hash algorithm identifier MUST be a value from the "Hash Name String" column in the IANA "Named Information Hash Algorithm" registry [IANA.Hash.Algorithms] or HMAC algorithms in "Algorithmn Name" column in the IANA "JSON Web Signature and Encryption Algorithms" registry [IANA.JWS.Algorithms]. </ins> To promote interoperability, implementations MUST support the SHA-256 <del> hash algorithm. </del> <ins> hash algorithm.  Other specifications and/or profiles of this specification may register additional algorithm identifiers. See security_considerations for requirements regarding entropy of the salt, minimum length of the salt, and choice of a hash function. </ins> 5.1.3.

Related discussion:
text: added HMAC algorithm to supported identifiers replaced with to enable random value being a cryptographic key
NAME ready from my side
Looks good, I just had a few nitpicks here and there.
resolve conflicts, change to sddigestderivation_alg check if renders correctly...
Verbal approval from NAME
NAME sorry for the late revision it seems that here we have merge conflicts exposed URL
thanks! yes, fixed them in a PR that was merged
Code change:
Implementations MUST support ephemeral key exchange sizes of at least 2048 bits for cipher suites that use ephemeral finite field Diffie- Hellman (DHE) TLS13 and 224 bits for cipher suites that use ephemeral <del> elliptic curve Diffie-Hellman (ECDHE) RFC4492.  Clients MUST accept </del> <ins> elliptic curve Diffie-Hellman (ECDHE) RFC8422.  Clients MUST accept </ins> DHE sizes of up to 4096 bits.  Endpoints MAY treat negotiation of key sizes smaller than the lower limits as a ConnectionErrorHandler of type INADEQUATE_SECURITY.

Related discussion:
text: RFC 4492 is obsolete. This is a TLS 1.2 section, so it is OK to refer to the TLS 1.2 document here.
Code change:
A trailer section allows the sender to include additional fields at the end of a chunked message in order to supply metadata that might <del> be dynamically generated while the message body is sent, such as a </del> <ins> be dynamically generated while the payload data is sent, such as a </ins> message integrity check, digital signature, or post-processing status.  The proper use and limitations of trailer fields are defined in trailer.fields.

Related discussion:
text: I think we discussed this last week and Julian has pending changes to be made before review.
This just moves the ABNF, not the definition of the transfer codings.
This is the remaining ABNF production that Semantics imports from Messaging (for the definition of "TE"). Maybe we should move the production to messaging, reversing the dependency.
Discussed on call; worth a try.
URL out that there are a few more things to consider: Semantics currently claims there are regular parameters here, but transfer-parameter is special wrt BWS should we move the special case of "trailers" in the grammar into prose? In any case, what would it mean to have a ranking on "trailers"? Invalid, thus ignore? "t-ranking" seems to duplicate "weight"
Fine to merge, but shouldn't we also move the extensibility and IANA registry sections?
Code change:
A trailer section allows the sender to include additional fields at the end of a chunked message in order to supply metadata that might <del> be dynamically generated while the message body is sent, such as a </del> <ins> be dynamically generated while the payload data is sent, such as a </ins> message integrity check, digital signature, or post-processing status.  The proper use and limitations of trailer fields are defined in trailer.fields.

Related discussion:
text: This eliminates confusion with the message body protocol element of HTTP/1.1 and other usage of multipart body parts, and should make it easier to describe HTTP/2 and HTTP/3 data frames.
except for multipart body parts or when referring specifically to HTTP/1.1 message body.
See related comment: URL
I believe this is good; but more eyes are needed :-) If we go ahead with that, we may want to call out the new terminolody in one of the "changes from 723x" sections.
Code change:
If more members remain in input_dictionary: <del> Append a COMMA to output. </del> <ins> Append "," to output. </ins> Append a single SP to output.

Related discussion:
text: The term COMMA is not defined anywhere in this document, or in any of the documents it imports. But we can just use the literal instead.
Thanks.
The structured headers draft imports and uses a number of productions from RFC 5234 for typographically awkward characters and character classes (, , etc), but there is no definition of provided anywhere. Similar to the way that , , , , and are used without special treatment, can probably be replaced with wherever it occurs.
Code change:
The SETTINGS frame precedes any HTTP/2 priority signal sent from a client, so a server can determine if it needs to allocate any resource to signal handling before they arrive.  A server that <del> receives SETTINGS_DEPRECATE_RFC7540_PRIORITIES with value of 1 MUST ignore HTTP/2 priority signals. </del> <ins> receives SETTINGS_NO_RFC7540_PRIORITIES with value of 1 MUST ignore HTTP/2 priority signals. </ins> Where both endpoints disable RFC 7540 stream priority, the client is expected to send this scheme's priority signal.  Handling of omitted

Related discussion:
text: RFC 7540 priorities are already deprecated.
That's the kind of thing I expect reviewers to question if we made a typo :) How about just changing the text to "using a setting to disable RFC 7540 priorities was inspired by I-D.lassey-priority-setting? Alternatively, we could just drop the mention altogther, although I think the context is useful.
"disable" WFM.
Proposed changes look good. In addition, I think we might want to change : For this case, maybe changing deprecate to depreciate would be the minimum required change.
Code change:
2.2.2. When a dictionary is stored as a result of a "Use-As-Dictionary" <del> directive, it includes "match", "match-search" and "match-dest" strings that are used to match an outgoing request from a client to the available dictionaries. </del> <ins> directive, it includes "match" and "match-dest" strings that are used to match an outgoing request from a client to the available dictionaries. Dictionaries MUST have been served from the same {Origin} as the outgoing request to match. </ins> To see if an outbound request matches a given dictionary, the following algorithm will return TRUE for a successful match and FALSE

Related discussion:
text: This changes the URLPattern match to use a single match pattern to be consistent with other uses of URLPattern.
NAME NAME this is an attempt at a change to have it use a single string for pattern construction. I don't feel great about the same-origin check part of the validation but I don't see why it wouldn't work. It still allows for people to waste bytes by not using path-relative patterns so I may have to re-open the issue around that but should provide the consistency you were asking for. This would be instead of PR .
a couple nitpicks while passing by