Expand normalize to handle special delimiters in path segment and (possibly) handle normalization of dot segments

From the naming I gathered that the intended use case for normalize was that uris that are semantically equivalent should get a canonical form. Some examples where this is currently not the case:

(require '[lambdaisland.uri.normalize :as norm]
         '[lambdaisland.uri :as uri])

Path segments:

(norm/normalize (uri/uri "https://foobar.org/foo/../bar"))
(norm/normalize (uri/uri "https://foobar.org/foo/./bar"))

Scheme based normalization (the following are urls are equivalent)

      http://example.com
      http://example.com/
      http://example.com:/
      http://example.com:80/

See here.

Is this sort of out of scope for this library? Should this be added?

Also, from my understanding of rfc3986, but this might be wrong, if I want to use a reserved character as part of the data I need to percent-encode it. For example, let's say I want to use / in my data, the request for an endpoint of /api/{data} could look for example something like "http://foobar.com/api/some%2Fdata". normalize would then confound the following two uris.

(norm/normalize (uri/uri "http://foobar.com/api/some%2Fdata"))
(norm/normalize (uri/uri "http://foobar.com/api/some/data"))

So my question is, shouldn't only unreserved characters be decoded as part of the normalization?

Start by reading the normalize namespace and comparing its behavior with RFC 3986 section 6.2.2.3. Resolve the expected handling of dot segments, default ports and trailing slashes, and encoded reserved characters; done means the library's normalization rules are explicitly decided and covered for the examples in the issue.