> How is this better than agreeing that link paths in gemtext are always > completely percent-encoded? In that case, clients can percent-decode the > path and display that. Authors could use a tool that 'fully' (as in, it > also turns every "%" into "%25") percent-encodes a link for them. > > Counterintuitively, in this way I think mandating completely > percent-encoded paths in gemtext link lines might actually result in > easier linking for authors. This is -- as I read it -- what the spec requires now. I think that's the best solution. The wording in the spec can (and maybe should) be clarified, though. > * all clients need to convert to punycode when following a link, authors > can easily link to IDNs without a tool (though they're already using a > tool for unicode paths), somewhat inconsistent/strange > * fancy clients will convert from punycode when displaying a link, > authors need a tool to be able to easily make links to IDNs (though > they're already using a tool for unicode paths) I think that all clients *should* convert links to punycode. If they did authors could write punycoded or unicode domains in their links and both would work. Right now authors can't expect clients to punycode for them, so the safest recourse is to punycode links yourself before publishing. Note that none of this requires a spec change (except for maybe clarifying the percent encoding of links in gemtext). I think it's fair to assume that IDNs will just work, and if they don't work in a browser/client we can report that as a bug (or send a PR that fixes it). After all IDNs have existed for some years, and URL libs across languages are very likely to support it. Cheers, ew0k ??
---
Previous in thread (11 of 34): 🗣️ Sean Conner (sean (a) conman.org)
Next in thread (13 of 34): 🗣️ Jason McBrayer (jmcbray (a) carcosa.net)