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