jiebi/TextFlow huggingface dataset:
Original text:
responds with a "Digest" field even though the client did not solicit one using "Want-Digest". <del> Some examples include JSON objects in the payload data.  For presentation purposes, objects that fit completely within the line- length limits are presented on a single line using compact notation with no leading space.  Objects that would exceed line-length limits are presented across multiple lines (one line per key-value pair) with 2 spaced of leading indentation. </del>  "Digest" is media-type agnostic and does not provide canonicalization algorithms for specific formats.  Examples of "Digest" are calculated

Reviewer comments:
Use "content" instead of "payload data".
to reference semantics-14, including "payload data" --> "content".

Revised text:
responds with a "Digest" field even though the client did not solicit one using "Want-Digest".  <ins> Some examples include JSON objects in the content.  For presentation purposes, objects that fit completely within the line-length limits are presented on a single line using compact notation with no leading space.  Objects that would exceed line-length limits are presented across multiple lines (one line per key-value pair) with 2 spaced of leading indentation. </ins> "Digest" is media-type agnostic and does not provide canonicalization algorithms for specific formats.  Examples of "Digest" are calculated
Original text:
10.2. <del> Requests without payload data can still send a "Digest" field applying the digest-algorithm to an empty representation. </del>  The response "Digest" field-value is calculated over the JSON object "{"hello": "world"}", which is not shown because there is no payload

Reviewer comments:
Use "content" instead of "payload data".
to reference semantics-14, including "payload data" --> "content".

Revised text:
10.2.  <ins> Requests without content can still send a "Digest" field applying the digest-algorithm to an empty representation. </ins> The response "Digest" field-value is calculated over the JSON object "{"hello": "world"}", which is not shown because there is no payload
Original text:
The response "Digest" field-value depends on the representation metadata header fields, including "Content-Encoding: br" even when <del> the response does not contain payload data. </del>  Request:

Reviewer comments:
Use "content" instead of "payload data".
to reference semantics-14, including "payload data" --> "content".

Revised text:
The response "Digest" field-value depends on the representation metadata header fields, including "Content-Encoding: br" even when  <ins> the response does not contain content. </ins> Request:
Original text:
Response: <del> Note that a "204 No Content" response without payload data but with the same "Digest" field-value would have been legitimate too. </del>  10.8.

Reviewer comments:
Use "content" instead of "payload data".
to reference semantics-14, including "payload data" --> "content".

Revised text:
Response:  <ins> Note that a "204 No Content" response without content but with the same "Digest" field-value would have been legitimate too. </ins> 10.8.
Original text:
Response: <del> Note that a "204 No Content" response without payload data but with the same "Digest" field-value would have been legitimate too. </del>  10.10.

Reviewer comments:
Use "content" instead of "payload data".
to reference semantics-14, including "payload data" --> "content".

Revised text:
Response:  <ins> Note that a "204 No Content" response without content but with the same "Digest" field-value would have been legitimate too. </ins> 10.10.
Original text:
The following examples demonstrate interactions where a client solicits a "Digest" using "Want-Digest". <del> Some examples include JSON objects in the payload data.  For presentation purposes, objects that fit completely within the line- length limits are presented on a single line using compact notation with no leading space.  Objects that would exceed line-length limits are presented across multiple lines (one line per key-value pair) with 2 spaced of leading indentation. </del>  "Digest" is media-type agnostic and does not provide canonicalization algorithms for specific formats.  Examples of "Digest" are calculated

Reviewer comments:
Use "content" instead of "payload data".
to reference semantics-14, including "payload data" --> "content".

Revised text:
The following examples demonstrate interactions where a client solicits a "Digest" using "Want-Digest".  <ins> Some examples include JSON objects in the content.  For presentation purposes, objects that fit completely within the line-length limits are presented on a single line using compact notation with no leading space.  Objects that would exceed line-length limits are presented across multiple lines (one line per key-value pair) with 2 spaced of leading indentation. </ins> "Digest" is media-type agnostic and does not provide canonicalization algorithms for specific formats.  Examples of "Digest" are calculated
Original text:
12.7. When "Digest" is used in trailer fields, the receiver gets the digest <del> value after the payload data and may thus be tempted to process the data before validating the digest value.  It is prefereable that data is only be processed after validating the Digest. </del>  If received in trailers, "Digest" MUST NOT be discarded; instead, it MAY be merged in the header section (See Section 6.5.1 of SEMANTICS).

