jiebi/TextFlow huggingface dataset:
Original text:
after validating the Digest. If received in trailers, Digest MUST NOT be discarded; instead it MAY <del> be merged in the header section (See Section 7.1.2 of !MESSAGING=I- D.ietf-httpbis -messaging). </del>  Not every digest-algorithm is suitable for trailers, as they may require to pre-process the whole payload before sending a message

Reviewer comments:
HTTP 1.1 messaging is not normative replaced "message body" with a periphrases
Digest to be indepentent from http/1.1 (messaging) See URL
NAME iiuc the only MESSAGING-depending parts is: URL The spec references the term "message body" 3 times too, which is defined in MESSAGING. Do you think we should replace it? How would you do it?
trailers: you may want to reference URL message body: this might be "payload" (URL)

Revised text:
after validating the Digest. If received in trailers, Digest MUST NOT be discarded; instead it MAY  <ins> be merged in the header section (See Section 5.6.2 of SEMANTICS). </ins> Not every digest-algorithm is suitable for trailers, as they may require to pre-process the whole payload before sending a message
Original text:
different digest values. To allow both parties to exchange a Digest of a representation with <del> no content codings (see Section 7.1.2 of SEMANTICS) two more </del>  algorithms are added ("id-sha-256" and "id-sha-512"). 1.3.

Reviewer comments:
is preliminary to Consistently use instead of . In case we need to further focus on the value, we can say or . Looking at "content-coding" vs "content coding" in URL I think that this choice makes the document more readable.

Revised text:
different digest values. To allow both parties to exchange a Digest of a representation with  <ins> no content codings (see Section 7.1.2 of SEMANTICS) two more digest- </ins> algorithms are added ("id-sha-256" and "id-sha-512"). 1.3.
Original text:
Digest coverage for either the resource's "representation data" or "selected representation data" communicated via HTTP. <del> Support for multiple digest algorithms. </del>  Negotiation of the use of digests.

Reviewer comments:
is preliminary to Consistently use instead of . In case we need to further focus on the value, we can say or . Looking at "content-coding" vs "content coding" in URL I think that this choice makes the document more readable.

Revised text:
Digest coverage for either the resource's "representation data" or "selected representation data" communicated via HTTP.  <ins> Support for multiple digest-algorithms. </ins> Negotiation of the use of digests.
Original text:
SEMANTICS together with an indication of the algorithm used (and any parameters) <del> The checksum is computed using one of the "digest-algorithms" listed in algorithms and then encoded in the associated format. </del>  The example below shows the "sha-256" digest-algorithm which uses base64 encoding.

Reviewer comments:
is preliminary to Consistently use instead of . In case we need to further focus on the value, we can say or . Looking at "content-coding" vs "content coding" in URL I think that this choice makes the document more readable.

Revised text:
SEMANTICS together with an indication of the algorithm used (and any parameters)  <ins> The checksum is computed using one of the digest-algorithms listed in algorithms and then encoded in the associated format. </ins> The example below shows the "sha-256" digest-algorithm which uses base64 encoding.
Original text:
5. <del> Digest algorithm values are used to indicate a specific digest computation.  For some algorithms, one or more parameters can be supplied. </del>  The BNF for "parameter" is defined in Section 5.4.1.4 of SEMANTICS. All digest-algorithm values are case-insensitive.

Reviewer comments:
is preliminary to Consistently use instead of . In case we need to further focus on the value, we can say or . Looking at "content-coding" vs "content coding" in URL I think that this choice makes the document more readable.

Revised text:
5.  <ins> Digest-algorithm values are used to indicate a specific digest computation.  For some digest-algorithms, one or more parameters can be supplied. </ins> The BNF for "parameter" is defined in Section 5.4.1.4 of SEMANTICS. All digest-algorithm values are case-insensitive.
Original text:
digest-algorithm values.  The registry contains the tokens listed below. <del> Some algorithms, although registered, have since been found vulnerable: the "MD5" algorithm MUST NOT be used due to collision attacks CMU-836068 and the "SHA" algorithm MUST NOT be used due to collision attacks IACR-2020-014. </del> 

