jiebi/CodeConvo huggingface dataset:
Code change:
Replaced unstructured header with and Dictionary Structured Header Fields. Defined content identifiers for individual Dictionary members, e.g., . Defined content identifiers for first N members of a List, e.g., . A signature in a request now looks like this:
I like this PR! We just need some tweaks, but it greatly improves the way the spec can be used.
This PR also fixes . Should we remove that appendix in this PR?
Redefine the Signature header field to use . This will simplify both the definition and the parsing of this header field value.
The Covered Content list, Algorithm, and Verification Key identifier should all be part of the Signature Input, to protect against malicious changes.
The Covered Content list contains identifiers for more than just headers, so the parameter name is no longer appropriate. Some alternatives: "content", "signed-content", "covered-content".
I like the direction this PR is taking: spec is more focused because it outsources spec of field format to draft-kamp-httpbis-structure dictionary format is more flexible and allows multiple signatures (important)

Related discussion:
text: signature over the empty string. If the signature's Algorithm name does not start with rsa, <del> hmac, or ecdsa, signers SHOULD include (created) and (request- target) in the list. </del> <ins> hmac, or ecdsa, signers SHOULD include "*created" and "*request-target" in the list. </ins> If the signature's Algorithm starts with rsa, hmac, or ecdsa, <del> signers SHOULD include date and (request-target) in the list. </del> <ins> signers SHOULD include "date" and "*request-target" in the list. </ins> Further guidance on what to include in this list and in what order is out of scope for this document.  However, the list
Code change:
Replaced unstructured header with and Dictionary Structured Header Fields. Defined content identifiers for individual Dictionary members, e.g., . Defined content identifiers for first N members of a List, e.g., . A signature in a request now looks like this:
I like this PR! We just need some tweaks, but it greatly improves the way the spec can be used.
This PR also fixes . Should we remove that appendix in this PR?
Redefine the Signature header field to use . This will simplify both the definition and the parsing of this header field value.
The Covered Content list, Algorithm, and Verification Key identifier should all be part of the Signature Input, to protect against malicious changes.
The Covered Content list contains identifiers for more than just headers, so the parameter name is no longer appropriate. Some alternatives: "content", "signed-content", "covered-content".
I like the direction this PR is taking: spec is more focused because it outsources spec of field format to draft-kamp-httpbis-structure dictionary format is more flexible and allows multiple signatures (important)

Related discussion:
text: lowercased identifier followed with a colon "":"", a space "" "", and the identifier's canonicalized value (described below). <del> If Covered Content contains "(created)" and the signature's Creation </del> <ins> If Covered Content contains "*created" and the signature's Creation </ins> Time is undefined or the signature's Algorithm name starts with "rsa", "hmac", or "ecdsa" an implementation MUST produce an error. <del> If Covered Content contains "(expires)" and the signature does not </del> <ins> If Covered Content contains "*expires" and the signature does not </ins> have an Expiration Time or the signature's Algorithm name starts with "rsa", "hmac", or "ecdsa" an implementation MUST produce an error.
Code change:
Replaced unstructured header with and Dictionary Structured Header Fields. Defined content identifiers for individual Dictionary members, e.g., . Defined content identifiers for first N members of a List, e.g., . A signature in a request now looks like this:
I like this PR! We just need some tweaks, but it greatly improves the way the spec can be used.
This PR also fixes . Should we remove that appendix in this PR?
Redefine the Signature header field to use . This will simplify both the definition and the parsing of this header field value.
The Covered Content list, Algorithm, and Verification Key identifier should all be part of the Signature Input, to protect against malicious changes.
The Covered Content list contains identifiers for more than just headers, so the parameter name is no longer appropriate. Some alternatives: "content", "signed-content", "covered-content".
I like the direction this PR is taking: spec is more focused because it outsources spec of field format to draft-kamp-httpbis-structure dictionary format is more flexible and allows multiple signatures (important)

