jiebi/TextFlow huggingface dataset:
Original text:
send only the extensions that narrowly specify which certificates would be acceptable.  6.3. Failure to provide a certificate for a stream after receiving

Reviewer comments:
I believe that NAME comment on that issue is already covered by the following section on Denial of Service.
If a malicious server claims support for a variety of common hostnames for which it doesn't actually possess certificates, browser clients with a long-lived connection to the attacker will probe for certificates when the user attempts to access those sites. This allows the server to monitor user behavior during the lifetime of the connection, even without valid certificates. One obvious strategy is to probe everything "interesting" ASAP after the ORIGIN frame, but that obviously leaks what the client considers interesting, which is its own privacy leak. Note that a DNS lookup of claimed hostnames prior to requesting the cert prevents this attack. Should probably recommend that clients which omit the DNS lookup never solicit secondary server certificates, but probably don't need to mandate anything.
In addition to monitoring user behavior, depending on client behavior (do you race two connections? fallback on error?), the malicious server could also deny access to other hostname or degrade performance.

Revised text:
send only the extensions that narrowly specify which certificates would be acceptable. <ins> Servers can also learn information about clients using this mechanism.  The hostnames a user agent finds interesting and retrieves certificates for might indicate origins the user has previously accessed. </ins> 6.3. Failure to provide a certificate for a stream after receiving
Original text:
3.1. The urgency parameter ("u") takes an integer between 0 and 7, in <del> descending order of priority. </del>  The value is encoded as an sh-integer.  The default value is 1.

Reviewer comments:
We landed a change to remove the semantic meanings of urgency levels but neglected to remove a considerations section that discussed this. This PR moves some of the still relevant text out of the section and nukes the stuff no longer needed.
oops, this will need a rebase...

Revised text:
3.1. The urgency parameter ("u") takes an integer between 0 and 7, in  <ins> descending order of priority.  This range provides sufficient granularity for prioritizing responses for ordinary web browsing, at minimal complexity. </ins> The value is encoded as an sh-integer.  The default value is 1.
Original text:
way that is backwards compatible for peers that are unaware of the extended meaning.  4. The Priority HTTP header field can appear in requests and responses.

Reviewer comments:
We landed a change to remove the semantic meanings of urgency levels but neglected to remove a considerations section that discussed this. This PR moves some of the still relevant text out of the section and nukes the stuff no longer needed.
oops, this will need a rebase...

Revised text:
way that is backwards compatible for peers that are unaware of the extended meaning. <ins> For example, if there is a need to provide more granularity than eight urgency levels, it would be possible to subdivide the range using an additional parameter.  Implementations that do not recognize the parameter can safely continue to use the less granular eight levels. Alternatively, the urgency can be augmented.  For example, a graphical user-agent could send a "visible" parameter to indicate if the resource being requested is within the viewport. </ins> 4. The Priority HTTP header field can appear in requests and responses.
Original text:
6. It is not always the case that the client has the best understanding <del> of how the HTTP responses deserve to be prioritized.  For example, use of an HTML document might depend heavily on one of the inline images.  Existence of such dependencies is typically best known to the server. </del>  An origin can use the Priority response header field to indicate its view on how an HTTP response should be prioritized.  An intermediary

Reviewer comments:
We landed a change to remove the semantic meanings of urgency levels but neglected to remove a considerations section that discussed this. This PR moves some of the still relevant text out of the section and nukes the stuff no longer needed.
oops, this will need a rebase...

Revised text:
6. It is not always the case that the client has the best understanding  <ins> of how the HTTP responses deserve to be prioritized.  The server might have additional information that can be combined with the client's indicated priority in order to improve the prioritization of the response.  For example, use of an HTML document might depend heavily on one of the inline images; existence of such dependencies is typically best known to the server.  Or, a server that receives requests for a font RFC8081 and images with the same urgency might give higher precedence to the font, so that a visual client can render textual information at an early moment. </ins> An origin can use the Priority response header field to indicate its view on how an HTTP response should be prioritized.  An intermediary
Original text:
textual value makes the prioritization scheme extensible; see the discussion below. <del> 8.2. One of the aims of this specification is to define a mechanism for merging client- and server-provided hints for prioritizing the responses.  For that to work, each urgency level needs to have a well-defined meaning.  As an example, a server can assign the highest precedence among the supplementary responses to an HTTP response carrying an icon, because the meaning of "u=2" is shared among the endpoints. This specification restricts itself to defining a minimum set of urgency levels in order to provide sufficient granularity for prioritizing responses for ordinary web browsing, at minimal complexity. However, that does not mean that the prioritization scheme would forever be stuck to the eight levels.  The design provides extensibility.  If deemed necessary, it would be possible to subdivide any of the eight urgency levels that are currently defined. Or, a graphical user-agent could send a "visible" parameter to indicate if the resource being requested is within the viewport. A server can combine the hints provided in the Priority header field with other information in order to improve the prioritization of responses.  For example, a server that receives requests for a font RFC8081 and images with the same urgency might give higher precedence to the font, so that a visual client can render textual information at an early moment. </del> 9. This specification registers the following entry in the Permanent

