jiebi/TextFlow huggingface dataset:
Original text:
The "Host" header field in a request provides the host and port information from the target URI, enabling the origin server to distinguish among resources while servicing requests for multiple <del> host names on a single IP address. </del>  <del> Since the Host field value is critical information for handling a request, a user agent SHOULD generate Host as the first field in the header section. </del>  For example, a GET request to the origin server for <http://www.example.org/pub/WWW/> would begin with: <del> Since the Host header field acts as an application-level routing mechanism, it is a frequent target for malware seeking to poison a shared cache or redirect a request to an unintended server.  An interception proxy is particularly vulnerable if it relies on the Host field value for redirecting requests to internal servers, or for use as a cache key in a shared cache, without first verifying that the intercepted connection is targeting a valid IP address for that host. </del>  7.1.3.

Reviewer comments:
by changing DL to a table and tweaking description of HEAD.
"HEAD: the same representation as GET, but without the representation data;" Should that be "payload data"?
No, that's correct, but I will tweak it slightly: HEAD: the same representation as GET, but without transferring the representation data;
Note that the context is a discussion of what representation is included in a 200 response, which is why we are talking about representation data here instead of payload data.

Revised text:
The "Host" header field in a request provides the host and port information from the target URI, enabling the origin server to distinguish among resources while servicing requests for multiple  <ins> host names. </ins>  <ins> In HTTP/2 RFC7540 and HTTP/3 HTTP3, the Host header field is, in some cases, supplanted by the ":authority" pseudo-header field of a request's control data. The target URI's authority information is critical for handling a request.  A user agent SHOULD generate Host as the first field in the header section of a request unless it has already generated that information as an ":authority" pseudo-header field. </ins> For example, a GET request to the origin server for <http://www.example.org/pub/WWW/> would begin with:  <ins> Since the host and port information acts as an application-level routing mechanism, it is a frequent target for malware seeking to poison a shared cache or redirect a request to an unintended server. An interception proxy is particularly vulnerable if it relies on the host and port information for redirecting requests to internal servers, or for use as a cache key in a shared cache, without first verifying that the intercepted connection is targeting a valid IP address for that host. </ins> 7.1.3.
Original text:
validation requests for the content might only be applicable along the same request path (through the same proxies). <del> The 203 response is similar to the Warning code of 214 Transformation Applied (field.warning), which has the advantage of being applicable to responses with any status code. </del> A 203 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see heuristic.freshness).

Reviewer comments:
by changing DL to a table and tweaking description of HEAD.
"HEAD: the same representation as GET, but without the representation data;" Should that be "payload data"?
No, that's correct, but I will tweak it slightly: HEAD: the same representation as GET, but without transferring the representation data;
Note that the context is a discussion of what representation is included in a 200 response, which is why we are talking about representation data here instead of payload data.

Revised text:
validation requests for the content might only be applicable along the same request path (through the same proxies).  A 203 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see heuristic.freshness).
Original text:
implementing such verification can be difficult (see Georgiev). Authority for a given origin server can be delegated through protocol <del> extensions; for example, RFC7838.  Likewise, the set of servers that a connection is considered authoritative for can be changed with a </del>  protocol extension like RFC8336. Providing a response from a non-authoritative source, such as a

Reviewer comments:
by changing DL to a table and tweaking description of HEAD.
"HEAD: the same representation as GET, but without the representation data;" Should that be "payload data"?
No, that's correct, but I will tweak it slightly: HEAD: the same representation as GET, but without transferring the representation data;
Note that the context is a discussion of what representation is included in a 200 response, which is why we are talking about representation data here instead of payload data.

Revised text:
implementing such verification can be difficult (see Georgiev). Authority for a given origin server can be delegated through protocol  <ins> extensions; for example, RFC7838.  Likewise, the set of servers for which a connection is considered authoritative can be changed with a </ins> protocol extension like RFC8336. Providing a response from a non-authoritative source, such as a
Original text:
with the registration procedure of status.code.registry and the status code values summarized in the following table. <del> Additionally, please update the following entry in the Hypertext Transfer Protocol (HTTP) Status Code Registry: </del> 18.4. This specification updates the HTTP related aspects of the existing

Reviewer comments:
by changing DL to a table and tweaking description of HEAD.
"HEAD: the same representation as GET, but without the representation data;" Should that be "payload data"?
No, that's correct, but I will tweak it slightly: HEAD: the same representation as GET, but without transferring the representation data;
Note that the context is a discussion of what representation is included in a 200 response, which is why we are talking about representation data here instead of payload data.

