[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: JDNI allows non-schema changes (ITS#2151)

At 11:02 AM 2002-10-25, quanah@stanford.edu wrote:

>--On Friday, October 25, 2002 10:51 AM -0700 "Kurt D. Zeilenga" 
><Kurt@OpenLDAP.org> wrote:
>> At 10:29 AM 2002-10-25, quanah@stanford.edu wrote:
>>> Ah, hm, I think I see what you are saying.   Currently, suPerson does
>>> not  have the following objectclasses as MUSTS (although they really are
>>> required for it to be a valid suPerson entry):
>> The language you use above I find a bit confusing.  An objectClass
>> cannot MUST another objectClass, it can only inherit properties
>> of another objectClass (or "subclass") using the SUP (superior)
>> clause.
>> I assume you mean that suPerson subclasses directly or indirectly
>> from the following classes.
>>> person
>>> organizationalPerson
>>> inetOrgPerson
>>> eduPerson
>>> suPerson
>>> suKerberosService
>>> krb5Principal
>>> So, we should have those as MUSTS in the suPerson entry for the add I
>>> showed you to fail, correct?
>> Rewording this "So, we should list SUPeriors of suPerson
>> as values of the entry's objectClass attribute, correct?"
>> No, it is not necessary to list SUPeriors of objectClass
>> values as any unlisted SUPerior of suPerson is implicit.
>> That is, listing only 'suPerson' as a value of objectClass
>> is semantically equivalent to listing 'suPerson' and its
>> SUPeriors as values of objectClass.
>Hm, okie.  So, then from what you are saying, if I have this right:
>We want suRegid to have to contain these 3 objectclasses:
>(cutting out the ones prior to suPerson based on what you note above about 
>Since the add we are doing is only putting in entries from the suPerson 
>object class, suPerson is the only one being put in place when we do the 
>add.  What we want, is when an suRegID is created by our person creation 
>object, is that all those above objectclasses MUST be a part of the suRegID 
>entry, or it will fail.  And I see your point about the MUST on suPerson 
>being incorrect.  Is there anyway to enforce that an add must include those 
>3 objectclasses for the suRegID?

I don't believe there is any mechanism to require explicit listing
of objectClass values which are implicitly present.