[Spec] Spec (un)freezes and the spec's future

[Stephane Bortzmeyer]

On Mon, Dec 21, 2020 at 11:10:46PM +0100,
 Petite Abeille <petite.abeille at gmail.com> wrote 
 a message of 44 lines which said:

> - Usually, a spec is not meant to mandate implementation
> details.. i.e. do that, don't do that... as it has no mean to
> enforce any of it... its role is rather to describe a normative
> interaction (the protocol) or format (text/gemini).

In another way: the spec of a network protocol is here to allow
*interoperability*. Unilateral actions (such as logging) has no
influence on interoperability.

> - The gemini protocol is not well tailored to handle anything
> sensitive.

Why? At least for privacy, it is certainly better than HTTPS.

> That said, Gemini could sport a set of recommendation and/or "best
> practices" in a companion document, such as "be mindful of what you
> log as it may contain sensitive information" and "consider using the
> underlying TLS mechanism for strong authentication".

Good idea. A good example is RFC 8932. It is for DNS servers but its
method can be applied to Gemini servers easily. For instance, it
contains a very good and detailed discussion of IP addresses "anonymization".

gemini://gemini.bortzmeyer.org/rfc-mirror/rfc8932.txt

> Guidelines for Writing RFC Text on Security Considerations
> https://tools.ietf.org/html/rfc3552

Or on the geminispace

gemini://gemini.bortzmeyer.org/rfc-mirror/rfc3552.txt

> Finally, The National Institute of Standards and Technology has a rather comprehensive document on the matter:

Since one of the goals of Gemini is privacy, I don't think that
relying on an US official document is a good idea.