Code change:
act in parallel and perhaps at cross-purposes, we cannot require that such changes be observable beyond the scope of a single response. <del> Each HTTP message is either a request or a response.  A server listens on a connection for a request, parses each message received, interprets the message semantics in relation to the identified target resource, and responds to that request with one or more response messages.  A client constructs request messages to communicate specific intentions, examines received responses to see if the intentions were carried out, and determines how to interpret the results. </del> <ins> 1.2. HTTP has been the primary information transfer protocol for the World Wide Web since its introduction in 1990.  It began as a trivial mechanism for low-latency requests, with a single method (GET) to request transfer of a presumed hypertext document identified by a given pathname (HTTP/0.9).  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 being defined as HTTP/1.0 RFC1945. HTTP/1.1 was designed to refine the protocol's features while retaining compatibility with the existing text-based messaging syntax, improving its interoperability, scalability, and robustness across the Internet.  This included length-based payload delimiters for both fixed and dynamic (chunked) content, a consistent framework for content negotiation, opaque validators for conditional requests, cache controls for better cache consistency, range requests for partial updates, and default persistent connections.  HTTP/1.1 was introduced in 1995 and published on the standards track in 1997 RFC2068, 1999 RFC2616, and 2014 (RFC7230 - RFC7235). HTTP/2 (RFC7540) introduced a multiplexed session layer on top of the existing TLS and TCP protocols for exchanging concurrent HTTP messages with efficient header field compression and server push. HTTP/3 (HTTP3) has gone even further, guiding the development of QUIC as a secure multiplexing transport over UDP. All three major versions of HTTP rely on the semantics defined by this document.  They have not obsoleted each other because each one has specific benefits and limitations depending on the context of use.  Implementations are expected to choose the most appropriate transport and messaging syntax for their particular context. This revision of HTTP separates the definition of semantics (this document) and caching (Caching) from the current HTTP/1.1 messaging syntax (Messaging) to allow each major protocol version to progress independently while referring to the same core semantics. 1.3. </ins> HTTP provides a uniform interface for interacting with a resource <del> (resources), regardless of its type, nature, or implementation, via the manipulation and transfer of representations (representations). This document defines semantics that are common to all versions of HTTP.  HTTP semantics include the intentions defined by each request method (methods), extensions to those semantics that might be described in request header fields (request.header.fields), the meaning of status codes to indicate a machine-readable response (status.codes), and the meaning of other control data and resource metadata that might be given in response header fields </del> <ins> (resources), regardless of its type, nature, or implementation, by sending messages that manipulate or transfer representations (representations). Each message is either a request or a response.  A client constructs request messages that communicate its intentions and routes those messages toward an identified origin server.  A server listens for requests, parses each message received, interprets the message semantics in relation to the identified target resource, and responds to that request with one or more response messages.  The client examines received responses to see if its intentions were carried out, determining what to do next based on the received status and payloads. HTTP semantics include the intentions defined by each request method (methods), extensions to those semantics that might be described in request header fields (request.header.fields), status codes that describe the response (status.codes), and other control data and resource metadata that might be given in response fields </ins> (response.header.fields). <del> This document also defines representation metadata that describe how a payload is intended to be interpreted by a recipient, the request header fields that might influence content selection, and the various </del> <ins> Semantics also include representation metadata that describe how a payload is intended to be interpreted by a recipient, request header fields that might influence content selection, and the various </ins> selection algorithms that are collectively referred to as " " (content.negotiation). <del> This document defines HTTP range requests, partial responses, and the multipart/byteranges media type. </del> <ins> 1.4. </ins> <del> This document obsoletes the portions of RFC7230 that are independent of the HTTP/1.1 messaging syntax and connection management, with the changes being summarized in changes.from.rfc.7230.  The other parts of RFC7230 are obsoleted by "HTTP/1.1 Messaging" Messaging.  This document also obsoletes RFC2818 (see changes.from.rfc.2818), RFC7231 (see changes.from.rfc.7231), RFC7232 (see changes.from.rfc.7232), RFC7233 (see changes.from.rfc.7233), RFC7233 (see changes.from.rfc.7235), RFC7233 (see changes.from.rfc.7538), RFC7615 (see changes.from.rfc.7615), and RFC7615 (see changes.from.rfc.7694). </del> <ins> This document obsoletes the following specifications: </ins> <del> 1.1. </del> <ins> [*] This document only obsoletes the portions of RFC7230 that are independent of the HTTP/1.1 messaging syntax and connection management; the remaining bits of RFC7230 are obsoleted by "HTTP/1.1 Messaging" Messaging. 1.5. </ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and

Related discussion:
text: I got distracted by old text and revised the introduction of semantics.
The introduction should reference the currently defined wire formats (1.1 and 2, also 1.0 maybe). We also need to figure out whether and where to mention differences: expect/continue transfer codings status phrase
Also, the current introduction to all three documents says: That needs to be adjusted to something like:
HTTP/1.2? Is there something you need to share with the working group, NAME
I think (but am not sure) that this has been covered by the changes made in Maybe NAME and NAME could have a look and see if the short HTTP/2 and HTTP/3 descriptions need more flowers.
I think that the number of flowers (->0) is entirely appropriate and I would be happy with those descriptions, with maybe a small tweak to the HTTP/3 text.
I left a review; once we resolve comments on the PR, I think this can be closed.
Some nits, but I like the direction generally.Awesome!