jiebi/TextFlow huggingface dataset:
Original text:
[8] https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml [9] https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml 

Reviewer comments:
Obsolete ADLER-32 but don't forbid it.
NAME will this work for you?
I think the pull request is OK as-is, but might be improved slightly. In particularly, I'm wondering if SHOULD NOT is too strong for the server. A server could support ADLER32 without that support impacting on cryptographic data integrity provided that server also supports a cryptographically secure hash; e.g., SHA-512. Clients that wish to protect against malicious actor changes would use the SHA-512 hash and not request (or ignore) the ADLER32 value. Therefore, I would suggest that, for the server, the document says a server MAY implement ADLER32. I think it is perfectly reasonable for the document to say the client SHOULD NOT use ADLER32, for the reasons stated. That said, I can't decide if this distinction is really helpful, so I defer to your judgement, here.
I'm not so sure we want to make a distinction between client and server as you write it. Both client and server can attach Digest header to request or response. It is the receiver of Digest that is exposed to the risk of using a weak digest. The current language avoids mentioning either endpoint so we leave it to implementers. I'm not opposed to spelling things out more clearly but we'd really need to nail down what we mean by "using Digest algorithms" because that relates to requesting them, generating them, regenerating them (proxy), validating them (endpoint or proxy) etc.
That's a good point about client/server. Sorry, I had that wrong. As you say, it's the recipient of a Digest that must decide whether the algorithm is sufficient. This recipient may be either the client or the server. I think the document is right to point out the dangers of accepting a weak digest. Perhaps there is a useful distinction between generating a digest and accepting a digest; e.g., an agent MAY support generating a weak digest but SHOULD NOT accept a weak digest.
Not wrong, just partially true. That could work for me. I'll leave it to NAME to decide what he things makes sense to do.
NAME NAME as this issue is for ADLER, I moved the discussion to As it's in the listed algorithms, the server MAY already implement ADLER32, though it SHOULD NOT be used by both sides of the communication. I think sender and receiver should behave consistently (see again).
Merging as for the positive feedback from NAME and NAME comment URL

Revised text:
[8] https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml [9] https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml <ins> [10] https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml </ins>
Original text:
because it is not clear whether they will be used, and sending them impacts both performance and privacy. <del> This document defines two response headers, Accept-CH and Accept-CH- Lifetime, that servers can use to advertise their use of request headers for proactive content negotiation, along with a set of guidelines for the creation of such headers, colloquially known as "Client Hints." </del>  Note to Readers

Reviewer comments:
Based on discussion at IETF 105, removing explicit lifetime in favor of implicit opt-in registration and persistence. NAME can you please take a look? In particular, current language states the preference should be persisted but doesn't explicitly state for what the lifetime is.. Modulo, in privacy section we do talk about MUST criteria for clearing it. Any suggestions or recommendations for how to best approach this?
LGTM

Revised text:
because it is not clear whether they will be used, and sending them impacts both performance and privacy.  <ins> This document defines an Accept-CH response header that servers can use to advertise their use of request headers for proactive content negotiation, along with a set of guidelines for the creation of such headers, colloquially known as "Client Hints." </ins> Note to Readers
Original text:
This document defines a new response header, Accept-CH, that allows an origin server to explicitly ask that clients send these headers in <del> requests, for a period of time bounded by the Accept-CH-Lifetime response header.  It also defines guidelines for content negotiation </del>  mechanisms that use it, colloquially referred to as Client Hints. Client Hints mitigate the performance concerns by assuring that

Reviewer comments:
Based on discussion at IETF 105, removing explicit lifetime in favor of implicit opt-in registration and persistence. NAME can you please take a look? In particular, current language states the preference should be persisted but doesn't explicitly state for what the lifetime is.. Modulo, in privacy section we do talk about MUST criteria for clearing it. Any suggestions or recommendations for how to best approach this?
LGTM

