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

RE: protocol: compare operation



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