[Date Prev][Date Next]
Re: JDNI allows non-schema changes (ITS#2151)
--On Friday, October 25, 2002 10:51 AM -0700 "Kurt D. Zeilenga"
> At 10:29 AM 2002-10-25, firstname.lastname@example.org 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)
> I assume you mean that suPerson subclasses directly or indirectly
> from the following classes.
>> 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?
Senior Systems Administrator
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html