Revised text:
with the registration procedure of status.code.registry and the status code values summarized in the following table.  18.4. This specification updates the HTTP related aspects of the existing
Original text:
validation requests for the content might only be applicable along the same request path (through the same proxies). <del> The 203 response is similar to the Warning code of 214 Transformation Applied (field.warning), which has the advantage of being applicable to responses with any status code. </del> A 203 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see heuristic.freshness).

Reviewer comments:
"The 203 response is similar to the Warning code of 214 Transformation Applied (Section 5.5 of [Caching]), which has the advantage of being applicable to responses with any status code." But then we have removed "Warning"...
I think we can just remove this text; if it's important, we can refer to 7234 and mention that it's deprecated.
I say just remove the sentence.

Revised text:
validation requests for the content might only be applicable along the same request path (through the same proxies).  A 203 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see heuristic.freshness).
Original text:
HTTP depends on the security properties of the underlying transport- or session-level connection to provide confidential transmission of <del> fields.  In other words, if a server limits access to authenticated users using this framework, the server needs to ensure that the connection is properly secured in accordance with the nature of the authentication scheme used.  For example, services that depend on individual user authentication often require a connection to be secured with TLS ("Transport Layer Security", RFC8446) prior to exchanging any credentials. </del>  17.15.2.

Reviewer comments:
" For example, services that depend on individual user authentication often require a connection to be secured with TLS ("Transport Layer Security", [RFC8446]) prior to exchanging any credentials." This originates from RFC 7235. Nowaday, shouldn't we instead say "require HTTPS"?
I think it should be ... authentication require a secured connection prior to exchanging any credentials (ref target="URL"). and x:ref around the term "secured" (defined in that section).

Revised text:
HTTP depends on the security properties of the underlying transport- or session-level connection to provide confidential transmission of  <ins> fields.  Services that depend on individual user authentication require a connection prior to exchanging credentials (https.uri). </ins> 17.15.2.
Original text:
This section is meant to inform developers, information providers, and users of known security concerns relevant to HTTP semantics and its use for transferring information over the Internet. <del> Considerations related to message syntax, parsing, and routing are discussed in Messaging-security.considerations. </del>  The list of considerations below is not exhaustive.  Most security concerns related to HTTP semantics are about securing server-side

Reviewer comments:
" Considerations related to message syntax, parsing, and routing are discussed in Section 11 of [Messaging]." Make clear that these are only the HTTP/1.1 considerations. Optionally add links for HTTP/2 and HTTP/3.

Revised text:
This section is meant to inform developers, information providers, and users of known security concerns relevant to HTTP semantics and its use for transferring information over the Internet.  <ins> Considerations related to caching are discussed in Caching- security.considerations and considerations related to HTTP/1.1 message syntax and parsing are discussed in Messaging- security.considerations. </ins> The list of considerations below is not exhaustive.  Most security concerns related to HTTP semantics are about securing server-side
Original text:
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information <del> systems.  This document defines the semantics of HTTP: its architecture, terminology, the "http" and "https" Uniform Resource Identifier (URI) schemes, core request methods, request header fields, response status codes, response header fields, and content negotiation. </del>  This document obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions of RFC 7230.

Reviewer comments:
"This document defines the semantics of HTTP: its architecture, terminology, the "http" and "https" Uniform Resource Identifier (URI) schemes, core request methods, request header fields, response status codes, response header fields, and content negotiation." replace by just "fields"?
I think it's useful to retain the current text, because those phrases are more likely to be recognised by readers coming to the document.
No real opinion, but it should be rewritten anyway: This document defines the semantics shared by all versions of the Hypertext Transfer Protocol (HTTP), including its architecture, terminology, and core protocol elements, along with the "http" and "https" identifier schemes. It could go on from there to describe the core elements, and maybe the core features as well, but shrug.

Revised text:
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information  <ins> systems.  This document defines the semantics shared by all versions of HTTP, including its architecture, terminology, core protocol elements, and extensibility mechanisms, along with the "http" and "https" Uniform Resource Identifier (URI) schemes. </ins> This document obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions of RFC 7230.
Original text:
provides a list of representations for the user agent to choose from, and "request payload" negotiation, where the user agent selects the representation for a future request based upon the server's stated <del> preferences in past responses.  Other patterns of content negotiation include "conditional content", where the representation consists of multiple parts that are selectively rendered based on user agent parameters, "active content", where the representation contains a script that makes additional (more specific) requests based on the user agent characteristics, and "Transparent Content Negotiation" (RFC2295), where content selection is performed by an intermediary. These patterns are not mutually exclusive, and each has trade-offs in </del>  applicability and practicality. Note that, in all cases, HTTP is not aware of the resource semantics.

