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

Kurt,

Kurt D. Zeilenga wrote:
> At 10:58 PM 3/7/2005, Steven Legg wrote:
> 
> 
>>Kurt,
>>
>>Kurt D. Zeilenga wrote:
>>
>>>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. 
>>>
>>>It is not clear to me that X.500 requires for every equality
>>>matching rule R and every value X of the applicable attribute
>>>value syntax that:
>>>       R( X, X ) == TRUE
>>>In absence of a guarantee that R( X, X) is always TRUE,
>>>the [Models] statement in necessary.
>>
>>It is only necessary in the case of the string matching rules because LDAPprep
>>can fail.
> 
> 
> It's also necessary because X.500, I think, doesn't guarantee
> that all equality rules ensure R( X, X ) == TRUE.

I not arguing against having a general requirement that R(X, X) == TRUE.
It could equally well be described as R(X, X) != Undefined, since X.500's
conditions on equality matching rules mean that R(X, X) == FALSE can never
happen. What I'm concerned about, and what I think Hallvard is concerned
about, is that LDAPprep is causing the string matching rules to evaluate
R(X, X) to Undefined for a wider range of inputs than we think is desirable.

The requirement for R(X, X) == TRUE is effectively imposing a restriction
on the string syntaxes, but it does not restrict arbitrary string components
of more complex syntaxes. Component matching can apply a string matching
rule to such components and I would much prefer that the result is definitively
TRUE or FALSE (as it currently is in my implementation), rather than Undefined
in some cases.

> 
> And, in regards to LDAPprep, it is difficult to prevent LDAPprep
> from failing.  For instance, step 3 (Normalize) will fail
> on any input which cannot be processed by NKFC algorithm.

I did a quick scan of Unicode Standard Annex #15 and couldn't see any evidence
that the normalization procedure can fail. Can you point me at a definitive
statement ?

> Hence, if X.500 requires all equality rules to ensure R(X,X),
> not only would be have to eliminate all prohibitions, we'd
> have to eliminate NKFC normalization.

I don't see how that follows, especially since the prohibition step
comes after the normalization step. I'm asking that LDAPprep not fail.
Normalization is not incompatible with that.

Regards,
Steven

> 
> 
>>If LDAPprep didn't fail then R(X, X) = TRUE would always be trivially
>>satisfied. No test would be required.
>>
>>BTW, in the case where matching is not undefined, the X.500 requirement for
>>transitivity, i.e. a=b and b=c then a=c, and commutativity, i.e. a=b then b=a, guarantees a=a.  If b=c then c=b, which means a=b and c=b implies a=c. If c is identical to a then we have a=a.
> 
> 
> If you can find values of b and c such that these statements
> are true in respect to a, then, yes, a==a.  However, if
> R(a,a) is Undefined, you shouldn't be able to find any such
> b and c.
> 
> Kurt 
> 
>