Re: Protocol: Compare contradiction

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

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.  And the equivalent appropriate language
for False.  I no longer know if that belongs in [Models] or [Protocol],
though.

>> (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.

> 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.

> 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:-)

>>>         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.

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'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?

-- 
Hallvard