Subject: Re: nameForms and dITContentRules

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 20 Aug 1999 11:48:20 -0600

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

Oops, I got my wires crossed.  I meant to say structure rules, not 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. 

From our experience, people occasionally want to change (add optional) attributes.  They rarely want to change the naming or structure rules.  In fact, we've only recently entertained adding new naming attributes and structure rules.

What does it buy us to make the object class static but allow modifications to content, naming, and structure rules?  The goal behind a static object class seems to be interoperability. To me, we're saying, you can count on the OID of an objectclass to represent that object class, but this isn't true, you have to also look at its content, naming, and structure rules.  If an entry of objectclass 1.2.3.4 is exported from DIT A, and imported to DIT B (which also supports objectclass 1.2.3.4), the export/import process must be aware of the three X.500 subschema attributes in order to ensure the entry will look/behave the same on both DITs.

>But I guess 
>you break this latter rule as well dont you, by changing the definition 
>and keeping the same OID.

We do break this rule by allowing people to add more optional attributes to an object class. To fix that, I suppose we would need to either make use of content rules, or just make people subclass or use aux classes.. Currently, we don't allow the naming attributes to be changed, nor do we allow the containment (structure rules) to be changed (only specified when the object class is created).  To allow those features, we'd have to support name forms and structure rules (or be 'bad' and just allow them to change our existing object class definition).

Jim

---

From: "David Chadwick" <[email-masked]>
Date: Sun, 22 Aug 1999 20:13:41 +0100

Date sent:      	Fri, 20 Aug 1999 11:48:20 -0600
From:           	"Jim Sermersheim" <[email-masked]>

> What does it buy us to make the object class static but allow
> modifications to content, naming, and structure rules?  

One of the initial reasons (from what I recall) was that users 
searching the DIT could get information about certain known types 
of object and be guaranteed that they contained this minimum set of 
attributes. (They might contain additional ones as well, but that would 
be part of some other object class, which some other user might be 
interested in). Thus every attribute in an entry comes from some 
object class or another, that represents some facet of the entry. 
Each facet (ie object class) is guaranteed to be the same whichever 
server you contact, from whichever manufacturer, so there is some 
common standard throughout the world.

>The goal behind a
> static object class seems to be interoperability. 

True, that is also important.

>To me, we're saying, you
> can count on the OID of an objectclass to represent that object class, but
> this isn't true,

It is true. It does represent the object class but it does NOT 
represent the entry. An entry is typically many object classes.

Content rules were added later as a pragmatic way of tweaking the 
content of an entry but not altering its basic object class. In this way 
it is true that to find out EXACTLY the contents of an entry you can 
no longer rely solely on its object classes. You also have to consult 
the content rules.

But naming and structure rules are pretty much INDEPENDENT of 
the contents of an entry (except that the attributes of the RDN 
obviously have to be present in the entry :-)
These latter two are completely separate, in that two entries with the 
SAME contents can have different structure rules and name forms. 
As a simple example, consider a person working at head office (no 
OU in the DN) and one working in an org unit (an OU immediately 
superior).

> you have to also look at its content, naming, and
> structure rules.  If an entry of objectclass 1.2.3.4 is exported from DIT
> A, and imported to DIT B (which also supports objectclass 1.2.3.4), the
> export/import process must be aware of the three X.500 subschema
> attributes in order to ensure the entry will look/behave the same on both
> DITs.

Six actually - object classes and content rules govern content, name 
forms and structure rules govern position in DIT, and attribute types 
and matching rules govern display and searching.

> We do break this rule by allowing people to add more optional
> attributes to an object class. To fix that, I suppose we would need to
> either make use of content rules, or just make people subclass or use aux
> classes..

That would be the conformant way of doing things, yes

> Currently, we don't allow the naming attributes to be changed,
> nor do we allow the containment (structure rules) to be changed (only
> specified when the object class is created).  To allow those features,
> we'd have to support name forms and structure rules (or be 'bad' and just
> allow them to change our existing object class definition).
> 

True, but you do have other things going for you other than 
conformance to standards :-)

David

> Jim

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

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

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

---

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 23 Aug 1999 23:08:06 -0600

>content of an entry but not altering its basic object class. In this way 

That makes sense.  The only problem I remember seeing with this approach of 'extending' object classes is that the content rules aren't inherited by subclasses (but I'm veering off track).

>and matching rules govern display and searching.

Hmm, yeah thanks for the correction.  So back to my original (or at least intended) question which is unanswered. *Do LDAP directory vendors and client application writers want to do all of this, or is something more 'lightweight' preferable*?

Jim