jiebi/TextFlow huggingface dataset:
Original text:
Description: The SHA-1 algorithm RFC3174.  The output of this algorithm is encoded using the base64 encoding RFC4648.  This <del> digest-algorithm MUST NOT be used as it's now vulnerable to collision attacks.  See NO-SHA1 and IACR-2020-014. </del>  Reference: RFC3174, RFC6234, RFC4648, this document.

Reviewer comments:
[x] 5. I think you should come out and say that digest-algorithm values MUST be compared in a case-insensitive fashion. [x] 5. 'The IANA acts a registry' reads oddly; it maintains the registry. Also, saying 'the registry contains the tokens listed below' is misleading; these are initial registrations, which can be modified and added to after the RFC is published. [x] 5. There should not be RFC2219-MUSTs in IANA registry text. [x] This can be addressed by having a requirement similar to "Deprecated digest algorithms MUST NOT be used."
[ ] 5. Also, is the entire checksum value case-insensitive, or just the token identifying the value? NAME the checksum value is defined by the digest-algorithm, which defines its case. [ ] 5- Also, these might be better placed in IANA Considerations. NAME can we just drop any mention of IANA in this section? I like it. [x] * 5. The ability to have a digest algorithm that ignores content-codings is something of a surprise after reading section 2; it needs to be at least mentioned up there. NAME it is stated in the introduction URL . how would you specify it?
lgtm but keen to see mnot's approval too

Revised text:
Description: The SHA-1 algorithm RFC3174.  The output of this algorithm is encoded using the base64 encoding RFC4648.  This  <ins> digest-algorithm is now vulnerable to collision attacks.  See NO-SHA1 and IACR-2020-014. </ins> Reference: RFC3174, RFC6234, RFC4648, this document.
Original text:
3. <del> The "Digest" field contains a list of one or more representation digest values as defined in representation-digest.  It can be used in both requests and responses. </del>  For example:

Reviewer comments:
[x] 3. It's probably worth mentioning that they're comma-separated in prose. [x] 3. Disagreeing plurals in 'an incremental digest-algorithms'. [x] 4. Is Want-Digest a request field, a response field, or both? In either or both cases, what's the scope of the assertion? [x] 4. A reference to SEMANTICS 12.4.2 is necessary. See

Revised text:
3.  <ins> The "Digest" field contains a comma-separated list of one or more representation digest values as defined in representation-digest.  It can be used in both requests and responses. </ins> For example:
Original text:
algorithm, or even knowing that the recipient will ignore it. "Digest" can be sent in a trailer section.  When an incremental <del> digest-algorithms is used, the sender and the receiver can dynamically compute the digest value while streaming the content. </del>  4. The "Want-Digest" field indicates the sender's desire to receive a representation digest on messages associated with the request URI and <del> representation metadata. </del>  <del> If a digest-algorithm is not accompanied by a "qvalue", it is treated as if its associated "qvalue" were 1.0. </del>  The sender is willing to accept a digest-algorithm if and only if it is listed in a "Want-Digest" field of a message, and its "qvalue" is

Reviewer comments:
[x] 3. It's probably worth mentioning that they're comma-separated in prose. [x] 3. Disagreeing plurals in 'an incremental digest-algorithms'. [x] 4. Is Want-Digest a request field, a response field, or both? In either or both cases, what's the scope of the assertion? [x] 4. A reference to SEMANTICS 12.4.2 is necessary. See

Revised text:
algorithm, or even knowing that the recipient will ignore it. "Digest" can be sent in a trailer section.  When an incremental  <ins> digest-algorithm is used, the sender and the receiver can dynamically compute the digest value while streaming the content. </ins> 4. The "Want-Digest" field indicates the sender's desire to receive a representation digest on messages associated with the request URI and  <ins> representation metadata.  It can be used in both requests and responses. </ins>  <ins> If a digest-algorithm is not accompanied by a "qvalue" (see Section 12.4.2 ofSEMANTICS), it is treated as if its associated "qvalue" were 1.0. </ins> The sender is willing to accept a digest-algorithm if and only if it is listed in a "Want-Digest" field of a message, and its "qvalue" is
Original text:
algorithm, or even knowing that the recipient will ignore it. "Digest" can be sent in a trailer section.  In this case, "Digest" <del> MAY be merged in the header section (See Section 6.5.1 of SEMANTICS). </del>  When an incremental digest-algorithm is used, the sender and the receiver can dynamically compute the digest value while streaming the

