Hi, if I am not mistaken there are some errors in your list of valid URI References. > => gemini://example.net/path/foo.gemini Absolute URL - fully > specified > => //example.net/path/foo.gemini??????? relative URL - no scheme > => /path/foo.gemini???????????????????? relative URL - no host > => foo.gemini?????????????????????????? relative URL - no path > => ../path/foo.gemini?????????????????? relative URL - relative First of, these are not URLs, RFC 3986 specifies URIs and URI References. As we are speaking about links, we need to speak about URI References rather then URLs or URIs. Note that this does not apply to requests, there we speak about URIs. So instead, this would be the terminology I would use: => gemini://example.net/path/foo.gemini URI Reference => //example.net/path/foo.gemini relative URI reference - no scheme, absolute path => /path/foo.gemini relative URI Reference - no host, absolute path => foo.gemini relative URI Reference - no host, relative path (Note that this is not a reference without a specified path, for that, it would have to begin with //.) => ../path/foo.gemini relative URI Reference - no host, relative path The following examples would also be valid: => gemini://example.net URI Reference - empty path => //example.net relative URI Reference - no scheme, empty path => / relative URI Reference - no host, absolute path Looking at the ABNF in Appendix A of RFC 3986, this gets pretty clear. IMO the current solution is pretty good, requiring a URI for requests and a URI Reference for links, this is as it should be. If I read the spec change email correctly, now text/gemini documents also require full URIs in the links, I don't think of this as a good idea
---
Previous in thread (17 of 27): 🗣️ John Cowan (cowan (a) ccil.org)
Next in thread (19 of 27): 🗣️ A. E. Spencer-Reed (easrng (a) gmail.com)