[Date Prev][Date Next]
Re: dITStructureRules/nameForms in subschema subentry for informational purpose
- To: openldap-devel@OpenLDAP.org
- Subject: Re: dITStructureRules/nameForms in subschema subentry for informational purpose
- From: Michael Ströder <firstname.lastname@example.org>
- Date: Sat, 21 Mar 2009 10:58:41 +0100
- In-reply-to: <349BF019-4372-4CEE-966C-A94AE8BCA78D@OpenLDAP.org>
- References: <46E54313.email@example.com> <122731BC-F21D-4428-9747-F345C1250847@OpenLDAP.org> <46E79AA2.firstname.lastname@example.org> <349BF019-4372-4CEE-966C-A94AE8BCA78D@OpenLDAP.org>
- User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:184.108.40.206) Gecko/20090303 SeaMonkey/1.1.15
Kurt Zeilenga wrote:
> On Sep 12, 2007, at 9:52 AM, Michael Ströder wrote:
>> Kurt Zeilenga wrote:
>>> On Sep 10, 2007, at 3:13 PM, Michael Ströder wrote:
>>>> Discussed this very briefly with Howard at LDAPcon 2007 based on an
>>>> of Steve:
>>>> Support for dITStructureRules and nameForms is still in OpenLDAP's
>>>> In the meanwhile slapd could accept definitions for both in slapd.conf
>>>> and simply pass them on to a schema-aware LDAP client for informational
>>>> purpose without enforcing them. Same function like rootDSE <file> in
>>> One could implement them in a fashion similar to ditContentRules...
>>> (server wide instead of subtree specfication wide).
>> So you're voting against the approach suggested above?
> No. Above you say "without enforcing them". I suggest "with enforcing
> them", as ditContentRules are (if instantiated).
Well, this has been a while now. I understand that it would be much work
to fully implement this.
But since web2ldap fully supports DIT structures rules and nameforms
when adding/renaming entries it would be nice if I could stuff these
schema elements into the subschema subentry even if slapd does not
enforce them. Just as a hint to the client like the X-SUBST declaration
of syntaxes (see ITS#5663) or the rootDSE directive for extending the
rootDSE with the data read from a LDIF file. It's handy because web2ldap
then guides the user to do the right thing (choosing structural object
class and the RDN).
Yes, I could extend web2ldap to define additional schema elements at the
client-side. But I'd prefer if it's just in the server's subschema subentry.