> On 1 Jul 2021, at 22:40, Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote:
>
> On 30.06.21 22:46, Daniel Gustafsson wrote:
>> I think consistency is the interesting aspect here. We already have a mix of
>> SSL, TLS and SSL/TLS (although heavily skewed towards SSL) so we should settle
>> on one and stick to it. The arguments in the NSS thread which led to this
>> pointed to SSL/TLS. If we feel that the churn isn't worth it, then we should
>> change all to SSL and perhaps instead just add TLS as indexterms to those
>> sections.
>
> I think it is already consistent in that it uses "SSL". Is that not the case?
Almost, but not entirely, and if we want to settle on a single term now is a
good time before it diverges too far.
> I notice that the NSS documentation also uses "SSL" almost exclusively when referring to the SSL and TLS protocols
andrelated APIs.
To be fair, the NSS documentation has more or less not seen updates at all in
years, large parts of the API are completely missing.
The best maintained TLS library documentation today is, I would argue, OpenSSL
and grepping around there (unscientifially) looks a bit different:
SSL: 177 (corrected for not counting the SSL struct)
SSL/TLS (or TLS/SSL): 154
TLS: 252
This patch came about since there was an ask over in the NSS thread to top
using SSL as a term, but if there isn't enough support to warrant the churn
then we should standardize on SSL and just include a paragraph explaining what
we mean by that.
--
Daniel Gustafsson https://vmware.com/
