[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: RFC2251: RootDSE subschemasubentry issue
> >Why would you have 2 subschemasubentries for 1 NC?
>
> Separate subschema administrative areas within the NC.
> [See Mark Wahl's comment]
>
I proposed solving this problem by having separate subschema
subentries below each administrative point (ala X.500), then we still
can retain single valued attributes. This is what I understood Mark
was also proposing. Since the NC will probably be (but not
necessarily) an administrative point anyway, then it will usually have
a subschema subentry below it. For the few (rare?) cases where the
NC is not an admin point (e.g. an orgs DIT is distributed across 2
servers and thus 2 NCs, but both are controlled by the same
subschema) X.500 proposes having one subentry beneath the
upper NC, and this would be replicated into the subordinate server.
LDAP servers could choose instead to hold a copy of this
subschema subentry beneath the subordinate NC context prefix if
you wished to, or you could go with the X.500 model).
I dont object to you also holding a pointer in the NC, holding the DN
of the subschemasubentry directly beneath it, if you want to,
although it only adds minor efficiency gains since the subentry is
immediately subordinate to the NC context prefix entry anyway.
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
***************************************************