Subject: Duplicate entries filter

From: "David Chadwick" <[email-masked]>
Date: Sun, 6 Aug 2000 00:20:38 +0100

Jim

as we discussed at the Pittsburgh meeting, the text still says that 
duplicate entries will only be returned that pass the filter. Is this still 
the intention or is it a mistake. Text reproduced below:

"These duplicate entries are returned to the client only if they still 
match the asserted search filter."

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 [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: "Jim Sermersheim" <[email-masked]>
Date: Thu, 10 Aug 2000 13:26:10 -0600

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

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

---

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 16 Aug 2000 10:31:18 -0600

These examples do reflect the original intent of the I-D. While writing it, I had assumed the behavior previously discussed as a) (filter, duplicate, return). Given the usefulness of Kurt's example, I changed it to b) [filter, duplicate, filter, return (if your server can do this more efficiently, more power to ya)]. Then the notion of a flag was introduced.

I think a better alternative is to have the behavior be a) (which in my mind is simpler to implement), then allow use of the matched values control to produce the results of b). This way we are back to two separate controls that have non-overlapping specific functionality. If we agree to this proposal, I'll add appropriate text to the Interaction With Other Controls section.

Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 8/16/00 9:07:04 AM >>>
At 03:04 PM 8/16/00 +0100, David Chadwick wrote:

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

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

---

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

>I think a better alternative is to have the behavior be a) (which in my mind is simpler to implement), then allow use of the matched values control to produce the results of b). This way we are back…

I do prefer two separate controls as I believe it easier to describe
control combination semantics.

duplicate-entries:  filter, dup, return results
matched-values:  filter, trim, return results

duplicate-entries+matched-values: filter, dup, trim, return results
matched-values+duplicate-entries: filter, trim, dup, return results

other combinations?

---

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 16 Aug 2000 11:57:22 -0600

>>> "Kurt D. Zeilenga" <[email-masked]> 8/16/00 10:53:48 AM >>>

>matched-values+duplicate-entries: filter, trim, dup, return results

I think the duplicate entries draft would (in the interaction with other controls section) state something like "When this control is paired with the matched values control, this control MUST be applied first..." then probably expound using an example. The net effect being filter, dup, trim, return.

Jim