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