[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: A tricky matched values problem - I vote for (2)!!
I'm also voting for 2 for similar reasons.
However, instead of a "search filter", I think it should just be a "SET of
AVA". Eliminating the filter should eliminate all ambiguity about which
filter items get evaluated. In X.500 this should be added to
EntryInformationSelection.
> -----Original Message-----
> From: Anthony Hodson [mailto:aeh@xdotd.demon.co.uk]
> Sent: Monday, October 18, 1999 6:10 AM
> To: d.w.chadwick@salford.ac.uk
> Cc: ietf-ldapext@netscape.com; osidirectory@az05.bull.com
> Subject: A tricky matched values problem - I vote for (2)!!
>
>
> Hi, David!
>
> Good to have your analysis, which I *generally* agree with. But ...
>
> With 1A, consider a filter OR(A, B) where, with a particular
> entry, both
> A and B are true; as a result of this (using 1A), assume that A would
> cause a value x to be returned, and that B would cause a
> value y to be
> returned.
>
> Presumably you would return both x and y with 1A, even
> though neither A
> nor B could be *completely* said to have contributed, since
> either could
> be omitted without affecting the outcome.
>
> It was consideration of this kind of issue that led to the simple and
> easy-to-implement rough-justice rule: if a filter item is
> TRUE, send the
> value anyway. I don't defend it at all on philosophical grounds.
>
> My view is that your solution 2 is *much* the better
> solution because of
> its direct approach to solving the problem, since matched-values was
> always a bit kloodgy for the reasons that you suggest. I
> think that it
> would be much better for FDAS/F.510, too. Something has to
> change with
> existing MVO implementations, and (2) presents no technical
> challenges.
>
> Best wishes
>
> Anthony
>
> In message <E11cz2q-00018p-00@rhenium.btinternet.com>, David Chadwick
> <d.w.chadwick@salford.ac.uk> writes
> >First let me apologise for taking so long to answer all the
> emails on this
> >topic, but I have been up to the proverbials in work (I
> still am, its now
> >10,30pm on Sunday evening).
> >
> >Firstly I do not believe that the Molesworth principle
> should apply for the
> >matched values control. This is because the user, in
> specifying this control,
> >is obviously trying to limit the size of the response,
> therefore the correct
> >action by the server would be the Molesless principle if
> there were one i.e. if
> >in doubt return less attribute values rather than more.
> >But I am not advocating either principle, but rather I am
> agreeing with Paul
> >Dale that sound logic and a consistent and easily reasoned
> scheme is needed.
> >And as Erik said "we need to be precise".
> >
> >Harald has rightly pointed out that quote "it might be
> better to have a control
> >that tells the server something about what the client wants
> back rather than
> >something about how he wants the search criteria treated."
> What matched values
> >was trying to do was both with one simple boolean. ie. the
> matched values
> >boolean was saying something about what the client wanted
> back (i.e. limit the
> >values), but using the search filter to specify precisely
> which values are to
> >be limited in the return. The trouble as we can see arose
> because the search
> >filter can be a mixture of truths, unknowns and falses,
> and a simple
> >matchedValuesOnly boolean was too blunt a tool (as
> currently specified) to
> >differentiate between them. It therefore was not precise
> enough in its
> >specification.
> >
> >Therefore it seems that there are two sensible options that
> can be taken:
> >
> >1) is to tighten up considerably on the definition of the
> current MVO boolean.
> >There are three views of how to tighten up the definition.
> 1A) One is to say
> >that only those attributes that contributed to the overall
> truth of the filter
> >are governed by the MVO boolean. 1B) Another is to say
> that if the filter item
> >was true then MVO applies to the attributes in the filter
> item (even if the
> >subfilter containing the filter item was false). 1C) And
> the final one
> >suggested by Bruce was if the attribute was in the filter,
> even if the filter
> >item was false, then apply MVO.
> >
> >2) the other is to replace the boolean by a return filter
> (as suggested by both
> >Harald and Bruce) that acts on the attributes to be
> returned and filters out
> >some of the values. This works independently of, and
> after, the Search filter.
> >
> >My preferred approach is the first, 1A) i.e.only those
> attributes that
> >contributed to the overall truth of the filter are governed
> by the MVO boolean.
> >My reasons are as follows:
> >
> >I reject the current X.500 text (option 1B) for the
> following reason:
> >subfilters that evaluate false or undefined might as well
> be missing from the
> >filter, and if they were there on their own then no entries
> would be returned.
> >THerefore they have no claim to act on the returned values
> of any entries.
> >
> >I reject option 1C) as it is too loose and it does not work
> properly for false
> >filter items, as presumably no attribute values would be
> returned from these
> >attributes.
> >
> >Option 2) has its merits, and is clean. The reason for
> rejecting it is
> >compatibility with X.500, and that option 1A can (as Mark
> points out) do the
> >same task anyway, but perhaps not quite as efficiently. So
> option 2) might be
> >more efficient than 1A) but at the expense of
> compatibility with existing
> >implementations.
> >
> >I am happy to update the ID was the proposed solution 1A
> unless anyone has
> >strong objections to this.
> > David
> >
> > ***************************************************
> >David Chadwick IS Institute, University of Salford, Salford
> M5 4WT Tel +44 161
> >295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email
> >D.W.Chadwick@salford.ac.uk Home Page
http://www.salford.ac.uk/its024/chadwick.h
>tm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP
>Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key
validation
>string MLJ9-DU5T-HV8J
>***************************************************
Anthony Hodson <aeh@xdotd.demon.co.uk> 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
Mob: +44 771 360 7086
Fax: +44 870 056 8242