Reviewer comments:
We landed a change to remove the semantic meanings of urgency levels but neglected to remove a considerations section that discussed this. This PR moves some of the still relevant text out of the section and nukes the stuff no longer needed.
oops, this will need a rebase...

Revised text:
textual value makes the prioritization scheme extensible; see the discussion below.  9. This specification registers the following entry in the Permanent
Original text:
set of parameters when a request or a response is issued.  In order to reprioritize a request, HTTP-version-specific frames are used by clients to transmit the same information on a single hop.  If <del> intermediaries want to specify prioritizaton on a multiplexed HTTP </del>  connection, it SHOULD use a PRIORITY_UPDATE frame and SHOULD NOT change the Priority header field.

Reviewer comments:
Address some build warnings and fix typos.
and
Thank you for the fix. Merged.
Changes in structured headers means that boolean parameter values are reduced to their parameter name: -- URL
Q: should this be labeled ?
No, this issue addresses the minor editorial problem that needs fixing in the priorities spec e.g. URL just needs some tweaks to be compliant with structured headers.
The lowercase headings in the document imply that they represent field or parameter names, but these are concepts. For instance "incremental" doesn't appear on the wire, "i" does.

Revised text:
set of parameters when a request or a response is issued.  In order to reprioritize a request, HTTP-version-specific frames are used by clients to transmit the same information on a single hop.  If  <ins> intermediaries want to specify prioritization on a multiplexed HTTP </ins> connection, it SHOULD use a PRIORITY_UPDATE frame and SHOULD NOT change the Priority header field.
Original text:
The following example shows a request for a JPEG file with the urgency parameter set to "5" and the incremental parameter set to <del> "1". </del>  3.3.

Reviewer comments:
Address some build warnings and fix typos.
and
Thank you for the fix. Merged.
Changes in structured headers means that boolean parameter values are reduced to their parameter name: -- URL
Q: should this be labeled ?
No, this issue addresses the minor editorial problem that needs fixing in the priorities spec e.g. URL just needs some tweaks to be compliant with structured headers.
The lowercase headings in the document imply that they represent field or parameter names, but these are concepts. For instance "incremental" doesn't appear on the wire, "i" does.

Revised text:
The following example shows a request for a JPEG file with the urgency parameter set to "5" and the incremental parameter set to  <ins> "true". </ins> 3.3.
Original text:
server's disinterest in changing the client-provided value.  This is different from the logic being defined for the request header field, in which omission of a priority parameter implies the use of their <del> default values (see #parameters). </del>  As a non-normative example, when the client sends an HTTP request <del> with </del>  and the origin responds with the intermediary might alter its understanding of the urgency from "5" to "1", because it prefers the server-provided value over the <del> client's.  The incremental value continues to be "1", the value </del>  specified by the client, as the server did not specify the incremental("i") parameter.

Reviewer comments:
Address some build warnings and fix typos.
and
Thank you for the fix. Merged.
Changes in structured headers means that boolean parameter values are reduced to their parameter name: -- URL
Q: should this be labeled ?
No, this issue addresses the minor editorial problem that needs fixing in the priorities spec e.g. URL just needs some tweaks to be compliant with structured headers.
The lowercase headings in the document imply that they represent field or parameter names, but these are concepts. For instance "incremental" doesn't appear on the wire, "i" does.

Revised text:
server's disinterest in changing the client-provided value.  This is different from the logic being defined for the request header field, in which omission of a priority parameter implies the use of their  <ins> default values (see parameters). </ins> As a non-normative example, when the client sends an HTTP request  <ins> with the urgency parameter set to "5" and the incremental parameter set to "true" </ins> and the origin responds with the intermediary might alter its understanding of the urgency from "5" to "1", because it prefers the server-provided value over the  <ins> client's.  The incremental value continues to be "true", the value </ins> specified by the client, as the server did not specify the incremental("i") parameter.
Original text:
In order to mitigate this fairness problem, when a server responds to a request that is known to have come through an intermediary, the server SHOULD prioritize the response as if it was assigned the <del> priority of "u=1, i=?1" (i.e. round-robin) regardless of the value of </del>  the Priority header field being transmitted, unless the server knows the intermediary is not coalescing requests from multiple clients.

