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 <andrew.sciberras@eB2Bcom.com> 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. |