Three month spec freeze

[solderpunk]

On Tue, Jun 02, 2020 at 09:57:27PM +0200, Petite Abeille wrote:
> > 
> > As of yesterday, the freeze is over!  The spec is now "liquid" once again.
> 
> Cool. Can we remove things? :)

Yes, but not willy nilly. :)

> ❶ drop ;charset= from text/gemini content-type response. Everything is UTF-8. Gemini doesn't support legacy encodings. 
> 
> Rational: Clients shouldn't burden themselves with legacy charset conversions, which is finicky. Servers are better placed to normalize encoding if they must. Gemini is about the future, not the past (EBCDIC 273 anyone?).

Being "about the future" shouldn't mean "losing the ability to view the
past".

Clients are very explicitly permitted not to burden themselves with
legacy charset conversions.  From section 3.3:

> Compliant clients MUST support UTF-8-encoded text/* responses.
> Clients MAY optionally support other encodings.  Clients receiving a
> response in a charset they cannot decode SHOULD gracefully inform
> the user what happened instead of displaying garbage.

If the majority of clients don't support anything other than UTF-8
(which is likely, because adding support for other things is not fun,
and many Gemini clients will be written for fun as small
single-developer or small-team projects), this will exert a strong
pressure for people to only author in UTF-8 (which is also very
strongly encouraged in the Best Practices document that nobody reads),
as well as motivate the inclusion of automatic transcoding in servers.

> ❷ drop everything from text/gemini but text and link lines.
> 
> Rational: The world has enough formatting options as it is. Everybody and their pet fish has their preferences (most posts on this list are about formatting...). text/gemini will not move the state of the art. Keep it simple. Less is more.
 
My biggest objection to this is the heading lines, which I actually don't
see as fundamentally about formatting at all (although obviously clients
*can* use it as a hint for formatting and many do), but rather about
imparting genuine semantic structure to a text/gemini document.  Gemfeed
uses these headers to "just know" how to title entries in a feed and how
to title feeds themselves.  Lightweight CMS software could use them to
generate a directory listing of documents using their titles instead of
their filenames, relieving authors of the need to duplicate the title in
both post.gmi *and* index.gmi.  Clients can use it to let users skip
through long documents by section or subsection, or to display a table
of contents.  Those headers don't just look pretty in some clients, they
can and should do real actual work which genuinely enhances the
experience of consuming textual content.  I honestly think that getting
rid of those would be a case of "less is less".

> ❸ mandate >= TLS 1.3. Drop legacy support. 
> 
> Rational: no point dragging the burden of the past into the future. Gemini innovative take on TLS deserves a modern foundation.

Funny you should mention this. Just today (or yesterday?) a new LibreSSL
version was released which now enables TLS 1.3 support in both clients
and servers by default.  The only reason I didn't spec 1.3 in the first
place was because I didn't want to discourage the use of LibreSSL which
is a project I support a lot (and which the first ever Gemini server
happened to be built with!).  I used to think that as soon as TLS 1.3
came to LibreSSL, I would make exactly this change.

...

Since then I have also learned about BearSSL, which is *another*
implementation I really don't want to discourage use of due to its
extremely small footprint which I feel aligns nicely with Gemini's
philosophy.

That said, the odds of 1.3 support appearing in BearSSL any time soon
seem slim, so waiting for this as well could doom us to never ditching
1.2.

So, I will consider this.  Feedback from implementers welcome.
Statistics on how many known servers support 1.3 especially welcome!

Just for the record, that never-read Best Practices document also
encourages people implementing TLS 1.2 to limit the ciphersuite to
something 1.3-esque.
 
> In protocol design, perfection has been reached not when thereis nothing left to add, but when there is nothing left to take away.
> 
> This would make Saint-Exupéry proud.

This quote has always been dear to my heart. :)

Cheers,
Solderpunk