Proposed minor spec changes, for comment.

[solderpunk]

On Mon, May 18, 2020 at 05:37:15PM -0500, epoch wrote:
 
> https://tools.ietf.org/html/rfc5147#section-4.1
> 
> "   In Internet messages, line endings in text/plain MIME entities are
>    represented by CR+LF character sequences (see RFC 2046 [3] and RFC
>    3676 [6]).  However, some protocols (such as HTTP) additionally allow
>    other conventions for line endings."
> 
> precedent of protocols allowing for other line endings, so the gemini spec
> could just say the same thing that http does about line endings.
> 
> https://tools.ietf.org/html/rfc2616#section-3.7.1
> 
> "   When in canonical form, media subtypes of the "text" type use CRLF as
>    the text line break. HTTP relaxes this requirement and allows the
>    transport of text media with plain CR or LF alone representing a line
>    break when it is done consistently for an entire entity-body. HTTP
>    applications MUST accept CRLF, bare CR, and bare LF as being
>    representative of a line break in text media received via HTTP."

Aaah, wonderful!  Thanks for bringing this to my attention.

I *had* been wondering whether or not mainstream webservers were doing
newline translation for text/html, which I had convinced myself they
should have been doing, in principle.

Okay, so we can actually spec whatever we like here for stuff that goes
over the wire. CRLF is only mandatory for "canonical form" (although if
that's not what is on the disk and not what is on the wire, what the
heck *is* it?).

So now the question is which do we prefer, forcing servers to
canonicalise (canonise?) everything, with client behaviour then being
strictly limited, or letting servers just send whatever the author uses
and forcing clients to accept any of CRLF, CR or LF?

In general I have preferred pushing burden to server authors over client
authors for Gemini...but I expect the client burden is pretty small here
as most languages will have some kind of functionality for breaking
strings into lines which already handles this...

Cheers,
Solderpunk