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

From: Andrew Sciberras <[email-masked]>
Date: Tue, 17 May 2005 11:03:06 +1000

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: "Jim Sermersheim" <[email-masked]>
Date: Thu, 19 May 2005 16:49:21 -0600

Tow things:
 
1) Are you saying that the same logic should also apply to other search filters (not just the present filter)?
 
2) I'm missing the point about attribute subtyping. If a filter item considers attribute subtypes of the named attribute, and OID is still just as definitive isn't it? It either exists in the schema or it doesn't.
 
>>> Rici Lake <[email-masked]> 5/19/05 12:46:08 PM >>>

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.

---

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

On 19-May-05, at 5:49 PM, Jim Sermersheim wrote:

> Tow things:
>  
> 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.

>  
> 2) I'm missing the point about attribute subtyping. If a filter item 
> considers attribute subtypes of the named attribute, and OID is still 
> just as definitive isn't it? It either exists in the schema or it 
> doesn't.

The question is, could the unknown oid have a known oid as a subtype? 
On reflection, I think not... that should be in the schema. So it's 
still definitive.

---

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 19 May 2005 18:24:23 -0600

I agree with this. It makes the present filter consistent with the others.

>>> "Kurt D. Zeilenga" <[email-masked]> 5/19/05 6:16:59 PM >>>
At 04:22 PM 5/19/2005, Jim Sermersheim wrote:
>>>> Rici Lake < [email-masked] > 5/19/05 5:02:46 PM >>>
>>
>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

---

From: "Ramsay, Ron" <[email-masked]>
Date: Fri, 20 May 2005 11:14:36 +1000

"FALSE where an attribute or subtype of the specified attribute
        description is absent"

.. does not have the meaning you expect in English. I think you would have to use "neither the attribute nor any of its subtypes is present"

Ron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Kurt D. Zeilenga
Sent: Friday, 20 May 2005 10:17
To: Jim Sermersheim
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: Re: Evaluation of an unknown attribute description in a
presence filter

At 04:22 PM 5/19/2005, Jim Sermersheim wrote:
>>>> Rici Lake <[email-masked]> 5/19/05 5:02:46 PM >>>
>>

   

Kurt

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 20 May 2005 14:37:33 +1000 (EST)

Hi,

Thank you for your responses to this issue.

>----Original Message----
>From: [email-masked]
>Date: 20/05/2005 10:16:59
>To: Jim Sermersheim <[email-masked]>
>Cc: [email-masked], [email-masked], ietf-ldapbis@OpenLDAP.
org
>Subj: Re: Evaluation of an unknown attribute description in a  presence filter

>        description is absent, and Undefined otherwise.

Kurt, 

Based on your above reference, I think that in order to retain consistency with X.500,  
your suggested text should be making reference to values being present in 
the entry, not the attribute description. 

Cheers,
Andrew