Re: Protocol: Compare contradiction

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

At 10:39 AM 4/20/2004, Hallvard B Furuseth wrote:
>Kurt D. Zeilenga writes:
>>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.
>
>OK, but then it must still be specified somewhere that the AVA is True
>if at least one of the matches of one of the values evaluate to True, or
>however that should be worded.

Yes.  The current language in [Protocol-23] is misleading:
> ava:  holds the attribute description and assertion value with
>      which an attribute in the entry is to be compared.

This should simply be:
  ava: holds the attribute value assertion to be evaluated.

And then briefly describe that the AVA is TRUE if the
entry contains (per the equality matching rule of the
attribute type in the assertion), the assertion value in the
attribute, or its subtype, named in the description.

>And the equivalent appropriate language for False.

Yes.  I'll offer some replacement text in a bit.  I want
to digest the rest of [Protocol-22] first.

>I no longer know if that belongs in [Models] or [Protocol],
>though.

I think it's mostly a [Protocol] issue.

>>> (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 suppose so.  I do wonder if it will just introduce confusion, by
>having "AVA" mean different "actions" and not just different reasons to
>specify an <attribute description, value> combination.

My point is that the request is providing a single
AttributeValueAssertion and the response a single
result code.  Now, depending on context, an
AttributeValueAssertion doesn't necessarily represent
an Attribute Value Assertion [Models].  [Protocol]
needs to be clear as to semantics in each context.

>> 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).
>
>I don't understand.  If the client was not authorized, the server should
>return some other code than compare<False/True>, it should not lie about
>knowing the result.

I don't think I implied that the server should lie, though I
certainly do think servers may refuse to disclose what
the AVA evaluated to (for instance, if it only determined
the value as nondisclosurable after evaluating the AVA).

My point here is that, to the client, the AVA is Undefined
if any result code other than compareTrue or compareFalse
is returned, whether because the AVA wasn't evaluated,
evaluated to Undefined, or was evaluated but whoses
outcome was not disclosed.

>> 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).
>
>Sounds good.  I hope it survives the <undefined match> things -
>e.g. that I turn out to be wrong about that:-)

I think we need to be careful.  We're not always referring
to same Undefined things.


>>>>         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".
>
>[Syntaxes] 4.1 (General Considerations):
>
>   A matching rule
>   evaluates to TRUE, and in some cases Undefined, as specified in the
>   description of the matching rule, otherwise it evaluates to FALSE.

While AVA evaluation involves matching rule evaluation(s),
an Undefined matching rule evaluation doesn't necessarily
imply an Undefined AVA evaluation.

>Though the same paragraph also says
>
>   The conditions under which an AttributeValueAssertion or
>   MatchingRuleAssertion evaluates to Undefined are specified in [PROT].
>
>so I suppose [Prot] is free to define that if the matching rule
>evaluates to Undefined, the AVA evaluates to False, or something.  Is
>that what is happening?

I think your (and possible the documents) are confusing evaluation
of an AVA as a whole and evaluation(s) of the associated rule.

>I'm suddenly very confused, I thought these
>were the same values.  I'll have to study your X.500 references when I
>get time.
>
>Or perhaps you can clarify with a practical example:
>
>Which result code should the Compare operation return - and why? - for
>comparing AVA "cn=foo" with a "cn" attribute containing one valid UTF-8
>string which fails the Prohibit step of Strprep?

Well, certainly the caseIgnoreMatch(foo, bogus) will be Undefined.
Per X.501 though, the AVA (cn=foo) is FALSE.  But, I note, the
AVA (cn=bogus) would be Undefined (where bogus is some value
which fails stringprep).

Kurt