Reviewer comments:
moved normative parts in warn that trailers can be dropped by intermediaries.
[x] 12.7. If this is mergeable into headers when it occurs as a trailer, that needs to be said earlier in the spec, not in security considerations. [x] Also, you can't prohibit intermediaries from dropping the trailer; they're explicitly allowed to do so for all trailers.

Revised text:
algorithm, or even knowing that the recipient will ignore it. "Digest" can be sent in a trailer section.  In this case, "Digest"  <ins> MAY be merged in to the header section (See Section 6.5.1 of SEMANTICS). </ins> When an incremental digest-algorithm is used, the sender and the receiver can dynamically compute the digest value while streaming the
Original text:
9.3. <del> The "Cookie Attribute Registry" defines the name space of attribute used to control cookies' behavior.  The registry is maintained at https://www.iana.org/assignments/cookie-attribute-names [4]. </del>  9.3.1.

Reviewer comments:
The IANA Cookie Attribute Registry does not exist yet. It is requested that IANA create it. Clarify wording to reflect this. Addresses
The section titled "Cookie Attribute Registry" has a link to the attribute registry maintained by the IANA. This link is broken. Moreso, a cursory look through the IANA site doesn't turn up any similar pages suggesting that this section is obsolete.
The registry does not exist yet. The text about it was added in URL The prose should actually tell IANA that the registry needs to be created, not "updated".
Addressed by

Revised text:
9.3.  <ins> IANA is requested to create the "Cookie Attribute Registry", defining the name space of attribute used to control cookies' behavior.  The registry should be maintained at https://www.iana.org/assignments/ cookie-attribute-names [4]. </ins> 9.3.1.
Original text:
9.3.2. <del> The "Cookie Attribute Registry" will be updated with the </del>  registrations below: 10.  References

Reviewer comments:
The IANA Cookie Attribute Registry does not exist yet. It is requested that IANA create it. Clarify wording to reflect this. Addresses
The section titled "Cookie Attribute Registry" has a link to the attribute registry maintained by the IANA. This link is broken. Moreso, a cursory look through the IANA site doesn't turn up any similar pages suggesting that this section is obsolete.
The registry does not exist yet. The text about it was added in URL The prose should actually tell IANA that the registry needs to be created, not "updated".
Addressed by

Revised text:
9.3.2.  <ins> The "Cookie Attribute Registry" should be created with the </ins> registrations below: 10.  References
Original text:
Working Group information can be found at http://httpwg.github.io/ [2]; source code and issues list for this draft can be found at <del> https://github.com/httpwg/http-extensions/labels/client-cert-header </del>  [3]. 1.

Reviewer comments:
This was languishing in a PR within my repo, but since we've merged the actual draft, we can promote this to a PR in the main repo as well. (Yes, I'll rename the tag if we merge this as-is.)

Revised text:
Working Group information can be found at http://httpwg.github.io/ [2]; source code and issues list for this draft can be found at  <ins> https://github.com/httpwg/http-extensions/labels/client-cert-field </ins> [3]. 1.
Original text:
deployments to work in practice, the reverse proxy needs to convey information about the client certificate to the origin application server.  A common way this information is conveyed in practice today <del> is by using non-standard headers to carry the certificate (in some </del>  encoding) or individual parts thereof in the HTTP request that is dispatched to the origin server.  This solution works but interoperability between independently developed components can be cumbersome or even impossible depending on the implementation choices <del> respectively made (like what header names are used or are </del>  configurable, which parts of the certificate are exposed, or how the certificate is encoded).  A well-known predictable approach to this commonly occurring functionality could improve and simplify

