Evaluation of an unknown attribute description in a presence filter

[Andrew Sciberras <andrew.sciberras@eB2Bcom.com>]

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.