Reviewer comments:
Use "content" instead of "payload data".
to reference semantics-14, including "payload data" --> "content".

Revised text:
12.7. When "Digest" is used in trailer fields, the receiver gets the digest  <ins> value after the content and may thus be tempted to process the data before validating the digest value.  It is prefereable that data is only be processed after validating the Digest. </ins> If received in trailers, "Digest" MUST NOT be discarded; instead, it MAY be merged in the header section (See Section 6.5.1 of SEMANTICS).
Original text:
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 <del> of integrity "at rest" unless the whole (e.g. encoded) payload data is persisted. </del>  12.9.

Reviewer comments:
Use "content" instead of "payload data".
to reference semantics-14, including "payload data" --> "content".

Revised text:
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  <ins> of integrity "at rest" unless the whole (e.g. encoded) content is persisted. </ins> 12.9.
Original text:
required. Certificates - Applications using HTTP should specify that TLS <del> certificates are to be checked according to I-D.ietf-httpbis- semantics, Section 4.3.4 when HTTPS is used. </del>  Applications using HTTP should not statically require HTTP features that are usually negotiated to be supported by clients.  For example,

Reviewer comments:
I think this is a matter of taste, so I'm inclined to leave it as is. Could you please update your PRs to make the style consistent and back out these changes?
Consistent with what? There are two suggested forms of references ("Section x of [FOO]" and "[FOO], Section x"). Both have their legitimate uses. What doesn't work for me is using the second form inside a sentence without any delimitation, because it introduces a comma in the sentence structure where it does not be belong.

Revised text:
required. Certificates - Applications using HTTP should specify that TLS  <ins> certificates are to be checked according to Section 4.3.4 of I- D.ietf-httpbis-semantics when HTTPS is used. </ins> Applications using HTTP should not statically require HTTP features that are usually negotiated to be supported by clients.  For example,
Original text:
validation first because it does not always require a conversion into identity encoding. <del> There is a chance that a user agent supporting both mechanisms may find one validates successfully while the other fails.  This document specifies no requirements or guidance for user agents that experience such cases. </del>  10.

Reviewer comments:
clarifies that you can always ignore you can ignore when using SRI if you validate both, it is nice to provide useful errors
Me neither, but this comes from RFC3230.
Well. This is a standards track doc developed in an IETF WG. If we want to change things, we can.
"There is a chance that a user agent supporting both mechanisms may find one validates successfully while the other fails. This document specifies no requirements or guidance for user agents that experience such cases." This makes it sound almost as if it could be ok to ignore an error on one level if there's no error on the other level. I think the spec should say that a user agent supporting both mechanisms must implement all requirements of both specs, no matter what.
Thanks Julian. I agree and will make a PR to tighten up the language.
NAME should we really specify what a SRI implementor should do? RFC3230 explicitly states that URL and we are not changing this.
That doesn't seem to be producing a list in the actual Internet Draft; see URL - maybe an indentation problem.

Revised text:
validation first because it does not always require a conversion into identity encoding.  <ins> A user agent supporting both mechanisms: - can legitimately ignore "Digest" when using SRI, because digest specifies that "a recipient MAY ignore any or all of the representation-data-digests"; - enforce both "Digest" and SRI: in this case it can be useful to provide enough information to identify whether the mismatch happened at the "Digest" or the SRI level. </ins> 10.
Original text:
The SEARCH method is used to initiate a server-side search.  Unlike the HTTP GET method, which requests that a server return a  representation of the resource identified by the effective request <del> URI (as defined by RFC7230), the SEARCH method is used to ask the server to perform a query operation (described by the request payload) over some set of data scoped to the effective request URI. The payload returned in response to a SEARCH cannot be assumed to be a representation of the resource identified by the effective request </del> URI. The body payload of the request defines the query.  Implementations MAY use a request body of any content type with the SEARCH method; however, for backwards compatibility with existing WebDAV implementations, SEARCH requests that use the text/xml or <del> application/xml content types MUST be processed per the requirements </del>  established by RFC5323. SEARCH requests are both safe and idempotent with regards to the

Reviewer comments:
content-type / media type header / header field
This should include updating the core spec references; I will update this PR accordingly unless you get to that before me.
See

