Subject: Re: [Fwd: Returning single values from multivalued attributes]

From: Anthony Hodson <[email-masked]>
Date: Wed, 18 Aug 1999 13:03:55 +0100

Hi, Helmut!

Thanks for this.  (Just got it today on return from hols in NZ.)

I agree that the existing restrictions on matchedValuesOnly make it far
less useful than it should be.  The exclusion of equality filters was, I
think, based on the presumption that if you provided a matching value,
you knew the whole value.  This, of course, is untrue when using a
matching rule which (as for certificates and first-element matches)
match on only part of the value.

In the FPDAM, we amended the text to:

"The matchedValuesOnly argument indicates that certain attribute values
are to be omitted from the returned entry information. Specifically,
where an attribute to be returned is multi-valued, and some but not all
of the values of that attribute contributed to the search filter, [[in
its last effective form (i.e. taking relaxed matching rules into
account)]] returning TRUE via filter items other than present, then the
values that did not so contribute are omitted from the returned entry
information. An attribute value is said to contribute to the search
filter if is matched by any non-negated filter item in the filter (see
7.8.1), whether or not omission of that item would have led to a
different outcome in the selection of the containing entry."

The text [[...]] can be disregarded for present purposes.

Note that the presence match is still excluded, and the last para
attempts to clarify just what matching means.

Now to your specific comments and queries.

In message <[email-masked]>, Helmut Volpers <helmut.vo
[email-masked]> writes
>Hi Anthony,
>
>I send as an attachment a mail with a discussion about MatchedValuesOnly 
>flag in a search.why is it not valid for equality match ?

No good reason

> and why is
>there
>a difference between single and multivalued attributes.

The matchedValuesOnly attempts to exclude less interesting values.  With
a single-valued attribute, there are no "less interesting values"!  I
believe that a single-valued attribute here means one that in the
present instance has just one value, but which (like a common-name) may
be permitted to have multiple values.  (This may not be completely clear
from the text.)
>Thanks Helmut

All the best

Anthony

>David Chadwick wrote:
>> 
>> Mark Smith wrote
>> 
>> > I lean towards (i) but I'd like to have more discussion about this -- both
>> > about how people envision using this feature and how the existing feature
>> > works in X.500 DAP.  Can you explain exactly how the matchedValuesOnly
>> > argument works in DAP?  I find the text in X.511 to be quite confusing.
>> > Some basic questions I have:
>> >
>> > a) Does matchedValuesOnly affect single-valued attributes or just
>> > multivalued ones?
>> 
>> Its effect on a single valued attribute is null.

Agreed - but see clarification of what "single-valued" means!
>
>I find it surprising and confusing that the behavior is different when
>an attribute has multiple values vs. when it only has one.  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?  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).
>
>
>
>> 
>> >
>> > 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.  Presence filters are not allowed either.  This
>seems like an unnecessary limitation to me.
>

Anthony Hodson <[email-masked]>      X   X    DDD
XdotD Associates                             X X  O  D  D
Spring Lanes House, Holly Spring Lane         X  OOO D   D  
Bracknell, Berks RG12 2JL, ENGLAND           X X  O  D  D
Tel: +44 1344 310665                        X   X    DDD
Fax: +44 870 056 8242