Better define HTTP compliance

We define:

WebDriver remote ends must provide an HTTP compliant wire protocol where the endpoints map to different commands.

Where:

To be HTTP compliant, it is supposed that the implementation supports the relevant subsets of [RFC7230], [RFC7231], [RFC7232], [RFC7234], and [RFC7235].

It is not immediately apparent what the relevant subset is.

Our definition of the Processing model includes:

The remote end is an HTTP server reading requests from the client and writing responses, typically over a TCP socket. For the purposes of this specification we model the data transmission between a particular local end and remote end with a connection to which the remote end may write bytes and read bytes. However the exact details of how this connection works and how it is established are out of scope.

And:

Read bytes from the connection until a complete HTTP request can be constructed from the data. Let request be a request constructed from the received data, according to the requirements of [RFC7230]. If it is not possible to construct a complete HTTP request, the remote end must either close the connection, return an HTTP response with status code 500, or return an error with error code unknown error.

This presumably therefore implies that the wire protocol is always HTTP/1.1 (and thus WebDriver Classic over H2 or H3 would be non-compliant, even though we otherwise only deal with HTTP messages and there is nothing per-se preventing such an implementation); we're just agnostic about the underlying transport layer protocols, similar to HTTP/1.1 itself.

Start with the WebDriver definitions of “HTTP compliant” and the Processing model, then review the referenced RFC7230–RFC7235 requirements. Determine which HTTP versions and protocol requirements the specification intends to cover, including whether HTTP/2 and HTTP/3 are compliant. Done means the relevant subset and transport-version expectations are stated unambiguously.