Protocol: Compare contradiction

["Jim Sermersheim" <jimse@novell.com>]

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