Re: A tricky matched values problem

[Steve Fisher <S.A.Fisher@btinternet.com>]

Hi

I think that the what Harald has suggested and the FDAM text say suport the
basic idea of matchedValuesOnly and the 'Molesworth pronciple'. I think,
though that the original example touched upon other issues and situations in
which the Directory would have to intepret the intention of the query. There
could be situations where wrong results (which could disadvantage both the
entity querying the Directory and  objecst which match the search. Although
I do not have the definition of a Sub Filter, I am assuming that the
(AND(mail=sean.mullan@sun.com)(telephoneNumber=47)) group of filter items is
a Sub Filter. If the originator attaches some relational signiificance to
the two ANDed items, then this is where possible problems could occur.

On this basis, I do not think that it is clear that the standard should
adopt the proposed FDAM text (if indeed this is what is being proposed). I
think that a policy-based 'appropriate response' is more flexible, allowing
different administrations to determine how their Directories should respond.

Is my intepretation correct (especially on Sub Filters) ?

Regards

Steve Fisher

PS On the subject of Sub Filters, is it possible to get hold of the
definition of this?

>>>The solution to this which is given in the FDAM says (to counter this
>>>kind of problem):
>>>
>>>"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 it 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."
>>>
>>>Does this resolve the problem?
>>
>>It seems to me that matchedValuesOnly is asked to perform tasks of
>>intuiting the user's state of mind, which usually means that there's
>>something wrong with the design.
>
>Of course, we started off with a broken design, but the one chosen
>reflects the Molesworth principle, which is:
>
>        If in doubt, send too much.
>
>It's also a simple algorithm.
>
>The problem with what you suggest is that, if you have two parts of a
>filter, both of which match, which values do you send?
>
>All the best
>
>Anthony
>
>
>>
>>What about redefining the thing as an attribute return filter:
>>
>>INPUT:
>>   Attribute search filter
>>
>>OUTPUT:
>>   Only those values of that attribute, for all selected entries, that
match
>>   the filter.
>>
>>If the intent of the
>>
>>(OR(AND(mail=sean.mullan@sun.com)
>>        (telephoneNumber=47))
>>    (cn=Sean*))
>>
>>was to return all persons named Sean, and point out the one who had this
>>email address, it could be written as
>>
>>(OR(AND(mail=sean.mullan@sun.com)
>>        (telephoneNumber=47)
>>    (cn=Sean*)
>>
>>RETURNFILTERED (mail=sean.mullan@sun.com)
>>
>>this would return all people named Sean, and the email address for the
>>one who matched that.