[spec] Limit valid encodings of text/gemini to UTF-8

Philip Linde linde.philip at gmail.com
Mon Dec 28 15:34:29 GMT 2020


On Mon, 28 Dec 2020 14:30:38 +0100
"Solderpunk" <solderpunk at posteo.net> wrote:

> The spec says that "Compliant clients MUST support UTF-8-encoded text/*
> responses.  Clients MAY optionally support other encodings".  So, the
> argument that we should make things simpler for implementers does not
> really carry much weight here.  It's 100% okay to write a client which
> (gracefully) refuses to handle any encoding other than UTF-8. 

I am not so interested in what is okay or not in the abstract. As a
client author, the ideal situation for me is that my client supports the
entire per-specification geminispace. The specification currently makes
this a much harder problem than it would be if text/gemini documents
were limited to UTF-8. In fact, it's an open-ended problem that's
subject to change (as new encodings are introduced) and interpretation
(concerning what sequence of bytes represents e.g. "=>" in a
particular encoding, or how to transliterate URI to ASCII or IRI to
UTF-8). Thankfully, geminispace seems to have settled on UTF-8, which is
why I think this is a good time to tie that end up.

> People
> who want to serve text/gemini content with some other encoding can, but
> they have no right to complain when only a subset (potentially a very
> small one) of people can view said content.  This all seems fine to me.
> Nobody is required or expected to support anything difficult or unusual,
> but if some group of people all decide they want to do something
> difficult or unusual for some strange reason, and they're willing to do
> the work required, then nobody can tell them they're doing anything
> wrong.

Perhaps there is a great argument for allowing other encodings that
makes this an acceptable outcome, but a hypothetical effective split of
geminispace around which encodings are used and which clients support
them doesn't sound desirable in itself.

We can turn the question around and instead ask what motivates the
inclusion of each supported encoding (or arbitrary encodings in
general, a simpler question).

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201228/12e26723/attachment-0001.sig>


More information about the Gemini mailing list