Revised text:
The SEARCH method is used to initiate a server-side search.  Unlike the HTTP GET method, which requests that a server return a <ins> representation of the resource identified by the target URI (as defined by RFCHTTP), the SEARCH method is used to ask the server to perform a query operation (described by the request payload) over some set of data scoped to the effective request URI.  The payload returned in response to a SEARCH cannot be assumed to be a </ins> representation of the resource identified by the effective request  URI. The body payload of the request defines the query.  Implementations MAY use a request body of any content type with the SEARCH method; however, for backwards compatibility with existing WebDAV implementations, SEARCH requests that use the text/xml or  <ins> application/xml media types MUST be processed per the requirements </ins> established by RFC5323. SEARCH requests are both safe and idempotent with regards to the
Original text:
indication as to the final disposition of the search operation.  For instance, a successful search that yields no results can be represented by a 204 No Content response.  If the response includes a <del> body payload, the payload is expected to describe the results of the search operation.  In some cases, the server may choose to respond </del>  indirectly to the SEARCH request by returning a 3xx Redirection with <del> a Location header specifying an alternate Request URI from which the search results can be retrieved using an HTTP GET request.  Various non-normative examples of successful SEARCH responses are illustrated in examples. </del>  The response to a SEARCH request is not cacheable.  It ought to be noted, however, that because SEARCH requests are safe and idempotent,

Reviewer comments:
content-type / media type header / header field
This should include updating the core spec references; I will update this PR accordingly unless you get to that before me.
See

Revised text:
indication as to the final disposition of the search operation.  For instance, a successful search that yields no results can be represented by a 204 No Content response.  If the response includes a  <ins> content, it is expected to describe the results of the search operation.  In some cases, the server may choose to respond </ins> indirectly to the SEARCH request by returning a 3xx Redirection with  <ins> a Location header field specifying an alternate Request URI from which the search results can be retrieved using an HTTP GET request. Various non-normative examples of successful SEARCH responses are illustrated in examples. </ins> The response to a SEARCH request is not cacheable.  It ought to be noted, however, that because SEARCH requests are safe and idempotent,
Original text:
The semantics of the SEARCH method change to a "conditional SEARCH" if the request message includes an If-Modified-Since, If-Unmodified- <del> Since, If-Match, If-None-Match, or If-Range header field (RFC7232). </del>  A conditional SEARCH requests that the query be performed only under the circumstances described by the conditional header field(s).  It is important to note, however, that such conditions are evaluated

Reviewer comments:
content-type / media type header / header field
This should include updating the core spec references; I will update this PR accordingly unless you get to that before me.
See

Revised text:
The semantics of the SEARCH method change to a "conditional SEARCH" if the request message includes an If-Modified-Since, If-Unmodified-  <ins> Since, If-Match, If-None-Match, or If-Range header field (RFCHTTP). </ins> A conditional SEARCH requests that the query be performed only under the circumstances described by the conditional header field(s).  It is important to note, however, that such conditions are evaluated
Original text:
The "Accept-Search" response header field MAY be used by a server to directly signal support for the SEARCH method while identifying the <del> specific query format Content-Type's that may be used. </del>  <del> The Accept-Search header specifies a comma-separated listing of media types (with optional parameters) as defined by RFC7231. </del>  <del> The order of types listed by the Accept-Search header is </del>  insignificant. 4.

Reviewer comments:
content-type / media type header / header field
This should include updating the core spec references; I will update this PR accordingly unless you get to that before me.
See

Revised text:
The "Accept-Search" response header field MAY be used by a server to directly signal support for the SEARCH method while identifying the  <ins> specific query format media types that may be used. </ins>  <ins> The Accept-Search header field specifies a comma-separated listing of media types (with optional parameters) as defined by RFCHTTP. </ins>  <ins> The order of types listed by the Accept-Search header field is </ins> insignificant. 4.
Original text:
5. The SEARCH method is subject to the same general security <del> considerations as all HTTP methods as described in RFC7231. </del>  6. IANA is requested to update the registration of the SEARCH method in the permanent registry at <http://www.iana.org/assignments/http- <del> methods> (see RFC7231). </del> 

Reviewer comments:
content-type / media type header / header field
This should include updating the core spec references; I will update this PR accordingly unless you get to that before me.
See

