directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@apache.org>
Subject Re: DnParser
Date Tue, 18 Oct 2005 23:19:50 GMT
On Tue, 2005-10-18 at 15:52 -0700, Gianmaria Clerici wrote:

> NormalizationService will use org.apache.ldap.common.name.DnParser to
> normalize a Name.
> 
>  
> 
> For instance, if my Name looks like this:
> 
> ou=Sub Production  V,bsiViewName=Direct Report View
> 
>  
> 
> It will return this:
> ou=sub production v,bsiViewName=direct report view
> 
>  
> 
> As you can see it will replace the 2 spaces before the V with one
> space.
> 
>  
> 
> Is this the correct behavior ?


Even if stange, this is plain normal. The reason is that 'ou' (OID
2.5.4.11) inherits from attribute 'name' (OID 2.5.4.41) which syntax
is :


name ATTRIBUTE ::= {

	WITH SYNTAX DirectoryString {MAX}
	EQUALITY MATCH RULE caseIgnoreMatch
	SUBSTRINGS MATCHING RULE caseignoreSubstringsMatch
	ID {id-at-name}
}

Its EQUALITY MATCH RULE is caseIgnore Match, and the RFC 2252 says :

8.1 :
...
When performing the caseIgnoreMatch, caseIgnoreListMatch,
   telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
   multiple adjoining whitespace characters are treated the same as an
   individual space, and leading and trailing whitespace is ignored.



> I will need to look up an object using the normalized value (down in
> my partition code), but it’s a bit more challenging if the spaces have
> been, partially, removed.


Yes, it's challenging ;) And it's *not* funny at all to implement
either !



-- Emmanuel

Mime
View raw message