[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: A tricky matched values problem
Maybe then a solution is to ignore the matchedValuesOnly control or return
an error if the Filter is complex (contains any nested ORs or ANDs).
--Sean
"Salter, Thomas A" wrote:
>
> 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.
> >
> >
--
Sean Mullan Email: sean.mullan@sun.com
Sun Microsystems Laboratories Tel: (781) 442-0926
One Network Drive Fax: (781) 442-1692
Burlington, MA 01803-0902