Reviewer comments:
Address some build warnings and fix typos.
and
Thank you for the fix. Merged.
Changes in structured headers means that boolean parameter values are reduced to their parameter name: -- URL
Q: should this be labeled ?
No, this issue addresses the minor editorial problem that needs fixing in the priorities spec e.g. URL just needs some tweaks to be compliant with structured headers.
The lowercase headings in the document imply that they represent field or parameter names, but these are concepts. For instance "incremental" doesn't appear on the wire, "i" does.

Revised text:
In order to mitigate this fairness problem, when a server responds to a request that is known to have come through an intermediary, the server SHOULD prioritize the response as if it was assigned the  <ins> priority of "u=1, i" (i.e. round-robin) regardless of the value of </ins> the Priority header field being transmitted, unless the server knows the intermediary is not coalescing requests from multiple clients.
Original text:
If input_key contains characters not in lcalpha, DIGIT, "_", "-", ".", or "*" fail serialisation. <del> If the first character of input_key is not lcalpha, fail </del>  serialisation. Let output be an empty string.

Reviewer comments:
This change to the key syntax allows dictionaries and parameters to use "" as a starting character for names, allowing keys like value mygoditsfullofstars*
LGTM. Do you want to add the change note, or shall I do that after merging?
BTW - would take a PR with an example key that looks like the last one above :)
In URL, NAME asks for as a dictionary member name. I think this just means adding it to valid start characters in key.

Revised text:
If input_key contains characters not in lcalpha, DIGIT, "_", "-", ".", or "*" fail serialisation.  <ins> If the first character of input_key is not lcalpha or "*", fail </ins> serialisation. Let output be an empty string.
Original text:
Given an ASCII string as input_string, return a key. input_string is modified to remove the parsed value. <del> If the first character of input_string is not lcalpha, fail </del>  parsing. Let output_string be an empty string.

Reviewer comments:
This change to the key syntax allows dictionaries and parameters to use "" as a starting character for names, allowing keys like value mygoditsfullofstars*
LGTM. Do you want to add the change note, or shall I do that after merging?
BTW - would take a PR with an example key that looks like the last one above :)
In URL, NAME asks for as a dictionary member name. I think this just means adding it to valid start characters in key.

Revised text:
Given an ASCII string as input_string, return a key. input_string is modified to remove the parsed value.  <ins> If the first character of input_string is not lcalpha or "*", fail </ins> parsing. Let output_string be an empty string.
Original text:
Status: standard <del> Description: The sha-256 digest of the representation-data of the resource when no content coding is applied (eg.  "Content- Encoding: identity") Reference: RFC6234, RFC4648, this document. Status: standard </del>  If other digest-algorithm values are defined, the associated encoding MUST either be represented as a quoted string, or MUST NOT include

Reviewer comments:
NAME I was tired of the warnings of line too long, so I've reflowed a lot of the examples and also most of the text while I was at it. The Python code example was tricky, please pay attention to that as I may have mangled it.
LGTM

Revised text:
Status: standard  <ins> ID-SHA-256: : * Description: The sha-256 digest of the representation-data of the resource when no content coding is applied (eg.  "Content-Encoding: identity") * Reference: RFC6234, RFC4648, this document.  * Status: standard </ins> If other digest-algorithm values are defined, the associated encoding MUST either be represented as a quoted string, or MUST NOT include
Original text:
example: Members whose value is Boolean true MUST omit that value when <del> serialised, unless it has Parameters.  For example, here both "b" and "c" are true, but "c"'s value is serialised because it has Parameters: </del>  Note that this requirement is only on serialisation; parsers are <del> still required to correctly handle the true value when it appears in Dictionary values. </del>  A Dictionary with a member whose value is an Inner List of tokens:

