Re: [ldapext] Schema for posixGroup successor (RFC 2307 bis)

Andrew Findlay <andrew.findlay@skills-1st.co.uk> Thu, 12 February 2015 11:48 UTC

Return-Path: <andrew.findlay@skills-1st.co.uk>
X-Original-To: ldapext@ietfa.amsl.com
Delivered-To: ldapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC7D1A6F0E for <ldapext@ietfa.amsl.com>; Thu, 12 Feb 2015 03:48:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.602
X-Spam-Level:
X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BX4dNBzm6Jzk for <ldapext@ietfa.amsl.com>; Thu, 12 Feb 2015 03:48:11 -0800 (PST)
Received: from kea.ourshack.com (kea.ourshack.com [IPv6:2001:470:1f15:20::201]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 245001A1BEF for <ldapext@ietf.org>; Thu, 12 Feb 2015 03:48:10 -0800 (PST)
Received: from d.5.1.a.7.f.9.6.4.e.3.7.9.7.8.c.1.e.7.f.0.d.8.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:8d0:f7e1:c879:73e4:69f7:a15d] helo=slab.skills-1st.co.uk) by kea.ourshack.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <andrew.findlay@skills-1st.co.uk>) id 1YLsFc-0003Um-79; Thu, 12 Feb 2015 11:48:08 +0000
Received: from andrew by slab.skills-1st.co.uk with local (Exim 4.83) (envelope-from <andrew.findlay@skills-1st.co.uk>) id 1YLsFb-0003jP-Ot; Thu, 12 Feb 2015 11:48:07 +0000
Date: Thu, 12 Feb 2015 11:48:07 +0000
From: Andrew Findlay <andrew.findlay@skills-1st.co.uk>
To: Michael =?iso-8859-1?Q?Str=F6der?= <michael@stroeder.com>
Message-ID: <20150212114807.GG3229@slab.skills-1st.co.uk>
References: <54DB27C7.3060409@stroeder.com> <20150212102738.GC3229@slab.skills-1st.co.uk> <54DC8BD7.3040009@stroeder.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <54DC8BD7.3040009@stroeder.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: Andrew Findlay <andrew.findlay@skills-1st.co.uk>
Archived-At: <http://mailarchive.ietf.org/arch/msg/ldapext/cN4e1i2uqk-MmSHSX1Gk5j3Kx4o>
Cc: ldapext <ldapext@ietf.org>
Subject: Re: [ldapext] Schema for posixGroup successor (RFC 2307 bis)
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ldapext>, <mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ldapext/>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ldapext>, <mailto:ldapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Feb 2015 11:48:12 -0000

On Thu, Feb 12, 2015 at 12:17:43PM +0100, Michael Ströder wrote:

> Ok, you've overlooked that I wrote 'groupOfEntries' instead of 'groupOfNames'.

oops... I had assumed you were going for a standalone definition, so I
did indeed misread it.

> 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.

> > Looking through the common schemas it seems that multiple inheritance
> > is extremely rare, so I wonder whether all servers would even agree on
> > how it works...
> 
> It works for me. :-)
> 
> Ok, it works in OpenLDAP since years.  We could send a poll ot ldapext and
> ldapbis mailing lists which server products officially support multiple
> inheritance.

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.

Andrew
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------