jiebi/TextFlow huggingface dataset:
Original text:
A sender MUST NOT generate a bare CR (a CR character not immediately followed by LF) within any protocol elements other than the payload <del> body.  A recipient of such a bare CR MUST consider that element to be </del>  invalid or replace each bare CR with SP before processing the element or forwarding the message.

Reviewer comments:
This eliminates confusion with the message body protocol element of HTTP/1.1 and other usage of multipart body parts, and should make it easier to describe HTTP/2 and HTTP/3 data frames.
except for multipart body parts or when referring specifically to HTTP/1.1 message body.
See related comment: URL
I believe this is good; but more eyes are needed :-) If we go ahead with that, we may want to call out the new terminolody in one of the "changes from 723x" sections.

Revised text:
A sender MUST NOT generate a bare CR (a CR character not immediately followed by LF) within any protocol elements other than the payload  <ins> data.  A recipient of such a bare CR MUST consider that element to be </ins> invalid or replace each bare CR with SP before processing the element or forwarding the message.
Original text:
6. <del> The message body (if any) of an HTTP message is used to carry the payload body (payload.body) of that request or response.  The message body is identical to the payload body unless a transfer coding has been applied, as described in field.transfer-encoding. </del>  The rules for determining when a message body is present in an HTTP/1.1 message differ for requests and responses.

Reviewer comments:
This eliminates confusion with the message body protocol element of HTTP/1.1 and other usage of multipart body parts, and should make it easier to describe HTTP/2 and HTTP/3 data frames.
except for multipart body parts or when referring specifically to HTTP/1.1 message body.
See related comment: URL
I believe this is good; but more eyes are needed :-) If we go ahead with that, we may want to call out the new terminolody in one of the "changes from 723x" sections.

Revised text:
6.  <ins> The message body (if any) of an HTTP/1.1 message is used to carry payload data (payload) for the request or response.  The message body is identical to the payload data unless a transfer coding has been applied, as described in field.transfer-encoding. </ins> The rules for determining when a message body is present in an HTTP/1.1 message differ for requests and responses.
Original text:
or header field.  Request message framing is independent of method <del> semantics, even if the method does not define any use for a message body. </del>  The presence of a message body in a response depends on both the request method to which it is responding and the response status code <del> (status.line), and corresponds to when a payload body is allowed; see payload.body. </del>  6.1. The Transfer-Encoding header field lists the transfer coding names corresponding to the sequence of transfer codings that have been (or <del> will be) applied to the payload body in order to form the message </del>  body.  Transfer codings are defined in transfer.codings. Transfer-Encoding is analogous to the Content-Transfer-Encoding field

Reviewer comments:
This eliminates confusion with the message body protocol element of HTTP/1.1 and other usage of multipart body parts, and should make it easier to describe HTTP/2 and HTTP/3 data frames.
except for multipart body parts or when referring specifically to HTTP/1.1 message body.
See related comment: URL
I believe this is good; but more eyes are needed :-) If we go ahead with that, we may want to call out the new terminolody in one of the "changes from 723x" sections.

Revised text:
or header field.  Request message framing is independent of method  <ins> semantics. </ins> The presence of a message body in a response depends on both the request method to which it is responding and the response status code  <ins> (status.line), and corresponds to when payload data is allowed; see payload. </ins> 6.1. The Transfer-Encoding header field lists the transfer coding names corresponding to the sequence of transfer codings that have been (or  <ins> will be) applied to the payload data in order to form the message </ins> body.  Transfer codings are defined in transfer.codings. Transfer-Encoding is analogous to the Content-Transfer-Encoding field
Original text:
A recipient MUST be able to parse the chunked transfer coding (chunked.encoding) because it plays a crucial role in framing <del> messages when the payload body size is not known in advance.  A </del>  sender MUST NOT apply chunked more than once to a message body (i.e., chunking an already chunked message is not allowed).  If any transfer <del> coding other than chunked is applied to a request payload body, the </del>  sender MUST apply chunked as the final transfer coding to ensure that the message is properly framed.  If any transfer coding other than <del> chunked is applied to a response payload body, the sender MUST either apply chunked as the final transfer coding or terminate the message by closing the connection. </del>  For example, <del> indicates that the payload body has been compressed using the gzip </del>  coding and then chunked using the chunked coding while forming the message body.

