jiebi/TextFlow huggingface dataset:
Original text:
10.1. <del> A client sends request header fields to provide more information about the request context, make the request conditional based on the target resource state, suggest preferred formats for the response, supply authentication credentials, or modify the expected request processing.  These fields act as request modifiers, similar to the parameters on a programming language method invocation. </del> The request header fields below provide additional information about the request context, including information about the user, user agent, and resource behind the request.

Reviewer comments:
to be removed ... it was just leftover from the old org. Also, we should call it Request Context Fields.

Revised text:
10.1.  The request header fields below provide additional information about the request context, including information about the user, user agent, and resource behind the request.
Original text:
The status code indicates that the server did not receive a complete <del> request message within the time that it was prepared to wait.  If the client has an outstanding request in transit, the client MAY repeat that request on a new connection. </del>  15.5.10.

Reviewer comments:
"If the client has an outstanding request in transit, the client MAY repeat that request on a new connection."
I don't think this needs to be changed (connection is a defined term), but if you can think of some other way to say that the 408 implies partial receipt of the last request (which means the connection gone broke) then go ahead.
Suggestion:
+1

Revised text:
The status code indicates that the server did not receive a complete  <ins> request message within the time that it was prepared to wait. If the client has an outstanding request in transit, it MAY repeat that request.  If the current connection is not usable (e.g., as it would be in HTTP/1.1, because request delimitation is lost), a new connection will be used. </ins> 15.5.10.
Original text:
field-components defines some generic syntactic components for field values. <del> The rule below is defined in Messaging; </del> This specification uses the terms "character", "character encoding scheme", "charset", and "protocol element" as they are defined in RFC6365.

Reviewer comments:
: "A server MUST ignore a Range header field received with a request method other than GET." : "Likewise, if the new method might have some use for partial response semantics (Section 14.2), it ought to document this, too."
I can see why someone might want to use it with SEARCH as well, though they would more likely use a page parameter. I can't think of any other use case.
FWIW, that's exactly how it was used by MS in Exchange SEARCH: We need to decide which of the statements in our spec is correct.
Huh, that's news for me. We could have used that example for Range extensions.
Change requirement to MUST ignore Range when not defined for that method or the method is unrecognized.

Revised text:
field-components defines some generic syntactic components for field values.  This specification uses the terms "character", "character encoding scheme", "charset", and "protocol element" as they are defined in RFC6365.
Original text:
transfer codings the client is willing to accept in the response. The TE field value consists of a list of tokens, each allowing for <del> optional parameters (as described in parameter). </del>  10.1.5.

Reviewer comments:
: "A server MUST ignore a Range header field received with a request method other than GET." : "Likewise, if the new method might have some use for partial response semantics (Section 14.2), it ought to document this, too."
I can see why someone might want to use it with SEARCH as well, though they would more likely use a page parameter. I can't think of any other use case.
FWIW, that's exactly how it was used by MS in Exchange SEARCH: We need to decide which of the statements in our spec is correct.
Huh, that's news for me. We could have used that example for Range extensions.
Change requirement to MUST ignore Range when not defined for that method or the method is unrecognized.

Revised text:
transfer codings the client is willing to accept in the response. The TE field value consists of a list of tokens, each allowing for  <ins> optional parameters (except for the special case "trailers"). </ins> 10.1.5.
Original text:
A server MAY ignore the Range header field.  However, origin servers and intermediate caches ought to support byte ranges when possible, since they support efficient recovery from partially failed transfers <del> and partial retrieval of large representations.  A server MUST ignore a Range header field received with a request method other than GET. </del>  An origin server MUST ignore a Range header field that contains a range unit it does not understand.  A proxy MAY discard a Range

Reviewer comments:
: "A server MUST ignore a Range header field received with a request method other than GET." : "Likewise, if the new method might have some use for partial response semantics (Section 14.2), it ought to document this, too."
I can see why someone might want to use it with SEARCH as well, though they would more likely use a page parameter. I can't think of any other use case.
FWIW, that's exactly how it was used by MS in Exchange SEARCH: We need to decide which of the statements in our spec is correct.
Huh, that's news for me. We could have used that example for Range extensions.
Change requirement to MUST ignore Range when not defined for that method or the method is unrecognized.

Revised text:
A server MAY ignore the Range header field.  However, origin servers and intermediate caches ought to support byte ranges when possible, since they support efficient recovery from partially failed transfers  <ins> and partial retrieval of large representations. A server MUST ignore a Range header field received with a request method which is unrecognized or for which range handling is not defined.  For this specification, is the only method for which range handling is defined. </ins> An origin server MUST ignore a Range header field that contains a range unit it does not understand.  A proxy MAY discard a Range
Original text:
The status code indicates that the server did not receive a complete <del> request message within the time that it was prepared to wait.  If the client has an outstanding request in transit, the client MAY repeat that request on a new connection. </del>  15.5.10.

