[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: RFC2251: RootDSE subschemasubentry issue
> At 07:26 PM 2/9/00 -0000, David Chadwick wrote:
> >Do you agree with this analysis?
>
> Yes.
Good, we are making progress towards resolution.
>
> The next questions are:
>
> What other attributes published in RootDSE are naming
> context specific?
The question should actually be wider than this I believe. i.e. What
attributes are NC specific and what attributes are server specific
and what attributes are Management Domain specific, since
i) a Man Domain can comprise many servers
ii) a server can hold many NCs
iii) a server can hold many Man Domains.
So we really need placeholders for all of these.
It seems to me like the rootDSE should hold server specific
attributes, a subentry under the NC context prefix should hold NC
specific attributes (this is in line with the LDUP group I believe), and
a subentry under an Admin Point should hold Man Domain specific
attributes (this is in line with X.500(93)).
What do you think?
>
> I've seen a lot of proposals (including my own) which
> suggest attributes for publishing capabilities. It's
> likely that some of these are not server specific,
> but are naming context specific.
agreed
>
> From the design perpective, I see different ways of
> providing naming context specific information:
>
> 1) add new attributes which provide the context
> and the capability as combined value. (Ie:
> 1A) dn: (root dse)
> subschemasubentries: dc=openldap,dc=org $
> ( cn=subschema $ cn=openldap-subschema )
> subschemasubentries: dc=example,dc=com $ cn=subschema
> ...
>
> or:
> 1B) dn: (root dse)
> subschemasubentries: dc=openldap,dc=org $ cn=subschema
> subschemasubentries: dc=openldap,dc=org $ cn=opendlap-subschema
> subschemasubentries: dc=example,dc=com $ cn=subschema
>
> 2) provide an attribute which lists naming contexts
> AND a provides a DN of an entry (or subentry) which
> contains attributes describing the naming context
> specific capabilities.
Or, an attribute which lists NCs and have subentries under the NCs,
so that no pointer is needed in the rootDSE.
>
> dn: (root dse)
> namingContextCapabilities: dc=openldap,dc=org $ cn=openldap
> namingContextCapabilities: dc=example,dc=com $ cn=example
>
> dn: cn=openldap
> subschemasubentries: cn=subschema
> subschemasubentries: cn=openldap-subschema
Why would you have 2 subschemasubentries for 1 NC?
I think only one is needed (this is mandatory at the moment I believe)
David
>
> dn: cn=example
> subschemasubentires: cn=subschema
>
>
> Comments?
>
>
***************************************************
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
***************************************************