Reviewer comments:
is preliminary to Consistently use instead of . In case we need to further focus on the value, we can say or . Looking at "content-coding" vs "content coding" in URL I think that this choice makes the document more readable.

Revised text:
digest-algorithm values.  The registry contains the tokens listed below.  <ins> Some digest-algorithms, although registered, rely on vulnerable algorithms: the "MD5" digest-algorithm MUST NOT be used due to collision attacks CMU-836068 and the "SHA" digest-algorithm MUST NOT be used due to collision attacks IACR-2020-014. </ins>
Original text:
9.2. Requests without a payload body can still send a "Digest" field <del> applying the digest algorithm to an empty representation. </del>  As there is no content coding applied, the "sha-256" and the "id-sha- 256" digest-values in the response are the same.

Reviewer comments:
is preliminary to Consistently use instead of . In case we need to further focus on the value, we can say or . Looking at "content-coding" vs "content coding" in URL I think that this choice makes the document more readable.

Revised text:
9.2. Requests without a payload body can still send a "Digest" field  <ins> applying the digest-algorithm to an empty representation. </ins> As there is no content coding applied, the "sha-256" and the "id-sha- 256" digest-values in the response are the same.
Original text:
12.3. <del> This memo updates the "MD5" digest algorithm in the HTTP Digest </del>  Algorithm Values [5] registry: Digest Algorithm: MD5

Reviewer comments:
is preliminary to Consistently use instead of . In case we need to further focus on the value, we can say or . Looking at "content-coding" vs "content coding" in URL I think that this choice makes the document more readable.

Revised text:
12.3.  <ins> This memo updates the "MD5" digest-algorithm in the HTTP Digest </ins> Algorithm Values [5] registry: Digest Algorithm: MD5
Original text:
12.4. <del> This memo updates the "CRC32c" digest algorithm in the HTTP Digest </del>  Algorithm Values [6] registry: Digest Algorithm: CRC32c

Reviewer comments:
is preliminary to Consistently use instead of . In case we need to further focus on the value, we can say or . Looking at "content-coding" vs "content coding" in URL I think that this choice makes the document more readable.

Revised text:
12.4.  <ins> This memo updates the "CRC32c" digest-algorithm in the HTTP Digest </ins> Algorithm Values [6] registry: Digest Algorithm: CRC32c
Original text:
12.5. <del> This memo updates the "SHA" digest algorithm in the HTTP Digest </del>  Algorithm Values [7] registry: Digest Algorithm: SHA

Reviewer comments:
is preliminary to Consistently use instead of . In case we need to further focus on the value, we can say or . Looking at "content-coding" vs "content coding" in URL I think that this choice makes the document more readable.

Revised text:
12.5.  <ins> This memo updates the "SHA" digest-algorithm in the HTTP Digest </ins> Algorithm Values [7] registry: Digest Algorithm: SHA
Original text:
12.6. <del> This memo updates the "ADLER32" digest algorithm in the HTTP Digest </del>  Algorithm Values [8] registry: Digest Algorithm: ADLER32

Reviewer comments:
is preliminary to Consistently use instead of . In case we need to further focus on the value, we can say or . Looking at "content-coding" vs "content coding" in URL I think that this choice makes the document more readable.

Revised text:
12.6.  <ins> This memo updates the "ADLER32" digest-algorithm in the HTTP Digest </ins> Algorithm Values [8] registry: Digest Algorithm: ADLER32
Original text:
The status of "MD5" has been updated to "deprecated", and its description states that this algorithm MUST NOT be used. <del> The status of "SHA" has been updated to "obsoleted", and its description states that this algorithm is NOT RECOMMENDED. </del>  The status for "CRC32c" has been updated to "standard".

Reviewer comments:
Aligns a part of the doc with the SHA-1 deprecation we decided in We correctly deprecated SHA-1 but in this part we left it as NOT RECOMMENDED.

