Proposed minor spec changes, for comment.

[solderpunk]

Thanks, everybody, for your thoughts on this matter!  I've made a
decision.

Let me start out by saying how thoroughly ridiculous it is that in 2020
people can still have spirited discussions about how the concept of "a
line of text" should work!  I hope that one day this is standardised
once and for all across all systems, but I won't hold my breath.

The line of thinking to my decision has gone something like this:

While it's true that the spec currently is totally ambiguous on what our
supposedly line-oriented format uses to define a line, and that's a
genuine problem which needs to be fixed because specs *shouldn't* be
ambiguous about this kind of thing (thanks to everybody who flagged this
issue!), it's also true that as far as I'm aware this ambiguity has
created precisely zero interoperability problems for anybody.

In a situation where some spec detail is ambiguous but everything is
working just fine 100%, the obvious default course of action should be
to codify whatever the current practice is.

That seems to be everybody using plain LF.  So, there would need to be a
very compelling reason *not* to allow plain LF.  I can't think of any
and nobody has mentioned any, so, first conclusion: plain LF has to be
allowed.

As previously noticed, it is already IETF-mandated that the canonical
representation of anything with a text/* MIME type is CRLF.  HTTP sets a
precedent of protocols being able to permit additional line endings on
top of that, but it seems a very different proposition for a protocol to
*disallow* use of the canonical representation.  So, second conclusion,
CRLF has to be allowed as well.

This leaves only the question of whether or not plain CR should be
allowed as a third option.  Given the complete absence of any
CR-separated content in Geminispace so far, the poor support for
CR-separated line recognition in contemporary programming languages (and
the consequent poor support for it in almost all extant Gemini cliens),
and the fact that mandatory TLS means anybody who really wants to
implement Gemini on an old CR-based system is going to have muuuuuch
bigger problems to worry about than translating line endings, this seems
very hard to justify.  I did previously have the notion that this was
somehow "the right thing to do", but having had to spend more time and
energy thinking about this issue than it really deserves, I'm a bit more
inclined to help "grease the wheels of history" on its clear path toward
reduced variability in such a fundamental matter.  LFCR is now well and
truly dead, and CR is very, very close to it.  It's clear that other new
technologies are choosing to leave it behind, so we might as well follow
suit and help the world get to a place of only having to worry about two
common EOLs instead of three (and may our grandchildren only have to
worry about one!).  Conclusion the third, let's not allow CR.

Since CRLF is the canonical form of all text/* subtypes, these changes
to the Gemini spec won't go in section 1.3.5 (which defines
text/gemini), but in section 1.3.3 (which defines response bodies in
general, and is where we e.g. define UTF-8 as the default encoding).  I
will probably borrow verbatim the wording used by the HTTP spec but just
leave out CR.

This solves the ambiguity of the spec on this matter, and should involve
very little actual work from anybody to attain/retain compliance - which
is exactly how it should be, given that everything is already working
just fine despite the ambiguity.  In particular, given the complete lack
of modern systems using anything other than LF or CRLF, server munging
should not be necessary and Gemini content can be served as verbatim
binary data from the filesystem, which is a very desirable property.

I'll make this change, along with the two other uncontroversial
housekeeping changes (mandating SNI and requiring response headers to
use exactly one space instead of arbitrary whitespace), tonight or
tomorow.  Then we can shift focus to more important things, like client
certificates.

Cheers,
Solderpunk