Reviewer comments:
: "A server MUST ignore a Range header field received with a request method other than GET." : "Likewise, if the new method might have some use for partial response semantics (Section 14.2), it ought to document this, too."
I can see why someone might want to use it with SEARCH as well, though they would more likely use a page parameter. I can't think of any other use case.
FWIW, that's exactly how it was used by MS in Exchange SEARCH: We need to decide which of the statements in our spec is correct.
Huh, that's news for me. We could have used that example for Range extensions.
Change requirement to MUST ignore Range when not defined for that method or the method is unrecognized.

Revised text:
The status code indicates that the server did not receive a complete  <ins> request message within the time that it was prepared to wait. If the client has an outstanding request in transit, it MAY repeat that request.  If the current connection is not usable (e.g., as it would be in HTTP/1.1, because request delimitation is lost), a new connection will be used. </ins> 15.5.10.
Original text:
effort attempt to remove the information from volatile storage as promptly as possible after forwarding it. <del> This directive is NOT a reliable or sufficient mechanism for ensuring privacy.  In particular, malicious or compromised caches might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping. </del>  Note that if a request containing this directive is satisfied from a cache, the no-store request directive does not apply to the already

Reviewer comments:
"This directive is NOT a reliable or sufficient mechanism for ensuring privacy." Should be lowercase. Could use .
also in 5.2.2.4

Revised text:
effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.  <ins> This directive is a reliable or sufficient mechanism for ensuring privacy.  In particular, malicious or compromised caches might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping. </ins> Note that if a request containing this directive is satisfied from a cache, the no-store request directive does not apply to the already
Original text:
effort attempt to remove the information from volatile storage as promptly as possible after forwarding it. <del> This directive is NOT a reliable or sufficient mechanism for ensuring privacy.  In particular, malicious or compromised caches might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping. </del>  5.2.2.5.

Reviewer comments:
"This directive is NOT a reliable or sufficient mechanism for ensuring privacy." Should be lowercase. Could use .
also in 5.2.2.4

Revised text:
effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.  <ins> This directive is a reliable or sufficient mechanism for ensuring privacy.  In particular, malicious or compromised caches might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping. </ins> 5.2.2.5.
Original text:
member, as described in trailer.fields. Additionally, specific HTTP versions can use it to indicate the <del> transfer codings the client is willing to accept in the response. </del>  The TE field value consists of a list of tokens, each allowing for optional parameters (except for the special case "trailers").

Reviewer comments:
"Additionally, specific HTTP versions can use it to indicate the transfer codings the client is willing to accept in the response." If we phrase it this way, we'd have to say somewhere in Semantics what transfer codings actually are. Or we decide that they are specific to HTTP/1.*, rephrase this, and link to Messaging.

Revised text:
member, as described in trailer.fields. Additionally, specific HTTP versions can use it to indicate the  <ins> transfer codings the client is willing to accept in the response.  As of publication, only HTTP/1.1 uses transfer codings (see transfer.codings). </ins> The TE field value consists of a list of tokens, each allowing for optional parameters (except for the special case "trailers").
Original text:
Wide Web since its introduction in 1990.  It began as a trivial mechanism for low-latency requests, with a single method (GET) to request transfer of a presumed hypertext document identified by a <del> given pathname.  This original protocol is now referred to as HTTP/0.9 (see HTTP09). As the Web grew, HTTP was extended to enclose requests and responses within messages, transfer arbitrary data formats using MIME-like media types, and route requests through intermediaries, eventually being defined as HTTP/1.0 RFC1945. </del>  HTTP/1.1 was designed to refine the protocol's features while retaining compatibility with the existing text-based messaging

Reviewer comments:
Good point.
For .
URL be good to have tests...
goes back to URL
sent mail: URL
See URL
Proposal: leave weight in ABNF for consistency with other Accept-* fields change second requirement (on recipients) not to rely on "q" being last

Revised text:
Wide Web since its introduction in 1990.  It began as a trivial mechanism for low-latency requests, with a single method (GET) to request transfer of a presumed hypertext document identified by a  <ins> given pathname.  As the Web grew, HTTP was extended to enclose requests and responses within messages, transfer arbitrary data formats using MIME-like media types, and route requests through intermediaries.  These protocols were eventually defined as HTTP/0.9 and HTTP/1.0 (see RFC1945). </ins> HTTP/1.1 was designed to refine the protocol's features while retaining compatibility with the existing text-based messaging
Original text:
member, as described in trailer.fields. Additionally, specific HTTP versions can use it to indicate the <del> transfer codings the client is willing to accept in the response. </del>  The TE field value consists of a list of tokens, each allowing for optional parameters (except for the special case "trailers").

