> On 1 Jul 2021, at 22:40, Peter Eisentraut <peter.eisentr...@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 and related 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/
