directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@iktek.com>
Subject Re: DnNormalizer
Date Sat, 05 Feb 2005 02:30:30 GMT
I may have missed something, so the following should only be taken for
no more than my own perception of the problem :

I think that we should consider two cases :
- values that are sent through PDU
- values that are sent through files (ldif)

The first case does not need normalization : it's already done while
decoding the PDU

For ldif files, that quite different. Spacing should never be a problem.
LDAP server should store trimed values, so no difference. A space, a
tab, a nbsp are differents char, so they are stored as is. If a user
send a space instead of a nbsp;, too bad for him ! (modify or delete
orders, for instance).

There may be only one specially vicious case : a LDAP client that send a
request without triming spaces. (M$ could do that ! Embrass and extend
stuff). Then you are dead... Don't know if you have to deal with this
kind of brain dead client tier?

Am I a total fool, or just pretending that I'm sane?
Please feel free to tell me !

Cheers,
Emmanuel

Le vendredi 04 février 2005 à 21:15 -0500, Alex Karasulu a écrit :
> Alan D. Cabrera wrote:
> 
> > Why does it reparse the string when it's normalizing?
> 
> The string is reparsed because normalization is not just a matter of 
> handing whitespace.  It involves normalizing values so that case and 
> white space varience do not effect the outcome of addressing the entry 
> node within the namespace.  Things like the attribute schema determine 
> how this is going to happen.  However this might not contradict what you 
> are asking I just don't have enough info from this one liner.
> 
> I think you are referring to when a non-normalized DN (user provided 
> input) as an LdapName is converted into a string then put through the 
> parser again.  It might not have to be if I understand you. 
> 
> Alex
> 
> 



Mime
View raw message