Re: [ldapext] empty-groupOfNames-issue

Michael Ströder <> Fri, 04 December 2015 16:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BD14B1A8989 for <>; Fri, 4 Dec 2015 08:47:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.712
X-Spam-Status: No, score=-1.712 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id m7abNq3V1LHt for <>; Fri, 4 Dec 2015 08:47:10 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 86E511A8903 for <>; Fri, 4 Dec 2015 08:47:09 -0800 (PST)
Received: from srv4.stroeder.local (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.stroeder.local", Issuer " Server CA no. 2009-07" (verified OK)) by (Postfix) with ESMTPS id E81711CF66; Fri, 4 Dec 2015 16:47:06 +0000 (UTC)
Received: from nb2.stroeder.local (nb2.stroeder.local []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by srv4.stroeder.local (Postfix) with ESMTPS id A66581D29F; Fri, 4 Dec 2015 16:47:05 +0000 (UTC)
To: Simo Sorce <>, Andrew Findlay <>
References: <> <> <> <> <>
From: Michael Ströder <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Fri, 04 Dec 2015 17:47:04 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 SeaMonkey/2.39
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms060805090709060007090103"
Archived-At: <>
Cc: ldapext <>
Subject: Re: [ldapext] empty-groupOfNames-issue
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: LDAP Extension Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 04 Dec 2015 16:47:11 -0000

Simo Sorce wrote:
> I do not agree with this conclusion.
> Realxing the constraint from MUST to MAY is forward compatible, and
> older tools can keep doing what they always did.
> Given there is no provision in the old or new groupOfNames to have
> members that "make sense", software always need to be prepared to deal
> with bogus members, so p) is not a "problem to solve".
> You may have a point with q) if you want to deal with a generic
> management system, but then your proposal to create a new objectlcass
> adds exactly the same problem, as the management system need to know
> what to use, except it makes it worse in 2 ways:
> 1) you have no way to find out what to do just by inspecting the schema
> because both classes may be in the schema, which do you choose ?
> 2) you have to change all client applications that are hardcoded to use
> groupOfNames
> Looking at 1) and 2) then q) is a comparatively little price to pay.
>> On the other hand, the corrupt version of groupOfNames does serve as
>> a proof that groupOfEntries is desired by the community because it is
>> functionally identical.
> Yet it is not identical, see 2) above.

I concur with Simo: The issues are almost non-issues because applications
already have to deal with the non-standard variants today.

Also in practice I see much less client applications capable to properly add
dummy 'member' values, and if they do you have to explicitly configure it anyway.

The only soft issue is that changing 'groupOfNames', after careful
considerations of course, could be abused as an example to request more
quick&dirty changes in standardized schema (probably without careful

Ciao, Michael.