RE: A tricky matched values problem

["Salter, Thomas A" <Thomas.Salter@unisys.com>]

I'm not sure the 'Molesworth Principle" should apply here.  In this case,
the requestor has explicitly set "matchedValuesOnly" in an attempt to limit
the size of the response.  If he doesn't get enough information, he can
always remove the matchedValuesOnly control and try again.

If it is left up to policy, the control becomes unusable in multi-directory
environments.  I think it's better to pick one definition and stick with it.
On the other hand, in actual practice, matchedValuesOnly will probably only
be used with relatively simple filters, so this whole debate (which I helped
get started) is probably more theoretic than practical.

Tom

 > -----Original Message-----
 > From: Steve Fisher [mailto:S.A.Fisher@btinternet.com]
 > Sent: Monday, October 04, 1999 3:55 AM
 > To: Harald Tveit Alvestrand; Anthony Hodson
 > Cc: d.w.chadwick@salford.ac.uk; Erik Andersen;
 > osidirectory@az05.bull.com; ietf-ldapext@netscape.com
 > Subject: Re: A tricky matched values problem
 > 
 > 
 > 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.
 > 
 >