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:
Make sure that all references to MESSAGING which are not normative are clearly informative. (This ticket is not about those references which right now are indeed normative, see ).

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:
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:
Make sure that all references to MESSAGING which are not normative are clearly informative. (This ticket is not about those references which right now are indeed normative, see ).

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:
Make sure that all references to MESSAGING which are not normative are clearly informative. (This ticket is not about those references which right now are indeed normative, see ).

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:
determined by looking at the message itself, after decoding or reconstituting parts that have been compressed or elided in transit, without requiring an understanding of the sender's current <del> application state (established via prior messages). </del>  Note that this message abstraction is a generalization across many versions of HTTP, including features that might not be found in some

Reviewer comments:
… in that the request must be understood in order to parse and interpret the response.
Well, the simple version is a normative statement in sheep's clothing. Let's just make it normative.
Section 6 claims that . It uses the word "intended", which is an intention that is broadly achieved, with only one exception that I'm aware of at the syntactic level. Having recently implemented message/http, I discovered that some response messages cannot be processed without knowledge of the corresponding request. This is pretty annoying and might be worth noting as a possible exception here. As noted in the response to a HEAD request might include Content-Length, but the content of the response is always empty. At a semantic level, I don't think that any response can be considered without knowledge of the request, so I don't think that self-descriptiveness can possibly apply there. Besides, this section is clearly intended to provide an abstract definition of the syntax and not semantics.
See also

Revised text:
determined by looking at the message itself, after decoding or reconstituting parts that have been compressed or elided in transit, without requiring an understanding of the sender's current  <ins> application state (established via prior messages).  However, a client MUST retain knowledge of the request when parsing, interpreting, or caching a corresponding response.  For example, responses to the method look just like the beginning of a response to , but cannot be parsed in the same manner. </ins> Note that this message abstraction is a generalization across many versions of HTTP, including features that might not be found in some
Original text:
(a.k.a., <del> ), 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 </del>  <del> response to a GET request). </del>  A server might choose not to send an initial representation, other than the list of alternatives, and thereby indicate that reactive

Reviewer comments:
… in that the request must be understood in order to parse and interpret the response.
Well, the simple version is a normative statement in sheep's clothing. Let's just make it normative.
Section 6 claims that . It uses the word "intended", which is an intention that is broadly achieved, with only one exception that I'm aware of at the syntactic level. Having recently implemented message/http, I discovered that some response messages cannot be processed without knowledge of the corresponding request. This is pretty annoying and might be worth noting as a possible exception here. As noted in the response to a HEAD request might include Content-Length, but the content of the response is always empty. At a semantic level, I don't think that any response can be considered without knowledge of the request, so I don't think that self-descriptiveness can possibly apply there. Besides, this section is clearly intended to provide an abstract definition of the syntax and not semantics.
See also

Revised text:
(a.k.a.,  <ins> ), selection of content (regardless of the status code) is performed by the user agent after receiving an initial response.  The mechanism for reactive negotiation might be as simple as a list of references to alternative representations. </ins>  <ins> If the user agent is not satisfied by the initial response content, it can perform a GET request on one or more of the alternative resources to obtain a different representation.  Selection of such alternatives might be performed automatically (by the user agent) or manually (e.g., by the user selecting from a hypertext menu). </ins> A server might choose not to send an initial representation, other than the list of alternatives, and thereby indicate that reactive
Original text:
and <del> status codes include information about the available representations so that the user or user agent can react by making a selection. </del>  Reactive negotiation is advantageous when the response would vary over commonly used dimensions (such as type, language, or encoding),

Reviewer comments:
… in that the request must be understood in order to parse and interpret the response.
Well, the simple version is a normative statement in sheep's clothing. Let's just make it normative.
Section 6 claims that . It uses the word "intended", which is an intention that is broadly achieved, with only one exception that I'm aware of at the syntactic level. Having recently implemented message/http, I discovered that some response messages cannot be processed without knowledge of the corresponding request. This is pretty annoying and might be worth noting as a possible exception here. As noted in the response to a HEAD request might include Content-Length, but the content of the response is always empty. At a semantic level, I don't think that any response can be considered without knowledge of the request, so I don't think that self-descriptiveness can possibly apply there. Besides, this section is clearly intended to provide an abstract definition of the syntax and not semantics.
See also

