Subject: Re: Duplicate entries filter

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 09 Aug 2000 16:27:51 -0600

>>> "Kurt D. Zeilenga" <[email-masked]> 8/8/00 2:43:38 PM >>>
>>Oh yeah, now I remember.  This is an addition that Kurt pointed out should be there. The thinking was that it'd be unexpected to return entries that don't match the search filter. This being the case, there's a bit of functionality crossover between the dupent and matchedval drafts (under the right conditions).
>
>Of course, it quite normal (for a non-extended search) for returned
>entries not to match don't match the filter... (because of access
>controls or whatever).
>
>Basically, it's a issue of semantics.  Is the filter applied
>before or after duplication?  (note: servers often use the
>the filter for selection of "candidates" within scope, but this
>is an optimization which is irrelevant as long as outcome is
>not changed).

Hmm, I think the wording in the draft should be changed to reflect this. Currently it says "These duplicate entries are returned to the client only if they still match the asserted search filter". That's a little ambiguous.

>That is,
>        a) all entries within scope are duplicated per the control,
>      then filtered.
>
>        b) all entries within scope are filtered, then duplicated
>        per the control.
>
>I find a) more useful than b).  However, there could be room for
>both.  Dare I suggest another BOOLEAN?

Adding another flag is certainly more flexible - and it forces people to consider the issue, it just adds more implementation complexity. I don't mind adding it, what does anyone else think?

Jim

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 09 Aug 2000 16:48:24 -0700

>Hmm, I think the wording in the draft should be changed to reflect this. Currently it says "These duplicate entries are returned to the client only if they still match the asserted search filter". T…

Actually, I don't find that ambiguous at all... it's clearly option a).