Revised text:
This document defines a new response header, Accept-CH, that allows an origin server to explicitly ask that clients send these headers in  <ins> requests.  It also defines guidelines for content negotiation </ins> mechanisms that use it, colloquially referred to as Client Hints. Client Hints mitigate the performance concerns by assuring that
Original text:
will use that infrastructure.  Those features will be defined in their respective specifications. <del> This document does not supersede or replace the User-Agent header field.  Existing device detection mechanisms can continue to use both mechanisms if necessary.  By advertising user agent capabilities within a request header field, Client Hints allow for cache friendly and proactive content negotiation. </del> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Reviewer comments:
Based on discussion at IETF 105, removing explicit lifetime in favor of implicit opt-in registration and persistence. NAME can you please take a look? In particular, current language states the preference should be persisted but doesn't explicitly state for what the lifetime is.. Modulo, in privacy section we do talk about MUST criteria for clearing it. Any suggestions or recommendations for how to best approach this?
LGTM

Revised text:
will use that infrastructure.  Those features will be defined in their respective specifications.  1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Original text:
5. <del> This document defines the "Accept-CH" and "Accept-CH-Lifetime" HTTP response fields, and registers them in the Permanent Message Header Fields registry. </del>  5.1.

Reviewer comments:
Based on discussion at IETF 105, removing explicit lifetime in favor of implicit opt-in registration and persistence. NAME can you please take a look? In particular, current language states the preference should be persisted but doesn't explicitly state for what the lifetime is.. Modulo, in privacy section we do talk about MUST criteria for clearing it. Any suggestions or recommendations for how to best approach this?
LGTM

Revised text:
5.  <ins> This document defines the "Accept-CH" HTTP response field, and registers it in the Permanent Message Header Fields registry. </ins> 5.1.
Original text:
Specification document(s): accept-ch of this document Related information: for Client Hints <del> 5.2. Header field name: Accept-CH-Lifetime Applicable protocol: HTTP Status: standard Author/Change controller: IETF Specification document(s): accept-ch-lifetime of this document Related information: for Client Hints </del> 6.  References 6.1.  URIs

Reviewer comments:
Based on discussion at IETF 105, removing explicit lifetime in favor of implicit opt-in registration and persistence. NAME can you please take a look? In particular, current language states the preference should be persisted but doesn't explicitly state for what the lifetime is.. Modulo, in privacy section we do talk about MUST criteria for clearing it. Any suggestions or recommendations for how to best approach this?
LGTM

Revised text:
Specification document(s): accept-ch of this document Related information: for Client Hints  6.  References 6.1.  URIs
Original text:
algorithm without knowing whether the recipient supports the digest- algorithm, or even knowing that the recipient will ignore it.  ... 5.

Reviewer comments:
Adds id-sha-* algorithm examples throughout the document.
draft-ietf-httpbis-digest-headers includes examples of sha-256 in the Digest header value, but no examples of the two new algorithms it introduces: id-sha-256 and id-sha-512. Examples would be extremely useful to illustrate the difference between sha-256 and id-sha-256.
That sounds reasonable to me.
NAME WDYT?

Revised text:
algorithm without knowing whether the recipient supports the digest- algorithm, or even knowing that the recipient will ignore it. <ins> Examples: </ins> ... 5.
Original text:
7.1.2.  7.1.3. 7.1.4.

Reviewer comments:
Adds id-sha-* algorithm examples throughout the document.
draft-ietf-httpbis-digest-headers includes examples of sha-256 in the Digest header value, but no examples of the two new algorithms it introduces: id-sha-256 and id-sha-512. Examples would be extremely useful to illustrate the difference between sha-256 and id-sha-256.
That sounds reasonable to me.
NAME WDYT?

Revised text:
7.1.2. <ins> As there is no content coding applied, the "id-sha" and the "id-sha- 256" digest-values are the same. </ins> 7.1.3. 7.1.4.
Original text:
Digest can be used in requests too.  Returned value depends on the representation metadata header fields.  7.2. 7.2.1.

Reviewer comments:
Adds id-sha-* algorithm examples throughout the document.
draft-ietf-httpbis-digest-headers includes examples of sha-256 in the Digest header value, but no examples of the two new algorithms it introduces: id-sha-256 and id-sha-512. Examples would be extremely useful to illustrate the difference between sha-256 and id-sha-256.
That sounds reasonable to me.
NAME WDYT?

