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:
I think we discussed this last week and Julian has pending changes to be made before review.
This just moves the ABNF, not the definition of the transfer codings.
This is the remaining ABNF production that Semantics imports from Messaging (for the definition of "TE"). Maybe we should move the production to messaging, reversing the dependency.
Discussed on call; worth a try.
URL out that there are a few more things to consider: Semantics currently claims there are regular parameters here, but transfer-parameter is special wrt BWS should we move the special case of "trailers" in the grammar into prose? In any case, what would it mean to have a ranking on "trailers"? Invalid, thus ignore? "t-ranking" seems to duplicate "weight"
Fine to merge, but shouldn't we also move the extensibility and IANA registry 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:
I think we discussed this last week and Julian has pending changes to be made before review.
This just moves the ABNF, not the definition of the transfer codings.
This is the remaining ABNF production that Semantics imports from Messaging (for the definition of "TE"). Maybe we should move the production to messaging, reversing the dependency.
Discussed on call; worth a try.
URL out that there are a few more things to consider: Semantics currently claims there are regular parameters here, but transfer-parameter is special wrt BWS should we move the special case of "trailers" in the grammar into prose? In any case, what would it mean to have a ranking on "trailers"? Invalid, thus ignore? "t-ranking" seems to duplicate "weight"
Fine to merge, but shouldn't we also move the extensibility and IANA registry 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:
I think we discussed this last week and Julian has pending changes to be made before review.
This just moves the ABNF, not the definition of the transfer codings.
This is the remaining ABNF production that Semantics imports from Messaging (for the definition of "TE"). Maybe we should move the production to messaging, reversing the dependency.
Discussed on call; worth a try.
URL out that there are a few more things to consider: Semantics currently claims there are regular parameters here, but transfer-parameter is special wrt BWS should we move the special case of "trailers" in the grammar into prose? In any case, what would it mean to have a ranking on "trailers"? Invalid, thus ignore? "t-ranking" seems to duplicate "weight"
Fine to merge, but shouldn't we also move the extensibility and IANA registry 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:
I think we discussed this last week and Julian has pending changes to be made before review.
This just moves the ABNF, not the definition of the transfer codings.
This is the remaining ABNF production that Semantics imports from Messaging (for the definition of "TE"). Maybe we should move the production to messaging, reversing the dependency.
Discussed on call; worth a try.
URL out that there are a few more things to consider: Semantics currently claims there are regular parameters here, but transfer-parameter is special wrt BWS should we move the special case of "trailers" in the grammar into prose? In any case, what would it mean to have a ranking on "trailers"? Invalid, thus ignore? "t-ranking" seems to duplicate "weight"
Fine to merge, but shouldn't we also move the extensibility and IANA registry 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:
I think we discussed this last week and Julian has pending changes to be made before review.
This just moves the ABNF, not the definition of the transfer codings.
This is the remaining ABNF production that Semantics imports from Messaging (for the definition of "TE"). Maybe we should move the production to messaging, reversing the dependency.
Discussed on call; worth a try.
URL out that there are a few more things to consider: Semantics currently claims there are regular parameters here, but transfer-parameter is special wrt BWS should we move the special case of "trailers" in the grammar into prose? In any case, what would it mean to have a ranking on "trailers"? Invalid, thus ignore? "t-ranking" seems to duplicate "weight"
Fine to merge, but shouldn't we also move the extensibility and IANA registry 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:
I think we discussed this last week and Julian has pending changes to be made before review.
This just moves the ABNF, not the definition of the transfer codings.
This is the remaining ABNF production that Semantics imports from Messaging (for the definition of "TE"). Maybe we should move the production to messaging, reversing the dependency.
Discussed on call; worth a try.
URL out that there are a few more things to consider: Semantics currently claims there are regular parameters here, but transfer-parameter is special wrt BWS should we move the special case of "trailers" in the grammar into prose? In any case, what would it mean to have a ranking on "trailers"? Invalid, thus ignore? "t-ranking" seems to duplicate "weight"
Fine to merge, but shouldn't we also move the extensibility and IANA registry 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. <del> Parameters are in the form of a name=value pair. </del> All transfer-coding names are case-insensitive and ought to be registered within the HTTP Transfer Coding registry, as defined in transfer.coding.registry.  They are used in the <del> (field.te) and </del>  <del> (field.transfer-encoding) header fields. </del>  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:
I think we discussed this last week and Julian has pending changes to be made before review.
This just moves the ABNF, not the definition of the transfer codings.
This is the remaining ABNF production that Semantics imports from Messaging (for the definition of "TE"). Maybe we should move the production to messaging, reversing the dependency.
Discussed on call; worth a try.
URL out that there are a few more things to consider: Semantics currently claims there are regular parameters here, but transfer-parameter is special wrt BWS should we move the special case of "trailers" in the grammar into prose? In any case, what would it mean to have a ranking on "trailers"? Invalid, thus ignore? "t-ranking" seems to duplicate "weight"
Fine to merge, but shouldn't we also move the extensibility and IANA registry 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.  All transfer-coding names are case-insensitive and ought to be registered within the HTTP Transfer Coding registry, as defined in transfer.coding.registry.  They are used in the  <ins> (field.transfer-encoding) and </ins>  <ins> (field.te) header fields (the latter also defining the "transfer- coding" grammar). </ins> 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:
I think we discussed this last week and Julian has pending changes to be made before review.
This just moves the ABNF, not the definition of the transfer codings.
This is the remaining ABNF production that Semantics imports from Messaging (for the definition of "TE"). Maybe we should move the production to messaging, reversing the dependency.
Discussed on call; worth a try.
URL out that there are a few more things to consider: Semantics currently claims there are regular parameters here, but transfer-parameter is special wrt BWS should we move the special case of "trailers" in the grammar into prose? In any case, what would it mean to have a ranking on "trailers"? Invalid, thus ignore? "t-ranking" seems to duplicate "weight"
Fine to merge, but shouldn't we also move the extensibility and IANA registry 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:
This section is meant to inform developers, information providers, and users of known security considerations relevant to HTTP message <del> syntax, parsing, and routing.  Security considerations about HTTP semantics and payloads are addressed in Semantics. </del>  11.1.

