It was thus said that the Great solderpunk once stated: > > IMO, it makes sense to require CRLF in the plain text parts of the > > protocol (after requests, after the status line of a response), but I > > don't think that the text/gemini file format needs to have CR/LF; IMO > > clients should be prepared to accept either LF or CR/LF just as they > > would with text/plain. And maybe if we're serious about supporting old > > devices, clients should be prepared for bare CR, too (Classic MacOS). > > But it's a pain in the arse to authors to have to save text documents > > with non-native line endings, and I don't feel like servers need to be > > in the business of reformatting the content they serve. > > I will admit that the current liberal use of CRLF throughout the Gemini > spec is the result of me blindly copying from Gopher and other RFCs (as > Sean mentioned, it's ubiquitous). My initial response to what you wrote > above is that it makes an awful lot of sense. And, in fact, is probably > a lot closer to what extant clients are actually doing. > > Does anybody want to make a strong counterargument, that CRLF should be > strictly required in text/gemini? If not I'll update the spec-spec. As memntioned, I think the request and the status response should have the CRLF, but the content, even if text/gemini, should use whatever line endings are easier/standard for the content creator.. So clients should expect text/* types with endings of CRLF or LF (CR will probably be rare, and I've never encountered LFCR). -spc
---
Previous in thread (50 of 148): 🗣️ solderpunk (solderpunk (a) SDF.ORG)
Next in thread (52 of 148): 🗣️ Sean Conner (sean (a) conman.org)