Reviewer comments:
initial commit is just moving sections and updating headings; second commit will update some of "the following" comments to refer to the specific fields.
I believe it needs to be under "Proactive Negotiation" , or be a sibling of these...

Revised text:
provides a list of representations for the user agent to choose from, and "request payload" negotiation, where the user agent selects the representation for a future request based upon the server's stated  <ins> preferences in past responses. Other patterns of content negotiation include "conditional content", where the representation consists of multiple parts that are selectively rendered based on user agent parameters, "active content", where the representation contains a script that makes additional (more specific) requests based on the user agent characteristics, and "Transparent Content Negotiation" (RFC2295), where content selection is performed by an intermediary.  These patterns are not mutually exclusive, and each has trade-offs in </ins> applicability and practicality. Note that, in all cases, HTTP is not aware of the resource semantics.
Original text:
decimal point.  User configuration of these values ought to be limited in the same fashion. <del> 12.1.1.3. </del>  Most of these header fields, where indicated, define a wildcard value <del> ("*") to select unspecified values.  If no wildcard is present, all values not explicitly mentioned in the field are considered "not acceptable" to the client. </del>  <del> 12.1.2. </del>  The "Accept" header field can be used by user agents to specify their preferences regarding response media types.  For example, Accept

Reviewer comments:
initial commit is just moving sections and updating headings; second commit will update some of "the following" comments to refer to the specific fields.
I believe it needs to be under "Proactive Negotiation" , or be a sibling of these...

Revised text:
decimal point.  User configuration of these values ought to be limited in the same fashion.  <ins> 12.4.3. </ins> Most of these header fields, where indicated, define a wildcard value  <ins> ("*") to select unspecified values.  If no wildcard is present, values that are not explicitly mentioned in the field are considered unacceptable, except for within where it means the variance is unlimited. 12.5. </ins>  <ins> 12.5.1. </ins> The "Accept" header field can be used by user agents to specify their preferences regarding response media types.  For example, Accept
Original text:
would cause the following values to be associated: <del> 12.1.3. </del>  The "Accept-Charset" header field can be sent by a user agent to indicate its preferences for charsets in textual response content.

Reviewer comments:
initial commit is just moving sections and updating headings; second commit will update some of "the following" comments to refer to the specific fields.
I believe it needs to be under "Proactive Negotiation" , or be a sibling of these...

Revised text:
would cause the following values to be associated:  <ins> 12.5.2. </ins> The "Accept-Charset" header field can be sent by a user agent to indicate its preferences for charsets in textual response content.
Original text:
The special value "*", if present in the Accept-Charset header field, matches every charset that is not mentioned elsewhere in the field. <del> 12.1.4. </del>  The "Accept-Encoding" header field can be used to indicate preferences regarding the use of content codings (content.codings).

Reviewer comments:
initial commit is just moving sections and updating headings; second commit will update some of "the following" comments to refer to the specific fields.
I believe it needs to be under "Proactive Negotiation" , or be a sibling of these...

Revised text:
The special value "*", if present in the Accept-Charset header field, matches every charset that is not mentioned elsewhere in the field.  <ins> 12.5.3. </ins> The "Accept-Encoding" header field can be used to indicate preferences regarding the use of content codings (content.codings).
Original text:
response when the request payload was big enough to justify use of a compression coding but the client failed do so. <del> 12.1.5. </del>  The "Accept-Language" header field can be used by user agents to indicate the set of natural languages that are preferred in the

Reviewer comments:
initial commit is just moving sections and updating headings; second commit will update some of "the following" comments to refer to the specific fields.
I believe it needs to be under "Proactive Negotiation" , or be a sibling of these...

