Re: nameForms and dITContentRules

[David Chadwick <d.w.chadwick@salford.ac.uk>]

Date sent:      	Fri, 20 Aug 1999 11:48:20 -0600
From:           	"Jim Sermersheim" <JIMSE@novell.com>

> 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.

> 
> >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..

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 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

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