Revised text:
and  <ins> status codes include information about available representations so that the user or user agent can react by making a selection. </ins> Reactive negotiation is advantageous when the response would vary over commonly used dimensions (such as type, language, or encoding),
Original text:
(a.k.a., <del> ), 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). </del>  A server might choose not to send an initial representation, other than the list of alternatives, and thereby indicate that reactive

Reviewer comments:
in Section 12.2 uses "representation of the response", which I can't find a definition for. I think this should be "representation data" or "representation data contained in the response".
Much simpler, thanks.This is fine, but "a preferred kind of content" doesn't read well.

Revised text:
(a.k.a.,  <ins> ), selection of content (regardless of the status code) is performed by the user agent after receiving an initial response.  The mechanism for reactive negotiation might be as simple as a list of references to alternative representations. If the user agent is not satisfied by the initial response content, it can perform a GET request on one or more of the alternative resources to obtain a different representation.  Selection of such alternatives might be performed automatically (by the user agent) or manually (e.g., by the user selecting from a hypertext menu). </ins> A server might choose not to send an initial representation, other than the list of alternatives, and thereby indicate that reactive
Original text:
and <del> status codes include information about the available representations so that the user or user agent can react by making a selection. </del>  Reactive negotiation is advantageous when the response would vary over commonly used dimensions (such as type, language, or encoding),

Reviewer comments:
in Section 12.2 uses "representation of the response", which I can't find a definition for. I think this should be "representation data" or "representation data contained in the response".
Much simpler, thanks.This is fine, but "a preferred kind of content" doesn't read well.

Revised text:
and  <ins> status codes include information about available representations so that the user or user agent can react by making a selection. </ins> Reactive negotiation is advantageous when the response would vary over commonly used dimensions (such as type, language, or encoding),
Original text:
as shown here. Conformance criteria and considerations regarding error handling are <del> defined in Semantics-conformance. </del>  1.2.

Reviewer comments:
... components, depending on the form of request-target, and when authority might be empty. This is an alternative to
In determining the request target, the following text is included after failing to find an authority in configuration, the authority form target, or the Host header: This is a security risk because it means that servers might not agree with clients about the identity of the resource that the request is directed to. This is especially bad as a TLS certificate is good for every port and often good for multiple names, which can mean a fairly large scope over which an attacker can exploit this confusion. The origin form description doesn't use 2119 language, it says "A Host header field is also sent", citing . And that section is a bit weaselly in that regard, using a "URL". If this were a "MUST ... unless" in -semantics, this problem would not exist (at least in theory). Just to confuse things, the absolute-form says , which might be read to imply that Host truly is mandatory: The asterisk-form is the only other option that naturally lacks an authority, and that says nothing, so that might be fixed up similarly.
Keep in mind that the first text is what to do when receiving a message without Host or absolute-form, whereas the other texts are requirements on generation. Yes, it is a security risk to not send Host, and I assume it would be one to provide service for an https resource without verifying that the client's request indicates one of the server's host (somehow). So, PR welcome, but the final text still needs to accept non-TLS HTTP/1.0 requests without a Host (for ass-backwards reasons).
BTW, the reason it says SHOULD here instead of MUST is because this requirement about the ordering of fields in the header section, not about whether or not Host needs to be sent.
OK, that's good. It's not a genuine problem, we just need to be clearer about generation requirements (and we might be able to carefully condition the inclusion of a default).
better again

Revised text:
as shown here. Conformance criteria and considerations regarding error handling are  <ins> defined in Semantics. </ins> 1.2.
Original text:
robustness (see request.smuggling). HTTP does not place a predefined limit on the length of a request- <del> line, as described in Semantics-conformance.  A server that receives a method longer than any that it implements SHOULD respond with a </del>  status code.  A server that receives a request-target longer than any URI it wishes to parse MUST respond with a