Reviewer comments:
This was languishing in a PR within my repo, but since we've merged the actual draft, we can promote this to a PR in the main repo as well. (Yes, I'll rename the tag if we merge this as-is.)

Revised text:
deployments to work in practice, the reverse proxy needs to convey information about the client certificate to the origin application server.  A common way this information is conveyed in practice today  <ins> is by using non-standard fields to carry the certificate (in some </ins> encoding) or individual parts thereof in the HTTP request that is dispatched to the origin server.  This solution works but interoperability between independently developed components can be cumbersome or even impossible depending on the implementation choices  <ins> respectively made (like what field names are used or are </ins> configurable, which parts of the certificate are exposed, or how the certificate is encoded).  A well-known predictable approach to this commonly occurring functionality could improve and simplify
Original text:
This document aspires to standardize an HTTP header field named "Client-Cert" that a TLS terminating reverse proxy (TTRP) adds to <del> requests that it sends to the backend origin servers.  The header </del>  value contains the client certificate from the mutually-authenticated TLS connection between the originating client and the TTRP.  This enables the backend origin server to utilize the client certificate information in its application logic.  While there may be additional proxies or hops between the TTRP and the origin server (potentially even with mutually-authenticated TLS connections between them), the <del> scope of the "Client-Cert" header is intentionally limited to </del>  exposing to the origin server the certificate that was presented by the originating client in its connection to the TTRP.

Reviewer comments:
This was languishing in a PR within my repo, but since we've merged the actual draft, we can promote this to a PR in the main repo as well. (Yes, I'll rename the tag if we merge this as-is.)

Revised text:
This document aspires to standardize an HTTP header field named "Client-Cert" that a TLS terminating reverse proxy (TTRP) adds to  <ins> requests that it sends to the backend origin servers.  The field </ins> value contains the client certificate from the mutually-authenticated TLS connection between the originating client and the TTRP.  This enables the backend origin server to utilize the client certificate information in its application logic.  While there may be additional proxies or hops between the TTRP and the origin server (potentially even with mutually-authenticated TLS connections between them), the  <ins> scope of the "Client-Cert" header field is intentionally limited to </ins> exposing to the origin server the certificate that was presented by the originating client in its connection to the TTRP.
Original text:
2.1. <del> The field-values of the HTTP header defined herein utilize the </del>  following encoded form. A certificate is represented in text as an "EncodedCertificate",

Reviewer comments:
This was languishing in a PR within my repo, but since we've merged the actual draft, we can promote this to a PR in the main repo as well. (Yes, I'll rename the tag if we merge this as-is.)

Revised text:
2.1.  <ins> The field-values of the HTTP header field defined herein utilize the </ins> following encoded form. A certificate is represented in text as an "EncodedCertificate",
Original text:
The "Client-Cert" header field defined herein is only for use in HTTP requests and MUST NOT be used in HTTP responses.  It is a single HTTP <del> header field-value as defined in Section 3.2 of RFC7230, which MUST </del>  NOT have a list of values or occur multiple times in a request. 2.3.

Reviewer comments:
This was languishing in a PR within my repo, but since we've merged the actual draft, we can promote this to a PR in the main repo as well. (Yes, I'll rename the tag if we merge this as-is.)

Revised text:
The "Client-Cert" header field defined herein is only for use in HTTP requests and MUST NOT be used in HTTP responses.  It is a single HTTP  <ins> header field value as defined in Section 3.2 of RFC7230, which MUST </ins> NOT have a list of values or occur multiple times in a request. 2.3.
Original text:
be met in a number of ways, which will vary based on specific deployments.  The communication between a TTRP and backend or origin server, for example, might be authenticated in some way with the <del> insertion and consumption of the "Client-Cert" header occurring only </del>  on that connection.  Alternatively the network topology might dictate a private network such that the backend application is only able to accept requests from the TTRP and the proxy can only make requests to

