jiebi/CodeConvo huggingface dataset:
Code change:
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?

Related discussion:
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> <ins> syntax and parsing.  Security considerations about HTTP semantics, payloads, and routing are addressed in Semantics. </ins> 11.1.
Code change:
and only define the versioning there; leave message version requirements in control data. (no content changes)

Related discussion:
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
Code change:
and only define the versioning there; leave message version requirements in control data. (no content changes)

Related discussion:
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
Code change:
and only define the versioning there; leave message version requirements in control data. (no content changes)

Related discussion:
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
Code change:
and only define the versioning there; leave message version requirements in control data. (no content changes)

Related discussion:
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,
Code change:
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.

Related discussion:
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> <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.
Code change:
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.

Related discussion:
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> <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.
Code change:
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.

Related discussion:
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> <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 <del> (status.line), and corresponds to when a payload body is allowed; see payload.body. </del> <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 <del> will be) applied to the payload body in order to form the message </del> <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
Code change:
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.

Related discussion:
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> <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 <del> coding other than chunked is applied to a request payload body, the </del> <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 <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> <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, <del> indicates that the payload body has been compressed using the gzip </del> <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.
Code change:
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.

Related discussion:
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> <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 <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> <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.
Code change:
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.

Related discussion:
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> <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
Code change:
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.

Related discussion:
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> <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.
Code change:
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.

Related discussion:
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> <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.
Code change:
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.

Related discussion:
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> <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.
Code change:
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!

Related discussion:
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> <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
Code change:
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!

Related discussion:
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> <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
Code change:
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!

Related discussion:
text: The "Host" header field in a request provides the host and port information from the target URI, enabling the origin server to distinguish among resources while servicing requests for multiple <del> host names on a single IP address. </del> <ins> host names. </ins> <del> Since the Host field value is critical information for handling a request, a user agent SHOULD generate Host as the first field in the header section. </del> <ins> In HTTP/2 RFC7540 and HTTP/3 HTTP3, the Host header field is, in some cases, supplanted by the ":authority" pseudo-header field of a request's control data. The target URI's authority information is critical for handling a request.  A user agent SHOULD generate Host as the first field in the header section of a request unless it has already generated that information as an ":authority" pseudo-header field. </ins> For example, a GET request to the origin server for <http://www.example.org/pub/WWW/> would begin with: <del> Since the Host header field acts as an application-level routing mechanism, it is a frequent target for malware seeking to poison a shared cache or redirect a request to an unintended server.  An interception proxy is particularly vulnerable if it relies on the Host field value for redirecting requests to internal servers, or for use as a cache key in a shared cache, without first verifying that the intercepted connection is targeting a valid IP address for that host. </del> <ins> Since the host and port information acts as an application-level routing mechanism, it is a frequent target for malware seeking to poison a shared cache or redirect a request to an unintended server. An interception proxy is particularly vulnerable if it relies on the host and port information for redirecting requests to internal servers, or for use as a cache key in a shared cache, without first verifying that the intercepted connection is targeting a valid IP address for that host. </ins> 7.1.3.