Reviewer comments:
Good point.
For .
URL be good to have tests...
goes back to URL
sent mail: URL
See URL
Proposal: leave weight in ABNF for consistency with other Accept-* fields change second requirement (on recipients) not to rely on "q" being last

Revised text:
member, as described in trailer.fields. Additionally, specific HTTP versions can use it to indicate the  <ins> transfer codings the client is willing to accept in the response.  As of publication, only HTTP/1.1 uses transfer codings (see transfer.codings). </ins> The TE field value consists of a list of tokens, each allowing for optional parameters (except for the special case "trailers").
Original text:
subtypes of that type.  The media-range can include media type parameters that are applicable to that range. <del> Each media-range might be followed by zero or more applicable media type parameters (e.g., </del>  <del> ), an optional "q" parameter for indicating a relative weight (quality.values), and then zero or more extension parameters.  The "q" parameter is necessary if any extensions (accept-ext) are present, since it acts as a separator between the two parameter sets. </del>  The example

Reviewer comments:
Good point.
For .
URL be good to have tests...
goes back to URL
sent mail: URL
See URL
Proposal: leave weight in ABNF for consistency with other Accept-* fields change second requirement (on recipients) not to rely on "q" being last

Revised text:
subtypes of that type.  The media-range can include media type parameters that are applicable to that range.  <ins> Each media-range might be followed by optional applicable media type parameters (e.g., ), followed by an optional "q" parameter for indicating a relative weight (quality.values). </ins>  <ins> This specification does not define "accept parameters" following the special "q" parameter, as was done in earlier editions.  Senders using weights SHOULD send "q" last (after all media-range parameters).  Recipients SHOULD process any parameter named "q" as weight, regardless of parameter ordering. </ins> The example
Original text:
Wide Web since its introduction in 1990.  It began as a trivial mechanism for low-latency requests, with a single method (GET) to request transfer of a presumed hypertext document identified by a <del> given pathname.  This original protocol is now referred to as HTTP/0.9 (see HTTP09). As the Web grew, HTTP was extended to enclose requests and responses within messages, transfer arbitrary data formats using MIME-like media types, and route requests through intermediaries, eventually being defined as HTTP/1.0 RFC1945. </del>  HTTP/1.1 was designed to refine the protocol's features while retaining compatibility with the existing text-based messaging

Reviewer comments:
Im ok with replacing the 0.9 reference (although having the link here acknowledges where 0.9 came from, right). The idea was to mention 0.9 in the context of RFC 1945 as well as that is an IETF document which actually describes what 0.9 is.
URL out that RFC 1945 defines HTTP/0.9 as well (see URL). Maybe we should add this reference, or replace the existing one.
We do reference 1945 for HTTP/1.0. Revised proposal: just mention that that RFC describes 0.9 as well.

Revised text:
Wide Web since its introduction in 1990.  It began as a trivial mechanism for low-latency requests, with a single method (GET) to request transfer of a presumed hypertext document identified by a  <ins> given pathname.  As the Web grew, HTTP was extended to enclose requests and responses within messages, transfer arbitrary data formats using MIME-like media types, and route requests through intermediaries.  These protocols were eventually defined as HTTP/0.9 and HTTP/1.0 (see RFC1945). </ins> HTTP/1.1 was designed to refine the protocol's features while retaining compatibility with the existing text-based messaging
Original text:
The must-revalidate directive is necessary to support reliable operation for certain protocol features.  In all circumstances a <del> cache MUST obey the must-revalidate directive; in particular, if a cache is disconnected, the cache MUST generate a </del>  <del> response rather than reuse the stale response. </del>  The must-revalidate directive ought to be used by servers if and only if failure to validate a request on the representation could cause

Reviewer comments:
This issue is from a related discussion on Apache httpd, which was trying to comply by sending a 504 even though the revalidation error was a 502. That's nuts. The current text for says: However, if a proxy/gateway received a 5xx response while trying to revalidate, this requirement forces it to toss that information and supply a useless 504 instead. That isn't desirable. The entire purpose of this requirement is to make sure that the cache does not respond with its stale entry. Hence, any 5xx code is sufficient.
To fill in more detail, the change in question is this one: URL And covers the wide question of "which 5xx response is returned in low level network failure cases, such as DNS error, connection refused, connection timed out, etc". The commit message referred to RFC2616 14.9.4 Cache Revalidation and Reload Controls, but this seems to be a wider issue.
Yes, that MUST is too strong; I suspect it's there to make the mechanism reliable, not override other potential status codes. Will work on a PR.

