In the following post:
http://www.openldap.org/cgi-bin/wilma_hiliter/openldap-technical/201001/msg0...
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?
However, I will note, the definitions of these attributes are RFC defined. They have no ORDERING rule on purpose.
Just a quick follow-up on my own post:
The RFC is based on the ITU specification, which (as of ITU-T Rec. X.520 (11/2008)) says:
6.2.1: Name: The Name attribute type is the attribute supertype from which string attribute types typically used for naming may be formed.
name ATTRIBUTE ::= { WITH SYNTAX UnboundedDirectoryString EQUALITY MATCHING RULE caseIgnoreMatch SUBSTRINGS MATCHING RULE caseIgnoreSubstringsMatch ID id-at-name }
That certainly suggests that matching against this field should be case-insensitive, so it follows that ordering should also be case-insensitive.
openldap-technical@openldap.org
-
Tim Gustafson