RE: NOT filter question

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

Just two points, Kurt.

1) This consideration needn't apply to the evaluation of AVAs since the appropriate response for a compare is to return an error (no such attribute).

2) The addition to the 2000 text may have simply been a clarification. This would therefore need to be taken into account when making judgments based on the 1993 version.

Ron

-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Sunday, 5 September 2004 02:37
To: Ramsay, Ron
Cc: John McMeeking; ietf-ldapbis@OpenLDAP.org
Subject: RE: NOT filter question


At 06:14 PM 9/1/2004, Ramsay, Ron wrote:
>It was changed in X.500:2000.

Thanks for pointing out the precise text.
  An assertion which is defined by these conditions additionally
  evaluates to UNDEFINED if it relates to an attribute value
  and the attribute type is not present in an attribute against
  which the assertion is being tested.

(I find it a bit odd that this was added to X.511(2000), yet
X.501(2000) discussion of AVA evaluation remains consistent
with prior versions (notable, X.501(1993)).  As specified,
this text seems to only applies to DAP search filter items
and not AVA evaluation in general.)

>Just on a side note, it doesn't make sense to return TRUE.

I agree that its a side note, I disagree that it makes sense to
return TRUE (see my counter example).  I also feel that it is
generally ill-advised to make these kinds of changes (fundamental
changes to well-established semantics).

>Consider the filter: !(height<5)
>
>If there is no height attribute, this, according to you, should evaluate to true. But this implies that height >= 5.

According to X.501(2000), yes, the evaluation of an AVA where
the attribute does not exist is False and, hence, the negation
of that AVA would be True.   I disagree that (!(height<5))
(ignoring the invalidity of '<') is equivalent to (height>=5),
as per the well defined semantics of AVAs, both (height<5)
and (height>=5) can be False (certainly (per X.501) for a entry
not containing a height attribute, but also "otherwise"
(per X.501)).

>Say you were forming a volleyball team and you searched you company's directory for all employees at least 6' high. You then invite them to join a team. On the first day of training you turn up and they're all midgets!

counter example, consider (!(player=cn=Ron))
(where player is an multi-valued attribute of DN syntax
and has a distinguishedNameMatch equality rule)

If no player attribute, then per X.501(1993), (player=cn=Ron) is
False and hence (!(player=cn=Ron)) is True.  That is, the
evaluation indicates that cn=Ron is not on the volleyball team.
But in X.500(2000), as you indicate, (player=cn=Ron) is Undefined
if player is not present in the entry, hence (!(player=cn=Ron))
evaluates to Undefined, hence is treated as False.  That is,
the evaluation (under X.511(2000)) would indicate that cn=Ron
is on the volleyball team.  Yiks!

Kurt

>Ron
>
>-----Original Message-----
>From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
>Sent: Thursday, 2 September 2004 01:46
>To: Ramsay, Ron
>Cc: John McMeeking; ietf-ldapbis@OpenLDAP.org
>Subject: RE: NOT filter question
>
>
>X.501(93), 8.7.3:
>>An AVA is:
>>a) undefined, if any of the following hold:
>>1) the attribute type is unknown,
>
>CN is (presumed) known.
>
>>2) the attribute type has no equality matching rule,
>
>CN has an equality matching rule.
>
>>3) the value does not conform to the data type indicated by the syntax of the assertion of the attribute's
>>equality matching rule;
>
>"bob" conforms to assertion syntax.
>
>>b) true, if the entry contains an attribute of that type, one of whose values matches that value;
>
>The entry doesn't contain CN.
>
>>c) false, otherwise.
>
>(CN=bob) is False.  (!(CN=bob)) is True.
>
>
>At 07:18 PM 8/31/2004, Ramsay, Ron wrote:
>>Many (most?) LDAP servers evaluate it to true.
>
>I would hope so.
>
>Kurt