directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject DN & Attribute values issue : heads up
Date Mon, 06 Jun 2011 19:58:05 GMT
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"

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'm not sure right now if the solution would be to normalize the Rdn 
again (removing the escaped chars) or to modify the comparison between a 
Rdn and an Attribute Value.

Right now, I'm more inclined to investigate the second option, but it 
might not work.

In any case, this is a hell of painful issue...

Thoughts ?

-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com


Mime
View raw message