jiebi/TextFlow huggingface dataset:
Original text:
(protocol.version).  Response message control data includes a status code (status.codes), optional reason phrase, and protocol version. <del> In HTTP/1.1 Messaging and earlier, control data is sent as the first line of a message.  In HTTP/2 (RFC7540) and HTTP/3 (HTTP3), control data is sent as pseudo-header fields with a reserved name prefix (e.g., ":authority"). </del>  Every HTTP message has a protocol version.  Depending on the version in use, it might be identified within the message explicitly or

Reviewer comments:
I think it would be better to separate this into the purely editorial changes (all except TRACE), and then give the change to TRACE the full treatment separately (it's a normative change after all). Will work on the former first.
Sorry for this being a question. I answered the same question for -caching by searching through and realizing that while caching might be a version-independent extension, a practical consequence of the structure of documents is that it is inextricably linked to -semantics. That's cool. Having the definition of HTTP/N rely on -caching is eminently sensible. There is a normative reference to -messaging though. Why would HTTP/3 care about that? If this were software, I'd be horrified by pulling in a dependency like that. Most of the references to -messaging are strictly examples. I could only see two cases where there was a potentially normative dependency: recommends "message/http" and . These seem like they could be broken (the second easier than the first, certainly) and the reference made normative.
I agree that this would be good.
A SHOULD-level requirement to use message/http. Moving the media type definition over is not going to help, because it essentially defines the HTTP/1.1 wire format as media type. It seems the only way to fix this would be to relax the SHOULD. That one could probably be replaced with a reference to the transfer coding registry (which is what counts here), and the pointer to the spec text would then become informative.
History in and linked issues.
Concrete recommendation for 1: a server (intermediary) responding to TRACE MUST generate a representation of the request that it received in any format. The message/http is one possible way to represent a request message, so that can be an informative reference instead.

Revised text:
(protocol.version).  Response message control data includes a status code (status.codes), optional reason phrase, and protocol version.  <ins> In HTTP/1.1 (Messaging) and earlier, control data is sent as the first line of a message.  In HTTP/2 (RFC7540) and HTTP/3 (HTTP3), control data is sent as pseudo-header fields with a reserved name prefix (e.g., ":authority"). </ins> Every HTTP message has a protocol version.  Depending on the version in use, it might be identified within the message explicitly or
Original text:
6.5. <del> Fields (fields) that are sent/received after the header section has ended (usually after the content begins to stream) are referred to as "trailer fields" (or just "trailers", colloquially) and located within a </del>  <del> .  Trailer fields can be useful for supplying message integrity checks, digital signatures, delivery metrics, or post-processing status information. </del>  Trailer fields ought to be processed and stored separately from the fields in the header section to avoid contradicting message semantics

Reviewer comments:
I think it would be better to separate this into the purely editorial changes (all except TRACE), and then give the change to TRACE the full treatment separately (it's a normative change after all). Will work on the former first.
Sorry for this being a question. I answered the same question for -caching by searching through and realizing that while caching might be a version-independent extension, a practical consequence of the structure of documents is that it is inextricably linked to -semantics. That's cool. Having the definition of HTTP/N rely on -caching is eminently sensible. There is a normative reference to -messaging though. Why would HTTP/3 care about that? If this were software, I'd be horrified by pulling in a dependency like that. Most of the references to -messaging are strictly examples. I could only see two cases where there was a potentially normative dependency: recommends "message/http" and . These seem like they could be broken (the second easier than the first, certainly) and the reference made normative.
I agree that this would be good.
A SHOULD-level requirement to use message/http. Moving the media type definition over is not going to help, because it essentially defines the HTTP/1.1 wire format as media type. It seems the only way to fix this would be to relax the SHOULD. That one could probably be replaced with a reference to the transfer coding registry (which is what counts here), and the pointer to the spec text would then become informative.
History in and linked issues.
Concrete recommendation for 1: a server (intermediary) responding to TRACE MUST generate a representation of the request that it received in any format. The message/http is one possible way to represent a request message, so that can be an informative reference instead.

Revised text:
6.5.  <ins> Fields (fields) that are located within a </ins>  <ins> are are referred to as "trailer fields" (or just "trailers", colloquially).  Trailer fields can be useful for supplying message integrity checks, digital signatures, delivery metrics, or post- processing status information. </ins> Trailer fields ought to be processed and stored separately from the fields in the header section to avoid contradicting message semantics
Original text:
6.5.1. <del> Trailer sections are only possible when supported by the version of </del>  HTTP in use and enabled by an explicit framing mechanism.  For example, the chunked coding in HTTP/1.1 allows a trailer section to be sent after the content (chunked.trailer.section).

Reviewer comments:
I think it would be better to separate this into the purely editorial changes (all except TRACE), and then give the change to TRACE the full treatment separately (it's a normative change after all). Will work on the former first.
Sorry for this being a question. I answered the same question for -caching by searching through and realizing that while caching might be a version-independent extension, a practical consequence of the structure of documents is that it is inextricably linked to -semantics. That's cool. Having the definition of HTTP/N rely on -caching is eminently sensible. There is a normative reference to -messaging though. Why would HTTP/3 care about that? If this were software, I'd be horrified by pulling in a dependency like that. Most of the references to -messaging are strictly examples. I could only see two cases where there was a potentially normative dependency: recommends "message/http" and . These seem like they could be broken (the second easier than the first, certainly) and the reference made normative.
I agree that this would be good.
A SHOULD-level requirement to use message/http. Moving the media type definition over is not going to help, because it essentially defines the HTTP/1.1 wire format as media type. It seems the only way to fix this would be to relax the SHOULD. That one could probably be replaced with a reference to the transfer coding registry (which is what counts here), and the pointer to the spec text would then become informative.
History in and linked issues.
Concrete recommendation for 1: a server (intermediary) responding to TRACE MUST generate a representation of the request that it received in any format. The message/http is one possible way to represent a request message, so that can be an informative reference instead.

Revised text:
6.5.1.  <ins> A trailer section is only possible when supported by the version of </ins> HTTP in use and enabled by an explicit framing mechanism.  For example, the chunked coding in HTTP/1.1 allows a trailer section to be sent after the content (chunked.trailer.section).
Original text:
reflect the message received, excluding some fields described below, back to the client as the content of a <del> response with a of "message/http" (media.type.message.http).  The final recipient is either the origin server or the first server to receive a </del>  value of zero (0) in the request (field.max-forwards).

Reviewer comments:
I think it would be better to separate this into the purely editorial changes (all except TRACE), and then give the change to TRACE the full treatment separately (it's a normative change after all). Will work on the former first.
Sorry for this being a question. I answered the same question for -caching by searching through and realizing that while caching might be a version-independent extension, a practical consequence of the structure of documents is that it is inextricably linked to -semantics. That's cool. Having the definition of HTTP/N rely on -caching is eminently sensible. There is a normative reference to -messaging though. Why would HTTP/3 care about that? If this were software, I'd be horrified by pulling in a dependency like that. Most of the references to -messaging are strictly examples. I could only see two cases where there was a potentially normative dependency: recommends "message/http" and . These seem like they could be broken (the second easier than the first, certainly) and the reference made normative.
I agree that this would be good.
A SHOULD-level requirement to use message/http. Moving the media type definition over is not going to help, because it essentially defines the HTTP/1.1 wire format as media type. It seems the only way to fix this would be to relax the SHOULD. That one could probably be replaced with a reference to the transfer coding registry (which is what counts here), and the pointer to the spec text would then become informative.
History in and linked issues.
Concrete recommendation for 1: a server (intermediary) responding to TRACE MUST generate a representation of the request that it received in any format. The message/http is one possible way to represent a request message, so that can be an informative reference instead.

Revised text:
reflect the message received, excluding some fields described below, back to the client as the content of a  <ins> response.  The "message/http" (media.type.message.http) format is one way to do so.  The final recipient is either the origin server or the first server to receive a </ins> value of zero (0) in the request (field.max-forwards).
Original text:
application or data format, since orthogonal technologies deserve orthogonal specification. <del> Since message parsing (message.body) needs to be independent of method semantics (aside from responses to HEAD), definitions of new methods cannot change the parsing algorithm or prohibit the presence of content on either the request or the response message. </del>  Definitions of new methods can specify that only a zero-length content is allowed by requiring a Content-Length header field with a value of "0".

Reviewer comments:
I think it would be better to separate this into the purely editorial changes (all except TRACE), and then give the change to TRACE the full treatment separately (it's a normative change after all). Will work on the former first.
Sorry for this being a question. I answered the same question for -caching by searching through and realizing that while caching might be a version-independent extension, a practical consequence of the structure of documents is that it is inextricably linked to -semantics. That's cool. Having the definition of HTTP/N rely on -caching is eminently sensible. There is a normative reference to -messaging though. Why would HTTP/3 care about that? If this were software, I'd be horrified by pulling in a dependency like that. Most of the references to -messaging are strictly examples. I could only see two cases where there was a potentially normative dependency: recommends "message/http" and . These seem like they could be broken (the second easier than the first, certainly) and the reference made normative.
I agree that this would be good.
A SHOULD-level requirement to use message/http. Moving the media type definition over is not going to help, because it essentially defines the HTTP/1.1 wire format as media type. It seems the only way to fix this would be to relax the SHOULD. That one could probably be replaced with a reference to the transfer coding registry (which is what counts here), and the pointer to the spec text would then become informative.
History in and linked issues.
Concrete recommendation for 1: a server (intermediary) responding to TRACE MUST generate a representation of the request that it received in any format. The message/http is one possible way to represent a request message, so that can be an informative reference instead.

Revised text:
application or data format, since orthogonal technologies deserve orthogonal specification.  <ins> Since message parsing (message.abstraction) needs to be independent of method semantics (aside from responses to HEAD), definitions of new methods cannot change the parsing algorithm or prohibit the presence of content on either the request or the response message. </ins> Definitions of new methods can specify that only a zero-length content is allowed by requiring a Content-Length header field with a value of "0".
Original text:
Content coding registrations MUST include the following fields: Names of content codings MUST NOT overlap with names of transfer <del> codings (transfer.codings), unless the encoding transformation is identical (as is the case for the compression codings defined in content.codings). </del>  Values to be added to this namespace require IETF Review (see RFC8126) and MUST conform to the purpose of content coding defined in

Reviewer comments:
I think it would be better to separate this into the purely editorial changes (all except TRACE), and then give the change to TRACE the full treatment separately (it's a normative change after all). Will work on the former first.
Sorry for this being a question. I answered the same question for -caching by searching through and realizing that while caching might be a version-independent extension, a practical consequence of the structure of documents is that it is inextricably linked to -semantics. That's cool. Having the definition of HTTP/N rely on -caching is eminently sensible. There is a normative reference to -messaging though. Why would HTTP/3 care about that? If this were software, I'd be horrified by pulling in a dependency like that. Most of the references to -messaging are strictly examples. I could only see two cases where there was a potentially normative dependency: recommends "message/http" and . These seem like they could be broken (the second easier than the first, certainly) and the reference made normative.
I agree that this would be good.
A SHOULD-level requirement to use message/http. Moving the media type definition over is not going to help, because it essentially defines the HTTP/1.1 wire format as media type. It seems the only way to fix this would be to relax the SHOULD. That one could probably be replaced with a reference to the transfer coding registry (which is what counts here), and the pointer to the spec text would then become informative.
History in and linked issues.
Concrete recommendation for 1: a server (intermediary) responding to TRACE MUST generate a representation of the request that it received in any format. The message/http is one possible way to represent a request message, so that can be an informative reference instead.

Revised text:
Content coding registrations MUST include the following fields: Names of content codings MUST NOT overlap with names of transfer  <ins> codings (as per the "HTTP Transfer Coding registry", located at <https://www.iana.org/assignments/http-parameters/>), unless the encoding transformation is identical (as is the case for the compression codings defined in content.codings). </ins> Values to be added to this namespace require IETF Review (see RFC8126) and MUST conform to the purpose of content coding defined in
Original text:
The TE field (field.te) is used in HTTP/1.1 to indicate what transfer-codings, besides chunked, the client is willing to accept in <del> the response, and whether or not the client is willing to accept </del>  trailer fields in a chunked transfer coding. A client MUST NOT send the chunked transfer coding name in TE;

Reviewer comments:
Trailers that come after the body has well-defined semantics (i.e. metadata applicable to the entire body). Interleaved, mid-stream trailers are considered and implemented as extensions, and maybe we should delay adding them to the core semantics. This is however an important topic for HTTPAPI, IMO.
See related mailing list thread at .
Discussed at Feb 21 interim; sentiment is to remove it; NAME to create a PR.
WFM, thanks.

Revised text:
The TE field (field.te) is used in HTTP/1.1 to indicate what transfer-codings, besides chunked, the client is willing to accept in  <ins> the response, and whether or not the client is willing to preserve </ins> trailer fields in a chunked transfer coding. A client MUST NOT send the chunked transfer coding name in TE;
Original text:
Framing and control data is sent first, followed by a header section containing fields for the headers table.  When a message includes <del> content, the content is sent after the header section and potentially interleaved with zero or more trailer sections containing fields for the trailers table. </del>  Messages are expected to be processed as a stream, wherein the purpose of that stream and its continued processing is revealed while

Reviewer comments:
Trailers that come after the body has well-defined semantics (i.e. metadata applicable to the entire body). Interleaved, mid-stream trailers are considered and implemented as extensions, and maybe we should delay adding them to the core semantics. This is however an important topic for HTTPAPI, IMO.
See related mailing list thread at .
Discussed at Feb 21 interim; sentiment is to remove it; NAME to create a PR.
WFM, thanks.

Revised text:
Framing and control data is sent first, followed by a header section containing fields for the headers table.  When a message includes  <ins> content, the content is sent after the header section, potentially followed by a trailer section that might contain fields for the trailers table. </ins> Messages are expected to be processed as a stream, wherein the purpose of that stream and its continued processing is revealed while
Original text:
to know immediately, header fields describe what needs to be known before receiving content, the content (when present) presumably contains what the recipient wants or needs to fulfill the message <del> semantics, and trailer fields provide additional metadata that can be dropped (safely ignored) when not desired. </del>  Messages are intended to be

Reviewer comments:
Trailers that come after the body has well-defined semantics (i.e. metadata applicable to the entire body). Interleaved, mid-stream trailers are considered and implemented as extensions, and maybe we should delay adding them to the core semantics. This is however an important topic for HTTPAPI, IMO.
See related mailing list thread at .
Discussed at Feb 21 interim; sentiment is to remove it; NAME to create a PR.
WFM, thanks.

Revised text:
to know immediately, header fields describe what needs to be known before receiving content, the content (when present) presumably contains what the recipient wants or needs to fulfill the message  <ins> semantics, and trailer fields provide optional metadata that was unknown prior to sending the content. </ins> Messages are intended to be
Original text:
Note that this message abstraction is a generalization across many versions of HTTP, including features that might not be found in some versions.  For example, trailers were introduced within the HTTP/1.1 <del> chunked transfer coding as a single trailer section after the content.  An equivalent feature is present in HTTP/2 and HTTP/3 within the header block that terminates each stream.  However, multiple trailer sections interleaved with content have only been deployed as frame extensions. </del>  6.1.

Reviewer comments:
Trailers that come after the body has well-defined semantics (i.e. metadata applicable to the entire body). Interleaved, mid-stream trailers are considered and implemented as extensions, and maybe we should delay adding them to the core semantics. This is however an important topic for HTTPAPI, IMO.
See related mailing list thread at .
Discussed at Feb 21 interim; sentiment is to remove it; NAME to create a PR.
WFM, thanks.

Revised text:
Note that this message abstraction is a generalization across many versions of HTTP, including features that might not be found in some versions.  For example, trailers were introduced within the HTTP/1.1  <ins> chunked transfer coding as a trailer section after the content.  An equivalent feature is present in HTTP/2 and HTTP/3 within the header block that terminates each stream. </ins> 6.1.
Original text:
6.5. <del> Fields (fields) that are sent/received after the header section has ended (usually after the content begins to stream) are referred to as "trailer fields" (or just "trailers", colloquially) and located within a </del>  <del> .  Trailer fields can be useful for supplying message integrity checks, digital signatures, delivery metrics, or post-processing status information. </del>  Trailer fields ought to be processed and stored separately from the fields in the header section to avoid contradicting message semantics

Reviewer comments:
Trailers that come after the body has well-defined semantics (i.e. metadata applicable to the entire body). Interleaved, mid-stream trailers are considered and implemented as extensions, and maybe we should delay adding them to the core semantics. This is however an important topic for HTTPAPI, IMO.
See related mailing list thread at .
Discussed at Feb 21 interim; sentiment is to remove it; NAME to create a PR.
WFM, thanks.

Revised text:
6.5.  <ins> Fields (fields) that are located within a </ins>  <ins> are are referred to as "trailer fields" (or just "trailers", colloquially).  Trailer fields can be useful for supplying message integrity checks, digital signatures, delivery metrics, or post- processing status information. </ins> Trailer fields ought to be processed and stored separately from the fields in the header section to avoid contradicting message semantics
Original text:
6.5.1. <del> Trailer sections are only possible when supported by the version of </del>  HTTP in use and enabled by an explicit framing mechanism.  For example, the chunked coding in HTTP/1.1 allows a trailer section to be sent after the content (chunked.trailer.section).

Reviewer comments:
Trailers that come after the body has well-defined semantics (i.e. metadata applicable to the entire body). Interleaved, mid-stream trailers are considered and implemented as extensions, and maybe we should delay adding them to the core semantics. This is however an important topic for HTTPAPI, IMO.
See related mailing list thread at .
Discussed at Feb 21 interim; sentiment is to remove it; NAME to create a PR.
WFM, thanks.

Revised text:
6.5.1.  <ins> A trailer section is only possible when supported by the version of </ins> HTTP in use and enabled by an explicit framing mechanism.  For example, the chunked coding in HTTP/1.1 allows a trailer section to be sent after the content (chunked.trailer.section).