Re: RFC2251: RootDSE subschemasubentry issue

[David Chadwick <d.w.chadwick@salford.ac.uk>]

Date forwarded: 	Mon, 7 Feb 2000 09:40:11 -0800 (PST)
Date sent:      	Mon, 07 Feb 2000 09:40:04 -0800
To:             	ietf-ldapext@netscape.com
From:           	"Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject:        	RFC2251: RootDSE subschemasubentry issue
Forwarded by:   	ietf-ldapext@netscape.com

> As previously noted <8525679B.003DD02B.00@D51MTA04.pok.ibm.com>,
> RFC 2251 states subschemaSubentry attribute type within the
> Root DSE may contain multiple values though the attribute type
> is single valued.

Sorry, I dont follow this. What do you mean by "THe attribute type is 
single valued." Do you mean the attribute type definition mandates a 
single valued attribute? This is surely wrong, as the definition must 
allow for multiple values.

> 
> I do not believe it necessary to provide a mechanism to allow
> clients to obtain a complete list of subschema entries (or
> subentries) known to this server. 

This is part of the confusion, and is due to poor wording in 2251. 
What the RFC is trying to say is "subschema entries known to be 
controlling the entries held in this server". It does not mean 
subschema entries anywhere in the world that this server happens to 
know about.  If you read further in the RFC you will find some 
limited clarification about subschema subentries for master and 
copy entries viz:

If the server does not master entries and does 
not know the locations
   of schema information, the subschemaSubentry 
attribute is not present
   in the root DSE.  If the server masters 
directory entries under one
   or more schema rules, there may be any number 
of values of the
   subschemaSubentry attribute in the root DSE.


Again, this is ambiguously worded, as "may be any 
number of values" should really be "will be an 
equivalent number of values"


> This list could be quite
> large and, IMO, rather useless.  Applications need to known
> which subschema controls which entries.

Agreed. This is due to a wrong interpretation of the RFC (due to 
ambiguous wording)

> 
> I suggest that applications obtain the DN of the subschema entry
> (subentry) from either the entry(ies) they intend to access or
> from the entry at the root of the naming context. 

In general a client may not know the root of the naming context, but 
will know the root of the DIT, hence the ability to find the subschema 
entry from the root.

> 
> To resolve this issue, I suggest:
> 
> RFC 2251, 3.4 "--subsubschemaSubentry" subsection be removed
> and that a note be added to the end of the section:

I disagree, but a better wording should be used.

> 
>   Note: the subsubschemaSubentry attribute type, if
>   present, contains the Distinguished Name of the
>   subschema entry (or subentry) which controls the
>   schema for the Root DSE.

This is wrong. The subschema subentry does not control the 
schema of the root DSE - nothing does. Rather it controls the 
schema of a naming context.

David

> 
> Comments?
> 
>  Kurt
> 
> 
> 


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

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

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