Subject: Re: Duplicate entries filter

From: "David Chadwick" <[email-masked]>
Date: Wed, 16 Aug 2000 23:30:58 +0100

Date sent:      	Wed, 16 Aug 2000 10:31:18 -0600
From:           	"Jim Sermersheim" <[email-masked]>
To:             	<[email-masked]>,<[email-masked]>
Copies to:      	<[email-masked]>
Subject:        	Re: Duplicate entries filter

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

Jim,
two points

i) I note that in both a) and b) above you never mention (duplicate, 
filter, return) which was one of the earlier threads that was being 
discussed. Is this option finally being laid to rest? I hope so.

ii) for option b) by combining duplicate entries and matched values 
we actually have (search filter, duplicate, match filter, return) which 
is more powerful than using the same filter in both instances. And 
as Kurt pointed out, we can alternate the ordering of the duplication 
and match filter (although this probably will not give different results 
except for the case of when an empty set of attributes is returned. 
With duplicate followed by match you could get identical entries 
returned several times, containing an attribute with no values)

David

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

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

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: Wed, 16 Aug 2000 16:54:30 -0700

>discussed. Is this option finally being laid to rest? I hope so.

Please...  Remember I only dared to suggest it.  :-)

>returned several times, containing an attribute with no values).

This may be the case, it's just wasn't obvious to me (and "probably"
you as well).   I'll have to chew on this to see if both orderings
are useful enough to warrant specification.

I namely brought the ordering of controls issue as it seemed relevant
to the "Extensions Guide" thread.  That is,
  Controls ::= SEQUENCE OF Control
implies that order may matter (and multiple controls of the
same type or even identical controls may be listed multiple times...
which may or may not make sense depending upon the semantics of
the control).

Kurt