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

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

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

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

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

Related discussion:
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> <ins> semantics, and trailer fields provide optional metadata that was unknown prior to sending the content. </ins> Messages are intended to be
Code change:
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.

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

Related discussion:
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> <ins> Fields (fields) that are located within a </ins> <del> .  Trailer fields can be useful for supplying message integrity checks, digital signatures, delivery metrics, or post-processing status information. </del> <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
Code change:
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.

Related discussion:
text: 6.5.1. <del> Trailer sections are only possible when supported by the version of </del> <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).
Code change:
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 ).

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

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

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

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

Related discussion:
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> <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> <del> response to a GET request). </del> <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
Code change:
… 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

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

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

Related discussion:
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> <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),