|
X.511 is fairly clear that if the compare operation was able to compare the attribute values with the assertion (attribute or subtype is present, and permissions allow), either TRUE or FALSE is used to indicate the result. TRUE is returned when the assertion matches any one of the attribute values, otherwise FALSE is returned.
Regarding the absense of an EQUALITY matching rule, I assume we use the equality rule in Section 2.3 of Models.
I will clarify along these lines.
Jim
>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 1/5/04 11:40:52 AM >>> At 01:07 AM 1/5/2004, Hallvard B Furuseth wrote: >Ramsay, Ron writes: >> By undefined, do you mean the attribute is unknown or not present >> in the entry? > >No, I mean the attribute is present in the entry and has an equality >matching rule, but that matching rule evaluates to Undefined when >comparing the attribute value with the assertion value. E.g. if >string preparation (draft-ietf-ldapbis-strprep-xx.txt) fails on the >attribute value or the assertion value. Any matching rule can evaluate to True, False, or Undefined. (So, this issue is not specific to ldapprep.) I agree that TS for compare should be a bit more clear here. It should say something like: The compareTrue result code is returned if and only if the assertion is TRUE. The compareFalse result code is returned if and only if the assertion is FALSE. If the assertion is Undefined or an error occurred, a result code indicating the nature of the problem is to be returned. >> -----Original Message----- >> From: owner-ietf-ldapbis@OpenLDAP.org >> [mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Hallvard B Furuseth >> (...) >> The Compare operation is under-specified. What is the result if: >> - The match evaluates to Undefined? >> - Match against one attribute value evaluates to FALSE and against >> another evaluates to TRUE or Undefined? >> (...) > >-- >Hallvard |