Revised text:
Digest can be used in requests too.  Returned value depends on the representation metadata header fields. <ins> 7.1.5. The response contains two digest values: one with no content coding applied, which in this case accidentally matches the unencoded digest-value sent in the request; one taking into account the "Content-Encoding". </ins> 7.2. 7.2.1.
Original text:
<del> Resource Digests for HTTP </del>  draft-ietf-httpbis-digest-headers-latest Abstract

Reviewer comments:
Align the I-D title with the .md file name suggested by NAME before the adoption.
We can consider to change the to the more direct .

Revised text:
 <ins> Digest Headers </ins> draft-ietf-httpbis-digest-headers-latest Abstract
Original text:
required to be unique within the scope of the dictionary they occur within.  Implementations MUST provide access to dictionaries both by index and by name.  Specifications MAY use either means of accessing the members.

Reviewer comments:
Now that we are generalizing how the types are used, I think it might be a good idea to allow a dictionary value to be a mapping (i.e., a list of parameters). This would be a generalization. At the moment, top level elements can contain scalars, lists, or dictionaries. However, it is at the moment impossible to use a dictionary at the second level even though scalars and lists are permitted. In terms of use-case, the proposed change would allow for example something like a cache-control directive to take a mapping as an argument (see URL). Logic-wise, I assume that the added complexity would not be significant, as we can reuse the definition for the parameters of a parameterised list.
NAME are you just asking for parameters on dictionary values, in a manner that's equivalent to list values?
NAME Sorry for the belated response. Yes. I'd be fine with member-value being exactly list-member.

Revised text:
required to be unique within the scope of the dictionary they occur within. <ins> Each member of the dictionary can also have associated parameters - an ordered map of key-value pairs where the keys are short, textual strings and the values are items (item).  There can be zero or more parameters on a member, and their keys are required to be unique within that scope. </ins> Implementations MUST provide access to dictionaries both by index and by name.  Specifications MAY use either means of accessing the members.
Original text:
A dictionary with a member whose value is an inner-list of tokens: <del> Typically, a header field specification will define the semantics of individual member names, as well as whether their presence is </del>  required or optional.  Recipients MUST ignore names that are undefined or unknown, unless the header field's specification specifically disallows them.

Reviewer comments:
Now that we are generalizing how the types are used, I think it might be a good idea to allow a dictionary value to be a mapping (i.e., a list of parameters). This would be a generalization. At the moment, top level elements can contain scalars, lists, or dictionaries. However, it is at the moment impossible to use a dictionary at the second level even though scalars and lists are permitted. In terms of use-case, the proposed change would allow for example something like a cache-control directive to take a mapping as an argument (see URL). Logic-wise, I assume that the added complexity would not be significant, as we can reuse the definition for the parameters of a parameterised list.
NAME are you just asking for parameters on dictionary values, in a manner that's equivalent to list values?
NAME Sorry for the belated response. Yes. I'd be fine with member-value being exactly list-member.

Revised text:
A dictionary with a member whose value is an inner-list of tokens:  <ins> A dictionary with a mix of singular and list values, some with parameters: Typically, a header field specification will define the semantics using individual member names, as well as whether their presence is </ins> required or optional.  Recipients MUST ignore names that are undefined or unknown, unless the header field's specification specifically disallows them.
Original text:
Append mem_value to output. <del> For each parameter in parameters: Append ";" to output. Let name be the result of applying Serializing a Key (ser- key) to parameter's param-name. Append name to output. If parameter has a param-value: Let value be the result of applying Serializing an Item (ser-item) to parameter's param-value. Append "=" to output. Append value to output. </del>  If more members remain in input_plist:

Reviewer comments:
Now that we are generalizing how the types are used, I think it might be a good idea to allow a dictionary value to be a mapping (i.e., a list of parameters). This would be a generalization. At the moment, top level elements can contain scalars, lists, or dictionaries. However, it is at the moment impossible to use a dictionary at the second level even though scalars and lists are permitted. In terms of use-case, the proposed change would allow for example something like a cache-control directive to take a mapping as an argument (see URL). Logic-wise, I assume that the added complexity would not be significant, as we can reuse the definition for the parameters of a parameterised list.
NAME are you just asking for parameters on dictionary values, in a manner that's equivalent to list values?
NAME Sorry for the belated response. Yes. I'd be fine with member-value being exactly list-member.

