[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: RFC2251: RootDSE subschemasubentry issue
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]