[Fedora-directory-users] Wishlist

[Rich Megginson]

That's a very good question.  The "one structural objectclass" rule 
probably comes from X.500.  Can you post this same question to the 
ldap at umich.edu list?  There are many people there who are knowledgeable 
about the roots of LDAP and X.500 who would probably be able to answer 
your question.

I believe this is going to become more and more of a problem with LDAP 
in general - how to create entries that belong to many different 
objectclasses, if more than one of them are structural?  It's almost as 
if you need an analogous auxiliary objectclass for each structural one.

I've encountered this problem before in Java programming, and I used the 
following paradigm: create pairs of interface/implementation class.
Start with the interface e.g.
public interface IDoer {
    public String getProp1();
    public String getProp2();
...
}

Then, create the implementation class:
public class DoerImpl implements IDoer {
    ...
}

This idea could be extended to LDAP (albeit clumsily perhaps) e.g.
objectclass auxInetOrgPerson SUP 'inetOrgPerson' AUXILIARY
to "extend" the structural inetOrgPerson class into an "interface" that 
could be mixed in with another structural objectclass.  I don't know if 
this is possible or allowed by LDAP or X.500.  It would probably have 
been better to do the obverse e.g. create auxInetOrgPerson first as an 
AUXILIARY class with all of the attributes, then create inetOrgPerson 
SUP 'auxInetOrgPerson' STRUCTURAL.  But then you would have to do that 
with all of the superclasses as well: organizationalPerson and person.

Jeff Clowser wrote:

> Sorry to dredge up a really old thread, but I've been trying to track 
> down something about it that's been bothering me.
>
> 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(?)
>
> It was something I hadn't known before, so finally got around to 
> looking for where that was defined.
>
> Looking at RFC 2251:
>
> Each entry MUST have an objectClass attribute.  The objectClass
> attribute specifies the object classes of an entry, which along with
> the system and user schema determine the permitted attributes of an
> entry.  Values of this attribute may be modified by clients, but the
> objectClass attribute cannot be removed.  Servers may restrict the
> modifications of this attribute to prevent the basic structural class
> of the entry from being changed (e.g. one cannot change a person into
> a country).  When creating an entry or adding an objectClass value to
> an entry, all superclasses of the named classes are implicitly added
> as well if not already present, and the client must supply values for
> any mandatory attributes of new superclasses.
>
> Looking at rfc 2252:
>
> 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.  Whether an object class is abstract,
> structural or auxiliary is defined when the object class identifier
> is assigned.  An object class definition should not be changed
> without having a new identifier assigned to it.
>
>
> 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.
>
> Did I misunderstand something?  If this is actually illegal, does 
> anyone know a reference that documents this?  Or am I just completely 
> confused here?
>
> - Jeff
>
>>> Looking briefly at rfc1274, it looks like host is an allowed 
>>> attribute of account objectclass, so actually, the schema is all 
>>> already there if you create users that have the account, 
>>> posixAccount, and shadowAccount objectclasses, ...
>>
>>
>> Unfortunately, the objectclass "account" is a structural objectclass, 
>> which means you can't "mix it in" with other structural objectclasses 
>> such as inetOrgPerson.  So I think either the standard needs to be 
>> revised to make account auxiliary, or create a new objectclass 
>> (auxAccount?).
>
>
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

-------------- 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/20050825/4710a1bc/attachment.bin>