RE: compare result codes

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

comments below...

> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]

> I've been reviewing the BLITS compare tests and had a couple
> of questions regarding the proper result code to return
> upon certain conditions:

> 1) unknown attribute type
> 2) compare known attribute type without defined equality matching rule
> 3) not present attribute type with asserted value of invalid syntax
> 4) not present attribute type with asserted value of valid syntax
> 5) present attribute type with asserted value of invalid syntax
> 6) present attribute type with asserted value of valid syntax
>    and attribute without asserted value
> 7) present attribute with asserted value of valid syntax
>    and attribute with value

> What result code is appropriate for each case?

> Here are my initial thoughts:

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

> 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. Now this is really splitting
hairs here but we don't include this as an error for search either.

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. 

> 6) compareFalse
> 7) compareTrue

> This usage is fairly consistent with X.511, 12.4.
>   "An attributeError reports an attribute-related problem."

>    a)	noSuchAttributeOrValue - The named entry lacks one of the
> 	attributes or attribute values specified as an argument
> 	of the operation.
>    b)	invalidAttributeSyntax - A purported attribute value, specified
> 	as an argument of the operation, does not conform to the attribute
> 	syntax of the attribute type.
>    c)	undefinedAttributeType - An undefined attribute type was provided
> 	as an argument to the operation. This error may occur only in
> 	relation to addEntry or modifyEntry operations.
>    d)	inappropriateMatching - An attempt was made, e.g. in a filter,
> 	to use a matching rule not defined for the attribute type concerned.


> excepting that c) specifically says the error may only occur in
> relation to addEntry or modifyEntry operations.  Now, one could
> return noSuchAttribute(OrValue), but this seems inappropriate
> as it implies able to determine the entry doesn't contain the
> attribute type... which implies the attribute type is defined...
> which it isn't.
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). 

It would be nice, though, to know if the attribute is even defined -- for
example if I have made a mistake typing the attribute name it would be nice
to get a more specific error than noSuchAttribute (especially since I could
also be using a common attribute alias that the server simply isn't aware
of). However, since X.511 is so very explicit in the case of
undefinedAttributeType I'm not sure we should change this behaviour. I think
we've restricted changes in our document to result codes where there are
ambiguities or conflicting uses (as in the case of operationsError). 

> Maybe a clarification to X.511 is in order to either:
> 	A) change c) above to allow return by compare
> 	B) clarifiy which result codes should be returned
> 	in the cases listed above.

> Maybe this could be done for LDAP in the rescodes I-D.
The LDAP rescodes doc already has some examples for compare but it is
missing some of the examples that you have provided above, I think these
should be added. 
-Kristianne

> Kurt