Re: [Models] An attribute value should be equal to self

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 12:20 AM 3/10/2005, Steven Legg wrote:

>Hallvard,
>
>Hallvard B Furuseth wrote:
>>Steven Legg <steven.legg@eb2bcom.com>
>>
>>>I will have to review that discussion yet again soon...
>>>
>>>It was a short thread:
>>>http://www.openldap.org/lists/ietf-ldapbis/200411/msg00190.html
>>
>>Ah, thanks.
>>Kurt D. Zeilenga writes:
>>
>>>At 05:20 PM 3/7/2005, Steven Legg wrote:
>>>
>>>>I dislike it too. I would prefer that LDAPprep removes troublesome
>>>>characters instead of failing.
>>
>>I'm not sure that is right; it might be better to translate them to some
>>otherwise unused character or leave them alone or something.
>
>You're right. Removing the troublesome characters means that a string
>with "garbage" will match a string without "garbage". I'd suggest mapping
>to something like the replacement character rather than leaving the characters
>alone for the reason that two distinct bad sequences might one day be made
>equivalent, which would then present a problem if an attribute already has both
>as values.

I don't see any value in mapping troublesome characters,
presently prohibited, to a character which itself remains
prohibited.  If instead, you meant to map the troublesome
charactes to some character which is not prohibited, then
I think this be problematic for the reason you note,
string+garbage would be equivalent to string.

Also, I note, that even if there were no "prohibited" characters,
LDAPprep can still suffer failures.  For instance, Unicode
normalization failures, unassigned Code point failures, etc..


>> Or let
>>EQUALITY match use a fallback which does not do LDAPprep if LDAPprep
>>fails, like Rici suggested.
>
>That's fine for equality matching but could dramatically change the collation
>order for ordering matches. If two values are the same except for some final
>bad characters then it is desirable for them to still be close in the collation
>order.

Concur.


>Regards,
>Steven