"Drew DeVault" <sir@xxxxxxxxx> writes: > Can I get one of the maintainers to chime in on this thread and explain, > in their opinion, what this patchset needs before it is acceptable? I'm > not sure where I should go from this discussion. What you called "compromise" in the upthread didn't even smelled like a compromise but the safest way forward. My reasoning goes (thinking aloud, so that you and Ævar can correct me if I am talking nonsense and discount my input based on it): - If we were designing this from scratch, we would have called the smtps:// tunnelled transport SSL/TLS and in-place upgrade transport STARTTLS, like e-mail providers and client programs do, but unfortunately we didn't. We ended up with 'ssl' vs 'tls'. - We could introduce and advertise STARTTLS as a synonym to 'tls', but then those whose send-email does not understand STARTTLS but read about the new way of spelling would end up having no encryption due to another earlier mistake we made, i.e. an unrecognised option value silently turns into no encryption. - To avoid the above problem, the first phase is not to change the status quo that 'ssl' vs 'tls' are the only two choices. What we do is to make the program error out if we see an unrecognised value given to the option. We release this to the wild, and wait for the current versions of send-email that turns unrecognised words into no-encryption die out. It may take several years, though. - After waiting, we add 'starttls' as a synonym to 'tls'. We may also add 'ssl/tls' as a synonym to 'ssl'. Unfortunately 'tls' alone cannot be repurposed as a synonym for smtps:// without another deprecation dance, and it is not in scope of the transtion. Am I on the same page as you two?