Reviewer comments:
Ping NAME
LGTM from here, thanks!
Julian asked in e-mail why we can't have a dictionary with a default True value that is parameterised:
I think we could replace: With:
NAME NAME NAME thoughts?
Example-Field: ;param=on-default-boolean Is this a dictionary? What is the key here? (I see that the value is supposed to be implicit true, but I'm not grokking the implied syntax) If I ignore that (assuming I've misinterpreted something), I like the idea of allowing implicit True. The serialization algorithm needs a bit more surgery to support this as the canonical form, probably replacing: with something like: (unless we also modify Serializing an Item to optionally omit True values, but we can't just do that unconditionally, or else a simple Item header would be empty if True.) This is the same issue as URL, I think -- back in December you thought that it would take more drastic changes. If this is everything that it needs, though, it seems reasonable. None of the canonical tests break with this (except for a couple of serialization tests, which just need to be updated), and I don't see any obvious cases that would be parsed incorrectly.
Sorry, that was unrelated, accidentally copied from the email. Ignore. I'll work up a PR and see how it looks.
Awesome. Now, how about also collapsing the "false" value a bit. So instead of having a=?0 just say !a ?
IMHO explicit is better than implicit: I am not sure that is a good choice. I am not even sure that defaulting is a good choice.
Tantalizingly close to making Dictionary a superset of List. I can't think of anything that would break.

Revised text:
example: Members whose value is Boolean true MUST omit that value when  <ins> serialised.  For example, here both "b" and "c" are true: </ins> Note that this requirement is only on serialisation; parsers are  <ins> still required to correctly handle the true Boolean value when it appears in Dictionary values. </ins> A Dictionary with a member whose value is an Inner List of tokens:
Original text:
Append the result of running Serializing a Key (ser-key) with member's member_name to output. <del> If member_value is not Boolean true or parameters is not empty: </del>  Append "=" to output. <del> If member_value is an array, append the result of running Serialising an Inner List (ser-innerlist) with (member_value, parameters) to output. </del>  <del> Otherwise, append the result of running Serializing an Item (ser-item) with (member_value, parameters) to output. </del>  If more members remain in input_dictionary:

Reviewer comments:
Ping NAME
LGTM from here, thanks!
Julian asked in e-mail why we can't have a dictionary with a default True value that is parameterised:
I think we could replace: With:
NAME NAME NAME thoughts?
Example-Field: ;param=on-default-boolean Is this a dictionary? What is the key here? (I see that the value is supposed to be implicit true, but I'm not grokking the implied syntax) If I ignore that (assuming I've misinterpreted something), I like the idea of allowing implicit True. The serialization algorithm needs a bit more surgery to support this as the canonical form, probably replacing: with something like: (unless we also modify Serializing an Item to optionally omit True values, but we can't just do that unconditionally, or else a simple Item header would be empty if True.) This is the same issue as URL, I think -- back in December you thought that it would take more drastic changes. If this is everything that it needs, though, it seems reasonable. None of the canonical tests break with this (except for a couple of serialization tests, which just need to be updated), and I don't see any obvious cases that would be parsed incorrectly.
Sorry, that was unrelated, accidentally copied from the email. Ignore. I'll work up a PR and see how it looks.
Awesome. Now, how about also collapsing the "false" value a bit. So instead of having a=?0 just say !a ?
IMHO explicit is better than implicit: I am not sure that is a good choice. I am not even sure that defaulting is a good choice.
Tantalizingly close to making Dictionary a superset of List. I can't think of anything that would break.

Revised text:
Append the result of running Serializing a Key (ser-key) with member's member_name to output.  <ins> If member_value is Boolean true: Append the result of running Serializing Parameters (ser- params) with parameters to output. Otherwise: </ins> Append "=" to output.  <ins> If member_value is an array, append the result of running Serialising an Inner List (ser-innerlist) with (member_value, parameters) to output. </ins>  <ins> Otherwise, append the result of running Serializing an Item (ser-item) with (member_value, parameters) to output. </ins> If more members remain in input_dictionary:
Original text:
Let value be Boolean true. <del> Let parameters be an empty, ordered map. </del>  Let member be the tuple (value, parameters).

Reviewer comments:
Ping NAME
LGTM from here, thanks!
Julian asked in e-mail why we can't have a dictionary with a default True value that is parameterised:
I think we could replace: With:
NAME NAME NAME thoughts?
Example-Field: ;param=on-default-boolean Is this a dictionary? What is the key here? (I see that the value is supposed to be implicit true, but I'm not grokking the implied syntax) If I ignore that (assuming I've misinterpreted something), I like the idea of allowing implicit True. The serialization algorithm needs a bit more surgery to support this as the canonical form, probably replacing: with something like: (unless we also modify Serializing an Item to optionally omit True values, but we can't just do that unconditionally, or else a simple Item header would be empty if True.) This is the same issue as URL, I think -- back in December you thought that it would take more drastic changes. If this is everything that it needs, though, it seems reasonable. None of the canonical tests break with this (except for a couple of serialization tests, which just need to be updated), and I don't see any obvious cases that would be parsed incorrectly.
Sorry, that was unrelated, accidentally copied from the email. Ignore. I'll work up a PR and see how it looks.
Awesome. Now, how about also collapsing the "false" value a bit. So instead of having a=?0 just say !a ?
IMHO explicit is better than implicit: I am not sure that is a good choice. I am not even sure that defaulting is a good choice.
Tantalizingly close to making Dictionary a superset of List. I can't think of anything that would break.

Revised text:
Let value be Boolean true.  <ins> Let parameters be the result of running Parsing Parameters parse-param with input_string. </ins> Let member be the tuple (value, parameters).