Re: Schema for posixGroup successor (RFC 2307 bis)

Ludovic Poitou <[email protected]> Thu, 12 Feb 2015 13:26:05 +0100
Newsgroups gmane.ietf.ldapext
Message-ID <[email protected]>
I was trying to define the posixGroup2 object class in OpenDJ, and the server refuses it because we do not allow to define a structural objectClass that inherits from auxiliary objectClasses.

And this is the proper behavior as RFC4512, section 2.4.2 specifically calls it:

<quote>
 Structural object classes cannot subclass auxiliary object classes.
</quote>

Regards,

Ludo
-- 
Ludovic Poitou
http://ludopoitou.com

On 12 Feb 2015 at 12:53:17, Michael Ströder ([email protected]) wrote:

Andrew Findlay wrote:  
> On Thu, Feb 12, 2015 at 12:17:43PM +0100, Michael Ströder wrote:  
>> In draft-howard-rfc2307bis-02 'posixGroup' is declared as AUXILIARY, a change  
>> which is forbidden according to Kurt's IANA rules. And the draft contains a  
>> declaration of 'groupOfMembers' which is pretty much the same as  
>> 'groupOfEntries'. We will sort that out...  
>  
> Right. That is why I want to separate the groups work from any 2307  
> updates as far as possible.  

+1  

Could you please go ahead pushing draft-findlay-ldap-groupofentries?  

> That would be useful. Are we agreed about how it *should* work?  
> My understanding is:  
>  
> The new class has a set of MUST attributes that is the union of the  
> MUST attributes of the superior classes.  
> The new class has a set of MAY attributes that is the union of the  
> MAY attributes of the superior classes.  
> Any attribute that is MUST in one superior and MAY in another will  
> become MUST in the new class.  

That's exactly how I see it.  

Ciao, Michael.  

_______________________________________________  
Ldapext mailing list  
[email protected]  
https://www.ietf.org/mailman/listinfo/ldapext

_______________________________________________
Ldapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ldapext