Re: RFC2251: RootDSE subschemasubentry issue

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

At 08:58 AM 2/11/00 -0500, Mark C Smith wrote:
>David Chadwick wrote:
>> 
>> > As Thomas Salter has already pointed out, the subschema subentry
>> > associated with a given naming context can be found by reading the
>> > naming context entry.
>> 
>> This is true.
>> 
>> >The root DSE already contains the set of naming
>> > contexts. Therefore the current model is not broken.
>> 
>> . Not broken in that way, but it still is, in that a single valued attribute
>> is required to hold multiple values
>
>I'd really prefer we choose the simple solution to this problem: 
>change the subschemasubentry attribute to multivalued, but stipulate
>that it can only have one value when it appears outside the rootDSE.

Sounds simple... but one cannot generally redefine an attribute
type, one must introduce a replacement attribute type.

>Does that solve the problem at hand?

No, because the client doesn't which subset of entries may
be controlled by a given value.   Additional information
is needed, such as a DN indicing the subtree of applicability,
to make the information generally useful.

>
>> 
>> >Also, in the
>> > current model, a server may have several naming contexts referring to
>> > a single subschema subentry. This would not be possible if subschema
>> > subentries were assumed to be under the naming context.
>> 
>> I dealt with this one by saying that in this case the subschema
>> subentry would be below the administrative point for the domain, if
>> they are all in the same management domain (In fact this is the
>> model the NHS are using in the UK).
>
>But as far as I know LDAPv3 doesn't require that servers support
>administrative domains at all.  Some servers do, some do not.  Also,
>what if the naming contexts are disjoint yet all share the same schema?
>That is a very common situation today.

I agree this is common and the information model should support
sharing of subschema across multiple naming contexts.   I suggest
we don't adopt a means which "hardcodes" the name and/or
location of subschema subentries so as to maintain the greatest
amount of flexibility possible.