[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Sorting the NAME Attribute
- To: openldap-technical@openldap.org
- Subject: Sorting the NAME Attribute
- From: Tim Gustafson <tjg@ucsc.edu>
- Date: Tue, 31 Mar 2015 17:11:09 -0700
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucsc.edu; s=ucsc-google; h=mime-version:date:message-id:subject:from:to:content-type; bh=uge2L2wkoVr4B32gmx/VoGQFeOwXQq28LhkGUDYf7aM=; b=g3Su/GjhkPRwNYdYNWZxC0l9By6jXMRyYvWP9i2XvBJ597gPZ2zSCQ/lLfjicuwdW4 9GSONykLUfe1HgkasFptu0f4svs5jqH1b8m37InqGVXbegWd139Sa9mvSsb4T5Sf1v0F rVKcNMQoaAs1UHIyNkCZ+OcRWpAAXu6fTPALM=
In the following post:
http://www.openldap.org/cgi-bin/wilma_hiliter/openldap-technical/201001/msg00076.html
Quanah said:
> However, I will note, the definitions of these attributes are RFC
> defined. They have no ORDERING rule on purpose.
I was not able to find what that purpose was. Does anyone have any
idea why it was decided that something as critical as "name"
attributes shouldn't have an ORDERING rule?
In my case, I have users who have a lower-case first-letter in their
last name, which makes them appear at the bottom of all lists of
people when sorted on the LDAP server. Needless to say, this makes
them unhappy.
For most of my purposes, I simply sort the data in my code once it is
retrieved from the LDAP server, but in some cases I don't have control
over the software being used and therefore can't change it, and in
other cases this is terribly inefficient or impractical.
Other than "because the RFC says so", what's the reasoning behind not
defining an ORDERING rule for "name" attributes", preferably one that
is case-insensitive? Could it at least be made a build option to
enable or disable an ORDERING rule on at least that attribute (or
perhaps in a more general configurable way for other attributes as
well), even if it's not truly RFC-compliant?
--
Tim Gustafson
tjg@ucsc.edu
831-459-5354
Baskin Engineering, Room 313A