HI!
Discussed this very briefly with Howard at LDAPcon 2007 based on an idea of Steve:
Support for dITStructureRules and nameForms is still in OpenLDAP's TODO.
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 slapd.conf.
Opinions?
Ciao, Michael.
On Sep 10, 2007, at 3:13 PM, Michael Ströder wrote:
HI!
Discussed this very briefly with Howard at LDAPcon 2007 based on an idea of Steve:
Support for dITStructureRules and nameForms is still in OpenLDAP's TODO.
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 slapd.conf.
Opinions?
One could implement them in a fashion similar to ditContentRules... (server wide instead of subtree specfication wide).
-- Kurt
Ciao, Michael.
-- Michael Ströder E-Mail: michael@stroeder.com http://www.stroeder.com
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 idea of Steve:
Support for dITStructureRules and nameForms is still in OpenLDAP's TODO.
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 slapd.conf.
Opinions?
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?
Ciao, Michael.
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 idea of Steve:
Support for dITStructureRules and nameForms is still in OpenLDAP's TODO.
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 slapd.conf.
Opinions?
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).
-- Kurt
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 idea of Steve:
Support for dITStructureRules and nameForms is still in OpenLDAP's TODO.
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 slapd.conf.
Opinions?
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.
Ciao, Michael.