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: a sample of links resulting from my research of the subject: URL URL URL URL URL URL URL URL
As for the percent-encoding, section 6 of RFC 3986 seems to have the answer that servers aren't allowed to interpret URIs differing only in them as identifying different resources. However, I have 3 more remarks: I wish the MUST requirement were stated explicitly to avoid confusion among implementors, content authors, server administrators and other audiences. The following excerpt seems to erroneously (because absolute examples are present in the following section) limit the whole chapter 6. to relative URI references, thus excluding e.g. the of s (RFC 7230, section 5.3.2.):The difference, introduced in RFC 3986, between URIs (which are always absolute and don't undergo resolution) and URI references (which may be absolute or relative and chapter 5. defines how to resolve them to obtain a URI) is subtle. Extra care to pick the right one each time should be exercised when using the terms. Particularly with normalization. Currently it's not easy to find and definitively interpret text in the standards clarifying whether both are normalized, when, and how normalization rules for them differ.
URL is useful to the extent it provides a way to talk about this. Would it be sane to say that servers MUST do the things described in 6.2.2 of that document? When I'm a client implementor I would be shocked, and my caching software might well break, in dealing with a server that didn't. Section 6.2.3? I think so probably, but it's not nearly as clear and concise as 6.2.2.
NAME I concur, make the language of 6.2.2 and 6.2.3 more precise and with uppercase MUSTs instead of present shoulds. On the other hand, 6.2.4 is bogus in this context, may be moved somewhere and rephrased to be clearly just informative advice. A trailing slash does make a URI semantically different, at least with the and schemes, unless it's immediately preceded by an authority.
Saying servers MUST do anything has the effect of requiring intermediaries to modify URIs on the way through.