Subject: RE: RFC2251: RootDSE subschemasubentry issue

From: Gil Kirkpatrick <[email-masked]>
Date: Thu, 10 Feb 2000 19:33:06 -0700

David,

Why does the rootDSE need to contain subschemaSubentrys for each NC hosted
by the server? Why is not sufficient to maintain the subschemaSubentrys in
the NCs themselves?

-gil

Gil Kirkpatrick
Director of Engineering
Netpro

> -----Original Message-----
> From:	David Chadwick [SMTP:[email-masked]]
> Sent:	Wednesday, February 09, 2000 12:27 PM
> To:	Kurt D. Zeilenga; [email-masked]; Mark Wahl
> Subject:	Re: RFC2251: RootDSE subschemasubentry issue
> 
> Mark, Kurt
> 
> I think I have an answer to the problem(s) being posed by Kurt.
> 
> The model as it stands is OK if a server only masters one naming 
> context. Everything works fine. All the entries in the NC and the 
> rootDSE can contain the subschemaSubentry attribute which points 
> to the single subschema subentry.
> 
> The problem arises once we have multiple NCs in a server. The 
> subschemaSubentry attribute can still be single valued and exist in 
> each entry in each NC and point to the correct subschema 
> subentry. However, the attribute in the root DSE no longer works, for 
> two reasons.
> 
> Firstly it is supposed to be single valued (as Kurt pointed out) and 
> now it needs to have multiple values.
> 
> Secondly, (again as Kurt pointed out) there is no way for the user to 
> know from the multivalued attribute in the rootDSE which value 
> points to which subschema subentry for which NC. THis of course is 
> not a problem for the entries within the NC, as they only still need a 
> single pointer to their one and only subschema subentry.
> 
> Thus I conclude that the model is broken for multiple naming 
> contexts, and that the subschemaSubentry attribute in the rootDSE 
> needs to be replaced by a multivalued attribute, having two 
> components - the context prefix of an NC (an LDAP DN), and the 
> pointer to the subschemaSubentry.
> 
> Do you agree with this analysis?
> 
> 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: "David Chadwick" <[email-masked]>
Date: Sat, 12 Feb 2000 13:57:14 -0000

Date forwarded: 	Thu, 10 Feb 2000 18:36:03 -0800 (PST)
From:           	Gil Kirkpatrick <[email-masked]>
To:             	"[email-masked]'" <[email-masked]>,
       	"Kurt D. Zeilenga" <[email-masked]>, [email-masked],
       	Mark Wahl <[email-masked]>
Subject:        	RE: RFC2251: RootDSE subschemasubentry issue
Date sent:      	Thu, 10 Feb 2000 19:33:06 -0700
Forwarded by:   	[email-masked]

> David,
> 
> Why does the rootDSE need to contain subschemaSubentrys for each NC
> hosted by the server? Why is not sufficient to maintain the
> subschemaSubentrys in the NCs themselves?
> 

The original reason (if I remember correctly) was because the 
subschema subentries could be held anywhere in the DIT by an 
LDAP server, and not necessarily within the NCs. Thus pointers to 
them were needed, and the rootDSE was the obvious place to put a 
pointer that everyone would know how to get at. It was the LDUP 
group that first defined subentries beneath the NC context prefix, 
and this came way after the LDAP RFCs were published. I dont 
know if this has yet been widely accepted as a way of stroring 
subschema entries or not. If not, then pointers are still needed to the 
entries, where ever they may be in the NC.

David

> > rootDSE can contain the subschemaSubentry attribute which points to
> > the single subschema subentry.
> > 
> > each entry in each NC and point to the correct subschema subentry.
> > However, the attribute in the root DSE no longer works, for two
> > reasons.
> > 
> > Secondly, (again as Kurt pointed out) there is no way for the user
> > to know from the multivalued attribute in the rootDSE which value
> > not a problem for the entries within the NC, as they only still need
> > a single pointer to their one and only subschema subentry.
> > 

David Chadwick