CRLF requirements (was Re: Text format proposal)

[Sean Conner]

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