[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: I-D ACTION:draft-ietf-ldapext-ldapv3-dupent-00.txt



Uppili Srinivasan wrote:

> What is the rationale for wanting the server to do this.  Should this
> probably be a client side issue (like you pointed out).  Probabaly an
> API option to facilitate those clients who might need this
> convenience?

The canonical example I've heard is as follows:

There are people entries in a corporate directory.
Some of the people have two surnames. (perhaps they
recently became married, or are in a witness protection program)
This is represented in the directory as multivalued "sn" 
attributes.

A client submits a search with server-side sorting
along the lines of "give me a sorted list of all the
people in the company, sorted by surname".

Following the current directory information model
and rules for how to construct search result sets,
the client would see a result set with n entries returned.
Any entry with multiple "sn" values would only show
up once, and in the position in the list appropriate
to the "lowest" of the multiple values.

So, someone called "smith" and "bloggs" would
only show up in the "bloggs" position in the sorted
list. Note that both values "smith" and "bloggs"
would be returned to the client in the entry,
we're only talking about position in the list here.

Now, some would find this irritating and plausibly
"incorrect" because they consult the sorted list,
looking for their friend "smith"---going to the
smith-ish part of the sorted list they see no
such entry. They conclude that Ms. Smith has been
fired...

The intent of Jim's document (as I understand it)
is to enable a client to say "hey, don't do that---
return copies of those entries at the appropriate
positions in the sorted list". Then the client will
display the perceived "correct" list of results.