Revised text:
Append mem_value to output.  <ins> Append the result of Serializing Parameters ser-params with parameters to output. </ins> If more members remain in input_plist:
Original text:
4.1.1.2.  Given a key as input_key: If input_key is not a sequence of characters, or contains

Reviewer comments:
Now that we are generalizing how the types are used, I think it might be a good idea to allow a dictionary value to be a mapping (i.e., a list of parameters). This would be a generalization. At the moment, top level elements can contain scalars, lists, or dictionaries. However, it is at the moment impossible to use a dictionary at the second level even though scalars and lists are permitted. In terms of use-case, the proposed change would allow for example something like a cache-control directive to take a mapping as an argument (see URL). Logic-wise, I assume that the added complexity would not be significant, as we can reuse the definition for the parameters of a parameterised list.
NAME are you just asking for parameters on dictionary values, in a manner that's equivalent to list values?
NAME Sorry for the belated response. Yes. I'd be fine with member-value being exactly list-member.

Revised text:
4.1.1.2. <ins> Given an ordered dictionary parameters: Let output be an empty string. For each parameter in parameters: Append ";" to output. Let name be the result of applying Serializing a Key (ser-key) to parameter's param-name. Append name to output. If parameter has a param-value: Let value be the result of applying Serializing an Item (ser- item) to parameter's param-value. Append "=" to output. Append value to output. Return output. 4.1.1.3. </ins> Given a key as input_key: If input_key is not a sequence of characters, or contains
Original text:
Let output be an empty string. <del> For each member mem of input_dictionary: </del>  Let name be the result of applying Serializing a Key (ser-key) <del> to mem's member-name. </del>  Append name to output. Append "=" to output. <del> If mem is an array, let value be the result of applying Serialising an Inner List (ser-innerlist) to mem. </del>  Otherwise, let value be the result of applying Serializing an <del> Item (ser-item) to mem. </del>  Append value to output.  If more members remain in input_dictionary: Append a COMMA to output.

Reviewer comments:
Now that we are generalizing how the types are used, I think it might be a good idea to allow a dictionary value to be a mapping (i.e., a list of parameters). This would be a generalization. At the moment, top level elements can contain scalars, lists, or dictionaries. However, it is at the moment impossible to use a dictionary at the second level even though scalars and lists are permitted. In terms of use-case, the proposed change would allow for example something like a cache-control directive to take a mapping as an argument (see URL). Logic-wise, I assume that the added complexity would not be significant, as we can reuse the definition for the parameters of a parameterised list.
NAME are you just asking for parameters on dictionary values, in a manner that's equivalent to list values?
NAME Sorry for the belated response. Yes. I'd be fine with member-value being exactly list-member.

Revised text:
Let output be an empty string.  <ins> For each (member, parameters) of input_dictionary: </ins> Let name be the result of applying Serializing a Key (ser-key)  <ins> to member's member-name. </ins> Append name to output. Append "=" to output.  <ins> If member is an array, let value be the result of applying Serialising an Inner List (ser-innerlist) to member. </ins> Otherwise, let value be the result of applying Serializing an  <ins> Item (ser-item) to member. </ins> Append value to output. <ins> Append the result of Serializing Parameters ser-params with parameters to output. </ins> If more members remain in input_dictionary: Append a COMMA to output.
Original text:
Consume the first character of input_string; if it is not "=", fail parsing. <del> If the first character of input_string is "(", let this_value be the result of running Parsing an Inner List (parse- innerlist) with input_string. Else, let this_value be the result of running Parsing an Item (parse-item) with input_string. </del>  <del> Add name this_key with value this_value to dictionary. </del>  Discard any leading OWS from input_string.

