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

[Petite Abeille]

> On Dec 22, 2020, at 08:42, Stephane Bortzmeyer <stephane at sources.org> wrote:
> 
> 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.

Right. The specification should concern itself with interoperability.

> 
>> - The gemini protocol is not well tailored to handle anything
>> sensitive.
> 
> Why? At least for privacy, it is certainly better than HTTPS.

I'm not a security expert, so I will spare myself the embarrassment of articulating a cogent answer, but by "sensitive" I understood "secure". 

There are different aspects to security: data at rest vs data in transit vs data in use, etc.

A threat model helps as well: https://blog.ivanristic.com/2009/09/ssl-threat-model.html

In any case, all above my pay grade. Perhaps someone with actual expertise in this domain could help out. 

Privacy is something else altogether.

> 
>> 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

Nice.

> 
>> 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

Let's split the difference:

https://portal.mozz.us/gemini/gemini.bortzmeyer.org/rfc-mirror/rfc3552.txt

In general, would people prefer gemini links? or http ones?

Accessibility is an issue. At this conjuncture, I do not have the proper tooling to systematically provide gemini links by default.  

> 
>> 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.
> 

This is a technical document, not a political pamphlet. Let's keep it that way.

By the same account, avoid ARPANET and its decedents. A creation of the United States Department of Defense.

Let's not be overly childish.