On Feb 7, 2017, at 12:12 PM, Dave Crocker <dhc(_at_)dcrocker(_dot_)net> wrote:
But how large a community is this and why is this problem not mitigated
simply by having the user interface take one password specification and map
it to the two, underlying (and existing) protocols?
I agree that this can go a long way. On iOS and macOS, we've done this to a
limited degree, by building a central database of accounts that each app uses.
“Branded partner” accounts like Google/Yahoo!/Aol/etc have the credentials
centrally stored, and child accounts (IMAP, SMTP, etc) inherit them, with a
single UI framework to re-authenticate.
Unfortunately, regular accounts still don’t have this treatment, and it still
drives a lot of calls to AppleCare. There are a bunch of reasons why, but one
is that it’s tricky to be sure that the various protocols/hostnames have been
appropriately bundled together into what is truly the same service, where the
same username/password truly applies, and there isn’t a security issue from
taking your user-updated IMAP password and sending it off to a CalDAV server
with a different hostname. This does seem like an incrementally solvable
problem, though, with some of the other work being done in the account
configuration space.
However, there are still some operational issues that arise, even with this
kind of UI, for example:
(a) Two different protocols/servers often lead to very confusing partial
failures (I can check for my Mail, but I can’t send any).
(b) Port fire-walling. It was a more common support issue for us 8-10 years
ago, but has subsided in recent years.
That all being said, I think there are some very compelling aspects here,
particularly the stateless nature of the protocol, and using HTTP underneath.
From a client’s perspective, I can say that this would lead to a far simpler
implementation, with pre-existing EWS/EAS implementations being the backing of
that statement.