Re: [imap5] Feature set? - was Re: Designing a new replacement protocol for IMAP

[Cyrus Daboo <[e-mail]>]

Hi Sebastian,

--On February 16, 2012 10:35:43 AM +0100 Sebastian Hagedorn 
<[e-mail]> wrote:

>> There are settings for:
>>
>> SMTP: specification of server, choice of authentication method, choice of
>> security (SSL vs STARTTLS vs none), username and password.
>> IMAP: specification of server, choice of authentication method, choice of
>> security (SSL vs STARTTLS vs none), username and password.
>> LDAP: specification of server(s), choice of authentication method, choice
>> of security (SSL vs STARTTLS vs none), username and password.
>
> Another way of dealing with that particular issue is autoconfiguration.
> Unfortunately there's no accepted standard for that yet, but we (Cologne
> University) support Microsoft's and Thunderbird's mechanisms. If you
> enter a @uni-koeln.de address in the new account wizard, all settings are
> filled in automatically.

Today we have SRV mechanisms for email and CalDAV/CardDAV. Whilst the 
former is relatively new and apparently not supported in any big way (*), 
the later is used by servers and clients.

That said, at the Calendaring and Scheduling Consortium, we have been 
discussing putting together a more generic "account" provisioning mechanism 
as opposed to a per-service lookup which is essentially what SRV provides. 
I am planning on starting some discussion inthe IETF apps area on this. An 
initial proposal would be to use an HTTP well-known URI to advertise a 
site's set of services and basic user account provisioning. Many of the 
vendors involved in CalConnect want this because they feel that the current 
approach of configuring "standards" based protocols is too unwieldy for 
users (e.g. having to separately setup email, calendaring, chat etc) vs the 
kind of setup one gets with e.g. Exchange.

Now one could argue that the current complexity could be hidden behind a 
simple UI on the client (where the client does all the multitude of SRV 
lookups to see what services are available) but there are downsides to that 
(multiple DNS requests, inability to tailor response on a per-user basis 
etc) - basically the process is too complex.

So, I (we - CalConnect) want to see something done in this area. Keeping 
the scope as small and simple as possible will be key though...


(*) Some services do have SRVs for email, CalDAV, CardDAV, e.g. try:

dig _imaps._tcp.gmail.com srv
dig _caldavs._tcp.gmail.com srv
dig _caldavs._tcp.icloud.com srv
dig _carddavs._tcp.icloud.com srv

-- 
Cyrus Daboo