Revised text:
response when the request payload was big enough to justify use of a compression coding but the client failed do so.  <ins> 12.5.4. </ins> The "Accept-Language" header field can be used by user agents to indicate the set of natural languages that are preferred in the
Original text:
does not provide such control to the user MUST NOT send an Accept- Language header field. <del> 12.2. With (a.k.a., ), selection of the best response representation (regardless of the status code) is performed by the user agent after receiving an initial response from the origin server that contains a list of resources for alternative representations.  If the user agent is not satisfied by the initial response representation, it can perform a GET request on one or more of the alternative resources, selected based on metadata included in the list, to obtain a different form of representation for that response.  Selection of alternatives might be performed automatically by the user agent or manually by the user selecting from a generated (possibly hypertext) menu. Note that the above refers to representations of the response, in general, not representations of the resource.  The alternative representations are only considered representations of the target resource if the response in which those alternatives are provided has the semantics of being a representation of the target resource (e.g., a response to a GET request) or has the semantics of providing links to alternative representations for the target resource (e.g., a response to a GET request). A server might choose not to send an initial representation, other than the list of alternatives, and thereby indicate that reactive negotiation by the user agent is preferred.  For example, the alternatives listed in responses with the and status codes include information about the available representations so that the user or user agent can react by making a selection. Reactive negotiation is advantageous when the response would vary over commonly used dimensions (such as type, language, or encoding), when the origin server is unable to determine a user agent's capabilities from examining the request, and generally when public caches are used to distribute server load and reduce network usage. Reactive negotiation suffers from the disadvantages of transmitting a list of alternatives to the user agent, which degrades user-perceived latency if transmitted in the header section, and needing a second request to obtain an alternate representation.  Furthermore, this specification does not define a mechanism for supporting automatic selection, though it does not prevent such a mechanism from being developed as an extension. 12.2.1. </del>  The "Vary" header field in a response describes what parts of a request message, aside from the method and target URI, might

Reviewer comments:
initial commit is just moving sections and updating headings; second commit will update some of "the following" comments to refer to the specific fields.
I believe it needs to be under "Proactive Negotiation" , or be a sibling of these...

Revised text:
does not provide such control to the user MUST NOT send an Accept- Language header field.  <ins> 12.5.5. </ins> The "Vary" header field in a response describes what parts of a request message, aside from the method and target URI, might
Original text:
it considers the variance less significant than the performance cost of Vary's impact on caching. <del> 12.3. When content negotiation preferences are sent in a server's response, the listed preferences are called because they intend to influence selection of an appropriate payload for subsequent requests to that resource.  For example, the (field.accept) and (field.accept-encoding) header fields can be sent in a response to indicate preferred media types and content codings for subsequent requests to that resource. Similarly, RFC5789 defines the "Accept-Patch" response header field which allows discovery of which content types are accepted in PATCH requests. </del> 13. A conditional request is an HTTP request with one or more request

Reviewer comments:
initial commit is just moving sections and updating headings; second commit will update some of "the following" comments to refer to the specific fields.
I believe it needs to be under "Proactive Negotiation" , or be a sibling of these...

Revised text:
it considers the variance less significant than the performance cost of Vary's impact on caching.  13. A conditional request is an HTTP request with one or more request
Original text:
can be distinguished from a valid <del> by examining the first two characters for a DQUOTE. </del>  If the validator given in the If-Range header field matches the current validator for the selected representation of the target

Reviewer comments:
(this text is present in RFC 7233 as well) "A valid entity-tag can be distinguished from a valid HTTP-date by examining the first two characters for a DQUOTE." Hm, no. If we want to properly handle weak etags, we either need to inspect three characters (actually position 0 and 2) for DQUOTE, or check pos 0 for DQUOTE or pos 1 for "/". If we're not interested in weak etags, checking the first character is sufficient.

Revised text:
can be distinguished from a valid  <ins> by examining the first three characters for a DQUOTE. </ins> If the validator given in the If-Range header field matches the current validator for the selected representation of the target
Original text:
The status codes listed below are defined in this specification.  The reason phrases listed here are only recommendations -- they can be <del> replaced by local equivalents without affecting the protocol. </del>  Responses with status codes that are defined as heuristically cacheable (e.g., 200, 203, 204, 206, 300, 301, 308, 404, 405, 410,

Reviewer comments:
"The reason phrases listed here are only recommendations — they can be replaced by local equivalents without affecting the protocol." "URL left out altogether..." ?
(need to check where the fix went)

Revised text:
The status codes listed below are defined in this specification.  The reason phrases listed here are only recommendations -- they can be  <ins> replaced by local equivalents or left out altogether without affecting the protocol. </ins> Responses with status codes that are defined as heuristically cacheable (e.g., 200, 203, 204, 206, 300, 301, 308, 404, 405, 410,