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 at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-directory-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.fedoraproject.org/pipermail/389-users/attachments/20050826/e8db419d/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3312 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20050826/e8db419d/attachment.bin
