Scheme Section 2 quibble

On Tue, Nov 17, 2020 at 6:07 PM Alex // nytpu <alex at nytpu.com> wrote:


> Let's say I want to start hosting the git repo for my utility
> gemlog.sh[a] on gemini. I make a directory on my site, so the full url
> would be `gemini://nytpu.com/gemlog.sh/` <http://nytpu.com/gemlog.sh/>.
> Now, say I put a link in my
> root index.gmi (`/`) linking to `gemlog.sh`[b]. This is a perfectly
> valid link to a directory on my server, but this would instead be
> interpreted as the url `gemini://gemlog.sh/` <http://gemlog.sh/> if you
> use the faulty
> method of parsing. (`.sh` is a valid TLD[c] so it wouldn't work even if
> you have a whitelist of tlds).
>

In any case, nothing says a hostname has to be absolute.  If your hostname
is "client.example.com" then you can refer to "server.example.com" as
simply "server".  The only way to tell if "server" is a meaningful host is
to ask the DNS, and the answer can change.

> 4) Follow the carefully and clearly defined specification[d] that is
> over 15 years old and is well-adopted by existing uri parsing libraries.
> Requires minimal, non-breaking spec changes, purely for clarity.
>

Requires a small breaking spec change to remove the sentence about
defaulting to "gemini://" in 5.4.2 and preferably in 2 as well.  But 5.4.2
is self-contradictory and has to be fixed.

My proposal is to rewrite section 2 to say this:

<URL> is an absolute URL according to RFC 3986, of maximum length 1024
bytes.

And to rewrite section 5.4.2 to say this:

<URL> is a URI reference according to RFC 3986.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201117/8bc7
4bd0/attachment.htm>

---

Previous in thread (16 of 31): 🗣️ Philip Linde (linde.philip (a) gmail.com)

Next in thread (18 of 31): 🗣️ Philip Linde (linde.philip (a) gmail.com)

View entire thread.