Related discussion:
text: not present or malformed in the message, the implementation MUST produce an error. <ins> If Covered Content contains an identifier for a Dictionary member that references a header field that is not present, is malformed in the message, or is not a Dictionary Structured Field, the implementation MUST produce an error.  If the header field value does not contain the specified member, the implementation MUST produce an error. If Covered Content contains an identifier for a List Prefix that references a header field that is not present, is malformed in the message, or is not a List Structured Field, the implementation MUST produce an error.  If the header field value contains fewer than the specified number of members, the implementation MUST produce an error. </ins> For the non-normative example Signature metadata in example-metadata, the corresponding Signature Input is:
Code change:
Replaced unstructured header with and Dictionary Structured Header Fields. Defined content identifiers for individual Dictionary members, e.g., . Defined content identifiers for first N members of a List, e.g., . A signature in a request now looks like this:
I like this PR! We just need some tweaks, but it greatly improves the way the spec can be used.
This PR also fixes . Should we remove that appendix in this PR?
Redefine the Signature header field to use . This will simplify both the definition and the parsing of this header field value.
The Covered Content list, Algorithm, and Verification Key identifier should all be part of the Signature Input, to protect against malicious changes.
The Covered Content list contains identifiers for more than just headers, so the parameter name is no longer appropriate. Some alternatives: "content", "signed-content", "covered-content".
I like the direction this PR is taking: spec is more focused because it outsources spec of field format to draft-kamp-httpbis-structure dictionary format is more flexible and allows multiple signatures (important)

Related discussion:
text: 5.2. <del> This document defines the Signature header field, whose value contains a list of named parameters.  IANA is asked to create and maintain a new registry titled "HTTP Signature Parameters" to record and maintain the set of named parameters defined for use within the Signature header field.  Initial values for this registry are given in iana-param-contents.  Future assignments and modifications to existing assignment are to be made through the Expert Review registration policy RFC8126 and shall follow the template presented in iana-param-template. </del> <ins> This document defines the "Signature-Input" Structured Header, whose member values may have parameters containing metadata about a message signature.  IANA is asked to create and maintain a new registry titled "HTTP Signature Metadata Parameters" to record and maintain the set of parameters defined for use with member values in the "Signature-Input" Structured Header.  Initial values for this registry are given in iana-param-contents.  Future assignments and modifications to existing assignments are to be made through the Expert Review registration policy RFC8126 and shall follow the template presented in iana-param-template. </ins> 5.2.1. 5.2.2. The table below contains the initial contents of the HTTP Signature <del> Parameters Registry.  Each row in the table represents a distinct entry in the registry. </del> <ins> Metadata Parameters Registry.  Each row in the table represents a distinct entry in the registry. </ins> 6.
Code change:
separates MESSAGING and SEMANTICS concepts (Eg. fields)
Thanks! :tada:
The spec relies only on HTTP Semantics and not on HTTP/1.1 messaging. [ ] improve wording [ ] switch to http-core Check all references to Messaging and consider replacing them using Semantic. See URL
NAME NAME NAME I was re-reading the spec after the more recent filed issues, and I think that switching this draft to HTTP Core terminology (eg. I-D.ietf-httpbis-semantics ) we could have a more consistent background for taking the right decisions about things like transformations, intermediaries.
This should be taken care of with , NAME please re-open with comment if there are more things to be done.

