Subject: RFC2251: RootDSE subschemasubentry issue

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 07 Feb 2000 09:40:04 -0800

As previously noted <[email-masked]>,
RFC 2251 states subschemaSubentry attribute type within the
Root DSE may contain multiple values though the attribute type
is single valued.

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 list could be quite
large and, IMO, rather useless.  Applications need to known
which subschema controls which entries.

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. 

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:

  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.

Comments?

	Kurt

---

From: "David Chadwick" <[email-masked]>
Date: Tue, 8 Feb 2000 23:07:04 -0000

Date forwarded: 	Mon, 7 Feb 2000 09:40:11 -0800 (PST)
Date sent:      	Mon, 07 Feb 2000 09:40:04 -0800
To:             	[email-masked]
From:           	"Kurt D. Zeilenga" <[email-masked]>
Subject:        	RFC2251: RootDSE subschemasubentry issue
Forwarded by:   	[email-masked]

> Root DSE may contain multiple values though the attribute type

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.

> 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

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

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

> and that a note be added to the end of the section:

I disagree, but a better wording should be used.

>   subschema entry (or subentry) which controls the

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

>  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 [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: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 08 Feb 2000 15:42:42 -0800

At 11:07 PM 2/8/00 -0000, David Chadwick wrote:
>single valued attribute?

Yes.

RFC 2252, 5.1.5. subschemaSubentry 
   
   The value of this attribute is the name of a subschema entry (or
   subentry if the server is based on X.500(93)) in which the server
   makes available attributes specifying the schema.

    ( 2.5.18.10 NAME 'subschemaSubentry'
      EQUALITY distinguishedNameMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 NO-USER-MODIFICATION
      SINGLE-VALUE USAGE directoryOperation )

>This is surely wrong, as the definition must 

I believe SINGLE-VALUED is appropriate as an entry can only
have one controlling subschema subentry.  I believe the
use of this attribute type when the RootDSE to list available
subschema subentries is inappropriate as it imparts no
knowledge to the client as to which value controls which
entries.

>   subschemaSubentry attribute in the root DSE.

Which implies that the subschema controlling an
entry may not be listed in the RootDSE whilst other
subschemesubentries are listed, such as when the
entry is not mastered by the server (and subschema
not published this slaves), yet other name contexts
are.

>equivalent number of values"

In the Root DSE, which subschemasubentry value(s) belongs to
which namingContexts value(s)?

>schema of the root DSE - nothing does.

Something must... a client should be able to determine the
schema of attributes provided in the RootDSE and should
have some mechanism to determine which schema controls
the RootDSE.

>Rather it controls the 

Which naming context?

A server can support multiple naming contexts each with
different controlling subschemas.  The subschemasubentry
values of the RootDSE are fairly worthless without knownledge
of which value controls which naming context.

---

From: Mark Wahl <[email-masked]>
Date: Wed, 09 Feb 2000 07:24:05 -0600

The role of the subschemaSubentry attribute of the root DSE was discussed on
the IETF-ASID mailing list during the design of LDAPv3.   It provides an 
important adminstrative function to allow management clients to determine the
capabilities of an LDAP server and the data it contains.  

Mark Wahl, Directory Product Architect
Innosoft International, Inc.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 09 Feb 2000 08:49:41 -0800

At 07:24 AM 2/9/00 -0600, Mark Wahl wrote:
>the IETF-ASID mailing list during the design of LDAPv3.

Are the archives to the IETF-ASID mailing list still available?

>It provides an important adminstrative function to allow management
>clients to determine the capabilities of an LDAP server and the data
>it contains.  

A couple of questions:

How does a client determine which subschema subentry controls the
RootDSE?  David said that this wasn't needed.  I disagre. The RootDSE
may contain additional attributes to which the client may desire to
access and hence may desire to discover schema for. It's possible that
attribute type "foo" be listed differently in two different subschemas
(because each was being separately maintained).  Which defines "foo"
as used in the Root DSE?

But how can an attribute type restricted to SINGLE-VALUE (RFC 2252)
take on multiple values as prescribed (RFC 2251)?   Seems that one
of the two documents must be in error.

Kurt

---

From: "David Chadwick" <[email-masked]>
Date: Wed, 9 Feb 2000 19:26:37 -0000

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

---

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

Yes.

The next questions are:

What other attributes published in RootDSE are naming
context specific?

I've seen a lot of proposals (including my own) which
suggest attributes for publishing capabilities.  It's
likely that some of these are not server specific,
but are naming context specific.

From the design perpective, I see different ways of
providing naming context specific information:

1) add new attributes which provide the context
and the capability as combined value.  (Ie:
 1A)	dn:  (root dse)
	subschemasubentries: dc=openldap,dc=org $
	 ( cn=subschema $ cn=openldap-subschema )
	subschemasubentries: dc=example,dc=com $ cn=subschema
	...