Reviewer comments:
This eliminates confusion with the message body protocol element of HTTP/1.1 and other usage of multipart body parts, and should make it easier to describe HTTP/2 and HTTP/3 data frames.
except for multipart body parts or when referring specifically to HTTP/1.1 message body.
See related comment: URL
I believe this is good; but more eyes are needed :-) If we go ahead with that, we may want to call out the new terminolody in one of the "changes from 723x" sections.

Revised text:
A recipient MUST be able to parse the chunked transfer coding (chunked.encoding) because it plays a crucial role in framing  <ins> messages when the payload data size is not known in advance.  A </ins> sender MUST NOT apply chunked more than once to a message body (i.e., chunking an already chunked message is not allowed).  If any transfer  <ins> coding other than chunked is applied to a request's payload data, the </ins> sender MUST apply chunked as the final transfer coding to ensure that the message is properly framed.  If any transfer coding other than  <ins> chunked is applied to a response's payload data, the sender MUST either apply chunked as the final transfer coding or terminate the message by closing the connection. </ins> For example,  <ins> indicates that the payload data has been compressed using the gzip </ins> coding and then chunked using the chunked coding while forming the message body.
Original text:
When a message does not have a header field, a Content-Length header field can provide the <del> anticipated size, as a decimal number of octets, for a potential payload body.  For messages that do include a payload body, the </del>  Content-Length field value provides the framing information necessary <del> for determining where the body (and message) ends.  For messages that do not include a payload body, the Content-Length indicates the size of the selected representation (field.content-length). </del>  6.3.

Reviewer comments:
This eliminates confusion with the message body protocol element of HTTP/1.1 and other usage of multipart body parts, and should make it easier to describe HTTP/2 and HTTP/3 data frames.
except for multipart body parts or when referring specifically to HTTP/1.1 message body.
See related comment: URL
I believe this is good; but more eyes are needed :-) If we go ahead with that, we may want to call out the new terminolody in one of the "changes from 723x" sections.

Revised text:
When a message does not have a header field, a Content-Length header field can provide the  <ins> anticipated size, as a decimal number of octets, for potential payload data.  For messages that do include payload data, the </ins> Content-Length field value provides the framing information necessary  <ins> for determining where the data (and message) ends.  For messages that do not include payload data, the Content-Length indicates the size of the selected representation (field.content-length). </ins> 6.3.
Original text:
If the final response to the last request on a connection has been completely received and there remains additional data to read, a user agent MAY discard the remaining data or attempt to determine if that <del> data belongs as part of the prior response body, which might be the </del>  case if the prior message's Content-Length value is incorrect.  A client MUST NOT process, cache, or forward such extra data as a separate response, since such behavior would be vulnerable to cache

Reviewer comments:
This eliminates confusion with the message body protocol element of HTTP/1.1 and other usage of multipart body parts, and should make it easier to describe HTTP/2 and HTTP/3 data frames.
except for multipart body parts or when referring specifically to HTTP/1.1 message body.
See related comment: URL
I believe this is good; but more eyes are needed :-) If we go ahead with that, we may want to call out the new terminolody in one of the "changes from 723x" sections.

Revised text:
If the final response to the last request on a connection has been completely received and there remains additional data to read, a user agent MAY discard the remaining data or attempt to determine if that  <ins> data belongs as part of the prior message body, which might be the </ins> case if the prior message's Content-Length value is incorrect.  A client MUST NOT process, cache, or forward such extra data as a separate response, since such behavior would be vulnerable to cache
Original text:
7. Transfer coding names are used to indicate an encoding transformation <del> that has been, can be, or might need to be applied to a payload body in order to ensure "safe transport" through the network.  This </del>  differs from a content coding in that the transfer coding is a property of the message rather than a property of the representation that is being transferred.