Reviewer comments:
This was languishing in a PR within my repo, but since we've merged the actual draft, we can promote this to a PR in the main repo as well. (Yes, I'll rename the tag if we merge this as-is.)

Revised text:
be met in a number of ways, which will vary based on specific deployments.  The communication between a TTRP and backend or origin server, for example, might be authenticated in some way with the  <ins> insertion and consumption of the "Client-Cert" field occurring only </ins> on that connection.  Alternatively the network topology might dictate a private network such that the backend application is only able to accept requests from the TTRP and the proxy can only make requests to
Original text:
[2] http://httpwg.github.io/ [3] https://github.com/httpwg/http-extensions/labels/client-cert- <del> header </del> 

Reviewer comments:
This was languishing in a PR within my repo, but since we've merged the actual draft, we can promote this to a PR in the main repo as well. (Yes, I'll rename the tag if we merge this as-is.)

Revised text:
[2] http://httpwg.github.io/ [3] https://github.com/httpwg/http-extensions/labels/client-cert-  <ins> field </ins>
Original text:
To sign using this algorithm, the signer applies the "RSASSA-PSS-SIGN (K, M)" function RFC8017 with the signer's private signing key ("K") <del> and the signature input string ("M") (create-sig-input).  The hash SHA-512 RFC6234 is applied to the signature input string to create the digest content to which the digital signature is applied.  The resulting signed content byte array ("S") is the HTTP message signature output used in sign. </del>  To verify using this algorithm, the verifier applies the "RSASSA-PSS- VERIFY ((n, e), M, S)" function RFC8017 using the public key portion of the verification key material ("(n, e)") and the signature input <del> string ("M") re-created as described in verify.  The hash function SHA-512 RFC6234 is applied to the signature input string to create the digest content to which the verification function is applied. The verifier extracts the HTTP message signature to be verified ("S") as described in verify.  The results of the verification function are compared to the http message signature to determine if the signature presented is valid. </del>  3.3.2.

Reviewer comments:
This text should be more precise about the definition of different signature parameters, including inputs to PSS. All examples have been updated. Examples for ECDSA and HMAC have been added.

Revised text:
To sign using this algorithm, the signer applies the "RSASSA-PSS-SIGN (K, M)" function RFC8017 with the signer's private signing key ("K")  <ins> and the signature input string ("M") (create-sig-input).  The mask generation function is "MGF1" as specified in RFC8017 with a hash function of SHA-512 RFC6234.  The salt length ("sLen") is 64 bytes. The hash function ("Hash") SHA-512 RFC6234 is applied to the signature input string to create the digest content to which the digital signature is applied.  The resulting signed content byte array ("S") is the HTTP message signature output used in sign. </ins> To verify using this algorithm, the verifier applies the "RSASSA-PSS- VERIFY ((n, e), M, S)" function RFC8017 using the public key portion of the verification key material ("(n, e)") and the signature input  <ins> string ("M") re-created as described in verify.  The mask generation function is "MGF1" as specified in RFC8017 with a hash function of SHA-512 RFC6234.  The salt length ("sLen") is 64 bytes.  The hash function ("Hash") SHA-512 RFC6234 is applied to the signature input string to create the digest content to which the verification function is applied.  The verifier extracts the HTTP message signature to be verified ("S") as described in verify.  The results of the verification function are compared to the http message signature to determine if the signature presented is valid. </ins> 3.3.2.
Original text:
applied.  The resulting signed content byte array ("S") is the HTTP message signature output used in sign. <del> To verify using this algorithm, the verifier applies the "RSASSA-PSS- VERIFY ((n, e), M, S)" function RFC8017 using the public key portion of the verification key material ("(n, e)") and the signature input string ("M") re-created as described in verify.  The hash function SHA-256 RFC6234 is applied to the signature input string to create the digest content to which the verification function is applied. The verifier extracts the HTTP message signature to be verified ("S") as described in verify.  The results of the verification function are compared to the http message signature to determine if the signature presented is valid. </del>  3.3.3.

