RE: I-D ACTION:draft-ietf-ldapext-matchedval-01.txt

[David Chadwick <d.w.chadwick@salford.ac.uk>]

Date forwarded: 	Thu, 9 Sep 1999 08:44:37 -0700 (PDT)
From:           	"Salter, Thomas A" <Thomas.Salter@unisys.com>
To:             	ietf-ldapext@netscape.com
Subject:        	RE: I-D ACTION:draft-ietf-ldapext-matchedval-01.txt
Date sent:      	Thu, 9 Sep 1999 11:42:07 -0400 
Forwarded by:   	ietf-ldapext@netscape.com

> In general, I think this draft is fine, and provides a useful feature when
> simple filters are used.  However, I'm confused as to what should happen
> when the filter is rather complex.  (Admittedly, I'm thinking of
> pathological cases that should rarely occur in normal use.)
> 
> Some questions:

Pretty good questions these. I'll have a go at answering them

> 1.  Does the rule of ignoring a NOT filter mean to ignore the entire,
> possibly complex filter, the not applies to, 

Yes

>even if it is ultimately a
> double NOT ? 

Yes. Because of 3 valued logic, a double not is not always true, but 
will be undefined for entries where the attribute does not exist.

>So this filter "(!(!(mail=sean.mullan@sun.com)))" has no
> effect of returned values, whereas "(mail=sean.mullan@sun.com)" does.

Correct.

> 
> 2. Consider the "Sean Mullan" example from the draft.  What if the filter
> was 
>   "(|(mail=sean.mullan@sun.com)(telephoneNumber=47))" ?  
> Now the entry is returned because the entire filter is true.  What is
> returned for telephoneNumber?  As I read the draft all values of the
> telephoneNumber should be returned, since that clause evaluates FALSE.  Is
> this right?

This is correct, as no telephone numbers would be marked as 
contributing. (Only the mail address contributed to passing the filter)

> 
> 3. What about this filter: 
> "(|(&(mail=sean.mullan@sun.com) 
>      (telephoneNumber=47))
>    (cn=Sean*))"
> Here the mail clause evaluates TRUE, but does not contribute to the
> overall truth of the filter, because the rest of the AND is FALSE.  Is
> only the one value of mail returned?

Now this is where X.500 is slightly better than LDAP, because X.500 
differentiates between a filter item and a filter in the ASN.1. LDAP 
does not do so, so it is difficult to differentiate between the two as 
filter item is an undefined term in LDAP. In fact, in X.500 the 
attribute is counted if the filter item evaluates to true, not the filter, 
but we have no way in LDAP of saying this (unless I am mistaken, 
although I note that filter item is used in the LDAPv3 spec without 
defining it.). ANyhow lets assume that we all know what a filter item 
is. In your example the mail filter item evaluates to true, therefore the 
matching value is marked as contributing. So only this email value is 
returned (therefore your analysis was correct)

Question. Can and should we update the ID to talk about filter items?
My suggested answer. Yes, and we should point to X.500 for a 
definition of filter item.

> 
> 4. One more:
>   "(|(mail=sean.mullan@sun.com)(telephoneNumber=555-9999))"  
> Here both clauses are TRUE, but the second would normally not need to be
> evaluated.  I assume that's irrelevant and only one matched value each of
> both mail and telephone number is returned.

Correct.

Conclusion. Each of your very tricky examples have been correctly 
interpreted by yourself,  therefore it seems like the ID is reasonably 
clear.

David

> 
> 


***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
*NEW* Email D.W.Chadwick@salford.ac.uk *NEW*
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************