> On Feb 7, 2017, at 12:12 PM, Dave Crocker <dhc@xxxxxxxxxxxx> 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.