On Tue Sep 19 18:50:41 2006, Robert Sayre wrote:
Tony Finch wrote:
The implementations fail to use the negotiation features to
work securely when possible, and instead baffle users with
terrible user
interfaces bristling with options.
Negotiation features don't work very well in practice so client
vendors don't rely on them.
They work just fine in email, which is where Tony is complaining
about their lack of use.
It's entirely possible to discover TLS support and authentication
methods, and automatically select the strongest combination, with
minimal user interaction. I have yet to find any email server (IMAP,
ESMTP, ACAP, etc) for which the negotiation in-built into the
protocol fails to the extent that the negotiated features are not in
fact supported.
Twice, I have seen the negotiated features fail, but only twice, both
times asa result of bugs in the server, and nothing to do with the
design of the protocols as such. Both cases are vanishingly rare, and
one was in unreleased software, so I'm less than convinced that they
represent an argument that this negotiation does not work very well
in practise.
Unfortunately, this does not leave many possible explanations for why
many client implementors make this much more complicated for the user
than it needs to be.
Dave.
--
Dave Cridland - mailto:dave@xxxxxxxxxxxx - xmpp:dwd@xxxxxxxxxx
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf