Subject: RE: NOT filter question

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 01 Sep 2004 08:46:25 -0700

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: "Ramsay, Ron" <[email-masked]>
Date: Fri, 3 Sep 2004 12:31:29 +1000

X.511 (02/2001) 7.8.2

"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. An assertion which is
defined by these conditions and relates to the presence of an attribute type evaluates to FALSE."

Ron

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Friday, 3 September 2004 03:12
To: Ramsay, Ron
Cc: John McMeeking; [email-masked]
Subject: RE: NOT filter question

At 06:14 PM 9/1/2004, Ramsay, Ron wrote:
>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: "Ramsay, Ron" <[email-masked]>
Date: Fri, 3 Sep 2004 13:39:26 +1000

This construct will give the result intended in X.500.

-----Original Message-----
From: Jim Sermersheim [mailto:[email-masked]]
Sent: Friday, 3 September 2004 01:06
To: Ramsay, Ron; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: NOT filter question

(&(height=*)(!(height<6))) works to weed out all height-impared people
with all versions

>>> "Ramsay, Ron" <[email-masked]> 9/1/04 7:14:44 PM >>>

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

CN is (presumed) known.

>3) the value does not conform to the data type indicated by the syntax
of the assertion of the attribute's

I would hope so.

Kurt

---

From: "Ramsay, Ron" <[email-masked]>
Date: Mon, 6 Sep 2004 11:36:17 +1000

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:[email-masked]]
Sent: Sunday, 5 September 2004 02:37
To: Ramsay, Ron
Cc: John McMeeking; [email-masked]
Subject: RE: NOT filter question

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

>>3) the value does not conform to the data type indicated by the syntax of the assertion of the attribute's
>>equality matching rule;
>

---

From: "Ramsay, Ron" <[email-masked]>
Date: Mon, 6 Sep 2004 11:44:22 +1000

Kurt,

I think I must differ from you here.

Firstly, AVA evaluation is misleading as, for example, a compare request can return an attribute error. Therefore, there is no need in a section on AVA evaluation to mention the case where the attribute is not present in the entry. The appropriate place is in X.511 under filter evaluation.

Secondly, the new text on the 2000 edition relating to filters seems to be a clarification and so must be taken into account when reading the 1993 edition.

I admit that most LDAP servers behave as you say, but this would be because one server did originally. If you want all LDAP servers to behave like this to be conformant, then you are going to have to put specific words to this effect in the protocol document. I don't think X.500, 1993 or otherwise, supports your arguments. (I note that one X.500/LDAP server conformas to X.511.)

Ron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Kurt D. Zeilenga
Sent: Sunday, 5 September 2004 02:52
To: John McMeeking
Cc: [email-masked]
Subject: RE: NOT filter question

At 09:49 AM 9/2/2004, John McMeeking wrote:
>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.

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

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

>Some disagreement on the correct behavior has been expressed in these notes
>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
>agreement that current practice is (cn=bob) evaluates to FALSE if there is
>no cn attribute in the entry.

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

>John  McMeeking
>
>
>"Kurt D. Zeilenga" <[email-masked]> wrote on 09/01/2004 09:37:16 PM:
>
>> Well, since we reference X.500(1993), we can and should
>> ignore the change. -- Kurt
>>