jiebi/TextFlow huggingface dataset:
Original 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>  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>  have an Expiration Time or the signature's Algorithm name starts with "rsa", "hmac", or "ecdsa" an implementation MUST produce an error.

Reviewer comments:
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)

Revised text:
lowercased identifier followed with a colon "":"", a space "" "", and the identifier's canonicalized value (described below).  <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.  <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.
Original text:
not present or malformed in the message, the implementation MUST produce an error.  For the non-normative example Signature metadata in example-metadata, the corresponding Signature Input is:

Reviewer comments:
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)

Revised 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:
Original 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>  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>  6.

Reviewer comments:
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)

Revised text:
5.2.  <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  <ins> Metadata Parameters Registry.  Each row in the table represents a distinct entry in the registry. </ins> 6.
Original text:
context: Re-ordering of header fields with different header field names <del> (HTTP, Section 3.2.2). </del>  <del> Combination of header fields with the same field name (HTTP, </del>  Section 3.2.2). Removal of header fields listed in the "Connection" header field <del> (HTTP, Section 6.1). </del>  <del> Addition of header fields that indicate control options (HTTP, Section 6.1). </del>  <del> Addition or removal of a transfer coding (HTTP, Section 5.7.2). </del>  <del> Addition of header fields such as "Via" (HTTP, Section 5.7.1) and "Forwarded" (RFC7239, Section 4). </del>  1.3.

Reviewer comments:
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.

Revised text:
context: Re-ordering of header fields with different header field names  <ins> (MESSAGING, Section 3.2.2). </ins>  <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  <ins> (MESSAGING, Section 6.1). </ins>  <ins> Addition of header fields that indicate control options (MESSAGING, Section 6.1). </ins>  <ins> Addition or removal of a transfer coding (MESSAGING, Section 5.7.2). </ins>  <ins> Addition of header fields such as "Via" (MESSAGING, Section 5.7.1) and "Forwarded" (RFC7239, Section 4). </ins> 1.3.
Original 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>  Additionally, all changes to content not covered by the signature are considered safe.

Reviewer comments:
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.

Revised text:
Changes to the "request-target" and "Host" header field that when applied together do not result in a change to the message's  <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.
Original 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>  For brevity, the term "signature" on its own is used in this document to refer to both digital signatures and keyed MACs.  Similarly, the

Reviewer comments:
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.

Revised text:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here.  <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
Original 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>  include it. 2.

Reviewer comments:
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.

Revised 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  <ins> deprecated in MESSAGING, and senders MUST NOT generate messages that </ins> include it. 2.
Original text:
Signature may be verified multiple times, potentially by different entities.  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

Reviewer comments:
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

Revised 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
Original 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>  The use of seconds since the Epoch to canonicalize a timestamp simplifies processing and avoids timezone management required by

Reviewer comments:
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

Revised text:
the "*created" identifier. Its canonicalized value is an Integer String containing the  <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
Original 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>  2.6.

Reviewer comments:
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

Revised text:
the "*expires" identifier. Its canonicalized value is a Decimal String containing the  <ins> signature's Expiration Time expressed in "Unix time". </ins> 2.6.
Original 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>  V1_chap04.html#tag_04_16

Reviewer comments:
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

Revised text:
[1] https://openjdk.java.net/groups/net/httpclient/intro.html  <ins> [2] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/ </ins> V1_chap04.html#tag_04_16
Original 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>  <del> If the signature's Algorithm starts with rsa, hmac, or ecdsa, signers SHOULD include "date" and "*request-target" in the list. </del>  Further guidance on what to include in this list and in what order is out of scope for this document.  However, the list

Reviewer comments:
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.

Revised text:
This list MUST NOT be empty, as this would result in creating a signature over the empty string.  <ins> Signers SHOULD include "*request-target" in the list. </ins>  <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
Original 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>  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>  If Covered Content contains an identifier for a header field that is not present or malformed in the message, the implementation MUST

Reviewer comments:
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.

Revised text:
the identifier's canonicalized value (described below). If Covered Content contains "*created" and the signature's Creation  <ins> Time is undefined an implementation MUST produce an error. </ins> If Covered Content contains "*expires" and the signature does not  <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
Original 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

Reviewer comments:
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.

Revised text:
attribute-name of "SameSite" and an attribute-value of "enforcement".  5.3.7.1. Same-site cookies in "Strict" enforcement mode will not be sent along
Original 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>  12.7.

Reviewer comments:
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)

Revised text:
stripped or added. Any mangling of "Digest", including de-duplication of representation-  <ins> data-digest values or combining different field values (see Section 5.2 of SEMANTICS) might affect signature validation. </ins> 12.7.
Original 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>  across hops and system boundaries, and can be used to validate integrity when reconstructing a resource fetched using different HTTP connections.

Reviewer comments:
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!

Revised 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  <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.
Original 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>  The value of "Digest" is calculated on selected representation, which is tied to the value contained in any "Content-Encoding" or "Content-

Reviewer comments:
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!

Revised text:
representation, or conveys a partial representation of a resource eg. Range Requests (see Section 14.2 of SEMANTICS).  <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-