Re: empty-groupOfNames-issue

On Fri, Dec 04, 2015 at 12:17:49PM +0100, Michael Str=F6der wrote:

> 1. Modified standard schema descriptions for 'groupOfNames' and
> 'groupOfUniqueNames':
> =

> This is the work-around already chosen by various vendors:
> The MUST member or MUST uniqueMember is turned into MAY.
> =

> + it just works, no interop-problems seen so far.
> + no change required in LDAP clients
> + no change required in access control rules
> + no change required in other client or server-side code dealing with gro=
ups
> =

> - It violates standardization best practices, most notably IANA considera=
tions.
> - It could serve as a bad example to change standard schema at will.
> =

> Hopefully Rolf Sonneveld and Andrew Findlay will clearly comment on IANA
> considerations.

I don't think there is an IANA consideration here. The modified schema
is (currently) incorrect according to RFC4519 or is alternatively an
experiment leading to a proposed change to a standard. In the latter
case it would have to be accepted by IETF and published in a new RFC
that obsoletes 4519. At that time, IANA would update the reference in
the Object Identifiers table to point to the new document but would have
no other involvement.

In practice I cannot see such a change ever being accepted into the
standards track. If anything, the relatively wide distribution of
non-conformant implementations makes a stronger case for deprecating
these objectclasses for new deployments.

The definition of groupOfNames goes right back to X.521(1988) and it was
already broken at that point:

a)	member was a mandatory attribute

b)	Nested groups were mentioned in the text but the semantics
	were left undefined

> -------------------------------------------------------------------------
> =

> 2. new object class 'groupOfEntries'
> =

> Andrew kindly wrote an mini I-D defining a new structural object class
> 'groupOfEntries' simply with MAY member instead of MUST meant as direct
> replacement for 'groupOfNames'.
> =

> http://tools.ietf.org/html/draft-findlay-ldap-groupofentries
> =

> + Very simple
> + Fully compliant to standardization best practices
> =

> - It's not clear whether it was widely adopted in deployments.

Maybe not in the exact form I described in that I-D, but functionally
equivalent objectclasses have been in most of my customers' systems.
It could be argued that the corrupted form of groupOfNames described
above is actually proof of widespread deployment of an analogous class.

> - small change required in LDAP clients for searching group entries
> - small change required in access control rules
> - small changes required in other client or server-side code dealing with=
 groups

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