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

Andrew Findlay <andrew.findlay@skills-1st.co.uk> Thu, 12 February 2015 10:27 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 B203B1A86EC for <ldapext@ietfa.amsl.com>; Thu, 12 Feb 2015 02:27:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.098
X-Spam-Level: *
X-Spam-Status: No, score=1.098 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 nCoit8ZWyeNS for <ldapext@ietfa.amsl.com>; Thu, 12 Feb 2015 02:27:46 -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 9C1871A86F6 for <ldapext@ietf.org>; Thu, 12 Feb 2015 02:27:42 -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 1YLqzi-0002ZW-Q0; Thu, 12 Feb 2015 10:27:38 +0000
Received: from andrew by slab.skills-1st.co.uk with local (Exim 4.83) (envelope-from <andrew.findlay@skills-1st.co.uk>) id 1YLqzi-0003FY-C9; Thu, 12 Feb 2015 10:27:38 +0000
Date: Thu, 12 Feb 2015 10:27:38 +0000
From: Andrew Findlay <andrew.findlay@skills-1st.co.uk>
To: Michael Ströder <michael@stroeder.com>
Message-ID: <20150212102738.GC3229@slab.skills-1st.co.uk>
References: <54DB27C7.3060409@stroeder.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <54DB27C7.3060409@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/ldmhPv1KSu4iZlO3wiacOe18xJU>
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 10:27:48 -0000

On Wed, Feb 11, 2015 at 10:58:31AM +0100, Michael Ströder wrote:

> To preserve backwards compability I'd like to propose the following:
> 
> ( <OID TBD>
>   NAME 'posixGroup2'
>   DESC '<TBD>'
>   SUP ( groupOfEntries $ posixGroup )
>   STRUCTURAL )

That's a very cunning plan, but I am not sure that it will work...

> 1. posixGroup2 would have 'member' and 'memberUID' both as optional attributes,

That depends on exactly how multiple inheritance works. The only
definition I have found so far is in RFC4512:

      An object class may be derived from two or more direct
      superclasses (superclasses not part of the same superclass chain).
      This feature of subclassing is termed multiple inheritance.

   Each object class identifies the set of attributes required to be
   present in entries belonging to the class and the set of attributes
   allowed to be present in entries belonging to the class.  As an entry
   of a class must meet the requirements of each class it belongs to, it
   can be said that an object class inherits the sets of allowed and
   required attributes from its superclasses.  A subclass can identify
   an attribute allowed by its superclass as being required.  If an
   attribute is a member of both sets, it is required to be present.

Thus I think that your new class would have *more* mandatory
attributes than either of its superiors:

	MUST ( member $ cn $ gidNumber )

Not quite the point as we really want member to be optional.

> 2. the object class still can be found with (objectClass=posixGroup) and

I like that bit!

> 3. the object class is STRUCTURAL and therefore one can assign a specific DIT
> content rule to it allowing to preclude either 'member' or 'memberUID' with
> NOT to meet local system requirements.

+1

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

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