Subject: Re: subschemaSubentry within the root DSE

From: "Timothy Hahn" <[email-masked]>
Date: Mon, 12 Mar 2001 13:36:54 -0500

Kurt,

I agree with your proposed changes.

Further, I would suggest some sort of note that a common mechanism for 
determining the active schema(s) for a server is to query the 
subschemasubentry attribute for each of the naming context DNs that are 
found in the namingContexts attribute of the root DSE.

Regards,
Tim Hahn

Internet: [email-masked]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681

Sent by:        [email-masked]
To:     [email-masked]
cc: 
Subject:        subschemaSubentry within the root DSE

As discussed previously (LDAPext, LDAPbis lists), RFC 2251
Section 3.4 use of subschemaSubentry is significantly flawed.

The following attributes of the root DSE are defined in section 5 of
[5].  Additional attributes may be defined in other documents.
  ...
   - subschemaSubentry: subschema entries (or subentries) known by this
     server.

The subschemaSubentry attribute, like all other subschemaSubentry,
should provide the name of the entry (or subentry) containing
the subschema controlling the entry.  That is, the
subschemaSubentry attribute contained in the root DSE should
refer to the particular subschema subentry containing the
subschema controlling the root DSE itself.

I note that 3.4 use calls for the subschemaSubentry to be used
in a manner which is clearly inconsistent with the primary use
of subschemaSubentry [and its description (as single-valued and
directoryOperation)].

Hence, I suggest the following changes be made to RFC 2251:

The 3.4 text:
   - subschemaSubentry: subschema entries (or subentries) known by this
     server.

be replaced with:
   - subchemaSubentry: the name of the subschema entry containing the
        schema controlling the root DSE.

The 3.4 text:
   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.

be deleted.

Section 6.2 text:
   The client can retrieve the subschema entries referenced by
   the subschemaSubentry attribute in the server's root DSE or
   in entries held by the server.

be replaced with:
   The client can obtain the name of the subschema entry (or
   subentry) controlling a particular entry by retrieve that
   entry's subschemaSubentry attribute.

These changes make the use of subschemaSubentry attribute consistent
throughout the LDAP technical specification and with X.500.

The addition of a note that LDAP does not address the subschema
chicken and egg problem (discovery of schema controlling a yet
to be added entry at the root of a subschema administrative
area) might be also be appropriate.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 12 Mar 2001 12:04:48 -0800

At 01:36 PM 3/12/01 -0500, Timothy Hahn wrote:
>Further, I would suggest some sort of note that a common mechanism for determining the active schema(s) for a server is to query the subschemasubentry attribute for each of the naming context DNs that are found in the namingContexts attribute of the root DSE.

There may be multiple subschemas controlling various entries
within a naming context.  Subschemas may local to administrative
areas in accordance with X.500 models.  Administrative areas
may be as small as one entry.

In general, to determine all the subschema entries controlling
entries within a namingContext, the client would request the
return of the subschemaSubentry attribute for each entry in
the context.  The client should not assume that any two entries
within the context are controlled by the same subschema without
knowledge of subschema administrative areas in play.

We need to avoid discussing administrative areas in LDAP (in
the TS) as this is an area of future standardization.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 12 Mar 2001 12:12:40 -0800

>       schema controlling the root DSE.

s/subchema/subschema/ 
s/entry/entry (or subentry)/

>  entry's subschemaSubentry attribute.

s/controlling/containing the controlling schema of/

>area) might be also be appropriate.

Of course, the problem with adding such a note is that it would
beg the question "What's an administrative area?"... and I don't
think we want/should/can to go there.

Kurt