[Fedora-directory-users] Wishlist

[Jeff Clowser]

Steven Bonneville wrote:

> 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...
>
>...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.
>  
>
Just talking this through:
I was looking for where this is specifically stated as illegal.  I guess 
the answer to this is the X.501 spec (I think it costs money to get 
this, though?). 

RFC2252 states "The format for representation of object classes is 
defined in X.501 [3].  In general every entry will contain an abstract 
class ("top" or "alias"), at least one structural object class, and zero 
or more auxiliary object classes.".  This could be interpreted as 
saying: LDAP is based on and follows X.501, unless otherwise specified, 
and here is where we specifically state where LDAP differs from X.501, 
and X.501 has this limit, but strictly speaking, LDAP does not(?)  I 
suppose you could also interpret that as allowing multiple structural 
objectclasses, as long as they have a common ancestor (the LDAP RFC 
doesn't say that, but I suppose that might be more clearly stated in the 
X.501 spec?).  Sounds like I am stepping into an LDAP/X.50x holy war :)

Thinking about this in a real-world context, given/if multiple 
structural objectclasses are illegal, then it seems that the definition 
of the account objectclass is poorly thought out (granted, it was 
defined long, long ago...) - it makes sense to extend a person entry to 
be an account (or vice versa), so that you don't have to have separate 
entries for one person to define unix login, "account" info, etc - I 
should be able to define a single user all in one entry, so that if I 
want to change a users password, grant or remove access to services, 
etc, I do it in one place. (maybe a bad example, since account doesn't 
include a password, which seems kinda strange itself...)  Otherwise, you 
defeat part of the purpose of LDAP, and violate some basic tenants of 
data design (i.e. avoiding duplication of data, etc).

FWIW, this all started with a discussion of posixAccount, and how to 
restrict what hosts a user can log into.  My initial thought was to just 
add the account objectclass to a user to have a host attribute for a 
user (wouldn't have to extend the schema, and could use existing 
standard oc's) , but then you run into the multiple structural oc's 
issue.  I guess the "right" answer would be to define a non-standard 
objectclass that is an extention of person, posixaccount, or whatever 
that allows the host attribute.

 - Jeff