From: Chris R. <chr...@me...> - 2000-11-29 17:46:32
|
"Kurt D. Zeilenga" <Ku...@Op...> wrote: > At 05:15 PM 11/29/00 +0000, Chris Ridd wrote: >> "Kurt D. Zeilenga" <Ku...@Op...> wrote: >>> BTW, OpenLDAP 2.x provides an LDAPv3 implementation. >>> >>> At 10:46 AM 11/29/00 +0000, Chris Ridd wrote: >>>> OK, that's not the way LDAP does it really. LDAPv3 servers store schema >>>> in special places called subentries in the directory, and places >>>> pointers (ie DNs) to those subentries in the subschemaSubentry >>>> attribute in the root DSE. >>> >>> Every entry should have a subschemaSubentry attribute whose value >>> refers to the subschema entry (or subentry) which controls it. >> >> Whilst that is true (it is actually an operational attribute) I didn't >> describe that mechanism because it didn't appear to fit in with what >> Javier was doing. > > I thought Javier was attempting to discover the schema controlling > an entry. > > The general method for discover such is to obtain the controlling > schema from the subschema subentry referred to by the entry's > subschemaSubentry attribute. The Root DSE approach is known to > be seriously flawed and, IMO, should be avoided until the IETF > determines how to fix it. > > Kurt > That is the far superior approach, as otherwise you'd have to look at all the values of subschemaSubentry and work out which one is 'nearest' to you. Following X.500's line here is sensible. (X.500 has operational attributes on each entry called attributeTypes and objectClasses (etc) which provide the subschema information directly, without having to do the extra read of the subschema subentry.) Cheers, Chris |