Revised text:
The must-revalidate directive is necessary to support reliable operation for certain protocol features.  In all circumstances a  <ins> cache MUST NOT ignore the must-revalidate directive; in particular, if a cache is disconnected, the cache MUST generate an error response rather than reuse the stale response.  The generated status code SHOULD be </ins>  <ins> unless another error status code is more applicable. </ins> The must-revalidate directive ought to be used by servers if and only if failure to validate a request on the representation could cause
Original text:
the namespace for HTTP field names. Any party can request registration of a HTTP field.  See <del> considerations.for.new.field.values for considerations to take into account when creating a new HTTP field. </del>  The "Hypertext Transfer Protocol (HTTP) Field Name Registry" is located at <https://www.iana.org/assignments/http-fields/>.

Reviewer comments:
Including a re-org of Considerations for New Fields
I think it should be mentioned as an aside in the section on common rules for defining field values.
maybe wait until RFC is out...

Revised text:
the namespace for HTTP field names. Any party can request registration of a HTTP field.  See  <ins> considerations.for.new.fields for considerations to take into account when creating a new HTTP field. </ins> The "Hypertext Transfer Protocol (HTTP) Field Name Registry" is located at <https://www.iana.org/assignments/http-fields/>.
Original text:
16.3.2.  Authors of specifications defining new fields are advised to choose a short but descriptive field name.  Short names avoid needless data transmission; descriptive names avoid confusion and "squatting" on

Reviewer comments:
Including a re-org of Considerations for New Fields
I think it should be mentioned as an aside in the section on common rules for defining field values.
maybe wait until RFC is out...

Revised text:
16.3.2. <ins> HTTP header and trailer fields are a widely-used extension point for the protocol.  While they can be (and often are) used in an ad hoc fashion, fields that are widely used need to be more carefully documented, to ensure interoperability. In particular, authors of specifications defining new fields are advised to consider and, where appropriate, document the following aspects: Request header fields have additional considerations that need to be documented if the default behaviour is not appropriate: 16.3.2.1. </ins> Authors of specifications defining new fields are advised to choose a short but descriptive field name.  Short names avoid needless data transmission; descriptive names avoid confusion and "squatting" on
Original text:
To that end, limited-use fields (such as a header confined to a single application or use case) are encouraged to use a name that <del> includes its name (or an abbreviation) as a prefix; for example, if </del>  the Foo Application needs a Description field, it might use "Foo- Desc"; "Description" is too generic, and "Foo-Description" is needlessly long.

Reviewer comments:
Including a re-org of Considerations for New Fields
I think it should be mentioned as an aside in the section on common rules for defining field values.
maybe wait until RFC is out...

Revised text:
To that end, limited-use fields (such as a header confined to a single application or use case) are encouraged to use a name that  <ins> includes that use (or an abbreviation) as a prefix; for example, if </ins> the Foo Application needs a Description field, it might use "Foo- Desc"; "Description" is too generic, and "Foo-Description" is needlessly long.
Original text:
prefixes are only an aid to recognizing the purpose of a field, and do not trigger automatic processing. <del> 16.3.3. </del>  <del> Authors of specifications defining new fields are advised to consider documenting: </del>  16.4.

Reviewer comments:
Including a re-org of Considerations for New Fields
I think it should be mentioned as an aside in the section on common rules for defining field values.
maybe wait until RFC is out...

Revised text:
prefixes are only an aid to recognizing the purpose of a field, and do not trigger automatic processing.  <ins> 16.3.2.2. A major task in the definition of a new HTTP field is the specification of the field value syntax: what senders should generate, and how recipients should infer semantics from what is received. Authors are encouraged (but not required) to use either the ABNF rules in this specification or those in RFCSTRF to define the syntax of new field values. Authors are advised to carefully consider how the combination of multiple field lines will impact them (see field-order).  Because senders might send erroneously send multiple values, and both intermediaries and HTTP libraries can perform combination automatically, this applies to all field values -- even when only a single value is anticipated. Therefore, authors are advised to either delimit values that contain commas (e.g., with the rule; see quoted.strings, or the String data type in RFCSTRF), or encode or escape them.  This ensures that commas in the payload of the field value are not confused with those used to delimit list values. For example, the field value only allows commas inside quoted strings, and so can be reliably parsed, even when multiple values are present.  The field value provides a counter-example that should not be emulated: because URIs can include commas, it is not possible to reliably distinguish between a single value that includes a comma from two values. </ins>  <ins> Authors of fields with a singleton value (see field-values) are additionally advised to document how to treat messages where the multiple members are present (a sensible default would be to ignore the field, but this might not always be the right choice). </ins> 16.4.