Re: Protocol: Compare contradiction

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 07:40 AM 4/20/2004, Hallvard B Furuseth wrote:
>Kurt D. Zeilenga writes:
>>At 03:13 PM 4/19/2004, Jim Sermersheim wrote:
>>> I'm thinking it might be best to state that if the compare cannot
>>> resolve to a true or false state an appropriate result code is
>>> returned.
>> 
>> I suggest saying something like:
>>         The compareTrue resultCode indicates the AVA is True.
>
>s/the AVA/at least one AVA/.

The Compare operation only requests one AVA be evaluated.
Performance of that assertion might involve evaluation of a
rule for multiple attributes, and multiple values of that
attribute, but that's all part of a single AVA.

>(BTW, is it correct to say that the AVA "is" True?  Or should
>it be "evaluated to" True?)

I think it is at least proper to say "is" True.  Obviously, for
an assertion to be true, that assertion must have been "evaluated".

I use "indicates" as, for codes indicating the AVA is Undefined,
could be because the AVA itself was not actually evaluated (for
instance, because the client was not authorized to use the
compare operation on the target entry).

Note that I purposely turned the text around so that it
didn't prescribe server behavior (which code should return
when), but described the semantics of the information
exchanged (this code means this).

>>         The compareFalse resultCode indicates that the AVA is False.
>
>s/the AVA is False/there is one or more AVA, and they are all False/.
>Except...

See above.

>>         All other resultCodes indicate the AVA is Undefined
>>         (see A.2 for a description of these other result codes).
>
>What if there is no error (or at least none covered by the available
>result codes), but the matching rule simply evaluated to Undefined?

Don't know what you mean by "simply evaluates to Undefined".
An AVA evaluates to Undefined on three conditions:
        attribute type was unrecognized
        attribute type was has no equality rule
        assertion value is Undefined.

Otherwise, the rule evaluates to True or False.  However,
the rule may not be evaluated for a number of other reasons,
and in these cases, the AVA is also said to be Undefined
as it has not been evaluated.  Now, maybe the last sentence
should be:

        The undefinedAttributeType result code indicates the
        AVA is Undefined due to the asserted attribute
        description being unrecognized.

        The inappropriateMatching result code indicates the
        AVA is Undefined due to attribute type of the asserted
        attribute description not having an equality matching
        rule.

        The invalidSyntax result code indicates the AVA is
        Undefined as the asserted value does not valid
        per the syntax of the assertion value.

        All other result codes indicate an exception
        condition and generally imply that the assertion
        was not evaluated (or that the result of the
        evaluation is undisclosed).     
        

>I don't see what else than compareFalse can be returned.

Can you come up with an equality rule (see X.501 for requirements
of equality rules) for which Undefined is not an exceptional
condition.

(Note: a rule which always evaluates to Undefined does so
not on exception, but such a rule cannot be an equality rule).

>> and then avoid reinterating information about these other
>> resultCodes in this section.
>
>Good, unless pulling Undefined into compareFalse makes it less
>clear what is an error...

No.  An Undefined (in the X.501 sense) AVA is not to be reported
as compareFalse.