Re: Protocol: Compare contradiction

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

At 06:44 PM 4/16/2004, Jim Sermersheim wrote:
>The current protocol draft (in my editor) contradicts itself by stating
>that the result of a compare will be compareFalse when the asserted
>value doesn't match any attribute values or is Undefined (and refers to
>Section 4.5.1). 
>
>Then it says if the attribute or subtype has no equality matching rule,
>innapropriateMatching is returned in the resultCode.
>
>Section 4.5.1 is clear that Undefined is the result of no equality
>match.
>
>So the question is: in the absence of an equality rule, is compare
>supposed to return compareFalse, or innapropriateMatching?

inappropriateMatcing.  A key difference between the compare
AVA and search AVA (in filters) processing is that compare
returns an indication of why the AVA is Undefined.

In terms of the 3-value logic, the result of the AVA is
Undefined.  In terms of the LDAP resultCode, an Undefined
AVA results in an error code which indicates why the AVA
is Undefined.

>X.501 is pretty lame on this one:
>
>"The purported argument identifies the attribute type and value to be
>compared with that in the entry. The comparison is TRUE if the entry
>holds the purported attribute type or one of its subtypes, or there is a
>collective attribute of the entry which is the purported attribute type
>or one of its subtypes (see 7.6), and if there is a value of that
>attribute which matches the purported value using the attribute's
>equality matching rule."
>
>It doesn't offer guidance when there is no equality matching rule.
>Later it says:
>
>"The matched result parameter, holds the result of the comparison. The
>parameter takes the value TRUE if the values were compared and matched,
>and FALSE if they did not."
>
>and again in the access control instructions:
>
>"If there exists a value within the attribute being compared that
>matches the purported argument and for which Compare permission is
>granted, the operation returns the value TRUE in the matched result
>parameter of the CompareResult. Otherwise, the operation returns the
>value FALSE."
>
>This can be read to say that if anything prevented the values to match
>while comparing, the answer is FALSE. But I doubt that was the intent.
>
>Jim