Code change:
and with the hope of being useful for quicwg/base-drafts I suspect that we also need to move "Initiating HTTP over TLS" down to the section on Routing, but that can be done separately.
This is now ready to merge, IMO. There is more work to do after merging, specifically taking the old RFC2818 description of initiating HTTP over TLS out and moving just the 1.1-specific bits to Messaging, but I don't want to do that in the same PR.
I agree with Roy. This is big enough that merging and iterating is the right path.
From :
Looks good enough to merge and iterate upon. Will need change notes, of course.

Related discussion:
text: 5.3. <ins> Conceptually, HTTP/TLS is very simple.  Simply use HTTP over TLS precisely as you would use HTTP over TCP. The agent acting as the HTTP client should also act as the TLS client.  It should initiate a connection to the server on the appropriate port and then send the TLS ClientHello to begin the TLS handshake.  When the TLS handshake has finished.  The client may then initiate the first HTTP request.  All HTTP data MUST be sent as TLS "application data".  Normal HTTP behavior, including retained connections should be followed. 5.3.1. In general, HTTP/TLS requests are generated by dereferencing a URI. As a consequence, the hostname for the server is known to the client. If the hostname is available, the client MUST check it against the server's identity as presented in the server's Certificate message, in order to prevent man-in-the-middle attacks. If the client has external information as to the expected identity of the server, the hostname check MAY be omitted.  (For instance, a client may be connecting to a machine whose address and hostname are dynamic but the client knows the certificate that the server will present.)  In such cases, it is important to narrow the scope of acceptable certificates as much as possible in order to prevent man in the middle attacks.  In special cases, it may be appropriate for the client to simply ignore the server's identity, but it must be understood that this leaves the connection open to active attack. If a subjectAltName extension of type dNSName is present, that MUST be used as the identity.  Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used.  Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead. Matching is performed using the matching rules specified by RFC5280. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.)  Names may contain the wildcard character * which is considered to match any single domain name component or component fragment.  E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com. In some cases, the URI is specified as an IP address rather than a hostname.  In this case, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP in the URI. If the hostname does not match the identity in the certificate, user oriented clients MUST either notify the user (clients MAY give the user the opportunity to continue with the connection in any case) or terminate the connection with a bad certificate error.  Automated clients MUST log the error to an appropriate audit log (if available) and SHOULD terminate the connection (with a bad certificate error). Automated clients MAY provide a configuration setting that disables this check, but MUST provide a setting which enables it. Note that in many cases the URI itself comes from an untrusted source.  The above-described check provides no protection against attacks where this source is compromised.  For example, if the URI was obtained by clicking on an HTML page which was itself obtained without using HTTP/TLS, a man in the middle could have replaced the URI.  In order to prevent this form of attack, users should carefully examine the certificate presented by the server to determine if it meets their expectations. 5.3.2. Typically, the server has no external knowledge of what the client's identity ought to be and so checks (other than that the client has a certificate chain rooted in an appropriate CA) are not possible.  If a server has such knowledge (typically from some source external to HTTP or TLS) it SHOULD check the identity as described above. 5.4. </ins> Once an inbound connection is obtained, the client sends an HTTP request message (http.message).