Are the X.5xx documents available on-line?

Steven Bonneville wrote:
Jeff Clowser wrote:

  
Basically, part of the thread devolved to the idea of creating a single
user entry that has objectclasses:  inetorgperson, account,
posixaccount, shadowaccount, etc.  If I understand the response (see
below), this violates ldap standards because you are mixing in
structural objectclasses and that is not allowed(?)

This is all I could find that came close - rfc2251 seems to say servers
may disallow changing structural objectclasses on an entry (to prevent
changing a user to a country, for example).  RFC 2252 actually seems to
specifically say you _can_ mix structural objectclasses in one entry.
    

Well, sort of.  What X.501 says and the LDAP RFCs follow is that an entry
is characterized by exactly one *chain* of structural object classes that 
has exactly one structural object class as the most subordinate object 
class in the chain.  You then can add zero or more auxiliary object 
classes to add more attributes.  So an entry structured as

  objectclass: top
  objectclass: person
  objectclass: organizationalPerson
  objectclass: inetOrgPerson
  objectclass: posixAccount
  objectclass: shadowAccount

is legal.  The most subordinate structural object class is inetOrgPerson,
which the schema says is a subclass of organizationalPerson, which is a
subclass of person, which is a subclass of top.  The posixAccount and
shadowAccount object classes are auxiliary, so no problem including those.
Now, we can't add account as an object class of this entry, because it is
a structural object class that is not part of the structural object class
chain connecting inetOrgPerson to top, so we'd end up with two structural
object class chains -- that's illegal.

By using inetOrgPerson, you also have to include all of its superclasses.
So you can't have inetOrgPerson without organizationalPerson, for example.

If you can extend the schema, you can always derive a new structural 
class from an existing one.  The parent structural class still appears 
as an objectclass attribute of an entry since it is part of the superclass 
chain of the structural object class of the entry.  Look at evolutionPerson 
(in /usr/share/evolution-data-server-1.0/evolutionperson.schema on RHEL4)
for an example.  It's derived from inetOrgPerson and therefore gets all its 
attributes and the attributes of inetOrgPerson's superclasses.

  -- Steve Bonneville

--
Fedora-directory-users mailing list
Fedora-directory-users@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-directory-users