Unicode vs. the World

PJ vM pjvm742 at disroot.org
Wed Dec 16 14:22:33 GMT 2020


On 12/15/20 9:00 PM, Côme Chilliet wrote:
>> =>gemini://example.com/%XY.gmi
> Because this is not a valid link, neither URI nor IRI.

My thinking was that it is a valid link after percent-encoding.

But OK, so the client would percent-encode exactly those characters that
are not reserved but not in ascii. That would indeed be unambiguous. It
would not be one-to-one with percent-decoding, though, which is
unavoidable with this approach to IRIs.

> a completely percent encoded link ...

Yes, that was a misuse of the word "completely" on my part

> you feel like this is better because you are use to english and
> ascii.

That is a failed attempt at mind-reading.

> But you will always need to remember which chars you need to percent
> encode. You will never be able to use "/" in a file name without
> percent encoding. Or "?".

Yes, when someone wants to link to a resource with "?", "/" or "#" in
the filename, that will basically always require manual intervention.

One error in my previous email was that of course, you can also use a
tool to percent-encode just spaces and percent signs for you. There's
not much difference in what the author has to think about, then.

Still, with both IRI paths and IDNs, I'm not really seeing the "added
value" of having them in the spec. I'm quite sure they will be there
either way: if it doesn't get into the spec, it is still possible for
clients to provide the same experience with (seemingly) about the same
amount of programming effort - and it seems plenty of client authors
would -, and authors would not be much worse off if they use a tool.

Meanwhile, the negatives are rather visible to me: they're breaking
changes, they increase the complexity that a client *must* have.

-- 
pjvm


More information about the Gemini mailing list