Unicode vs. the World

[John Cowan]

On Tue, Dec 15, 2020 at 2:11 PM PJ vM <pjvm742 at disroot.org> wrote:


> This introduces a pitfall for authors: they never have to think about
> percent-encoding, *except* when there are percent signs in the path.
>

Or spaces, because in a link line a space terminates the URI.  So if the
author wants to link to "gemini://example.com/foo bar", the author *must*
write gemini://example.com/foo%20.bar.  In principle you have the same
problem with wanting line endings in a URI, though they are much less
likely to be an issue.

All this boils down to this question:  Who should pay the price for i18n in
links, clients or authors?"  Any third alternative is hacky at best (there
is typically no library routine for "encode everything that needs to be
encoded except in the sequences %20 and %25") and broken at worst.

How is this better than agreeing that link paths in gemtext are always
> completely percent-encoded?


I don't understand.  Do you mean "link paths are already %-encoded when you
get them" (status quo) or "link paths must be %-encoded when you get them"
(IRIs in link lines)?

On Tue, Dec 15, 2020 at 3:00 PM Côme Chilliet <come at chilliet.eu> wrote:

Because a completely percent encoded link is hell to read and to write, for
> instance:
> gemini://gemini.circumlunar.space/%64%6f%63%73/%66%61%71%2e%67%6d%69


+1


> Yes.
> I am for IDN in link lines, but I am also in favor of IRI in link lines.
>

+1


> And I would be supportive of using IRI in request line also for that
> matter. And redirect responses.
>

-1.  That's a change to the protocol, and only protocol agents (clients,
servers) should see such lines; it doesn't matter how ugly they are.  So
"machines speak URIs, humans speak IRIs".




John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Uneasy lies the head that wears the Editor's hat! --Eddie Foirbeis Climo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201216/87991be9/attachment-0001.htm>