Code change:
4.2.3. <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 each scheme. If the port is equal to the default port for a scheme, the normal form is to omit the port subcomponent.  When not being used as the target of an OPTIONS request, an empty path component is equivalent to an absolute path of "/", so the normal form is to provide a path of "/" instead.  The scheme and host are case-insensitive and normally provided in lowercase; all other components are compared in a case-sensitive manner.  Characters other than those in the "reserved" set are equivalent to their percent-encoded octets: the normal form is to not encode them (see Sections RFC3986 and RFC3986 of RFC3986). </del> <ins> The "http" and "https" URI are normalized and compared according to the methods defined in RFC3986, using the defaults described above for each scheme. HTTP does not require use of a specific method for determining equivalence.  For example, a cache key might be compared as a simple string, after syntax-based normalization, or after scheme-based normalization. Two HTTP URIs that are equivalent after normalization (using any method) can be assumed to identify the same resource, and any HTTP component MAY perform normalization.  As a result, distinct resources SHOULD NOT be identified by HTTP URIs that are equivalent after normalization (using any method defined in RFC3986). Scheme-based normalization (RFC3986) of "http" and "https" URIs involves the following additional rules: </ins> For example, the following three URIs are equivalent:

Related discussion:
text: That's clearly not going to happen, especially given how many different places URIs occur (request target, , , , etc.). OTOH there are some security implications if policy is applied before normalisation. Caches are less efficient as well (not an interop problem, just an efficiency one). Roy, you say 'The request target is whatever is provided by the client.' Do you mean the bytes on the wire (if so, what about h2/h3)? or do you mean after some amount of processing? I think we're just talking about the level of processing that's necessary before the protocol element is consumed (but not necessarily forwarded).
Is there a notion of a server which isn't an intermediary for a given request? If so, how about requiring it only of them? If not, can creators and administrators of resources (people minting URIs for them, either by hand or directing some tool to do it, possibly dynamically) be distinguished as an audience subject to its own set of requirements and have them MUST conform? The advantage of this approach would lie in abstracting from authorities, origins, websites, servers and intermediaries – just the assumptions about the semantics embodied in returned representations and metadata (responses in the case of HTTP) would count as the measure by which to judge conformance. (And they could achieve it with a single server, a server cluster, a CDN, proxies, including non-transparent ones, or whatever else.)
See PR.
Thank you, LGTM mostly. It still does allow minting URIs for different resources which are equal after normalization. It's a SHOULD NOT. I assume that the reluctance to go with MUST NOT results from the concerns raised above, but still it's such a corner case that support for it should IMO be trumped by clarity of semantics and ease of use and implementation. Though users and implementors are, by a MAY, explicitly allowed to conflate such URIs, making some resources unavailable via URI from their perspective, so it's a very strong SHOULD NOT and groups of people wishing to violate it for a good cause (whatever that may be, can you give a use case?) have to ensure there's nothing in either their systems or any intermediaries that would thwart their endeavour by performing normalization (which is always legal per the proposed spec).