Reviewer comments:
This eliminates confusion with the message body protocol element of HTTP/1.1 and other usage of multipart body parts, and should make it easier to describe HTTP/2 and HTTP/3 data frames.
except for multipart body parts or when referring specifically to HTTP/1.1 message body.
See related comment: URL
I believe this is good; but more eyes are needed :-) If we go ahead with that, we may want to call out the new terminolody in one of the "changes from 723x" sections.

Revised text:
7. Transfer coding names are used to indicate an encoding transformation  <ins> that has been, can be, or might need to be applied to a payload's data in order to ensure "safe transport" through the network.  This </ins> differs from a content coding in that the transfer coding is a property of the message rather than a property of the representation that is being transferred.
Original text:
7.1. <del> The chunked transfer coding wraps the payload body in order to transfer it as a series of chunks, each with its own size indicator, followed by an OPTIONAL trailer section containing trailer fields. Chunked enables content streams of unknown size to be transferred as a sequence of length-delimited buffers, which enables the sender to </del>  retain connection persistence and the recipient to know when it has received the entire message.

Reviewer comments:
This eliminates confusion with the message body protocol element of HTTP/1.1 and other usage of multipart body parts, and should make it easier to describe HTTP/2 and HTTP/3 data frames.
except for multipart body parts or when referring specifically to HTTP/1.1 message body.
See related comment: URL
I believe this is good; but more eyes are needed :-) If we go ahead with that, we may want to call out the new terminolody in one of the "changes from 723x" sections.

Revised text:
7.1.  <ins> The chunked transfer coding wraps payload data in order to transfer it as a series of chunks, each with its own size indicator, followed by an OPTIONAL trailer section containing trailer fields.  Chunked enables content streams of unknown size to be transferred as a sequence of length-delimited buffers, which enables the sender to </ins> retain connection persistence and the recipient to know when it has received the entire message.
Original text:
A trailer section allows the sender to include additional fields at the end of a chunked message in order to supply metadata that might <del> be dynamically generated while the message body is sent, such as a </del>  message integrity check, digital signature, or post-processing status.  The proper use and limitations of trailer fields are defined in trailer.fields.

Reviewer comments:
This eliminates confusion with the message body protocol element of HTTP/1.1 and other usage of multipart body parts, and should make it easier to describe HTTP/2 and HTTP/3 data frames.
except for multipart body parts or when referring specifically to HTTP/1.1 message body.
See related comment: URL
I believe this is good; but more eyes are needed :-) If we go ahead with that, we may want to call out the new terminolody in one of the "changes from 723x" sections.

Revised text:
A trailer section allows the sender to include additional fields at the end of a chunked message in order to supply metadata that might  <ins> be dynamically generated while the payload data is sent, such as a </ins> message integrity check, digital signature, or post-processing status.  The proper use and limitations of trailer fields are defined in trailer.fields.
Original text:
The request target's host and port value are passed within each HTTP request, identifying the origin and distinguishing it from other <del> namespaces that might be controlled by the same server.  It is the origin's responsibility to ensure that any services provided with control over its certificate's private key are equally responsible for managing the corresponding "https" namespaces, or at least prepared to reject requests that appear to have been misdirected.  A server might be unwilling to serve as the origin for some hosts even when they have the authority to do so. </del>  For example, if a network attacker causes connections for port N to be received at port Q, checking the target URI is necessary to ensure

Reviewer comments:
Recently I noticed that the host header field is being discussed in . I believe that we should move the definition of the host header to the HTTP/1.1 messaging draft, and discuss about "authority" as a concept in the semantics draft, as the "host" header is specific to HTTP/1.1 (except for handling of broken HTTP/2 clients)?
Hi Kazuho, We discussed this on the editors' call. Host's semantics aren't specific to HTTP/1.1, even if its requirements are different in other protocol versions. That's why we moved it to Semantics; it's not version-specific (and really very few headers should be). Closing; if you feel it needs more discussion please request re-opening and we'll do so.
Thank you for the consideration. While I do understand the argument that the semantics of the header field is not version specific, the use is. I've opened a PR that tries to clarify that.
Thank you for the changes!

