[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: A tricky matched values problem

I certainly agree that that we need an unambigious definition. It is confusing if a users different behaviour when accesing different directories. A user using an LDAP client might not be aware whether the LDAP server being accessed is an X.500 system or not. We should agree on a definition that applies across the board: We should not have any artificial differences. This may of particular interest for vendors otherwise having to implement two different schemes.

Erik Andersen

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