Revised text:
The status of "MD5" has been updated to "deprecated", and its description states that this algorithm MUST NOT be used.  <ins> The status of "SHA" has been updated to "deprecated", and its description states that this algorithm MUST NOT be used. </ins> The status for "CRC32c" has been updated to "standard".
Original text:
Via (RFC7230, Section 5.7.1) <del> Responding to requests coming through an intermediary in a round- robin manner works well when the network bottleneck exists between the intermediary and the end client, as the intermediary would be buffering the responses and then be forwarding the chunks of those buffered responses based on the prioritization scheme it implements. A sophisticated server MAY use a weighted round-robin reflecting the urgencies expressed in the requests, so that less urgent responses would receive less bandwidth in case the bottleneck exists between the server and the intermediary. </del> 8.2. It is common for CDN infrastructure to support different HTTP

Reviewer comments:
cc NAME since it closes your issue.
I believe this is now good to go, please approve or speak up if you disagree.
In there is a rather firm recommendation to erase priorities at servers that are served by coalescing intermediaries: This seems wrong to me. The Priority header field provides information about what the User Agent thinks of priority. This might be adjusted by intermediaries on the path, and it might not be globally consistent, but that does not mean the information should be discarded. Instead, I would prefer that we say that when an intermediary coalesces requests from multiple clients, servers need to be aware of that and account for that in their processing. The remainder of this text is fine in the sense that it identifies information the server can use to more fairly allocate resources to different requests, but - again - this is just information the server uses when making prioritization decisions. The model we operate on should not assume be that Priority is an instruction to the server, but that it provides the server (or intermediary) clues about how it might decide to allocate resources.
No one responded to this for a while, sorry. The text is mostly untouched but I did change the example to just . My read of this today, I'm concerned that the requirement is a bit specific. It's not clear if a server applying this would also discard any additional priority parameters. I don't know if NAME original point was along those lines or not, but I'll try to make a PR to address what I think needs fixing

Revised text:
Via (RFC7230, Section 5.7.1)  8.2. It is common for CDN infrastructure to support different HTTP
Original text:
A PRIORITY_UPDATE frame communicates a complete set of all parameters in the Priority Field Value field.  Omitting a parameter is a signal to use the parameter's default value.  Failure to parse the Priority <del> Field Value MUST be treated as a connection error of type FRAME_ENCODING_ERROR. </del>  A client MAY send a PRIORITY_UPDATE frame before the stream that it references is open.  Furthermore, HTTP/3 offers no guaranteed

Reviewer comments:
NAME correctly pointed out that the draft contained a made up error code. On inspection, we need to define specific error codes for both H2 and H3. This change does that.
The latest version of the draft states: There is no such error either in or in . Perhaps HTTP/3's H3FRAMEERROR was meant?
Dang, I worked from memory and should've spent 2 minutes for checking. I'll get this fixed up thanks.

Revised text:
A PRIORITY_UPDATE frame communicates a complete set of all parameters in the Priority Field Value field.  Omitting a parameter is a signal to use the parameter's default value.  Failure to parse the Priority  <ins> Field Value MUST be treated as a connection error.  In HTTP/2 the error is of type PROTOCOL_ERROR; in HTTP/3 the error is of type H3_FRAME_ERROR. </ins> A client MAY send a PRIORITY_UPDATE frame before the stream that it references is open.  Furthermore, HTTP/3 offers no guaranteed
Original text:
"Digest" may expose information details of encrypted payload when the checksum is computed on the unencrypted data.  An example of that is <del> the use of the "id-sha-256" digest-algorithm in conjuction with the </del>  encrypted content-coding RFC8188.  11.9. ...

Reviewer comments:
details encryption quirks: encryption functions may produce different results with the same data this means that if I GET an encrypted resource twice, I could get two different digest values so the digest value is just good to validate the ongoing message and not for further processing of the data at rest, unless I store the encrypted data or use an algorithm which in turn might disclose information. This
looks good, just some nits.

