[Kolab-devel] Ldap DN, from cn=..,dc=.. to mail=..,dc=..?

[Jorgen Hermanrud Fjeld]

On Mon, Jul 31, 2006 at 03:53:54PM +0200, Bernhard Reiter wrote:
> Am Montag, 31. Juli 2006 12:25 schrieb Jorgen Hermanrud Fjeld:
> > Is there a general agreement that the mail attribute is the way to go?
> 
> I think it is a viable approach, but it takes LDAP DNs to a new level of 
> absurdity, given that dcs should be the domain component
> and having an email address with other domain components just looks wrong.
> So we might be back to uids, but with Kolab Server, this is the primary email 
> address. %)
I wholeheartedly agree with you on this, however the mail=..,dc=..
approach appeared quite feasible and non-intrusive to me.

A cleaner design could be to set the base to nothing, and then actually
use use dc for the domain components, hence dn: uid=..,dc=..,dc=..,..
This would probably also be very nice from a multi-domain perspective,
giving each domain a separate branch. 
This would introduce a separate domain attribute, since it is awkward to
search for the domain based only on the dc components.
One could of course disregard the dc, and rather go with something like
dn: localpart=..,domain=.., allowing for easy matching on the domain in
filters, and a known tree depth, if one cares about that.
However it is not clear to me which ldap structure is the "best".
Hence, i think the mail=..,dc=.. is the pragmatic approach.

Anyway, this can be changed later. I think a good first step is
to use the mail=..,dc=.., solving a problem today, and then have an
elaborate technical discussion about the most practical/best solution
later.

-- 
Sincerely | Homepage:
Jørgen    | http://www.hex.no/jhf
          | Public GPG key:
          | http://www.hex.no/jhf/key.txt

An ounce of clear truth is worth a pound of obfuscation.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.kolab.org/pipermail/devel/attachments/20060801/78bbba8e/attachment.sig>