RE: Multi-valued RDNs: what are the options?

Wed, 21 Aug 96 15:35:29 PDT

On Wed, 21 Aug 1996 11:18:41 +0100 Ed Oskiewicz wrote:
>I have also had to tackle the problem of disambiguating
entries in a large
>corporate directory. I think the solution I used works but is
illegal (or at
>least immoral). We have unique Employee Id Numbers and I
constructed entries
>looking like:
>dn: cn=Joe Soap (123456), o=BT plc, c=gb (1)
>cn: Joe Soap
>ein: 123456
>objectclass: BTperson
>The number at the right is for reference and is not part of
the dn.
What do you mean "is not part of the dn" ?

if it is not part of the dn, you don't have a unique dn if
another cn=Joe Soap works in o=BT plc

> It seems
>I should have actually used a dn like:
>dn: cn=Joe Soap+ein=123456, o=BT plc, c=gb (2)
Exactly !

>However, given that dns only exist to uniquely label entries
then the
>following would suffice:
>dn: ein=123456, o=BT plc, c=gb (3)
This is possible as well. It depends on what you want to do.
If you have to display the dn to a user the (2) seems better;
because it is more user friendly.
But if you want to make a batch appli. searching only with ein,
(3) is fine.

>My questions/comments are:
>I believe the following to be true: In all three cases queries
of the form
>cn=*soap* would return the same results (because you query the
entry not the
>dn). Is this correct?
It is correct if in (3) you have cn=Joe Soap contained in the

>If dns are never displayed, then the third form would seem to
be preferable
>because it is most compact.

>Is the second form of multi-valued RDN actually part of some
standard? If so
>where is it documented and what is the advantage over simple
>as in the first form?.

Using the first form (the ein being part of the cn), you can't
do a successfull equality match search on "cn=Joe Soap". You
need to do a substring match search "cn=Joe Soap". This is more
time consuming than an equality match search.

Hope it helps,


Name: Eric Nisolle
SITA, Sophia Antipolis, France.
Date: 08/21/96
Time: 15:35:29