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

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 19 May 2005 17:22:05 -0600

>>> Rici Lake <[email-masked]> 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.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 19 May 2005 17:16:59 -0700

>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

---

From: Rici Lake <[email-masked]>
Date: Thu, 19 May 2005 19:28:42 -0500

That works for me too, for what it's worth.