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

[Adrien de Croy <[e-mail]>]

One of the things that discovery gives you is an opportunity when the 
discovery is initiated to make a decision about what will provide the 
service(s).

this means load-balancing, failover etc can be implemented.

One issue with using a well-known http URI for user account discovery, 
is that most organisations that run web services already have a website 
set up on their base domain.  So you'd have to wedge the discovery 
provision into an existing web site and infrastructure.

Another option could be to use DNS again.

e.g. do a dns SRV lookup for say _localpart._allservices._example.com

which could return multiple records, one for each available service.  
Could even use SRV records for this where the record name is _ldap._tcp 
etc.... possibly need some CNAME glue.

Adrien


On 17/02/2012 4:23 a.m., Cyrus Daboo wrote:
> 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.
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 is released! - http://www.wingate.com/getlatest/