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

RE: protocol: compare operation

You seem to imply that X.500 can return BOTH an error code and 'matched'. I think it is only the English, but X.500 can either return an error OR return a result - matched or not-matched.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Wednesday, 7 January 2004 05:01
To: Jim Sermersheim
Cc: h.b.furuseth@usit.uio.no; Ramsay, Ron; ietf-ldapbis@OpenLDAP.org
Subject: 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