Revised text:
"Digest" may expose information details of encrypted payload when the checksum is computed on the unencrypted data.  An example of that is  <ins> the use of the "id-sha-256" digest-algorithm in conjunction with the </ins> encrypted content-coding RFC8188. <ins> The representation-data-digest of an encrypted payload can change between different messages depending on the encryption algorithm used; in those cases its value could not be used to provide a proof of integrity "at rest" unless the whole (e.g. encoded) payload body is persisted. </ins> 11.9. ...
Original text:
However, there are cases where relying on this alone is insufficient. An HTTP-level integrity mechanism that operates independent of transfer can be used to detect programming errors and/or corruption <del> of data at rest, be used across multiple hops in order to provide end-to-end integrity guarantees, aid fault diagnosis across hops and system boundaries, and can be used to validate integrity when reconstructing a resource fetched using different HTTP connections. </del>  This document defines a mechanism that acts on HTTP representation- data.  It can be combined with other mechanisms that protect

Reviewer comments:
[x] avoid ambiguous statement on digest protecting from compressed content-coding URL i[x] t can protect from intermediaries altering representation metadata (content-type, content-coding)

Revised text:
However, there are cases where relying on this alone is insufficient. An HTTP-level integrity mechanism that operates independent of transfer can be used to detect programming errors and/or corruption  <ins> of data in flight or at rest, be used across multiple hops in order to provide end-to-end integrity guarantees, aid fault diagnosis across hops and system boundaries, and can be used to validate integrity when reconstructing a resource fetched using different HTTP connections. </ins> This document defines a mechanism that acts on HTTP representation- data.  It can be combined with other mechanisms that protect
Original text:
not the "representation metadata". Besides, it allows to protect "representation data" from buggy <del> manipulation, buggy compression, etc. </del>  Moreover, identity digest-algorithms (eg. "id-sha-256" and "id-sha- 512") allow piecing together a resource from different sources (e.g.

Reviewer comments:
[x] avoid ambiguous statement on digest protecting from compressed content-coding URL i[x] t can protect from intermediaries altering representation metadata (content-type, content-coding)

Revised text:
not the "representation metadata". Besides, it allows to protect "representation data" from buggy  <ins> manipulation, undesired "transforming proxies" (see Section 6.5 of SEMANTICS), etc. </ins> Moreover, identity digest-algorithms (eg. "id-sha-256" and "id-sha- 512") allow piecing together a resource from different sources (e.g.
Original text:
simplifies processing and avoids timezone management required by specifications such as RFC3339. <del> 2.3. </del>  The signature's Expiration Time (signature-metadata) is identified by <del> the "(expired)" identifier. </del>  Its canonicalized value is a Decimal String containing the signature's Expiration Time expressed as the number of seconds since the Epoch, as defined in Section 4.16 [4] of POSIX.1. <del> 2.4. </del>  The request target endpoint, consisting of the request method and the path and query of the effective request URI, is identified by the <del> "(request-target)" identifier. </del>  Its value is canonicalized as follows:

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:
simplifies processing and avoids timezone management required by specifications such as RFC3339.  <ins> 2.5. </ins> The signature's Expiration Time (signature-metadata) is identified by  <ins> the "*expires" identifier. </ins> Its canonicalized value is a Decimal String containing the signature's Expiration Time expressed as the number of seconds since the Epoch, as defined in Section 4.16 [4] of POSIX.1.  <ins> 2.6. </ins> The request target endpoint, consisting of the request method and the path and query of the effective request URI, is identified by the  <ins> "*request-target" identifier. </ins> Its value is canonicalized as follows:
Original text:
header in HTTP2, Section 8.1.2.3.  The resulting string is the canonicalized value. <del> 2.4.1. </del>  The following table contains non-normative example HTTP messages and <del> their canonicalized "(request-target)" values. </del>  3.

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:
header in HTTP2, Section 8.1.2.3.  The resulting string is the canonicalized value.  <ins> 2.6.1. </ins> The following table contains non-normative example HTTP messages and  <ins> their canonicalized "*request-target" values. </ins> 3.
Original 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>  If the signature's Algorithm starts with rsa, hmac, or ecdsa, <del> 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:
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:
signature over the empty string. If the signature's Algorithm name does not start with rsa,  <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,  <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