[spec] Proposed changes

[Solderpunk]

Hi all,

Below are some proposed spec changes to address some (but not yet all)
of the recently enumerated outstanding issues.  Feedback is welcome.

# Section 1.1:

In the outline of a Gemini transaction, the step:

> S:   Closes connection

becomes:

> S:   Closes connection (including TLS close_notify, see 4.2)

and the entire outline is followed by the following new text:

The outline above describes typical behaviour under typical
circumstances, and should be considered illustrative rather than
normative in every detail.  Some clarifying remarks follow.

It is generally the server's responsibility to close the connection,
however the client MAY close the connection at any time, e.g.
because it has not heard anything from the server for some time, or
because the size of the received response body has already exceeded
the size it is willing/able to handle.

Under non-success conditions, the server MAY send a response header
and close the connection before a complete request has been received
from the client.

The server SHOULD NOT close the connection without sending a response
header.

The client MAY begin handling a partially-received response body prior
to the closure of the connection by the server.

# Section 3

Two sets of changes here.  First, in order to address the issue of empty
<META>s:

The line:

> <META> is a UTF-8 encoded string of maximum length 1024 bytes, whose
> meaning is <STATUS> dependent.

becomes:

> <META> is a UTF-8 encoded string with a length between 1 and 1024
> bytes (inclusive), whose meaning is <STATUS> dependent.

(i.e. META may not be empty)

All instances of

> The contents of <META> may provide additional information on the
> failure

become:

> The contents of <META> SHOULD provide additional information on the
> failure

The line:

> If <META> is an empty string, the MIME type MUST default to
> "text/gemini; charset=utf-8".  The text/gemini media type is defined
> in section 5.

is removed.

Secondly, regarding redirects, the following additional lines are added
to the explanation of status code 3x in section 3.2.3:

Clients MAY request confirmation from a user before redirecting a
request.

Clients MUST NOT automatically redirect a request more than 5 times,
to prevent incorrectly or maliciously configured servers "trapping"
clients in infinite redirect sequences, which waste resources on
both sides.

# Section 4

A new subsection is added:

## 4.2 Close notification

As per RFCs 5246 and 8446, TLS 1.2 and 1.3 clients and servers both
MUST send a "close_notify" alert before closing their write side of
the connection.

Under ordinary conditions, the server is responsible for closing the
connection.  Besides being mandated by TLS RFCs, the use of
"close_notify" by the server is important as it allows clients to
disambiguate between successfully completed transactions and those
where the complete response body was not received due to a network
fault or attack.

Client authors should note that the semantics of "close_notify"
changed between TLS 1.2 and 1.3 - only in TLS 1.3 may a client safely
send a "close_notify" after a request to convey that it will not write
anything further and then continue to receive the response.  To avoid
interoperability problems, clients SHOULD NOT send a "close_notify"
before the server does under non-error conditions.  The completion of a
request is already unambiguously indicated by the CRLF characters.

Cheers,
Solderpunk