|
>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
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
|