Subject: Protocol: Compare contradiction

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 16 Apr 2004 19:44:38 -0600

The current protocol draft (in my editor) contradicts itself by stating
that the result of a compare will be compareFalse when the asserted
value doesn't match any attribute values or is Undefined (and refers to
Section 4.5.1). 

Then it says if the attribute or subtype has no equality matching rule,
innapropriateMatching is returned in the resultCode.

Section 4.5.1 is clear that Undefined is the result of no equality
match.

So the question is: in the absence of an equality rule, is compare
supposed to return compareFalse, or innapropriateMatching?

X.501 is pretty lame on this one:

"The purported argument identifies the attribute type and value to be
compared with that in the entry. The comparison is TRUE if the entry
holds the purported attribute type or one of its subtypes, or there is a
collective attribute of the entry which is the purported attribute type
or one of its subtypes (see 7.6), and if there is a value of that
attribute which matches the purported value using the attribute's
equality matching rule."

It doesn't offer guidance when there is no equality matching rule.
Later it says:

"The matched result parameter, holds the result of the comparison. The
parameter takes the value TRUE if the values were compared and matched,
and FALSE if they did not."

and again in the access control instructions:

"If there exists a value within the attribute being compared that
matches the purported argument and for which Compare permission is
granted, the operation returns the value TRUE in the matched result
parameter of the CompareResult. Otherwise, the operation returns the
value FALSE."

This can be read to say that if anything prevented the values to match
while comparing, the answer is FALSE. But I doubt that was the intent.

Jim

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sat, 17 Apr 2004 20:17:51 +0200

> supposed to return compareFalse, or innapropriateMatching?

The Search operation (4.5.1) has a good reason to not return an error in
this case: It supports complex filters and can return several entries.
It's useful that a problem in one filter component, or in one entry,
does not prevent the operation from returning the entries that do match
the rest of the filter.  If the attribute has no equality matching rule,
that might be because the server does not support the equality rule
which the attribute needs, but the server admin still wanted to support
the attribute.  E.g. labeledURI on a server without caseExactMatch.

I don't see any similar reasons that hold for the Compare operation.
So I think inappropriateMatching is the best result code to return.

OTOH, I have no idea if that breaks some clients, or is incompatible
with X.500.  Maybe you should ask an X.500 forum what X.500 servers do.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 19 Apr 2004 13:49:53 -0700

>supposed to return compareFalse, or innapropriateMatching?

inappropriateMatcing.  A key difference between the compare
AVA and search AVA (in filters) processing is that compare
returns an indication of why the AVA is Undefined.

In terms of the 3-value logic, the result of the AVA is
Undefined.  In terms of the LDAP resultCode, an Undefined
AVA results in an error code which indicates why the AVA
is Undefined.