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
<[email protected]> 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/
_______________________________________________
imap5 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imap5
