ldap attribute aliases

Howard Chu hyc at highlandsun.com
Sat Jan 15 19:02:10 GMT 2005


Simo Sorce wrote:
> Sorry if I insist Howard,
> I do not understand how youìre supposed to "help" older clients by
> returning a different attribute name.
> 
> When I ask for 'commonName' I expect to have back 'commonName' not 'cn'.
> When I ask for 'cn' I expect to have back 'cn' not 'commonName'.

What if you ask for both in the same request? Do you expect to get the 
same value returned twice, once with each name? That would be Bad, IMO, 
because that would lead users/implementers to believe that they are two 
separate attributes stored in two separate places, when in fact there is 
only one.

If the server behaved as you propose, then one would be lead to expect 
that it's OK to send a single Modify request to Replace each name with 
separate values. Such a request would succeed, but only one of the 
Replace's would be reflected in the result, and there would be no 
explanation of what happened to the other. For the server to accept a 
change but not actually store it (as would happen here) is a violation 
of the directory model.

> I'm asking because I missed the reason why openLdap return s 'cn'
> instead of 'commonName'.

This has been discussed many times before, at great length. Ultimately 
the answer is because doing so opens another can of worms that nobody 
wants to be responsible for.

> If I get you right you're saying that newer application should never ask
> for "commonName" but only for "cn", I'm fine with that, but I do not
> understand how that relates with the name of the attribute returned by
> the server, if they are used to aid transition I think it should try to
> accomodate older applications by 'speaking' their language and returning
> the attribute name in the form they show to be using ...

You're welcome to submit an ITS requesting this feature. Perhaps you can 
present a compelling enough argument to get the current position changed.

-- 
   -- Howard Chu
   Chief Architect, Symas Corp.       Director, Highland Sun
   http://www.symas.com               http://highlandsun.com/hyc
   Symas: Premier OpenSource Development and Support


More information about the samba-technical mailing list