Reviewer comments:
Now that we are generalizing how the types are used, I think it might be a good idea to allow a dictionary value to be a mapping (i.e., a list of parameters). This would be a generalization. At the moment, top level elements can contain scalars, lists, or dictionaries. However, it is at the moment impossible to use a dictionary at the second level even though scalars and lists are permitted. In terms of use-case, the proposed change would allow for example something like a cache-control directive to take a mapping as an argument (see URL). Logic-wise, I assume that the added complexity would not be significant, as we can reuse the definition for the parameters of a parameterised list.
NAME are you just asking for parameters on dictionary values, in a manner that's equivalent to list values?
NAME Sorry for the belated response. Yes. I'd be fine with member-value being exactly list-member.

Revised text:
Consume the first character of input_string; if it is not "=", fail parsing.  <ins> Let member be the result of running Parsing a Parameterized Member from Text (parse-param) with input_string. </ins>  <ins> Add name this_key with value member to dictionary. </ins> Discard any leading OWS from input_string.
Original text:
The ABNF for a Boolean in textual HTTP headers is: In textual HTTP headers, a boolean is indicated with a leading "?" <del> character.  For example: </del>  4.

Reviewer comments:
thx!
Boolean values can be conveyed in Structured Headers. The ABNF for a Boolean in textual HTTP headers is: sh-boolean = "?" boolean boolean = "0" / "1" Either say "0" is false and "1" is true, or maybe rephrase the ABNF to: sh-boolean = sh-false / sh-true sh-false = "?0" sh-true = "?1"

Revised text:
The ABNF for a Boolean in textual HTTP headers is: In textual HTTP headers, a boolean is indicated with a leading "?"  <ins> character followed by a "1" for a true value or "0" for false.  For example: </ins> 4.
Original text:
Abstract <del> This document clarifies the use of TLS 1.3 post-handshake authentication and key update with HTTP/2. </del>  Note to Readers

Reviewer comments:
This addresses feedback from the list: URL URL NAME NAME does this look good to you?
Very nice, thanks. You almost managed to do this with a net reduction in total lines. The only additions here are my fault. Respect.

Revised text:
Abstract  <ins> This document updates HTTP/2 to prohibit TLS 1.3 post-handshake authentication, as an analog to existing TLS 1.2 renegotiation restriction. </ins> Note to Readers
Original text:
TLS 1.3 RFC8446 updates TLS 1.2 to remove renegotiation in favor of separate post-handshake authentication and key update mechanisms. The former shares the same problems with multiplexed protocols, but <del> has a different name.  This makes it ambiguous whether post-handshake authentication is allowed in TLS 1.3. </del>  <del> This document clarifies that the prohibition applies to post- handshake authentication but not to key updates. </del>  2.

Reviewer comments:
This addresses feedback from the list: URL URL NAME NAME does this look good to you?
Very nice, thanks. You almost managed to do this with a net reduction in total lines. The only additions here are my fault. Respect.

Revised text:
TLS 1.3 RFC8446 updates TLS 1.2 to remove renegotiation in favor of separate post-handshake authentication and key update mechanisms. The former shares the same problems with multiplexed protocols, but  <ins> the prohibition in HTTP/2 only applies to TLS 1.2 renegotiation. </ins>  <ins> This document updates HTTP/2 to similarly forbid TLS 1.3 post- handshake authentication. </ins> 2.
Original text:
3. <del> The prohibition on renegotiation in section 9.2.1 of RFC7540 additionally applies to TLS 1.3 post-handshake authentication. </del> HTTP/2 servers MUST NOT send post-handshake TLS 1.3 CertificateRequest messages.  HTTP/2 clients MUST treat TLS 1.3 post- handshake authentication as a connection error (see section 5.4.1 of

Reviewer comments:
This addresses feedback from the list: URL URL NAME NAME does this look good to you?
Very nice, thanks. You almost managed to do this with a net reduction in total lines. The only additions here are my fault. Respect.

Revised text:
3.  HTTP/2 servers MUST NOT send post-handshake TLS 1.3 CertificateRequest messages.  HTTP/2 clients MUST treat TLS 1.3 post- handshake authentication as a connection error (see section 5.4.1 of