or:
 1B)	dn: (root dse)
	subschemasubentries: dc=openldap,dc=org $ cn=subschema
	subschemasubentries: dc=openldap,dc=org $ cn=opendlap-subschema
	subschemasubentries: dc=example,dc=com $ cn=subschema

2) provide an attribute which lists naming contexts
AND a provides a DN of an entry (or subentry) which
contains attributes describing the naming context
specific capabilities.

	dn: (root dse)
	namingContextCapabilities: dc=openldap,dc=org $ cn=openldap
	namingContextCapabilities: dc=example,dc=com $ cn=example

	dn: cn=openldap
	subschemasubentries: cn=subschema
	subschemasubentries: cn=openldap-subschema

	dn: cn=example
	subschemasubentires: cn=subschema

Comments?

---

From: "David Chadwick" <[email-masked]>
Date: Thu, 10 Feb 2000 14:22:17 -0000

> >Do you agree with this analysis?

Good, we are making progress towards resolution.

> What other attributes published in RootDSE are naming

The question should actually be wider than this I believe. i.e. What 
attributes are NC specific and what attributes are server specific 
and what attributes are Management Domain specific, since

i) a Man Domain can comprise many servers
ii) a server can hold many NCs
iii) a server can hold many Man Domains.

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?

> but are naming context specific.

agreed

> contains attributes describing the naming context

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

>  subschemasubentries: cn=openldap-subschema

Why would you have 2 subschemasubentries for 1 NC?
I think only one is needed (this is mandatory at the moment I believe)

David

David Chadwick

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 10 Feb 2000 11:00:56 -0800

>iii) a server can hold many Man Domains.

Yes...

>attributes (this is in line with X.500(93)).

Might be workable... [see below]

>so that no pointer is needed in the rootDSE.

I would like to have attribute type in the NC who's value
named the entry (or subentry) so as to avoid hardcoding the
DN of the subentry.  So, I'd like a pointer... but the
pointer can be in the NC.

If in the RootDSE, then it needs to contain both the DN of
the namingContext and the DN of the subentry.

>Why would you have 2 subschemasubentries for 1 NC?

Separate subschema administrative areas within the NC.
[See Mark Wahl's comment]

---

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

> [See Mark Wahl's comment]

I proposed solving this problem by having separate subschema 
subentries below each administrative point (ala X.500), then we still 
can retain single valued attributes. This is what I understood Mark 
was also proposing. Since the NC will probably be (but not 
necessarily) an administrative point anyway, then it will usually have 
a subschema subentry below it. For the few (rare?) cases where the 
NC is not an admin point (e.g. an orgs DIT is distributed across 2 
servers and thus 2 NCs, but both are controlled by the same 
subschema) X.500 proposes having one subentry beneath the 
upper NC, and this would be replicated into the subordinate server. 
LDAP servers could choose instead to hold a copy of this 
subschema subentry beneath the subordinate NC context prefix if 
you wished to, or you could go with the X.500 model).

I dont object to you also holding a pointer in the NC, holding the DN 
of the subschemasubentry directly beneath it, if you want to, 
although it only adds minor efficiency gains since the subentry is 
immediately subordinate to the NC context prefix entry anyway.

David

David Chadwick