Reviewer comments:
I think we discussed this last week and Julian has pending changes to be made before review.
This just moves the ABNF, not the definition of the transfer codings.
This is the remaining ABNF production that Semantics imports from Messaging (for the definition of "TE"). Maybe we should move the production to messaging, reversing the dependency.
Discussed on call; worth a try.
URL out that there are a few more things to consider: Semantics currently claims there are regular parameters here, but transfer-parameter is special wrt BWS should we move the special case of "trailers" in the grammar into prose? In any case, what would it mean to have a ranking on "trailers"? Invalid, thus ignore? "t-ranking" seems to duplicate "weight"
Fine to merge, but shouldn't we also move the extensibility and IANA registry sections?

Revised text:
This section is meant to inform developers, information providers, and users of known security considerations relevant to HTTP message  <ins> syntax and parsing.  Security considerations about HTTP semantics, payloads, and routing are addressed in Semantics. </ins> 11.1.
Original text:
given pathname.  This original protocol is now referred to as HTTP/0.9 (see HTTP09). <del> HTTP's version number consists of two decimal digits separated by a "." (period or decimal point).  The first digit ("major version") indicates the messaging syntax, whereas the second digit ("minor version") indicates the highest minor version within that major version to which the sender is conformant (able to understand for future communication). </del> 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

Reviewer comments:
and only define the versioning there; leave message version requirements in control data. (no content changes)

Revised text:
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
Original text:
of an underlying connection failure, as described in idempotent.methods.  3. HTTP was created for the World Wide Web (WWW) architecture and has

Reviewer comments:
and only define the versioning there; leave message version requirements in control data. (no content changes)

Revised text:
of an underlying connection failure, as described in idempotent.methods. <ins> 2.5. HTTP's version number consists of two decimal digits separated by a "." (period or decimal point).  The first digit ("major version") indicates the messaging syntax, whereas the second digit ("minor version") indicates the highest minor version within that major version to which the sender is conformant (able to understand for future communication). While HTTP's core semantics don't change between protocol versions, the expression of them "on the wire" can change, and so the HTTP version number changes when incompatible changes are made to the wire format.  Additionally, HTTP allows incremental, backwards-compatible changes to be made to the protocol without changing its version through the use of defined extension points (extending). The protocol version as a whole indicates the sender's conformance with the set of requirements laid out in that version's corresponding specification of HTTP.  For example, the version "HTTP/1.1" is defined by the combined specifications of this document, "HTTP Caching" Caching, and "HTTP/1.1" Messaging. HTTP's major version number is incremented when an incompatible message syntax is introduced.  The minor number is incremented when changes made to the protocol have the effect of adding to the message semantics or implying additional capabilities of the sender. The minor version advertises the sender's communication capabilities even when the sender is only using a backwards-compatible subset of the protocol, thereby letting the recipient know that more advanced features can be used in response (by servers) or in future requests (by clients). When a major version of HTTP does not define any minor versions, the minor version "0" is implied and is used when referring to that protocol within a protocol element that requires sending a minor version. </ins> 3. HTTP was created for the World Wide Web (WWW) architecture and has
Original text:
can change versions as it passes through intermediaries, because the semantics of a HTTP message are independent of its version. <del> While HTTP's core semantics don't change between protocol versions, the expression of them "on the wire" can change, and so the HTTP version number changes when incompatible changes are made to the wire format.  Additionally, HTTP allows incremental, backwards-compatible changes to be made to the protocol without changing its version through the use of defined extension points (extending). The protocol version as a whole indicates the sender's conformance with the set of requirements laid out in that version's corresponding specification of HTTP.  For example, the version "HTTP/1.1" is defined by the combined specifications of this document, "HTTP Caching" Caching, and "HTTP/1.1" Messaging. HTTP's major version number is incremented when an incompatible message syntax is introduced.  The minor number is incremented when changes made to the protocol have the effect of adding to the message semantics or implying additional capabilities of the sender. The minor version advertises the sender's communication capabilities even when the sender is only using a backwards-compatible subset of the protocol, thereby letting the recipient know that more advanced features can be used in response (by servers) or in future requests (by clients). </del> A client SHOULD send a request version equal to the highest version to which the client is conformant and whose major version is no higher than the highest version supported by the server, if this is

Reviewer comments:
and only define the versioning there; leave message version requirements in control data. (no content changes)

Revised text:
can change versions as it passes through intermediaries, because the semantics of a HTTP message are independent of its version.  A client SHOULD send a request version equal to the highest version to which the client is conformant and whose major version is no higher than the highest version supported by the server, if this is
Original text:
sufficiently backwards-compatible to be safely processed by any implementation of the same major version. <del> When a major version of HTTP does not define any minor versions, the minor version "0" is implied and is used when referring to that protocol within a protocol element that requires sending a minor version. </del> 5.3. HTTP messages use key/value pairs to convey data about the message,

Reviewer comments:
and only define the versioning there; leave message version requirements in control data. (no content changes)

Revised text:
sufficiently backwards-compatible to be safely processed by any implementation of the same major version.  5.3. HTTP messages use key/value pairs to convey data about the message,