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

Kurt,

Kurt D. Zeilenga wrote:
> At 12:20 AM 3/10/2005, Steven Legg wrote:
> 
> 
>>Hallvard,
>>
>>Hallvard B Furuseth wrote:
>>
>>>Steven Legg <[email protected]>
>>>
>>>>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.

I'm saying that none of the characters should be prohibited, at least as
far as matching rules are concerned.

 > 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..

By "troublesome characters" I meant all these sorts of things.

Regards,
Steven

> 
> 
> 
>>>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
> 
> 
>