Subject: RE: NOT filter question

From: "Ramsay, Ron" <[email-masked]>
Date: Thu, 2 Sep 2004 11:14:44 +1000

It was changed in X.500:2000.

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

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.

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!

Ron

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Thursday, 2 September 2004 01:46
To: Ramsay, Ron
Cc: John McMeeking; [email-masked]
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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 01 Sep 2004 19:37:16 -0700

>It was changed in X.500:2000.

Well, since we reference X.500(1993), we can and should
ignore the change. -- Kurt

---

From: John McMeeking <[email-masked]>
Date: Thu, 2 Sep 2004 11:49:39 -0500

Is this something that should be clarified in the LDAP standards?

It seems like this is an area where, arguably, we are departing from X.500.
The 1993 edition is unclear to me on this matter and the position that an
assertion about an attributetype that is not contained in the entry is
FALSE seems to be based on the X.501 and X.511 text not mentioning the
case.  Later editions appear to address this case, which seems to be a
clarification rather than a change.

Some disagreement on the correct behavior has been expressed in these notes
and past discussions I found in the archives.  There does seem to be
agreement that current practice is (cn=bob) evaluates to FALSE if there is
no cn attribute in the entry.

Should we state the correct LDAP behavior.  Perhaps add something like the
following to [protocol] 4.5.1 following the paragraph beginning "The
present match evalates to TRUE...":

"For filter elements other than present match, if no value of the specified
attribute description is present in the entry, the filter element evaluates
to FALSE."

The text about what consitutes an undefined filter element might need to be
moved up as well.

And if the concensus goes the other way (the issue doesn't seem quite
settled yet), add the corresponding note instead:

"For filter elements other than present match, if no value of the specified
attribute description is present in the entry, the filter element evaluates
to UNDEFINED."

John  McMeeking

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 02 Sep 2004 10:12:06 -0700

>It was changed in X.500:2000. 

I have not been able to locate this change in X.500(2000).
I see a clarification regarding attribute type assertion
evaluations, but I see no like change (or clarification)
regarding attribute value assertions.  As far as I can
tell, the AVA evaluation semantics are the same (ignoring
the new attribute context features).  Can you point out
the precise text which you believe changed semantics
between X.500(1993) and X.500(2000)?

Thanks, Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 04 Sep 2004 09:36:30 -0700

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

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

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 04 Sep 2004 09:51:49 -0700

>Is this something that should be clarified in the LDAP standards?

IMO, yes.  We should make it clear in [Protocol] that AVA evaluation
is a specified in X.501(1993), providing a summary of these
semantics.

>clarification rather than a change.

I think X.501(1993) is quite clear.  We have not, and should not,
depart from X.501(1993).  [Protocol] should make this clear.

>and past discussions I found in the archives.

I don't think there is any argument as to the behavior X.501(1993)
specifies, nor any argument that LDAP servers are to act in
accordance with X.501(1993) in this regard.

>There does seem to be

I agree that implementations seems to have gotten it right
(right as defined by the applicable technical specifications).

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 6 Sep 2004 01:50:17 +0200

> is a specified in X.501(1993), providing a summary of these

Do X.500/LDAP servers stay with 1993 semantics when accessed through
LDAP?  If not, a warning to client implementors and maybe an example
might be in order.  E.g. using (!(&(player=cn=Ron)(player=*))) instead
of (!(player=cn=Ron)), unless I've missed something.

-- 
Hallvard