Subject: Re: Evaluation of an unknown attribute description in a presence filter

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 18 May 2005 21:49:24 -0600

I've never understood why the presence filter item works this way. A quick browse of X.511 doesn't shed any light either.
 
I don't think I agree with your assertion that it should work differently depending on whether the numericoid versus the descr form of the attribute type is used. If that distinction were made for presence, shouldn't it also be made for other filter items as well? For example, it seems you argue that (2.5.616.123=jdoe) could evaluate to FALSE, while (bogusAttr=jdoe) would evaluate to UNDEFINED (where both are not known to the server's schema).

>>> Andrew Sciberras <[email-masked]> 5/16/05 7:03:06 PM >>>
Hi,

I would like to question the evaluation of presence filter items when 
the attribute type supplied is not recognized by the directory.

In RFC2251 the following text exists regarding the evaluation of a 
presence filter item:
"The present match evaluates to TRUE where there is an
attribute or subtype of the specified attribute description
present in an entry, and FALSE otherwise (including a
presence test with an unrecognized attribute description.)"

In the Protocol I-D, the following example exists in regards to the
evaluation of a presence Filter Item (Section 4.5.2):

"For example, if a server did not recognize the attribute type
shoeSize, a filter of (shoeSize=*) would evaluate to FALSE, ... "

I think that both the example and the RFC2251 statement are incorrect.

I'm of the opinion that if the filter item contained an OID
(Eg. 1.2.3.4.999=*) then the directory should be able to respond
definitively as to whether that attribute is present in any given entry.
However, if a filter item contains a short name (Eg. shoeSize=*) then it
must evaluate to Undefined. The server's inability to associate
"shoeSize" to an attribute type within its schema means that it is
ambiguous as to whether the attribute is present in any given entry. The
ambiguity is present, because the directory may be aware of the
attribute type by a different name.

In a more realistic example, lets say my directory contains the
following definition:

attributeTypes: ( 2.5.4.42 NAME 'givenName' SUP name
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

Lets also state that many "givenName" attributes exist in the directory.

I would think that correct behavior is:

Filter = (givenName=*)
The filter can be evaluated for each entry, since givenName is a known
attribute type. The appropriate results should be returned.

Filter = (2.5.4.42=*)
The filter can be evaluated for each entry, since 2.5.4.42 is a known
attribute type. The appropriate results should be returned.

Filter = (GN=*)
The filter item should evaluate to undefined, since the short name GN 
cannot be mapped to an OID.
In this case the directory is correctly acknowledging that
the short-name may (or may not) map to something that it knows about,
but since it cannot be absolutely certain, it will evaluate to undefined.
No results should be returned.

Filter = (!(GN=*))
The filter item should evaluate to undefined, since the short name GN is
not known. Once again, no results will be returned.

According to the example in Protocols, this final filter will result in
the directory returning every entry in the scope of the search. This
would be due to the fact that the directory would evaluate the filter
item to be FALSE, which will turn a TRUE upon negation.
I think that this behavior is incorrect because it is assuming that the
directory is making an unambiguous decision that the attribute type does
not exist; a decision that the directory cannot make when presented with
a short-name description.

Andrew Sciberras
eB2Bcom.

---

From: Rici Lake <[email-masked]>
Date: Thu, 19 May 2005 13:46:08 -0500

On 18-May-05, at 10:49 PM, Jim Sermersheim wrote:

> I don't think I agree with your assertion that it should work 
> differently depending on whether the numericoid versus the descr form 
> of the attribute type is used. If that distinction were made for 
> presence, shouldn't it also be made for other filter items as well? 
> For example, it seems you argue that (2.5.616.123=jdoe) could evaluate 
> to FALSE, while (bogusAttr=jdoe) would evaluate to UNDEFINED (where 
> both are not known to the server's schema).

That makes sense to me, assuming that attributetype inheritance is not 
taken into account by the filter. Then the non-presence of an attribute 
type identified by numeric oid would be definitive, whereas the 
non-presence of an attribute type identified by an unknown descr would 
be non-definitive.