[Fedora-directory-users] Wishlist

[Rich Megginson]

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://listman.redhat.com/archives/fedora-directory-users/attachments/20050826/e8db419d/attachment.htm>
-------------- 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://listman.redhat.com/archives/fedora-directory-users/attachments/20050826/e8db419d/attachment.bin>