Code change:
2.5.1. <del> The "http" URI scheme is hereby defined for the purpose of minting identifiers according to their association with the hierarchical namespace governed by a potential HTTP origin server listening for TCP (RFC0793) connections on a given port. </del> <ins> The "http" URI scheme is hereby defined for minting identifiers within the hierarchical namespace governed by a potential HTTP origin server listening for TCP (RFC0793) connections on a given port. </ins> The origin server for an "http" URI is identified by the <del> component, which includes a host identifier and optional TCP port (RFC3986).  The hierarchical path component and optional query component serve as an identifier for a potential target resource within that origin server's name space. </del> <ins> component, which includes a host identifier and optional port number (RFC3986).  If the port subcomponent is empty or not given, TCP port 80 (the reserved port for WWW services) is the default. The hierarchical path component and optional query component identify the target resource within that origin server's name space. </ins> A sender MUST NOT generate an "http" URI with an empty host identifier.  A recipient that processes such a URI reference MUST reject it as invalid. <del> If the host identifier is provided as an IP address, the origin server is the listener (if any) on the indicated TCP port at that IP address.  If host is a registered name, the registered name is an indirect identifier for use with a name resolution service, such as DNS, to find an address for that origin server.  If the port subcomponent is empty or not given, TCP port 80 (the reserved port for WWW services) is the default. Note that the presence of a URI with a given authority component does not imply that there is always an HTTP server listening for connections on that host and port.  Anyone can mint a URI.  What the authority component determines is who has the right to respond authoritatively to requests that target the identified resource.  The delegated nature of registered names and IP addresses creates a federated namespace, based on control over the indicated host and port, whether or not an HTTP server is present.  See establishing.authority for security considerations related to establishing authority. </del> When an "http" URI is used within a context that calls for access to the indicated resource, a client MAY attempt access by resolving the <del> host to an IP address, establishing a TCP connection to that address on the indicated port, and sending an HTTP request message (http.message) containing the URI's identifying data to the server. If the server responds to that request with a non-interim HTTP </del> <ins> host identifier to an IP address, establishing a TCP connection to that address on the indicated port, and sending an HTTP request message to the server containing the URI's identifying data (http.message). If the server responds to such a request with a non-interim HTTP </ins> response message, as described in status.codes, then that response is considered an authoritative answer to the client's request. <del> Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name delegation process depends on TCP for establishing authority.  An HTTP service based on some other underlying connection protocol would presumably be identified using a different URI scheme, just as the "https" scheme (below) is used for resources that require an end-to-end secured connection.  Other protocols might also be used to provide access to "http" identified resources -- it is only the authoritative interface that is specific to TCP. The URI generic syntax for authority also includes a deprecated userinfo subcomponent (RFC3986) for including user authentication information in the URI.  Some implementations make use of the userinfo component for internal configuration of authentication information, such as within command invocation options, configuration files, or bookmark lists, even though such usage might expose a user identifier or password.  A sender MUST NOT generate the userinfo subcomponent (and its "@" delimiter) when an "http" URI reference is generated within a message as a request target or header field value. Before making use of an "http" URI reference received from an untrusted source, a recipient SHOULD parse for userinfo and treat its presence as an error; it is likely being used to obscure the authority for the sake of phishing attacks. </del> <ins> Note, however, that the above is not the only means for obtaining an authoritative response, nor does it imply that an authoritative response is always necessary (see Caching).  The "http" scheme merely uses this relationship as its reference point for establishing and verifying authority, as defined in http.origin. </ins> 2.5.2. <del> The "https" URI scheme is hereby defined for the purpose of minting identifiers according to their association with the hierarchical namespace governed by a potential HTTP origin server listening to a given TCP port for TLS-secured connections (RFC8446). All of the requirements listed above for the "http" scheme are also requirements for the "https" scheme, except that TCP port 443 is the default if the port subcomponent is empty or not given, and the user agent MUST ensure that its connection to the origin server is secured through the use of strong encryption, end-to-end, prior to sending the first HTTP request. Note that the "https" URI scheme depends on both TLS and TCP for establishing authority.  Resources made available via the "https" scheme have no shared identity with the "http" scheme even if their resource identifiers indicate the same authority (the same host listening to the same TCP port).  They are distinct namespaces and are considered to be distinct origin servers.  However, an extension to HTTP that is defined to apply to entire host domains, such as the Cookie protocol RFC6265, can allow information set by one service to impact communication with other services within a matching group of host domains. 2.5.2.1. Conceptually, HTTP/TLS is very simple.  Simply use HTTP over TLS precisely as you would use HTTP over TCP. </del> <ins> The "https" URI scheme is hereby defined for minting identifiers within the hierarchical namespace governed by a potential origin server listening for TCP connections on a given port and capable of establishing a TLS (RFC8446) connection on behalf of the identified authority that has been secured for HTTP communication.  By "secured" in this section, we specifically mean that the server has been authenticated as as acting on behalf of the identified authority and all HTTP communication is encrypted for confidentiality and integrity protection. </ins> <del> 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. 2.5.2.2. 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. </del> <ins> The origin server for an "https" URI is identified by the </ins> <del> 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. </del> <ins> component, which includes a host identifier and optional port number (RFC3986).  If the port subcomponent is empty or not given, TCP port 443 (the reserved port for HTTP over TLS) is the default. </ins> <del> 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. </del> <ins> The hierarchical path component and optional query component identify the target resource within that origin server's name space. </ins> <del> 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. </del> <ins> A sender MUST NOT generate an "https" URI with an empty host identifier.  A recipient that processes such a URI reference MUST reject it as invalid. </ins> <del> 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. </del> <ins> A client MUST ensure that its HTTP requests for an "https" resource are secured, prior to being communicated, and that it only accepts secured responses to those requests. </ins> <del> 2.5.2.3. </del> <ins> When an "https" URI is used within a context that calls for access to the indicated resource, a client MAY attempt access by resolving the host identifier to an IP address, establishing a TCP connection to that address on the indicated port, securing the connection end-to- end by successfully initiating TLS over TCP with confidentiality and integrity protection, and sending an HTTP request message to the server over that secured connection containing the URI's identifying data (http.message). If the server responds to such a request with a non-interim HTTP response message, as described in status.codes, then that response is considered an authoritative answer to the client's request. </ins> <del> 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. </del> <ins> Note, however, that the above is not the only means for obtaining an authoritative response, nor does it imply that an authoritative response is always necessary (see Caching).  The "https" scheme merely uses this relationship as its reference point for establishing and verifying authority, as defined in http.origin. </ins> 2.5.3. <del> Fragment identifiers allow for indirect identification of a secondary resource, independent of the URI scheme, as defined in RFC3986.  Some protocol elements that refer to a URI allow inclusion of a fragment, while others do not.  They are distinguished by use of the ABNF rule for elements where fragment is allowed; otherwise, a specific rule that excludes fragments is used (see target.resource). 2.5.4. </del> Since the "http" and "https" schemes conform to the URI generic syntax, such URIs are normalized and compared according to the algorithm defined in RFC3986, using the defaults described above for

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