Don't shrink spaces in normalized RDN values

[pingidentity]

Don't shrink spaces in normalized RDN values

[dirmgr]

It sounds like the problem is with Active Directory and not with the LDAP SDK.

RFC 4518 states that for equality matching for matching rules that use insignificant space handling (which includes the cn attribute), sequences of multiple spaces are considered logically equivalent to a single space. Insignificant space handling is addressed in section 2.6.1, but a simpler explanation that applies for non-substring matching can be found in Appendix B, which states "all sequences of one or more spaces be replaced with one space and, if the string contains non-space characters, removal of all leading spaces and trailing spaces."

So in your example, the following would all be considered equivalent:

CN=F      O  O, CN=Bar
CN=F    O          O, CN=Bar
CN=F O O, CN=Bar

And to address your other point about capitalization, the cn attribute uses caseIgnore matching, so differences in capitalization are also considered insignificant. Attribute names are also always case insensitive, regardless of the syntax associated with that attribute. So in each of the cases listed above, the LDAP SDK should generate the following normalized representation:

cn=f o o,cn=bar

If it were to explicitly follow RFC 4518 section 2.6.1, it would yield:

cn=f  o  o,cn=bar

But that seems less natural (because it would convert every occurrence of a single space into two spaces), and because this particular normalized representation isn't intended for substring matching, it uses the simplified rules described in Appendix B.

[asaf-romano]

Thanks for the prompt reply!

I've never read the RFC, so I cannot reply on that. FWIW, LdapName (from javax) does not seem to consider the two equal.