Using distingushed name components as attributes.

[Stuart Schmukler <Stuart.Schmukler@ncal.kaiperm.org>]

I may be very dense here, but I loss in LDAP and X.500 naming land.  Does a name 
component attribute have to exist in the LDAP entry in addition to being in the DN of the entry?

I want to construct a tree structured name space for the organixation of
some program objects. The structure is:
	Division
	   Facility
	     Department
                         Unit
                            Role
                                ResourceID

Does a name component attribute have to exist in the LDAP entry in addition
to being in the DN of the entry?  The question boils down to building entries one
of two ways.

First way the entry has the name value pairs in both the 'dn' and as separate attributes:

dn: resourceid=0001, role=md, unit=4b, department=medicine, facility=Mountain View, divison=CA
objectclass: top
objectclass: mednode
resourceid=0001
role=md
unit=4b
department=medicine
facility=Mountain View
divison=CA
telephonenumber: +1 510 267 5491
...

The second way, the entry has the name value pairs only in the 'dn'

dn: resourceid=0001, role=md, unit=4b, department=medicine, facility="Mountain View", Divison=CA
objectclass: top
objectclass: person
telephonenumber: +1 510 267 5491
...

The second way seems to have less duplication and it may be possible to build the system without 
private a objectclass that has the names of the structure levels fixed when the LDBMs is started.  Fixing
the structure is a problem if there is a type of level added to the system tomorrow.  

I know that I can do something akin to the first example with 'dc's:

dn: resourceid=0001, dc=md, dc=4b, dc=medicine, dc=Mountain View, dc=CA
objectclass: top
objectclass: domain

Above losses the information about the structure of the name space because the type each name component is 
lost.  

Any pointers to information would help.

SaS (Stuart Schmukler 510-267-5491)