Re: Returning single values from multivalued attributes

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

Date sent:      	Tue, 10 Aug 1999 10:06:23 -0400
From:           	Mark Smith <mcs@netscape.com>

> True.  But it is certainly possible to construct compound filters that
> will always return the entry but may have one or more components that do
> not match.  Simple examples can be constructed using OR, e.g.,
> (|(cn=*)(member=<dn>))  Maybe no one wants to use such filters, but it
> seems inconsistent for the matchedValuesOnly flag to have differing
> behavior depending on how many values are present.
> 

Mark
I dont quite follow you here. Firstly, the user chooses which 
attributes are to be returned. Secondly, if the chosen attributes did 
not contribute to the filter, then matchedValuesOnly has no effect on 
them. ONly if the chosen attributes were also in the filter and they 
contributed to the matching, are the matched values only returned. 
Therefore there is no differing or inconsistent behaviour dependent 
upon the number of values in the attribute. If the attribute did not 
contribute, matched values is ignored, if the attribute did contribute 
(irrelevant how many values it has) then only the ones that matched 
are returned.

> My example is contrived, but the idea is that I want to always get back
> the entry's cn and also test for the presence of a particular certificate
> at the same time.  For E1, if my filter does not match the certificate, I
> don't want to get the certificate back (even though the other cn=*
> component of the filter does cause the entry to be returned).
> 
> 

This is where your misunderstanding comes in, I think. YOu decide 
whether you want the certificate attribute to be returned 
INDEPENDENT of matched values only. This is set in the attributes 
parameter of the Search. You cannot say "I only want this attribute 
if it contributed to the filter". Matched values says whether you want 
all certificates back or only some of them, but does not allow you to 
say none of them (which is what you wanted to do in your contrived 
example. For this you would need another control that has not been 
suggested yet by X.500 or LDAP


> > I see no reason at the moment why the matchedValuesOnly cannot be used
> > with equality filters ? David is there a reason ?

There was a reason originally proposed by Australia Telecom, but I 
cannot remember what it was. (I remember arguing against the 
restriction at the time, but lost, as it remained.)

> > How do you want to use matchedValuesOnly with the presence filter ?
> 
> Probably there is no good reason to do so.  The behavior of
> matchedValuesOnly just strikes me as inconsistent.  Maybe David or
> someone can explain what the correct server behavior is if a presence
> filter component is submitted along with matchedValuesOnly == TRUE.  Is an
> error returned to the client?
> 

Matched values does not make sense with a presence filter, since 
presence is only testing the attribute type and not any of the values, 
so how can you then ask for the matched values only? I would say 
that the matched values is simply ignored by the server.

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

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