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

[Steven Legg <steven.legg@eb2bcom.com>]

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