Subject: Re: RFC2251: RootDSE subschemasubentry issue

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 10 Feb 2000 11:07:14 -0700

>>> "David Chadwick" <[email-masked]> 2/10/00 7:24:12 AM >>>

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

<snip>

>Or, an attribute which lists NCs and have subentries under the NCs, 
>so that no pointer is needed in the rootDSE.

This makes sense to me. The current model of listing the DN's of all known subschema subentries is confusing because of the "decoupled from NCs" problems already discussed. As long as a client can discover the NCs, it can discover the entire set of subschema subentries.

Jim

---

From: Andy Coulbeck <[email-masked]>
Date: Thu, 10 Feb 2000 12:33:17 -0600

> This makes sense to me. The current model of listing the DN's of all known subschema subentries is confusing because of the "decoupled from NCs" problems already discussed. As long as a client can…

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. The root DSE already contains the set of naming
contexts. Therefore the current model is not broken. 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.

---

From: "David Chadwick" <[email-masked]>
Date: Thu, 10 Feb 2000 23:04:29 -0000

> 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

>Also, in the

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

Hope that helps

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 [email-masked]
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

***************************************************

---

From: [email-masked] (Mark C Smith)
Date: Fri, 11 Feb 2000 08:58:36 -0500

> 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.
Does that solve the problem at hand?

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

-- 
Mark Smith
iPlanet Directory Architect / Sun-Netscape Alliance
My words are my own, not my employer's.   Got LDAP?

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 11 Feb 2000 08:58:48 -0800

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

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

---

From: "David Chadwick" <[email-masked]>
Date: Sat, 12 Feb 2000 13:57:15 -0000

> type, one must introduce a replacement attribute type.

I agree with Kurt on this.

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

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