RE: compare result codes

[Kristianne Leclair <kristianne.leclair@entrust.com>]

-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Friday, June 23, 2000 6:18 PM
To: Kristianne Leclair
Cc: ietf-ldapext@netscape.com
Subject: RE: compare result codes


At 11:02 AM 6/21/00 -0400, Kristianne Leclair wrote:
>>> 1) undefinedAttributeType
>>> 2) inappropriateMatching
>>Agreed. Currently the rescodes doc doesn't have this listed as a possible
>>error for compare. This will have to be updated.

>It's X.511 that actually needs updating.... or we need to
>do something about that MUST X.511 in RFC 2251.
I see nothing in X.511 that prevents inappropriateMatching as a possible
result code for the compare operation -- this was simply an oversight on our
part. 

The other two errors discussed below are, I believe, a different matter. If
there is a general consensus on the list that LDAP should return these
results under the circumstances described then we can add them to the
rescodes draft. If there is a suggestion to add something that differs from
X.511 though, it might be a good idea to raise a defect report against X.511
as well.


>>> 3) noSuchAttribute (syntax not relevant in this case)
>>> 4) noSuchAttribute
>>> 5) invalidAttributeSyntax
>>I'm not sure whether this would be invalidAttributeSyntax, I would have
said
>>compareFalse.  It depends on exactly how you read the definition of
>>invalidAttributeSyntax; the key phrase is 'specified as an argument of the
>>operation'. The only operations where the attribute value is specifically
an
>>argument of the operation are Add and Modify.

>I feel it should apply to value of an attribute value assertion which
>is an argument to a compare operation.  
>>Now this is really splitting
>>hairs here but we don't include this as an error for search either.

>Guess you could split hairs over whether or not the value of an
>attribute value assertion is an attribute value or not... but I
>rather just clarify X.511 (and hence LDAPv3) that this result
>code can (and should) be returned in this case.

>>When a search filter is evaluated the attribute must be known and the
value
>>must conform to the syntax for the attribute. If both conditions are not
met
>>the filter is undefined and evaluates to false -- no error is returned if
>>the attribute syntax is incorrect. 

>Yes, but a compare, unlike search, should return an error instead
>of applying three value logic to the assertion. 


>>As I see it, the compare operation simply answers the question 'does the
>>entry contain an attribute with this name and this value?', I don't think
it
>>matters whether the attribute is defined or not (I guess this really
depends
>>on how the server goes about checking this though). 

>As I see it, compare provides key functional that cannot be
>mimiced with search.  In particular, compare returns the reason
>the assertion, if used in a search filter, would be undefined.

>Kurt