RE: protocol: compare operation

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

If there is an equality matching rule, I don't see how the result of applying it can be undefined. I don't think you should should encourage anyone in this kind of thinking. The result should be matched or not-matched.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Wednesday, 7 January 2004 11:36
To: Ramsay, Ron
Cc: ietf-ldapbis@OpenLDAP.org
Subject: RE: protocol: compare operation


At 03:21 PM 1/6/2004, Ramsay, Ron wrote:
>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.

I could have easily mis-read X.511.  I don't have a copy
of X.880 (or whatever defines OPERATION).  I was relying on:
 Should the request succeed (i.e. the comparison is actually
 carried out), the result shall be returned.

The comparison cannot actually be carried out if there is no
EQUALITY matching rule.
   Should the request fail, one of the listed errors shall be reported.
   The circumstances under which the particular errors shall be reported
   are defined in clause 12.
 
Clause 12:
   d) inappropriateMatching - An attempt was made, e.g. in a filter,
   to use a matching rule not defined for the attribute type concerned.

The "e.g. in a filter" phrase is not limiting.  It's only an example.

Hence, I think X.511 is actually quite clear that
inappropriateMatching should be returned where a comparison
is request against an attribute which does not have a defined
EQUALITY matching rule.

Now, a more interesting question is what happens when no error
occurs (the attribute exists, no access control issues, the
matching rule is defined, etc.), the rule is carried out but
yields Undefined.  I can see it reasonable to argue that this
can and should be treated as FALSE.

Hence, I offer new text:
  The server should (if actually carried out the comparison)
  indicate the outcome of the comparison:
        compareTrue indicates TRUE
        compareFalse indicates FALSE or Undefined.

  If the server did not actually carry out the comparison, the
  server returns an appropriate error code indicating the nature
  of the problem.




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