On 6/7/11 8:22 AM, Stefan Seelmann wrote:
On Mon, Jun 6, 2011 at 9:58 PM, Emmanuel Lecharny<[email protected]> wrote:
Hi guys,
following the two mails I sent today, I'd like to give a bit more heads up
about the pb we are facing
Currently, if we want to get the Dn/Rdn as a String, we have two methods to
do so :
- getName() which returns the User provided Dn's name
- getNormName() which returns the normalized Dn
The toString() method calls getName() internally.
So far, so good, except that it's not enough. There is a confusion between a
'normalized' DN and a 'Printable' Dn. Let's see with an example. The
following Dn :
"cn= Exa\+mple one"
once parsed, will return the following results :
getName() : "cn= Exa\+mple one "
getNormName() : "cn=Exa\+mple one"
If the Dn is schema aware, the result will be slightly different :
getName() : "cn= Exa\+mple one "
getNormName() : "2.5.4.3=exa\\+mple one"
Are there really two backslashes in the normalized DN? That is wrong.
No, it's just a copy from a Java String (so the '\' is duplicated). My bad.
Now, the problem is that the normalized value is only useful when
manipulating a Dn or a Rdn as a String. There are cases where we want to
compare the Rdn with some AttributeTypeAndValue. For instance, if we create
an entry like :
dn: cn= Exa\+mple one
Objectclass: top
ObjectClass: person
sn: example
cn: exa+mple one
then the server will blow chunks because the CN attribute cannot be compared
to the Rdn ("exa\+mple one" is not equal to "exa+mple one").
I agree that the DN/RDN's name can't be used. Instead the RDN's AVA
type and value must be compared with the attribute's type and value.
This is what we do internally, but there are some other problems (see
the mail I sent this morning)
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
