Autconfiguration for kolabclient

Christian Mollekopf mollekopf at
Fri Jun 20 14:21:44 CEST 2014

On Wednesday 04 June 2014 11.56:57 Sandro Knauß wrote:
> Hey,
> for beeing able to auto configure the client, we should create a file at the
> server to get most settings for the client. As base I used the Thunderbird
> autoconfig file [1].
> I added additional xml tags for ldapserver, freebusy and identities.
> Some questions:
> * should the file 
> <> be
> extended? pro: thunderbird can using the email part as well
> * the identity part isn't defined in hunderbird autoconf [1], do you know
> any configuration for that tag?
> Different modes:
> * requesting the file with auth basic  -> fill out password etc.
> * without login data -> return the file with %PASSWORD%, %USER%,...
> Using other urlpaths:
> or split everypart into an own file:
> would be only a xmlfile that refers to the other parts.

To get to a conclusion here, I'll line out what I think about it:

== What is autoconfig ==
Autoconfig is a mechanism for automatic discovery of servers/services and for 
preseeding deployment specific configuration data.

== What should it include ==
* discovery of imap/smtp server including default configuration
* discovery of ldap server including default configuration
* discovery of freebusy provider including default configuration

All these services are in a deployment specific location and normally need to 
be configured manually. Including those allows the client to automatically 
setup the services. Non of these settings belong to kolab configuration files 
that IMO should be used for your personal preferences, and not the deployment 
specific default values.

The identity is IMO only a nice-to have for new setups because it allows an 
organization to i.e. preseed a default signature, but it's not a requirement 
or core-feature of autoconfig. If the kolab account is already setup-up the 
identity should be read from the kolab configuration anyways.

== Open questions ==
* Do we need the default identity?
* Do we need to include credentials in the config?

If we need to provide credentials we need authenticated requests that allow 
providing a personalized autoconfig file, otherwise we can use a static one (In 
either case we can fallback from the personalized to the static one if not 
available). I suppose we need to provide credentials if they cannot be guessed 
from the provided email address and password that we have available.

== Proposal ==
I suggest we drop the default identity if we can (that just makes the whole 
setup process more complex).

Otherwise I agree with sandro's proposal other than renaming the <freebusy> 
tag to <freebusyProvider> and <ldapServer> to <ldapProvider>. I don't agree 
they should be part of the <emailProvider> tag (or at least I don't see why).

If we need to provide credentials we'll go with the authenticated request, 
otherwise with the static one.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: autoconfig.xml
Type: application/xml
Size: 3251 bytes
Desc: not available
URL: <>

More information about the format mailing list