Reviewer comments:
... components, depending on the form of request-target, and when authority might be empty. This is an alternative to
In determining the request target, the following text is included after failing to find an authority in configuration, the authority form target, or the Host header: This is a security risk because it means that servers might not agree with clients about the identity of the resource that the request is directed to. This is especially bad as a TLS certificate is good for every port and often good for multiple names, which can mean a fairly large scope over which an attacker can exploit this confusion. The origin form description doesn't use 2119 language, it says "A Host header field is also sent", citing . And that section is a bit weaselly in that regard, using a "URL". If this were a "MUST ... unless" in -semantics, this problem would not exist (at least in theory). Just to confuse things, the absolute-form says , which might be read to imply that Host truly is mandatory: The asterisk-form is the only other option that naturally lacks an authority, and that says nothing, so that might be fixed up similarly.
Keep in mind that the first text is what to do when receiving a message without Host or absolute-form, whereas the other texts are requirements on generation. Yes, it is a security risk to not send Host, and I assume it would be one to provide service for an https resource without verifying that the client's request indicates one of the server's host (somehow). So, PR welcome, but the final text still needs to accept non-TLS HTTP/1.0 requests without a Host (for ass-backwards reasons).
BTW, the reason it says SHOULD here instead of MUST is because this requirement about the ordering of fields in the header section, not about whether or not Host needs to be sent.
OK, that's good. It's not a genuine problem, we just need to be clearer about generation requirements (and we might be able to carefully condition the inclusion of a default).
better again

Revised text:
robustness (see request.smuggling). HTTP does not place a predefined limit on the length of a request-  <ins> line, as described in Semantics.  A server that receives a method longer than any that it implements SHOULD respond with a </ins> status code.  A server that receives a request-target longer than any URI it wishes to parse MUST respond with a
Original text:
The <del> of request-target is only used for CONNECT requests (CONNECT). </del>  When making a CONNECT request to establish a tunnel through one or <del> more proxies, a client MUST send only the target URI's authority component (excluding any userinfo and its "@" delimiter) as the request-target.  For example, </del>  3.2.4.

Reviewer comments:
... components, depending on the form of request-target, and when authority might be empty. This is an alternative to
In determining the request target, the following text is included after failing to find an authority in configuration, the authority form target, or the Host header: This is a security risk because it means that servers might not agree with clients about the identity of the resource that the request is directed to. This is especially bad as a TLS certificate is good for every port and often good for multiple names, which can mean a fairly large scope over which an attacker can exploit this confusion. The origin form description doesn't use 2119 language, it says "A Host header field is also sent", citing . And that section is a bit weaselly in that regard, using a "URL". If this were a "MUST ... unless" in -semantics, this problem would not exist (at least in theory). Just to confuse things, the absolute-form says , which might be read to imply that Host truly is mandatory: The asterisk-form is the only other option that naturally lacks an authority, and that says nothing, so that might be fixed up similarly.
Keep in mind that the first text is what to do when receiving a message without Host or absolute-form, whereas the other texts are requirements on generation. Yes, it is a security risk to not send Host, and I assume it would be one to provide service for an https resource without verifying that the client's request indicates one of the server's host (somehow). So, PR welcome, but the final text still needs to accept non-TLS HTTP/1.0 requests without a Host (for ass-backwards reasons).
BTW, the reason it says SHOULD here instead of MUST is because this requirement about the ordering of fields in the header section, not about whether or not Host needs to be sent.
OK, that's good. It's not a genuine problem, we just need to be clearer about generation requirements (and we might be able to carefully condition the inclusion of a default).
better again

Revised text:
The  <ins> of request-target is only used for CONNECT requests (CONNECT).  It consists of only the and number of the tunnel destination, separated by a colon (":"). </ins> When making a CONNECT request to establish a tunnel through one or  <ins> more proxies, a client MUST send only the host and port of the tunnel destination as the request-target.  The client obtains the host and port from the target URI's component, except that the scheme's default port is sent if the target URI elides the port.  For example, a CONNECT request to "http://www.example.com" looks like </ins> 3.2.4.