[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: Significance of attribute names / alias

Thank you for your reply Quanah.

I've read the enhancement requests you posted and your examples clearly
explain the issue, imho.

It is great to see responses like Howard's saying that it can be done, but
what would be nice here is an explanation of how ?

Forgive me for being relative new to using openLDAP.

I don't think it is unreasonable for openLdap to return "abc" in response to
a client request for "abc"  regardless of whether "abc" is an alias for
something else. If a client asks for "abc" and gets "123", it's isn't going
to know what "123" is.

I'm now going to err on the side of caution and assume this cannot be done.
However, I would love to hear to the contrary.


-----Original Message-----
From: owner-openldap-software@OpenLDAP.org
[mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Quanah
Sent: 06 March 2005 04:13
To: John Lane; openldap-software@OpenLDAP.org
Subject: Re: Significance of attribute names / alias

--On Sunday, March 06, 2005 2:20 AM +0000 John Lane
<listmail@oceanfree.net> wrote:

> I'm trying to put together a schema that works for both Outlook and
> Mozilla Thunderbird, as I haven't been able to find anything official or
> complete.
> I'm hitting a problem with a few fields where the two apps expect
> different names.
> For example, Outlook likes "URL" and Mozilla likes "workurl".
> I have something like this in my schema:
> attributetype (
>         NAME ( 'URL' 'workUrl')
>         EQUALITY caseIgnoreMatch
>         SUP name )
> If the NAME line is as above, Outlook can see the value, Mozilla can't.
> If the NAME line is as below, Mozilla can see the value, Outlook can't.
>         NAME ( 'workUrl' 'URL')
> Is there a way to set up the attribute so that either name or alias is
> equally valuable in a look-up ?

Hm, you've hit on a pet peeve of mine, so I'm going to rant for a second:


Email clients should not define a schema for address book lookups, period.
They should be configurable enough to allow users to assign address book
values to whatever attributes the LDAP server they are querying.  They
should also allow the user be able to define the filter that will be used
to search the directory.  The only email client that I know of that will do
this is Eudora, and as much as I don't like Eudora, it had the most thought
put into its LDAP lookup design than of any other email client I've looked


Back to your question, the almost same exact thing was asked a day or two
ago about a different attribute.  The answer lies in:

(From Howard Chu)
I'd agree that LDAP's design is deficient here. Certainly this problem does
not happen with X.500 DAP. I believe that you can use the rewrite overlay
and attribute mapping to handle this now. The relay backend may also be

(From ITS' I filed a year or so ago):



Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

"These censorship operations against schools and libraries are stronger
than ever in the present religio-political climate. They often focus on
fantasy and sf books, which foster that deadly enemy to bigotry and blind
faith, the imagination." -- Ursula K. Le Guin