[ANN] Specification update

[Solderpunk]

Greetings Geminauts,

I've just pushed the first changes to the official Gemini specification 
in close to one year!  As always the official specification can be 
viewed at:

* gemini://gemini.circumlunar.space/docs/specification.gmi
* gopher://gemini.circumlunar.space:70/0/docs/specification.txt
* https://gemini.circumlunar.space/docs/specification.html

You can also `git clone git://gemini.circumlunar.space/gemini-site` to 
see individual diffs for spec changes.

A quick preamble: in the gitlab.com repos set up by Sean to work on 
finalising the specification, the single document form of the current 
official spec has been replaced by two separate documents, one for the 
transport protocol and one for the markup language.  I think this is a 
good idea and I intend to adopt it for the official spec.  But I also 
want to work carefully through the proposed changes which made it into 
that repo and approve or reject them individually.  To facilitate this 
workflow it's easier for me, for now, to "backport" changes to the old 
format.  Once I've decided I'm happy with things I'll backport as much 
of the new writing as proves to be applicable when translating the 
format.  This is all a bit ugly, but it's not the end of the world.  
There's real value in having the diffs that actually change spec 
behaviour as opposed to wording/presentation be short and sweet.

Okay, I have made three changes:

1. Gemini URIs with empty paths (e.g. `gemini://example.com`) and those 
with paths of `/` (e.g. `gemini://example.com/`) are now equivalent by 
definition, and both clients and servers SHOULD normalise empty paths to 
`/` before sending/processing requests (along with applying other 
standard URI normalisations).
2. The use of the TLS `close_notify` mechanism is now mandatory (see 
sections 1.1 and 4).
3. The spec is now more explicit about clients not sending anything 
after a request and servers ignoring anything else they receive after a 
request.

You can find a little further explanation of my reasoning behind these 
changes in the corresponding Gitlab issues (#11, #2 and #40).

There are no major changes here.  `close_notify` was in fact *already* 
mandatory via the TLS specs, so we are just being very explicit by 
repeating that in the Gemini spec.  The tightened language in change 
three is just an attempt to close loopholes.  Nobody should have been 
doing any of the things it prohibits anyway.  If you were, you should 
feel bad.  The biggest change is the first one.  Depending on how you 
read RFC 3986, prior to this change it was maybe sorta technically okay 
for a server to serve different content from gemini://example.com and 
gemini://example.com/.  This is no longer allowed.  If you have actually 
been doing this you need to stop it, you strange, strange person.  Both 
client and server authors should also update their code to normalise 
URIs (see section 6.2.3 of RFC 3986).  Hopefully many will be able to 
rely on libraries to do this.  If you're forced to implement this by 
hand, the most important normalisation in practice is also one of the 
simplest: replace an empty path by a `/`.  This will help cut down on 
superfluous redirects.

Even if `close_notify` was not strictly required by the TLS RFCs, it 
would be logically necessary in Gemini, thanks to the lack of content 
length information, to disambiguate complete responses from erroneously 
or malisciously truncated responses.  There *are* servers out there 
which do not reliably use `close_notify`.  In principle clients visiting 
capsules at those servers should interpret this as something having gone 
wrong and e.g. notify the user or perhaps automatically retry the 
request.  In practice client authors may wish to "be gentle" for a 
little longer and give server authors time to catch on to this issue 
before making it difficult/ugly to visit their capsules.  Those who 
provide "torture test" services for server authors should certainly flag 
lack of `close_notify` as a problem.

Cheers,
Solderpunk