Re: Protocol: Compare contradiction

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Jim Sermersheim writes:
> 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?

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