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

[Cyrus Daboo <[e-mail]>]

Hi Giovanni,

--On February 16, 2012 10:52:43 AM +0100 Giovanni Panozzo 
<[e-mail]> wrote:

> b) Autoconfiguration is checked only at client configuration. I would
> like to have the client reconfigured at every startup. This will let me
> do major changes at the server sides (ie: enable SSL ? Change server
> names ?), and client will be able to reconfigure themselves at next
> startup.

One of the things we are doing in CalDAV is supporting a server-driven 
client re-configuration mode. In large scale CalDAV deployments it is 
sometimes more efficient to "redirect" users to a specific host rather than 
rely on some internal-to-the-server reverse proxying. To deal with that we 
simply have servers change a WebDAV property from a path absolute value 
(e.g. '/calendars/users/cyrus') to one with an FQDN (e.g. 
'https://newserver.example.com/calendars/users/cyrus'). Clients are then 
expected to check that property on a regular basis and if they see it point 
to a new host, they "re-base" the user account accordingly.

And of course IMAP has a similar mechanism - RLOGIN.

Now I think I would prefer to stick to a mechanism like that - i.e. the 
service (imap, CalDAV etc) provides a "redirect" mechanism or at least a 
signal to the client, to indicate that a re-basing of the account is 
needed. But that could also be the trigger for the client to go re-do 
account provisioning. However, you need to be careful in terms of 
understanding client side "layering". i.e. there are different apps for 
each service, and possible a separate overall account configuration system. 
It may not be feasible for say the email app to tell the account config app 
to re-do all the services for that account. In any case, there are some 
interesting things to think about here.

-- 
Cyrus Daboo