Reviewer comments:
This text should be more precise about the definition of different signature parameters, including inputs to PSS. All examples have been updated. Examples for ECDSA and HMAC have been added.

Revised text:
applied.  The resulting signed content byte array ("S") is the HTTP message signature output used in sign.  <ins> To verify using this algorithm, the verifier applies the "RSASSA- PKCS1-V1_5-VERIFY ((n, e), M, S)" function RFC8017 using the public key portion of the verification key material ("(n, e)") and the signature input string ("M") re-created as described in verify.  The hash function SHA-256 RFC6234 is applied to the signature input string to create the digest content to which the verification function is applied.  The verifier extracts the HTTP message signature to be verified ("S") as described in verify.  The results of the verification function are compared to the http message signature to determine if the signature presented is valid. </ins> 3.3.3.
Original text:
policy RFC8126 and shall follow the template presented in iana-hsa- template.  5.1.1.

Reviewer comments:
This text should be more precise about the definition of different signature parameters, including inputs to PSS. All examples have been updated. Examples for ECDSA and HMAC have been added.

Revised text:
policy RFC8126 and shall follow the template presented in iana-hsa- template. <ins> Algorithms referenced by algorithm identifiers have to be fully defined with all parameters fixed.  Algorithm identifiers in this registry are to be interpreted as whole string values and not as a combination of parts.  That is to say, it is expected that implementors understand "rsa-pss-sha512" as referring to one specific algorithm with its hash, mask, and salt values set as defined here. Implementors do not parse out the "rsa", "pss", and "sha512" portions of the identifier to determine parameters of the signing algorithm from the string. </ins> 5.1.1.
Original text:
2.3. <del> A prefix of a List Structured Field consisting of the first N members in the field's value (where N is an integer greater than 0 and less than or equal to the number of members in the List) is identified by the parameter "prefix" with the value of N as an integer. A list prefix value is canonicalized by applying the serialization algorithm described in RFC8941 on a List containing only the first N members as specified in the list prefix, in the order they appear in the original List. 2.3.1. This section contains non-normative examples of canonicalized values for list prefixes given the following example header fields, whose values are assumed to be Dictionaries: The following table shows example canonicalized values for different content identifiers, given those fields: 2.4. </del> Content not found in an HTTP header can be included in the signature base string by defining a content identifier and the canonicalization method for its content.

Reviewer comments:
Remove the list prefix parameter operation on structured headers. This was previously added to allow for signing of a subset of combined headers, but since the combined header value cannot be considered a structured header value, the prefix functionality did not ultimately serve this purpose. However, common cases such as adding additional headers to a request could still be covered by a different mechanism. Note that dictionary key indexing is still allowed and facilitates multi-signature use cases.
(emphasis added by me) That sounds as if a subset of a list is not a valid list? How so?

Revised text:
2.3.  Content not found in an HTTP header can be included in the signature base string by defining a content identifier and the canonicalization method for its content.
Original text:
registered in the HTTP Signatures Specialty Content Identifier Registry. (content-registry) <del> 2.4.1. </del>  The request target endpoint, consisting of the request method and the path and query of the effective request URI, is identified by the

Reviewer comments:
Remove the list prefix parameter operation on structured headers. This was previously added to allow for signing of a subset of combined headers, but since the combined header value cannot be considered a structured header value, the prefix functionality did not ultimately serve this purpose. However, common cases such as adding additional headers to a request could still be covered by a different mechanism. Note that dictionary key indexing is still allowed and facilitates multi-signature use cases.
(emphasis added by me) That sounds as if a subset of a list is not a valid list? How so?

Revised text:
registered in the HTTP Signatures Specialty Content Identifier Registry. (content-registry)  <ins> 2.3.1. </ins> The request target endpoint, consisting of the request method and the path and query of the effective request URI, is identified by the