Subject: objectclass of a subschemasubentry

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 10 Aug 1999 09:58:35 -0700

OpenLDAP's default subschemasubentry (cn=schema) list "subschema",
"extensibleObject", and "top" as objectclass values.  I just
realized that "subschema" is defined in RFC2252 as AUXILIARY
and as such our subschema subentry is without a STRUCTURAL
objectclass.

What is the recommended STRUCTURAL objectclass for subschema
subentries?

Kurt

---

From: Ella Paton Bassett <[email-masked]>
Date: Tue, 10 Aug 1999 14:22:35 -0400

Kurt:

From X.501:

13.2.1	The Subentry object class
The subentry object class is a structural object class and is defined as
follows:
subentry OBJECT-CLASS ::= {
	SUBCLASS OF	 	{ top }
	KIND			structural
	MUST CONTAIN	{ commonName | subtreeSpecification }
	ID				id-sc-subentry }

Annex A

id-sc-subentry	OBJECT IDENTIFIER	::=	{id-sc 0}

subentry	ID	::= 	{ds 17}

Ella

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 10 Aug 1999 23:41:18 -0700

>	MUST CONTAIN	{ commonName | subtreeSpecification }

I take it that's it's your opinion that RFC2252 then is in error
and that the subschema object class should be STRUCTURAL.   Do
others agree with this?

---

From: Ella Paton Bassett <[email-masked]>
Date: Wed, 11 Aug 1999 08:49:10 -0400

Kurt:

The subschema object class remains auxiliary. RFC 2252 should include
the subentry object class. Entries for the subschema would include the
object identifier for both the subschema object class and the subentry
object class.

Ella

---

From: Helmut Volpers <[email-masked]>
Date: Wed, 11 Aug 1999 15:32:07 +0200

I agree:

the SUBENRTY ObjectClass is structural and the
SUBSCHEMA ObjectClass is auxiliary. (in X.501)

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 11 Aug 1999 07:38:13 -0700

>object identifier for both the subschema object class and the subentry

Thanks for the clarification (I misread your previous post... I
inadvertently s/subentry/subschema/ when I read it).

I also noticed that the LDUP specifications rely on an LDAPsubentry
structural object class.  This seems more usable to me as it
doesn't require substreeSpecification attribute.  The single valueness
of subtreeSpecifiation would disallows a subschemaSubentry from
being used to define rules for multiple namingContexts (which our
server currently supports).

I believe the LDAP RFCs should be clarified which structural
object class should be used for subschema subentries
and how a client may determine which subschema subentry
(listed in the RootDSE) applies to which namingcontexts.

X.500 gives one approach.  Another would be use LDAPsubentry
as the structural object class for subentries.   As clients
can determine which subschema rules applies on a per DSE
basis already, listing of such in the subschemaSubentry is
not needed.

Has an OID been assigned to the LDAPsubentry object class?

On a related note, of what structural class should the rootDSE be?

Kurt

---

From: Mark Wahl <[email-masked]>
Date: Wed, 11 Aug 1999 10:17:44 -0500

At the time the LDAPv3 RFCs were completed, there was concern by a number 
of implementors that they did not want to have the subentry object class
included in RFC 2251/2252.  Therefore, we only included the subschema 
object class.  The definition of the subentry class could be found in 
X.501. Note that the use of the subentry class would typically be based on
an administrative model of a subentry being limited to the a single 
administrative area.   Other models do not have that limitation, and allow
a single subentry to cover multiple administrative areas.  Since 2251/2252 
only concerns itself with subschema _retrieval_, then this was not as big a 
problem as the upcoming draft on subschema advanced services (including 
maintenance) where the client would need to determine what model the server 
supported to best identify where it could create new subschema entries or 
subschema subentries. 

Mark Wahl, Directory Product Architect
Innosoft International, Inc.

---

From: "David Chadwick" <[email-masked]>
Date: Wed, 18 Aug 1999 16:18:49 +0100

Date forwarded: 	Wed, 11 Aug 1999 07:39:50 -0700 (PDT)
Date sent:      	Wed, 11 Aug 1999 07:38:13 -0700
To:             	Ella Paton Bassett <[email-masked]>
From:           	"Kurt D. Zeilenga" <[email-masked]>

> doesn't require substreeSpecification attribute.  The single valueness of
> subtreeSpecifiation would disallows a subschemaSubentry from being used to
> define rules for multiple namingContexts (which our server currently
> supports).

Just to let you know that the single value restriction is being removed 
in X.500 (2000)

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

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