Re: [ldapext] empty-groupOfNames-issue

Simo Sorce <simo@redhat.com> Fri, 04 December 2015 17:23 UTC

Return-Path: <simo@redhat.com>
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 2D37B1A8AEF for <ldapext@ietfa.amsl.com>; Fri, 4 Dec 2015 09:23:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 abFrnT-h8NDw for <ldapext@ietfa.amsl.com>; Fri, 4 Dec 2015 09:22:58 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF8BE1A8AE7 for <ldapext@ietf.org>; Fri, 4 Dec 2015 09:22:58 -0800 (PST)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 4D77E4C524; Fri, 4 Dec 2015 17:22:58 +0000 (UTC)
Received: from willson.usersys.redhat.com ([10.3.113.3]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tB4HMue9032518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 4 Dec 2015 12:22:57 -0500
Message-ID: <1449249776.3445.78.camel@redhat.com>
From: Simo Sorce <simo@redhat.com>
To: Andrew Findlay <andrew.findlay@skills-1st.co.uk>
Date: Fri, 04 Dec 2015 12:22:56 -0500
In-Reply-To: <20151204163429.GI3643@slab.skills-1st.co.uk>
References: <5661765D.6040603@stroeder.com> <20151204134757.GE3643@slab.skills-1st.co.uk> <1449243887.3445.59.camel@redhat.com> <20151204163429.GI3643@slab.skills-1st.co.uk>
Organization: Red Hat, Inc.
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Archived-At: <http://mailarchive.ietf.org/arch/msg/ldapext/nzpIecM-zbo7GbnzHOovuHVlPMk>
Cc: ldapext <ldapext@ietf.org>, Michael =?ISO-8859-1?Q?Str=F6der?= <michael@stroeder.com>
Subject: Re: [ldapext] empty-groupOfNames-issue
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 04 Dec 2015 17:23:00 -0000

On Fri, 2015-12-04 at 16:34 +0000, Andrew Findlay wrote:
> On Fri, Dec 04, 2015 at 10:44:47AM -0500, Simo Sorce wrote:
> 
> > An auxiliary class may be a better choice for a standard.
> 
> Yes: I also prefer to define aux classes where possible.
> groupOfEntries was defined STRUCTURAL to make it a drop-in
> replacement for groupOfNames.
> 
> If we were starting from a clean slate we might just define:
> 
>      ( 1.2.826.0.1.3458854.2.1.1.666 NAME 'membershipObject'
>             SUP top
>             AUXILIARY
>             MAY ( member )
>      )
> 
> and allow designers to apply it to any appropriate structural class.
> Following that to its logical conclusion would give almost 1:1
> correspondence between objectclasses and attributetypes, which most
> would probably regard as over-normalisation!
> 
> In fact I think groups are very reasonable STRUCTURAL objects,
> as the concept of groups has such broad application. Where I might argue
> with the current definition of groupOfNames/groupOfEntries is the list
> of other descriptive attributes (why should groups have a
> businessCategory but no displayName for example?)

I tend to agree, but posixGroup is structural ... sigh :)

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York