|
I agree with this. It makes the present filter consistent with the others. >>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 5/19/05 6:16:59 PM >>> At 04:22 PM 5/19/2005, Jim Sermersheim wrote: >>>> Rici Lake < rici@ricilake.net > 5/19/05 5:02:46 PM >>> >> >>On 19-May-05, at 5:49 PM, Jim Sermersheim wrote: >> >>> 1) Are you saying that the same logic should also apply to other >>> search filters (not just the present filter)? >> >>Yes. If the OID were known, then there would be no assertion of that >>type, so logically an unknown numericoid should be equivalent to the >>non-existence of an assertion, whether in a presence filter or an >>equality, substring, etc. filter. > >As of yet, in the protocol spec, there is no such thing as "no assertion". all filter items evaluate to TRUE, FALSE, or UNDEFINED. Are you instead suggesting that an unknown numericoid in an assertion evaluate to FALSE? > >Note that we are talking about changing X.500 semantics in this thread. I assume you are referring to Rici's numericoid suggestion. X.501 says: An AVA is: a) undefined, if any of the following hold: 1) the attribute type is unknown, We should remain consistent with X.500. In regards to Andrew's suggestion, X.500 says: The present match tests for the presence of any value of a particular type. The client did not unambiguously communicate a particular type to the server, hence the test cannot be performed. The assertion is, hence, Undefined. Another complication is that an LDAP server is not required to utilize the LDAP schema model and may not actually be aware of numeric OIDs. That is, an implementation may only know an attribute type by one or more descriptors. Hence, (2.5.4.0=*) is equivalent to (objectClass=*). Additionally, I note that RFC 2251 included the text equivalent to the [Protocol, 4.5.1.7.1]. Servers MUST NOT return errors if attribute descriptions or matching rule ids are not recognized, assertion values are invalid, or the assertion syntax is not supported. More details of filter processing are given in Clause 7.8 of [X.511]. (note that presence is an assertion syntax). But that this must not be viewed as requiring servers to evaluate every presence assertion. Just as with any other assertion, a server should be free to evaluate any assertion to Undefined (maybe the presence assertion syntax is not supported for the requested attribute description). So, I think [Protocol, 4.5.1.7.5] should read: The present match evaluates to TRUE where there is an attribute or subtype of the specified attribute description present in an entry, FALSE where an attribute or subtype of the specified attribute description is absent, and Undefined otherwise. and that "a filter of (shoeSize=*) would evaluate to FALSE" be replaced with "a filter of (shoeSize=*) would evaluate to Undefined". Kurt |