Subject: nameForms and dITContentRules

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 19 Aug 1999 12:02:25 -0600

NDS makes use of naming rules and content rules, but it does it differently than X.500.  It adds terms to the ObjectClassDescription and stores the information with the object class rather than in separate attributes (nameForms and dITContentRules).  At the bottom of this message is our modified ObjectClassDescription so you can see how it looks.

My questions are: Do other LDAP servers make use of naming and containment rules?  If so, how does a client read and write them?  I view connecting them to the object class as easier and more intuitive than using the nameForms and dITContentRules attributes.  I'm not sure what having them separate buys us.

NDSObjectClassDescription = "(" whsp
          numericoid whsp                     ; ObjectClass identifier
          [ "NAME" qdescrs ]
          [ "DESC" qdstring ]
          [ "OBSOLETE" whsp ]
          [ "SUP" oids ]                      ; Superior ObjectClasses
          [ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ]
                                              ; default structural
          [ "MUST" oids ]                     ; AttributeTypes
          [ "MAY" oids ]                      ; AttributeTypes
          [ "X-NDS_NOT_CONTAINER" qdstrings ] ; default container ('0')
          [ "X-NDS_NONREMOVABLE" qdstrings ]  ; default removable ('0')
          [ "X-NDS_CONTAINMENT" qdstrings ] 
          [ "X-NDS_NAMING" qdstrings ] 
       whsp ")"

Valid values for the qdstrings following X-NDS_NOT_CONTAINER are '0' (false) and '1' (true). If true, instances of this object class may not contain other object entries (it is a leaf node).
	
Valid values for the qdstrings following X-NDS_NONREMOVABLE are are '0' (false) and '1' (true). If true, this object class MAY NOT be removed from the schema. This term is read-only and is set only on base NDS schema object classes.

The qdstrings following X-NDS_CONTAINMENT contains a list of all object class names which may contain this object class. In other words, only entries that are of an object class listed here may be a direct superior in the DIT to entries of this object class. If this term is not included when defining an object class, it will be automatically filled with ( 'c' 'o' 'ou' 'l' 'domain')
	
The qdstrings following X-NDS_NAMING holds a list of all attribute type names which may be used to name this object class. If this term is not supplied when defining an object class, it will automatically be filled with a list of all MUST and MAY attributes which use human readable syntaxes.

---

From: "David Chadwick" <[email-masked]>
Date: Fri, 20 Aug 1999 17:15:22 +0100

Date forwarded: 	Thu, 19 Aug 1999 11:03:17 -0700 (PDT)
Date sent:      	Thu, 19 Aug 1999 12:02:25 -0600
From:           	"Jim Sermersheim" <[email-masked]>
To:             	<[email-masked]>
Subject:        	nameForms and dITContentRules
Forwarded by:   	[email-masked]

> NDS makes use of naming rules and content rules, but it does it
> differently than X.500.  It adds terms to the ObjectClassDescription and
> stores the information with the object class rather than in separate
> attributes (nameForms and dITContentRules).  At the bottom of this message
> is our modified ObjectClassDescription so you can see how it looks.
> 
> My questions are: Do other LDAP servers make use of naming and containment
> rules?  If so, how does a client read and write them?  I view connecting
> them to the object class as easier and more intuitive than using the
> nameForms and dITContentRules attributes.  I'm not sure what having them
> separate buys us.

In fact, if I read your definition correctly, it also contains Dit 
Structure Rules as well as name forms and content rules.

The reason for having these separate buys you flexibility. An object 
class is defined once and once only, and given a unique OID. If the 
object class definition is changed, then it should be given a new OID 
(so that everyone is singing from the same song sheet). Your 
extended construct requires the object class definer to define the 
DIT structure and entry contents all at once, and if these 
subsequently change (as surely they will, since directories are 
dynamic and administrators do find new objects and structures that 
they need to add from time to time) then your mega-object class 
definition will need to be updated and given a new OID. But I guess 
you break this latter rule as well dont you, by changing the definition 
and keeping the same OID.

David

>           numericoid whsp                     ; ObjectClass identifier [
>           "NAME" qdescrs ] [ "DESC" qdstring ] [ "OBSOLETE" whsp ] [ "SUP"
>           oids ]                      ; Superior ObjectClasses [ (
>           "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ]
>                                      ; default structural
>           [ "X-NDS_NOT_CONTAINER" qdstrings ] ; default container ('0') [
>           "X-NDS_NONREMOVABLE" qdstrings ]  ; default removable ('0') [
>           "X-NDS_CONTAINMENT" qdstrings ] [ "X-NDS_NAMING" qdstrings ] 
>        whsp ")"
> 
> Valid values for the qdstrings following X-NDS_NOT_CONTAINER are '0'
> (false) and '1' (true). If true, instances of this object class may not
> contain other object entries (it is a leaf node).
> 
> Valid values for the qdstrings following X-NDS_NONREMOVABLE are are '0'
> (false) and '1' (true). If true, this object class MAY NOT be removed from
> the schema. This term is read-only and is set only on base NDS schema
> object classes.
> 
> The qdstrings following X-NDS_CONTAINMENT contains a list of all object
> class names which may contain this object class. In other words, only
> entries that are of an object class listed here may be a direct superior
> in the DIT to entries of this object class. If this term is not included
> when defining an object class, it will be automatically filled with ( 'c'
> 'o' 'ou' 'l' 'domain')
> 
> The qdstrings following X-NDS_NAMING holds a list of all attribute type
> names which may be used to name this object class. If this term is not
> supplied when defining an object class, it will automatically be filled
> with a list of all MUST and MAY attributes which use human readable
> syntaxes.
> 
> 
> 

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

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

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