Revised text:
The request target's host and port value are passed within each HTTP request, identifying the origin and distinguishing it from other  <ins> namespaces that might be controlled by the same server (field.host). It is the origin's responsibility to ensure that any services provided with control over its certificate's private key are equally responsible for managing the corresponding "https" namespaces, or at least prepared to reject requests that appear to have been misdirected.  A server might be unwilling to serve as the origin for some hosts even when they have the authority to do so. </ins> For example, if a network attacker causes connections for port N to be received at port Q, checking the target URI is necessary to ensure
Original text:
and <del> fields ought to be implemented by all HTTP/1.x implementations whether or not they advertise conformance with HTTP/1.1. </del>  New fields can be introduced without changing the protocol version if their defined semantics allow them to be safely ignored by recipients

Reviewer comments:
Recently I noticed that the host header field is being discussed in . I believe that we should move the definition of the host header to the HTTP/1.1 messaging draft, and discuss about "authority" as a concept in the semantics draft, as the "host" header is specific to HTTP/1.1 (except for handling of broken HTTP/2 clients)?
Hi Kazuho, We discussed this on the editors' call. Host's semantics aren't specific to HTTP/1.1, even if its requirements are different in other protocol versions. That's why we moved it to Semantics; it's not version-specific (and really very few headers should be). Closing; if you feel it needs more discussion please request re-opening and we'll do so.
Thank you for the consideration. While I do understand the argument that the semantics of the header field is not version specific, the use is. I've opened a PR that tries to clarify that.
Thank you for the changes!

Revised text:
and  <ins> fields ought to be recognized by all HTTP implementations whether or not they advertise conformance with HTTP/1.1. </ins> New fields can be introduced without changing the protocol version if their defined semantics allow them to be safely ignored by recipients
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:
Recently I noticed that the host header field is being discussed in . I believe that we should move the definition of the host header to the HTTP/1.1 messaging draft, and discuss about "authority" as a concept in the semantics draft, as the "host" header is specific to HTTP/1.1 (except for handling of broken HTTP/2 clients)?
Hi Kazuho, We discussed this on the editors' call. Host's semantics aren't specific to HTTP/1.1, even if its requirements are different in other protocol versions. That's why we moved it to Semantics; it's not version-specific (and really very few headers should be). Closing; if you feel it needs more discussion please request re-opening and we'll do so.
Thank you for the consideration. While I do understand the argument that the semantics of the header field is not version specific, the use is. I've opened a PR that tries to clarify that.
Thank you for the changes!

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:
The request target's host and port value are passed within each HTTP request, identifying the origin and distinguishing it from other <del> namespaces that might be controlled by the same server.  It is the origin's responsibility to ensure that any services provided with control over its certificate's private key are equally responsible for managing the corresponding "https" namespaces, or at least prepared to reject requests that appear to have been misdirected.  A server might be unwilling to serve as the origin for some hosts even when they have the authority to do so. </del>  For example, if a network attacker causes connections for port N to be received at port Q, checking the target URI is necessary to ensure

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 request target's host and port value are passed within each HTTP request, identifying the origin and distinguishing it from other  <ins> namespaces that might be controlled by the same server (field.host). It is the origin's responsibility to ensure that any services provided with control over its certificate's private key are equally responsible for managing the corresponding "https" namespaces, or at least prepared to reject requests that appear to have been misdirected.  A server might be unwilling to serve as the origin for some hosts even when they have the authority to do so. </ins> For example, if a network attacker causes connections for port N to be received at port Q, checking the target URI is necessary to ensure
Original text:
and <del> fields ought to be implemented by all HTTP/1.x implementations whether or not they advertise conformance with HTTP/1.1. </del>  New fields can be introduced without changing the protocol version if their defined semantics allow them to be safely ignored by recipients

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:
and  <ins> fields ought to be recognized by all HTTP implementations whether or not they advertise conformance with HTTP/1.1. </ins> New fields can be introduced without changing the protocol version if their defined semantics allow them to be safely ignored by recipients