Re: RFC2251: RootDSE subschemasubentry issue

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 02:22 PM 2/10/00 -0000, David Chadwick wrote:
>
>> 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.

Yes...

>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?

Might be workable... [see below]

> 
>> 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.

I would like to have attribute type in the NC who's value
named the entry (or subentry) so as to avoid hardcoding the
DN of the subentry.  So, I'd like a pointer... but the
pointer can be in the NC.

If in the RootDSE, then it needs to contain both the DN of
the namingContext and the DN of the subentry.

>Why would you have 2 subschemasubentries for 1 NC?

Separate subschema administrative areas within the NC.
[See Mark Wahl's comment]