[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Protocol: Compare contradiction

That's certainly not the way the current draft is worded. Currently Undefined == compareFalse. If the Working Group believes it's correct to specify error behavior for all Undefined cases, I need to refactor that part of the doc. I assume the following attribute and value-related conditions can cause this state:
- The asserted attribute or subtype is not present in the named entry
- The asserted attribute is unknown
- There is no equality matching rule for the attribute or subtype
- There is a constraint violation with the asserted value
- There is a syntax violation with the asserted value
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.

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