plugd plugd at thelambdalab.xyz
Tue Jun 2 21:59:23 BST 2020
- - - - - - - - - - - - - - - - - - -
Hi, just some comments from the peanut gallery..
Petite Abeille writes:
❶ drop ;charset= from text/gemini content-type response. Everything is UTF-8. Gemini doesn't support legacy encodings.
Rational: Clients shouldn't burden themselves with legacy charset conversions, which is finicky. Servers are better placed to normalize encoding if they must. Gemini is about the future, not the past (EBCDIC 273 anyone?).
Clients don't have to implement any of these things. They can justrefuse to serve non-utf8 content. But at lease I _know_ that Ishouldn't try to render your koi8 page and can give a sensible reason why.Otherwise we're back to gopher, using guesswork and inference.
❷ drop everything from text/gemini but text and link lines.
Rational: The world has enough formatting options as it is. Everybody and their pet fish has their preferences (most posts on this list are about formatting...). text/gemini will not move the state of the art. Keep it simple. Less is more.
Ok, there goes ascii art from gemini. Seriously. This just forces meto choose between having prose rendered at a sensible width for readingor having nice art. Or having to implement more guesswork and inference.
❸ mandate
= TLS 1.3. Drop legacy support.
Rational: no point dragging the burden of the past into the future. Gemini innovative take on TLS deserves a modern foundation.
Is this really necessary? What's so awesome about 1.3 from alayperson's perspective? I'm honestly asking, not just trying to becontrary. I worry this would increase the difficulty of compliencewithout a real qualitative benifit. (Also, I think this wouldimmediately break my server, so I'm biased. :-) )
plugd-------------- next part --------------A non-text attachment was scrubbed...Name: signature.ascType: application/pgp-signatureSize: 487 bytesDesc: not availableURL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200602/930be09f/attachment.sig>