Original text:
For example, the following three URIs are equivalent:  3. 3.1.

Reviewer comments:
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.

Revised text:
For example, the following three URIs are equivalent: <ins> 2.5.4. The origin for a given URI is the triple of scheme, host, and port after normalizing the scheme and host to lowercase and normalizing the port to remove any leading zeros.  If port is elided from the URI, the default port for that scheme is used.  For example, the URI would have the origin which can also be described as the normalized URI prefix with port always present: The notion of an origin for any given URI is central to the semantics of HTTP.  Each origin defines its own namespace and controls how identifiers within that namespace are mapped to resources.  In turn, how the origin responds to valid requests, consistently over time, determines the semantics that users will associate with a URI, and the usefulness of those semantics is what ultimately transforms these mechanisms into a "resource" for users to reference and access in the future. The general term "authority" is also used as an abstract reference to whatever entity controls a given resource.  A single authority might control only parts of an origin, an entire origin, or many different origins. Two origins are distinct if they differ in scheme, host, or port. Even when it can be verified that the same authority controls two origins that might differ only by scheme name, the two namespaces under those origins are distinct unless explicitly aliased by that authority. Note that the presence of a URI does not imply that there is always an HTTP server at the identified origin listening for connections on the identified host and port.  Anyone can mint a URI.  What the origin 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 whether or not an HTTP server is present. Although HTTP is independent of the transport protocol, the "http" scheme is specific to associating authority with whomever controls the origin server listening for TCP connections on the indicated port of whatever host is identified within the authority component.  This is a very weak sense of authority because it depends on both client- specific name resolution mechanisms and communication that might not be secured from man-in-the-middle attacks.  Nevertheless, it is a sufficient minimum for binding "http" identifiers to an origin server for consistent resolution within a trusted environment. 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 an appropriate origin server. Access to "http" services is not limited to the authority mechanism. For example, the Alt-Svc header field RFC7838 allows an origin server to explicitly alias its own namespace to an alternative service at a different origin.  Access to "http" identified resources might also be provided by other protocols outside the scope of this document. The "https" scheme, in contrast, associates authority based on the ability of a server to use the private key associated with a certificate that the client considers to be trustworthy for the identified host.  If a server presents a certificate that verifiably applies to the host, along with proof that it controls the private key, then a client will accept a secured connection to that server as being authoritative for all origins with the same host.  However, each origin remains distinct (from origins with a different scheme or port) unless explicitly aliased by an origin server verified to be under the same authority. What the client is relying on for "https" authority is that there exists some chain of trust (possibly configured by exception) that verifies the certificate provided.  Hence, the authority is defined only by the host, the port impacts which certificate is chosen (assuming that certificate matches the host identifier), and the client trusts that match according to the secure handshake and certificate validation described in https.initiation. Note that the "https" scheme does not rely on TCP and the port number for establishing authority, even though it provides for use of HTTP over TLS over TCP via that port as the default mechanism for obtaining a certificate that can be used for verifying authority and providing access to the origin's resources.  The peers establishing a secure connection cannot trust transport parameters outside the secured channel, but the port number remains useful (beyond the default mechanism) as an identifier to distinguish different origin namespaces on the same host.  The port identifier is therefore applicable even when the protocols being used for access do not include TCP. In HTTP/1.1 and earlier, the only URIs for which the client will assign authority are those that contain a TLS server_name extension matching the origin's host. In HTTP/2, the client will assign authority to all names that are present in the certificate.  However, a client will only do that if it concludes that it could open a connection to the origin for that URL.  In practice, a client will make a DNS query and see that it contains the same server IP address.  A server sending the ORIGIN frame removes this restriction RFC8336. In addition to the client's verification, the origin server is responsible for verifying that that requests it receives over a connection correspond to resources for which it actually wants to be the origin.  If a network attacker causes connections for port N to be received at port Q, checking the Host header field is necessary to ensure that the attacker can't cause "https://example.com:N/foo" to be replaced by "https://example.com:Q/foo" without consent. Likewise, a server might be unwilling to serve as the origin for some hosts even when they have the authority to do so. Resources made available via the "https" scheme have no shared identity with the "http" scheme.  They are distinct origins with separate namespaces.  However, an extension to HTTP that is defined to apply to all origins with the same host, 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. See establishing.authority for security considerations related to establishing authority. 2.5.5. 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. 2.5.6. 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). </ins> 3. 3.1.