directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Howard Chu <...@symas.com>
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: https://issues.apache.org/jira/browse/DIRSTUDIO-528
>               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:

http://highlandsun.com/hyc/drafts/draft-chu-ldap-xordered-xx.html

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

> 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 
list.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

Mime
View raw message