directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Howard Chu <>
Subject Re: [jira] Created: (DIRSTUDIO-528) Handle schema extension used for OpenLDAP attribute ordering
Date Mon, 31 Aug 2009 09:22:10 GMT
Torsten Rehn (JIRA) wrote:
> Handle schema extension used for OpenLDAP attribute ordering
> ------------------------------------------------------------
>                   Key: DIRSTUDIO-528
>                   URL:
>               Project: Directory Studio
>            Issue Type: Improvement
>            Components: studio-ldapbrowser
>      Affects Versions: 1.4.0
>              Reporter: Torsten Rehn
>> From the OpenLDAP docs:
> "Since the ordering of olcAccess directives is essential to their proper
evaluation, but LDAP attributes normally do not preserve the ordering of their
values, OpenLDAP uses a custom schema extension to maintain a fixed ordering
of these values. This ordering is maintained by prepending a "{X}" numeric
index to each value [...]"

The format is fully documented in this draft:

I suppose at some point I should repost it to be published as an Informational 

> I don't know if ADStudio intends to support this, but if it does: it's a
mess right now. Editing and reordering those attributes is almost impossible.
This is really needed when editing access rules set via olcAccess in
cn=config. Are there any plans for handling those attributes better? The
current situation makes me want to go back to slapd.conf.
> My guess is that this would require some special editor that reads all
values of the attribute being edited, strips the curly braced indexes and uses
"changetype: replace" to modify the entire attribute instead of a single value.
> I understand that OpenLDAP is probably not your main concern, but it would
be nice.

Unfortunately the current behavior in OpenLDAP is so far from standard it can 
be a pain to implement in a schema-aware system. There were some issues with 
it that stopped the original draft from moving forward as a Standards Track 
document. But since we'd already implemented it I didn't have the motivation 
to fix the nits... Might be worth revisiting this on the ietf-ldapext mailing 

   -- Howard Chu
   CTO, Symas Corp. 
   Director, Highland Sun
   Chief Architect, OpenLDAP

View raw message