Re: Protocol: Compare contradiction

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

At 03:13 PM 4/19/2004, Jim Sermersheim wrote:
>I'm thinking it might be best to state that if the compare cannot resolve to a true or false state an appropriate result code is returned.

I suggest saying something like:
        The compareTrue resultCode indicates the AVA is True.
        The compareFalse resultCode indicates that the AVA is False.
        All other resultCodes indicate the AVA is Undefined
        (see A.2 for a description of these other result codes).

and then avoid reinterating information about these other
resultCodes in this section.

- Kurt


> 
>Jim
>
>>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 4/19/04 2:49:53 PM >>>
>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