|
Right, I'm not arguing that we shouldn't allow values other than comperTrue or compareFalse. In fact the draft already points out the scenarios that can cause an attribute error (or security error) just as X.511 does. X.511 does not mention the possibility of innapropriateMatching being returned.
It seems to me that X.511 is underspecified. Are there multiple implementations that return innapropriateMatching when the attribute in the AVA has no equality match rule?
Jim
>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 1/6/04 11:01:22 AM >>> At 09:36 AM 1/6/2004, Jim Sermersheim wrote: >If we are to follow X.511, I argue that compareFalse should be returned when the comparison is undefined due to the lack of a matching rule. X.511 has separate compareResult.matched from the result code. When an attribute error occurs, the DSA is required to indicate so by returning AttributeError. It also indicates the entry did not match by returning FALSE for compareResult.matched. LDAP differs from X.511 in that it has no compareResult.matched field. Hence, the client must infer that the entry did not match when an AttributeError is returned. It is crucial that we do not change the semantics of the compare operation. Clients need some mechanism, as they do in X.511 (presence of an error), to distinguish Undefined from FALSE. Kurt > >Jim > >>>> Hallvard B Furuseth < h.b.furuseth@usit.uio.no > 1/6/04 2:59:28 AM >>> >Jim Sermersheim writes: >> Regarding the absense of an EQUALITY matching rule, I assume we use the >> equality rule in Section 2.3 of Models. > >I don't think so. I think Compare should behave like Search and not >know how to compare the values. I'm not quite sure which result >code fits best, though. inappropriateMatching doesn't quite seem to >fit what was said in the thread about that result code. > >-- >Hallvard |