Related discussion:
text: context: Re-ordering of header fields with different header field names <del> (HTTP, Section 3.2.2). </del> <ins> (MESSAGING, Section 3.2.2). </ins> <del> Combination of header fields with the same field name (HTTP, </del> <ins> Combination of header fields with the same field name (MESSAGING, </ins> Section 3.2.2). Removal of header fields listed in the "Connection" header field <del> (HTTP, Section 6.1). </del> <ins> (MESSAGING, Section 6.1). </ins> <del> Addition of header fields that indicate control options (HTTP, Section 6.1). </del> <ins> Addition of header fields that indicate control options (MESSAGING, Section 6.1). </ins> <del> Addition or removal of a transfer coding (HTTP, Section 5.7.2). </del> <ins> Addition or removal of a transfer coding (MESSAGING, Section 5.7.2). </ins> <del> Addition of header fields such as "Via" (HTTP, Section 5.7.1) and "Forwarded" (RFC7239, Section 4). </del> <ins> Addition of header fields such as "Via" (MESSAGING, Section 5.7.1) and "Forwarded" (RFC7239, Section 4). </ins> 1.3.
Code change:
separates MESSAGING and SEMANTICS concepts (Eg. fields)
Thanks! :tada:
The spec relies only on HTTP Semantics and not on HTTP/1.1 messaging. [ ] improve wording [ ] switch to http-core Check all references to Messaging and consider replacing them using Semantic. See URL
NAME NAME NAME I was re-reading the spec after the more recent filed issues, and I think that switching this draft to HTTP Core terminology (eg. I-D.ietf-httpbis-semantics ) we could have a more consistent background for taking the right decisions about things like transformations, intermediaries.
This should be taken care of with , NAME please re-open with comment if there are more things to be done.

Related discussion:
text: Changes to the "request-target" and "Host" header field that when applied together do not result in a change to the message's <del> effective request URI, as defined in Section 5.5 of HTTP. </del> <ins> effective request URI, as defined in Section 5.5 of MESSAGING. </ins> Additionally, all changes to content not covered by the signature are considered safe.
Code change:
separates MESSAGING and SEMANTICS concepts (Eg. fields)
Thanks! :tada:
The spec relies only on HTTP Semantics and not on HTTP/1.1 messaging. [ ] improve wording [ ] switch to http-core Check all references to Messaging and consider replacing them using Semantic. See URL
NAME NAME NAME I was re-reading the spec after the more recent filed issues, and I think that switching this draft to HTTP Core terminology (eg. I-D.ietf-httpbis-semantics ) we could have a more consistent background for taking the right decisions about things like transformations, intermediaries.
This should be taken care of with , NAME please re-open with comment if there are more things to be done.

Related discussion:
text: BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <del> The terms "HTTP message", "HTTP method", "HTTP request", "HTTP response", "absolute-form", "absolute-path", "effective request URI", "gateway", "header field", "intermediary", "request-target", "sender", and "recipient" are used as defined in RFC7230. </del> <ins> The terms "HTTP message", "HTTP request", "HTTP response", "absolute- form", "absolute-path", "effective request URI", "gateway", "header field", "intermediary", "request-target", "sender", and "recipient" are used as defined in MESSAGING. The term "method" is to be interpreted as defined in Section 4 of SEMANTICS. </ins> For brevity, the term "signature" on its own is used in this document to refer to both digital signatures and keyed MACs.  Similarly, the
Code change:
separates MESSAGING and SEMANTICS concepts (Eg. fields)
Thanks! :tada:
The spec relies only on HTTP Semantics and not on HTTP/1.1 messaging. [ ] improve wording [ ] switch to http-core Check all references to Messaging and consider replacing them using Semantic. See URL
NAME NAME NAME I was re-reading the spec after the more recent filed issues, and I think that switching this draft to HTTP Core terminology (eg. I-D.ietf-httpbis-semantics ) we could have a more consistent background for taking the right decisions about things like transformations, intermediaries.
This should be taken care of with , NAME please re-open with comment if there are more things to be done.

Related discussion:
text: This document contains non-normative examples of partial and complete HTTP messages.  To improve readability, header fields may be split into multiple lines, using the "obs-fold" syntax.  This syntax is <del> deprecated in RFC7230, and senders MUST NOT generate messages that </del> <ins> deprecated in MESSAGING, and senders MUST NOT generate messages that </ins> include it. 2.
Code change:
reuses existing definitions for S-F and Unix time.
Doesn't make this PR redundant? (or regressive, really, because references the exact definitions to use - and from structured headers)
This probably

Related discussion:
text: Signature may be verified multiple times, potentially by different entities. <ins> The term "Unix time" is defined by POSIX.1 section 4.16 [2]. </ins> This document contains non-normative examples of partial and complete HTTP messages.  To improve readability, header fields may be split into multiple lines, using the "obs-fold" syntax.  This syntax is
Code change:
reuses existing definitions for S-F and Unix time.
Doesn't make this PR redundant? (or regressive, really, because references the exact definitions to use - and from structured headers)
This probably

Related discussion:
text: the "*created" identifier. Its canonicalized value is an Integer String containing the <del> signature's Creation Time expressed as the number of seconds since the Epoch, as defined in Section 4.16 [2] of POSIX.1. </del> <ins> signature's Creation Time expressed in "Unix time". </ins> The use of seconds since the Epoch to canonicalize a timestamp simplifies processing and avoids timezone management required by
Code change:
reuses existing definitions for S-F and Unix time.
Doesn't make this PR redundant? (or regressive, really, because references the exact definitions to use - and from structured headers)
This probably

Related discussion:
text: the "*expires" identifier. Its canonicalized value is a Decimal String containing the <del> signature's Expiration Time expressed as the number of seconds since the Epoch, as defined in Section 4.16 [3] of POSIX.1. </del> <ins> signature's Expiration Time expressed in "Unix time". </ins> 2.6.
Code change:
reuses existing definitions for S-F and Unix time.
Doesn't make this PR redundant? (or regressive, really, because references the exact definitions to use - and from structured headers)
This probably

Related discussion:
text: [1] https://openjdk.java.net/groups/net/httpclient/intro.html <del> [2] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/ V1_chap04.html#tag_04_16 [3] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/ </del> <ins> [2] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/ </ins> V1_chap04.html#tag_04_16
Code change:
removes algorithm specific rules for content identifiers Current layout is not backward compatible with http-signatures, so it's safe to do it.
The rules that restrict when the signer can or must include certain identifiers appear to be related to the pseudo-revving of the Cavage draft that happened when the algorithm was introduced. We should drop these rules, as it can be expected that anyone implementing this draft will support all content identifiers.

Related discussion:
text: This list MUST NOT be empty, as this would result in creating a signature over the empty string. <del> If the signature's Algorithm name does not start with rsa, hmac, or ecdsa, signers SHOULD include "*created" and "*request-target" in the list. </del> <ins> Signers SHOULD include "*request-target" in the list. </ins> <del> If the signature's Algorithm starts with rsa, hmac, or ecdsa, signers SHOULD include "date" and "*request-target" in the list. </del> <ins> Signers SHOULD include a date stamp, such as the "date" header or the "*created" field in the list. </ins> Further guidance on what to include in this list and in what order is out of scope for this document.  However, the list
Code change:
removes algorithm specific rules for content identifiers Current layout is not backward compatible with http-signatures, so it's safe to do it.
The rules that restrict when the signer can or must include certain identifiers appear to be related to the pseudo-revving of the Cavage draft that happened when the algorithm was introduced. We should drop these rules, as it can be expected that anyone implementing this draft will support all content identifiers.

Related discussion:
text: the identifier's canonicalized value (described below). If Covered Content contains "*created" and the signature's Creation <del> Time is undefined or the signature's Algorithm name starts with "rsa", "hmac", or "ecdsa" an implementation MUST produce an error. </del> <ins> Time is undefined an implementation MUST produce an error. </ins> If Covered Content contains "*expires" and the signature does not <del> have an Expiration Time or the signature's Algorithm name starts with "rsa", "hmac", or "ecdsa" an implementation MUST produce an error. </del> <ins> have an Expiration Time an implementation MUST produce an error. </ins> If Covered Content contains an identifier for a header field that is not present or malformed in the message, the implementation MUST
Code change:
It looks like this was forgotten in , when unknown values were switched from None to Default. /cc NAME this caused us some confusion over in Go, if you have time I'd appreciate hearing what you think we should do in golang/go. Thank you!
Thanks! LGTM.

Related discussion:
text: attribute-name of "SameSite" and an attribute-value of "enforcement". <del> Note: This algorithm maps the "None" value, as well as any unknown value, to the "None" behavior, which is helpful for backwards compatibility when introducing new variants. </del> 5.3.7.1. Same-site cookies in "Strict" enforcement mode will not be sent along
Code change:
Fixes field ordering reference
In 12.6: "Any mangling of Digest, including de-duplication of representation-data-digest values or combining different field values (see 5.3.1 of [SEMANTICS]) might affect signature validation." But 5.3.1 is "Request". (note that I didn't catch this earlier because it doesn't use the "Section X of [Y]" pattern; this should be gixed as well)

Related discussion:
text: stripped or added. Any mangling of "Digest", including de-duplication of representation- <del> data-digest values or combining different field values (see 5.3.1 of SEMANTICS) might affect signature validation. </del> <ins> data-digest values or combining different field values (see Section 5.2 of SEMANTICS) might affect signature validation. </ins> 12.7.
Code change:
This ended up being more changes than I first intended but I think most of them are uncontroversial and simply improve consistency through the document.
LGTM. Thanks NAME and Happy New Year!

Related discussion:
text: An HTTP-level integrity mechanism that operates independent of transfer can be used to detect programming errors and/or corruption of data in flight or at rest, be used across multiple hops in order <del> to provide end-to-end integrity guarantees, aid fault diagnosis </del> <ins> to provide end-to-end integrity guarantees, can aid fault diagnosis </ins> across hops and system boundaries, and can be used to validate integrity when reconstructing a resource fetched using different HTTP connections.
Code change:
This ended up being more changes than I first intended but I think most of them are uncontroversial and simply improve consistency through the document.
LGTM. Thanks NAME and Happy New Year!

Related discussion:
text: representation, or conveys a partial representation of a resource eg. Range Requests (see Section 14.2 of SEMANTICS). <del> Changes are semantically compatible with existing implementations and better cover both the request and response cases. </del> <ins> This document replaces RFC3230 to better align with SEMANTICS and to provide more detailed description of "Digest" usage in request and response cases.  Changes are intended to be semantically compatible with existing implementations but note that negotiation of "Content- MD5" is deprecated deprecate-contentMD5, "Digest" field parameters are obsoleted obsolete-parameters, "md5" and "sha" digest-algorithms are obsoleted broken-algorithms and the "adler32" algorithm is deprecated deprecated-algorithms. </ins> The value of "Digest" is calculated on selected representation, which is tied to the value contained in any "Content-Encoding" or "Content-
Code change:
This ended up being more changes than I first intended but I think most of them are uncontroversial and simply improve consistency through the document.
LGTM. Thanks NAME and Happy New Year!

Related discussion:
text: The goals do not include: <del> The digest mechanism described here does not cover the full HTTP message nor its semantic, as representation metadata are not included in the checksum. </del> <ins> Digest mechanisms do not cover the full HTTP message nor its semantic, as representation metadata is not included in the checksum. </ins> <del> The digest mechanisms described here cover only representation and selected representation data, and do not protect the integrity of </del> <ins> Digest mechanisms cover only representation and selected representation data, and do not protect the integrity of </ins> associated representation metadata or other message fields. <del> The digest mechanisms described here are not meant to support authentication of the source of a digest or of a message or anything else.  These mechanisms, therefore, are not a sufficient defense against many kinds of malicious attacks. </del> <ins> Digest mechanisms do not support authentication of the source of a digest, message or anything else.  These mechanisms, therefore, are not a sufficient defense against many kinds of malicious attacks. </ins> Digest mechanisms do not provide message privacy. <del> The digest mechanisms described here are not meant to support authorization or other kinds of access controls. </del> <ins> Digest mechanisms do not support authorization or other kinds of access controls. </ins> 1.4. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <del> "OPTIONAL" in this document are to be interpreted as described in BCP 14 (RFC2119 and RFC8174) when, and only when, they appear in all </del> <ins> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all </ins> capitals, as shown here. This document uses the Augmented BNF defined in RFC5234 and updated