[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: RFC2251: RootDSE subschemasubentry issue
> >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.
>
I agree with Kurt on this.
> >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.
>
This is true if the subentries can be held anywhere. The alternative
is to have a defined set of positions for them (as X.500 and LDUP
have done). In the latter case, pointers are not essential (but may
be an aid to efficiency).
>
> >But as far as I know LDAPv3 doesn't require that servers support
> >administrative domains at all. Some servers do, some do not. Also,
Administrative domains always exist. (Someone has to administer
the DIT subtrees). So a product that supports this element of reality
is better than one that does not
> >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.
>
>
This is arguing for pointers rather than fixed positions. Basically you
pays your money and takes your choice. I dont have a strong
preference for either. But once the decision is made then the model
has to be made to fully support it. We are currently in the position
where the model does not fully support fixed positions or pointers,
without some modification to it. And it is quite complex given the
multiple combinations you can have of administrative domains and
naming contexts.
David
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
***************************************************