Subject: Re: Protocol: Compare contradiction

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 19 Apr 2004 16:13:28 -0600

That's certainly not the way the current draft is worded. Currently
Undefined == compareFalse. If the Working Group believes it's correct to
specify error behavior for all Undefined cases, I need to refactor that
part of the doc. I assume the following attribute and value-related
conditions can cause this state:
 
- The asserted attribute or subtype is not present in the named entry
- The asserted attribute is unknown
- There is no equality matching rule for the attribute or subtype
- There is a constraint violation with the asserted value
- There is a syntax violation with the asserted value
 
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.
 
Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 4/19/04 2:49:53 PM >>>
At 06:44 PM 4/16/2004, Jim Sermersheim wrote:
>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?

inappropriateMatcing. A key difference between the compare
AVA and search AVA (in filters) processing is that compare
returns an indication of why the AVA is Undefined.

In terms of the 3-value logic, the result of the AVA is
Undefined. In terms of the LDAP resultCode, an Undefined
AVA results in an error code which indicates why the AVA
is Undefined.

>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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 19 Apr 2004 15:40:50 -0700

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.
        The compareFalse resultCode indicates that the AVA is False.
        All other resultCodes indicate the AVA is Undefined
        (see A.2 for a description of these other result codes).

and then avoid reinterating information about these other
resultCodes in this section.

- Kurt

>>The current protocol draft (in my editor) contradicts itself by stating
>>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,
>>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
>>"The matched result parameter, holds the result of the comparison. The
>>parameter takes the value TRUE if the values were compared and matched,
>>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

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 20 Apr 2004 16:40:23 +0200

>         The compareTrue resultCode indicates the AVA is True.

s/the AVA/at least one AVA/.

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

>         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 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?
I don't see what else than compareFalse can be returned.

> resultCodes in this section.

Good, unless pulling Undefined into compareFalse makes it less
clear what is an error...

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 20 Apr 2004 08:45:50 -0700

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

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

>s/the AVA is False/there is one or more AVA, and they are all False/.

See above.

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

>clear what is an error...

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

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 20 Apr 2004 19:39:23 +0200

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

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

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

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

> 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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 20 Apr 2004 12:24:06 -0700

At 10:39 AM 4/20/2004, Hallvard B Furuseth wrote:
>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.

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

>return some other code than compare<False/True>, it should not lie about

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.

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

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

>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

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