Re: Returning single values from multivalued attributes

[Mark Smith <mcs@netscape.com>]

Helmut Volpers wrote:
> 
> Mark C Smith wrote:
> > ...
> > I find it surprising and confusing that the behavior is different when
> > an attribute has multiple values vs. when it only has one.
> 
> I didn't follow the complete discusion but what is surprising ?
> When I have a single valued attribute I don't need a matchedValuesOnly
> because if it
> match you get it back and need no additional flag.

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.


> ...
>  Just so I
> > understand how this works, here's an example.  Suppose entry E1 has one
> > userCertificate value and entry E2 has two such values.  Further suppose
> > that a client wants to always retrieve the cn attribute from an entry
> > but wants to receive a userCertificate value only if the cert value
> > presented in a filter matches one of the certs present in the entry.
> > For E1, this will require two search operations (base search to grab the
> > cn and another to test for the cert) but for E2 it can be done in one
> > (base search with a filter like
> > "(|(cn=*)(userCertificate;binary=<DER>))" with matchedValuesOnly set to
> > TRUE).  Correct?
> 
> Not correct. If you make this search and the userCertificate match that
> in E1
> you get the entry and userCertificate back I hope.

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).


> But is this the normal search to find somebody in the directory where
> the client already know the complete userCertificate ? I think you have
> some parts
> of the userCertificate and use the special matching rules to find the
> complete userCertificates.

Sure, it might be that special matching rules are used.  But that
doesn't change the spirit of my example.


> 
> Or by "single valued attribute" do you mean an
> > attribute type that allows multiple values?  Technically, the filter I
> > present above won't work because presence and equality filters don't
> > work with matchedValuesOnly (see below).
> 
> I see no reason at the moment why the matchedValuesOnly cannot be used
> with equality filters ? David is there a reason ?
> >
> > >
> > > >
> > > > b) Can matchedValuesOnly be used with equality filters?
> > >
> > > No, but the easy work around to this is to put the equality filter in the
> > > extended filter element of the search.
> >
> > I'd like to see us fix this problem when we define a matched values only
> > control for LDAPv3.
> 
> I agree with you.
> 
>  Presence filters are not allowed either.
> 
> 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?

Anyway, I look forward to the draft on this topic.

-- 
Mark Smith
iPlanet Directory Architect / Sun-Netscape Alliance
My words are my own, not my employer's.   Got LDAP?