It was thus said that the Great Solderpunk once stated: > > Le lundi 28 d?cembre 2020, 14:16:27 CET Philip Linde a ?crit : > > > > I understand the need for other document types to take other character > > > encodings. For example, I have a collection of old text files in IBM437 > > > encoding. For text/gemini, we pretty much have a blank slate, though, > > > and I see no reason that it should extend to support arbitrary > > > encodings when limiting to UTF-8 creates a much simpler situation for > > > implementers and is already the unspoken standard. > > The spec says that "Compliant clients MUST support UTF-8-encoded text/* > responses. Clients MAY optionally support other encodings". I would ammend that to read "Compliant clients MUST support UTF-8 and US-ASCII encoded text/* reponses." This is because US-ASCII is a proper subset of UTF-8, and any valid ASCII file is also a valid UTF-8 file. I'm thinking here of automated MIME detection (ala libmagic) that might return a MIME type of 'text/plain; charset=us-ascii' for a text file. -spc
---
Previous in thread (6 of 29): 🗣️ Philip Linde (linde.philip (a) gmail.com)
Next in thread (8 of 29): 🗣️ Petite Abeille (petite.abeille (a) gmail.com)