[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: nameForms and dITContentRules
Date forwarded: Thu, 19 Aug 1999 11:03:17 -0700 (PDT)
Date sent: Thu, 19 Aug 1999 12:02:25 -0600
From: "Jim Sermersheim" <JIMSE@novell.com>
To: <ietf-ldapext@netscape.com>
Subject: nameForms and dITContentRules
Forwarded by: ietf-ldapext@netscape.com
> 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
>
> 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.
>
>
>
***************************************************
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 D.W.Chadwick@salford.ac.uk *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
***************************************************