Revised text:
5. The SEARCH method is subject to the same general security  <ins> considerations as all HTTP methods as described in RFCHTTP. </ins> 6. IANA is requested to update the registration of the SEARCH method in the permanent registry at <http://www.iana.org/assignments/http-  <ins> methods> (see RFCHTTP). </ins>
Original text:
Abstract <del> This document defines the HTTP Digest and Want-Digest fields, thus allowing client and server to negotiate an integrity checksum of the </del>  exchanged resource representation data. <del> This document obsoletes RFC 3230.  It replaces the term "instance" with "representation", which makes it consistent with the HTTP Semantic and Context defined in draft-ietf-httpbis-semantics. </del>  Note to Readers

Reviewer comments:
This change is done while ignoring the fact that we might want a bigger document reshuffle when bringing in a "content-digest" header. But it helps illustrate how the abstract / intro could be editorialized to address some off-list feedback.
LGTM :)

Revised text:
Abstract  <ins> This document defines the HTTP Digest and Want-Digest fields, which allows client and server to negotiate an integrity checksum of the </ins> exchanged resource representation data.  <ins> This document obsoletes RFC 3230. </ins> Note to Readers
Original text:
resources which uses a checksum that is calculated independently of the content (see Section 6.4 of SEMANTICS).  It uses the representation data (see Section 8.1 of SEMANTICS), that can be fully <del> or partially contained in the content, or not contained at all: </del>  This takes into account the effect of the HTTP semantics on the messages; for example, the content can be affected by Range Requests

Reviewer comments:
[x] 3. It's probably worth mentioning that they're comma-separated in prose. [ ] 3. I'm uncomfortable with relying on examples to specify how this spec works normatively; by their nature, examples are not 'comprehensive.' While this spec shouldn't re-specify HTTP, the header's definition should be clear enough that a reader doesn't have to dig around in the examples and other specs to understand what's going on. [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.

Revised text:
resources which uses a checksum that is calculated independently of the content (see Section 6.4 of SEMANTICS).  It uses the representation data (see Section 8.1 of SEMANTICS), that can be fully  <ins> or partially contained in the content, or not contained at all. </ins> This takes into account the effect of the HTTP semantics on the messages; for example, the content can be affected by Range Requests
Original text:
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 that uses base64 encoding. </del> 3. The "Digest" field contains a comma-separated list of one or more

Reviewer comments:
[x] 3. It's probably worth mentioning that they're comma-separated in prose. [ ] 3. I'm uncomfortable with relying on examples to specify how this spec works normatively; by their nature, examples are not 'comprehensive.' While this spec shouldn't re-specify HTTP, the header's definition should be clear enough that a reader doesn't have to dig around in the examples and other specs to understand what's going on. [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.

Revised text:
The checksum is computed using one of the digest-algorithms listed in algorithms and then encoded in the associated format.  3. The "Digest" field contains a comma-separated list of one or more
Original text:
Digest-algorithm values are used to indicate a specific digest computation. <del> All digest-algorithm values are case-insensitive but lower case is preferred. </del>  <del> The Internet Assigned Numbers Authority (IANA) acts as a registry for digest-algorithm values.  The registry contains the tokens listed below. </del>  <del> Some digest-algorithms, although registered, rely on vulnerable algorithms and MUST not be used: </del>  "md5", see CMU-836068 and NO-MD5;

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:
Digest-algorithm values are used to indicate a specific digest computation.  <ins> All digest-algorithm token values are case-insensitive but lower case is preferred; digest-algorithm token values MUST be compared in a case-insensitive fashion. </ins>  <ins> The Internet Assigned Numbers Authority (IANA) maintains a registry for digest-algorithm values.  The registry is initialized with the tokens listed below. </ins>  <ins> Deprecated digest algorithms MUST NOT be used: </ins> "md5", see CMU-836068 and NO-MD5;
Original text:
Description: The MD5 algorithm, as specified in RFC1321.  The output of this algorithm is encoded using the base64 encoding <del> RFC4648.  This digest-algorithm MUST NOT be used as it's now vulnerable to collision attacks.  See NO-MD5 and CMU-836068. </del>  Reference: RFC1321, 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 MD5 algorithm, as specified in RFC1321.  The output of this algorithm is encoded using the base64 encoding  <ins> RFC4648.  This digest-algorithm is now vulnerable to collision attacks.  See NO-MD5 and CMU-836068. </ins> Reference: RFC1321, RFC4648, this document.