Subject: compare result codes

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 16 Jun 2000 09:23:45 -0700

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
3) noSuchAttribute (syntax not relevant in this case)
4) noSuchAttribute
5) invalidAttributeSyntax
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.

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.

Kurt

---

From: Kristianne Leclair <[email-masked]>
Date: Wed, 21 Jun 2000 11:02:51 -0400

comments below...

> From: Kurt D. Zeilenga [mailto:[email-masked]]

> 1) undefinedAttributeType
Agreed. Currently the rescodes doc doesn't have this listed as a possible
error for compare. This will have to be updated.

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

> attribute type... which implies the attribute type is defined...
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 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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 23 Jun 2000 15:17:34 -0700

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

>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

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.

>the attribute syntax is incorrect. 

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

>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

---

From: Kristianne Leclair <[email-masked]>
Date: Mon, 26 Jun 2000 14:17:42 -0400

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Friday, June 23, 2000 6:18 PM
To: Kristianne Leclair
Cc: [email-masked]
Subject: RE: compare result codes

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