Proposed minor spec changes, for comment.

[Steve Ryan]

On 20/05/18 08:35PM, solderpunk wrote:
> ISSUE 2:
> 
> Problem: The spec makes a big fuss about how text/gemini is
> line-oriented, but does not clearly state what exactly constitutes a
> line.  The definition of link lines includes a <CR><LF> at the end but
> it's not clear if that applies to all line types - or whether I even
> meant to do this or it was a careless error.
> 
> Proposal: Actually, it turns out this is decided for us.  RFC2046,
> which defines the text/* MIME media type and the text/plain subtype
> covers this very clearly:
> 
> ---
> 4.1.1.  Representation of Line Breaks
> 
>    The canonical form of any MIME "text" subtype MUST always represent a
>    line break as a CRLF sequence.  Similarly, any occurrence of CRLF in
>    MIME "text" MUST represent a line break.  Use of CR and LF outside of
>    line break sequences is also forbidden.
> 
>    This rule applies regardless of format or character set or sets
>    involved.
> ---
> 
> Since text/gemini is, well, text/gemini, it is a "text" subtype and
> using anything other than CRLF means we're violating the RFCs we're
> supposedly building on top of.
> 
> So, CRLF everywhere it is.
> 
> I propose it be mostly the server's job to handle this.  Text editors
> on different operating systems used by content authors will use
> various different line break encodings which are beyond our control,
> so we can't really make it the author's job.  Servers can translate LF
> to CRLF before sending content over the network.  This way clients
> only need to handle the "canonical" format, no matter what authors do.
> 
> Rationale: Don't break foundational RFCs.
> 
> Yeah, I know, this is tedious and no fun for server authors, but, well,
> see above.

My only concern with this is the "server's job" part. I'd rather not
have my server transform user-supplied content, even if it's something
as minor as line breaks. Apache doesn't attempt to fix invalid HTML, why
should SecretShop fix invalid text/gemini? Seems to me this should be
handled by something like the gemini vim-syntax plugin.

It also makes writing servers a bit more complicated since text/gemini
has to be treated differently from other files and actually parsed
versus being directly served up. Not the biggest deal (and you've
already admited it's tedious) but just something I noticed.

> 
> ISSUE 4:
> 
> Problem: Name-based virtual hosting is explicitly described as being
> supported in the spec, but no mention is made of SNI (Server Name
> Indication, a TLS extension which puts the desired server hostname in
> the TLS handshake).  Without this, virtual hosting can't be made to
> work reliably.
> 
> Proposal: Mandate use of SNI by clients.
> 

SecretShop implements virtual-hosting with the assumption that clients
are using SNI, so I'm in favour.

-Steve