Subject: Re: Duplicate entries filter

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 11 Aug 2000 14:40:28 -0700

At 01:26 PM 8/10/00 -0600, Jim Sermersheim wrote:
>>>> "Kurt D. Zeilenga" <[email-masked]> 8/9/00 5:48:24 PM >>>
>>At 04:27 PM 8/9/00 -0600, Jim Sermersheim wrote:
> 
>>>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.
>
>>Actually, I don't find that ambiguous at all... it's clearly option a).
> 
>It doesn't say anything about other factors that might cause the entry (as seen by the client) to not match the filter (like ACI).

This is intrinsic behavior of search and, unless this I-D specifically
states otherwise, is the behavior of the operation as extended
by the control.  A statement that this behavior is unaffected by
the control may be appropriate.

The choices could be clarified as follows:

  a) all entries within scope are duplicated (per the
  control) which match the filter may be returned by the
  server (subject to other factors)

  b) all entries within scope and match the filter are
  duplicated (per the control) and may be returned by the
  server (subject to other factors).

That is, by "filtered" I meant to act of matching the
entries against the filter, not the act of trimming results
due to other factors.

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

BTW, I'd avoid the a v. b BOOLEAN if at all possible.

---

From: "David Chadwick" <[email-masked]>
Date: Tue, 15 Aug 2000 17:44:00 +0100

Date sent:      	Fri, 11 Aug 2000 14:40:28 -0700
To:             	"Jim Sermersheim" <[email-masked]>
From:           	"Kurt D. Zeilenga" <[email-masked]>

>   server (subject to other factors).

I personally thought that b) was always the intention of this control. 
i.e. it was to act on the way that the results of the search operation 
were returned, but was not meant to affect the operation of the 
search filter. If one considers that in many cases many thousands 
of entries are typically filtered down to only a handful, then 
duplication of the results with this control is only a small task, as 
opposed to a) where we have duplication of the thousands of 
entries and then the application of the filter to each of these. 

This is why I was surprised to see the addition of the sentence that 
I pointed out in my first message.

David

> BTW, I'd avoid the a v. b BOOLEAN if at all possible.

***************************************************

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 [email-masked]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
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

***************************************************

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 15 Aug 2000 13:36:55 -0700

>entries and then the application of the filter to each of these. 

a) sounds like lots more work, but in reality may not be (due to
indexing and/or other optimizations).  The server uses indexing
(as normal) to locate candidates, duplicates the candidates,
applies the filter, returns the results.

However, this shouldn't be the primary issue of a) v. b) (or both).

The issue should be what behavior do applications need and whether
a) or b) (or both) or other controls fulfill the need.  I think
we should take a step back and discuss background and intended
use information before choosing.

Kurt

---

From: "David Chadwick" <[email-masked]>
Date: Wed, 16 Aug 2000 15:04:31 +0100

> The issue should be what behavior do applications need and whether a)
> or b) (or both) or other controls fulfill the need.  I think we should
> take a step back and discuss background and intended use information
> before choosing.
> 

Agreed. The usage scenario that I have heard is producing a paper 
telephone directory, where you want one line for each telephone 
number, so that people may be listed several times in the directory. 
If the entry is only returned once with multiple values (as in the 
standard Search), this does not produce the desired result. I cannot 
remember another usage scenario being presented, but maybe 
others can?

David

David Chadwick

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 16 Aug 2000 08:07:04 -0700

>remember another usage scenario being presented, but maybe 

My scenario is similar, I wanted to be able to search the
directory for entries listing a specific area code and where
the entry contained multiple values with this area code are
returned as duplicated entries.  I only want and desire any
duplicates of containing a value within the desired area
code.  (One could call this "matched" duplicated entries).

Kurt