Re: adding url attribute to Organization or Organizational unit

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 11:27 AM 1/18/00 +1300, Graeme Joyce wrote:
>> That is, each entry should be of one structural objectclass.  You
>> should list derived classes as values of the objectclasses values.
>> Once created, you should never change, add, modify, delete the
>> objectclasses which affect the "structure" of the entry.  That is,
>> you shouldn't change a person to an inetOrgPerson (or vica versa)
>> after initial creation.
>>
>
>Just wondering how to correctly define the objectclass values for an
>"inetOrgperson" entry:
>
>1)
>objectclass: top
>objectclass: person
>objectclass: organizationalperson
>objectclass: inetorgperson
>
>OR
>
>2)
>objectclass: top
>objectclass: inetorgperson
>
>Does 1) meet the criteria: "entry should be of one structural class" ?

Don't confuse values of objectclass attribute with an entry's
structural object class.  The objectclass attribute lists all
object classes to which this entry has properties of.  On an
LDAPv3 server, both of the above the same... on an LDAPv2 you
should 1 as an LDAPv2 may not expand the list to included classes
derived from listed classes.

But note, in both examples above, the entry has the properties of
person, organizationalperson, inetOrgPerson BUT is structually an
inetOrgPerson.

Maybe I should clarify with two examples:

	dn: cn=foo
	objectclass: person
	objectclass: domain

This is illegal.  A person is not a domain and a domain is not
a person.

	dn: cn=foo
	objectclass: person

the:
	dn: cn=foo
	changetype: modify
	add: objectclass
	objectclass: inetOrgPerson

This is illegal.  One cannot modify the structural objectclass of
an entry.  To (correctly) make such a change requires the entry
be deleted and added as:
	dn: cn=foo
	objectclass: inetOrgPerson

Now, in LDAPv3, any class from which the listed objectclasses are
automatically added for you.  However, most LDAPv2 servers do NOT
expand the listing for you.  You should do this yourself.  Hence,
the first list is preferred.

>Is 2) acceptable, assuming you have no clients that require the "person" or
>"organizationalperson" objectclasses on the entry?

An entry which is structurally an inetOrgPerson has the properties of
"organizationalPerson", "person", and "top", but is structurally the
entry is an inetOrgPerson.

For LDAPv2, you should expand the list of objectclass values to
include all objectclasses derived from the entry's structural
object class and any listed auxiliary object class.  This is done
for the client in LDAPv3.