RE: Filter Items and Absent Attributes

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

Steven,

I believe the X.500 take is, can the question foo=bar be answered. If the
entry doesn't contain the attribute foo, the question cannot be answered.

The entry may not contain the attribute because, possibly, the attribute is
optional or not allowed by schema. The question cannot be answered. It is a
bit metaphysical to refer to the collection of all possible answers, the
practical approach is not to try to answer the question.

If I try to find everyone with a shoe size of 12, and Bob doesn't have a
shoe size attribute in his entry, shoudl I return Bob's entry? You say no
and I fail to be convinced. The only time 'no' is appropriate is if Bob's
shoe size has actually been entered into the directory. You can't say that
Bob doesn't have a shoe size just because it is not in his entry, you can
only say "don't know."

Ron. 

-----Original Message-----
From: Steven Legg [mailto:steven.legg@adacel.com.au]
Sent: Wednesday, 27 February 2002 16:49
To: Ramsay, Ron
Cc: ietf-ldapbis@OpenLDAP.org
Subject: RE: Filter Items and Absent Attributes



Ron,

Ramsay, Ron wrote:
> Our implementation treats it as UNDEFINED.
> 
> It is counter-intuitive only in the same way that all logic 
> assertions seem
> to defy logic. For example, an empty AND is TRUE.
> 
> The logic must be: Can I evaluate givenName=Bob if there is 
> no givenName
> attribute? The answer clearly is NO. Therefore, the assertion 
> is UNDEFINED.

What is "clear" critically depends on how one models the entry contents
and how one interprets the meaning of the assertions. I could model an
entry's contents as a set of (type, value) tuples and the assertion
(givenName=Bob) as the question "does the entry contain the tuple
(givenName, Bob)?" If the givenName attribute is absent then the
assertion is "clearly" FALSE. Such an interpretation is more in keeping
with LDAP, where no distinction is drawn between adding an attribute
and adding attribute values.

Given that there are multi-valued attributes and attribute subtyping,
we have a situation where the absence of an attribute could be
interpreted two ways:

(1) The value(s) of the attribute for the entity represented by the entry
are not known.

(2) There are no values of the attribute for the entity represented
by the entry.

For example, the absence of the telephoneNumber attribute could mean
that the telephone numbers for the entity are not known, or it could
mean that the entity doesn't have a phone (and hence no phone numbers).

The X.500 model doesn't provide us with a way to distinguish between
these two cases.

For the sake of argument, let us suppose that we can provide a mark for
each attribute type, whether the attribute is present or not, to indicate
whether the existing set of values (possibly empty) is complete (all values
are known) or incomplete (there may be other unknown values).

Case (1) above corresponds to an incomplete attribute with an empty
set of values. Case (2) corresponds to a complete attribute with an
empty set of values. There are two more cases: an incomplete attribute
with a non-empty set of values, and a complete attribute with a non-empty
set of values.

In reality, we don't have these complete/incomplete markers, so what we
are really talking about is whether we are to assume that an attribute is
complete or incomplete, in the absence of such indicators.

The 4th edition of X.511 treats an absent attribute as incomplete and a
present attribute as complete, which strikes me as inconsistent and
leads to some weird outcomes. Why should it be that if I add one known
value to a multi-valued attribute, it can suddenly mean that there are
no other unknown values ? Or the converse, if I remove one known value,
that it can suddenly mean there are now some unknown values as well. For
example, if the telephoneNumber attribute in a particular entry has the
value "+61 3 9999 9999" and I ask for:

	(!(telephoneNumber=+61 3 8888 8888))

I will get the entry back in the search result. If the telephoneNumber
value "+61 3 9999 9999" is removed, the entry is no longer returned by
the search filter, though the status of the entry with respect to the
particular value "+61 3 8888 8888" hasn't changed.

There are two consistent treatments: either assume every attribute
(whether or not it is empty/absent) is complete, or assume every
attribute is incomplete. The former implies that a filter item evaluates
to FALSE if the attribute is not present. The latter implies that filter
items evaluate to TRUE or UNDEFINED (never FALSE) for multi-valued
attributes that are present. My expectation is that most users will
unconsciously assume the former.

Both of the consistent treatments have the property that adding or
removing an unrelated value doesn't alter the outcome of a search.

Regards,
Steven

> The assertion !(givenName=Bob) is therefore also UNDEFINED. 
> This is logical.
> 
> I think you have been trying to apply heuristics. That is a 
> choice, but then
> logic cannot be your guide.
> 
> Ron.
> 
> -----Original Message-----
> From: Steven Legg [mailto:steven.legg@adacel.com.au]
> Sent: Tuesday, 26 February 2002 15:08
> To: ietf-ldapbis@OpenLDAP.org
> Subject: Filter Items and Absent Attributes
> 
> 
> 
> Folks,
> 
> A statement that is in the 4th edition of X.511, but not in the 2nd
> edition, was recently brought to my attention. I found it surprising.
> I suspect I not the only one.
> 
> In X.511:2001, Clause 7.8.2:
> 
>   "An assertion" ... "evaluates to UNDEFINED if it relates to 
> an attribute
>    value and the attribute type is not present in an" [ entry 
> ] "against
>    which the assertion is being tested."
> 
> This means, for example, that a filter item like 
> (givenName=Bob) evaluates
> to UNDEFINED, rather than FALSE, if an entry doesn't have the 
> givenName
> attribute. This affects how negated filter items are evaluated.
> For example, the filter (!(givenName=Bob)) only returns entries
> that have the givenName attribute, but not the givenName value "Bob".
> The entries that don't have the givenName attribute are not returned
> (giving the impression that they *do* have "Bob" as a givenName).
> 
> Apparently this behaviour was the original intention in the 
> 2nd edition
> of X.511 as well. It just wasn't explained properly.
> 
> Personally, I think returning UNDEFINED instead of FALSE would be
> counter-intuitive to most users, and therefore a bad idea.
> 
> Does anyone's server implementation evaluate filter items to UNDEFINED
> instead of FALSE when the attribute doesn't exist (obviously mine
> doesn't) ? The answer determines how I apply access controls 
> to searches
> in my I-D on X.500 Basic Access Control for LDAP. The current 
> specification
> is based on the assumption that everyone else is returning FALSE too.
> 
> If that is the case then we have to decide whether we want to define
> LDAP searches to behave exactly like X.500 searches (and change our
> implementations), or explicitly specify that LDAP behaves differently,
> or influence the X.500 working group to change X.511.
> 
> Regards,
> Steven
>