[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: RFC2251: RootDSE subschemasubentry issue
Mark, Kurt
I think I have an answer to the problem(s) being posed by Kurt.
The model as it stands is OK if a server only masters one naming
context. Everything works fine. All the entries in the NC and the
rootDSE can contain the subschemaSubentry attribute which points
to the single subschema subentry.
The problem arises once we have multiple NCs in a server. The
subschemaSubentry attribute can still be single valued and exist in
each entry in each NC and point to the correct subschema
subentry. However, the attribute in the root DSE no longer works, for
two reasons.
Firstly it is supposed to be single valued (as Kurt pointed out) and
now it needs to have multiple values.
Secondly, (again as Kurt pointed out) there is no way for the user to
know from the multivalued attribute in the rootDSE which value
points to which subschema subentry for which NC. THis of course is
not a problem for the entries within the NC, as they only still need a
single pointer to their one and only subschema subentry.
Thus I conclude that the model is broken for multiple naming
contexts, and that the subschemaSubentry attribute in the rootDSE
needs to be replaced by a multivalued attribute, having two
components - the context prefix of an NC (an LDAP DN), and the
pointer to the subschemaSubentry.
Do you agree with this analysis?
David
***************************************************
David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351 Fax +44 161 745 8169
Mobile +44 790 167 0359
Email D.W.Chadwick@salford.ac.uk
Home Page http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500 http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J
***************************************************