Re: [ldapext] groupOfEntries object class proposal

[Pete Rowley <prowley@redhat.com>]

Howard Chu wrote:
> Pete Rowley wrote:
> > Andrew Findlay wrote:
> > > At the recent LDAP conference in Cologne there was wide support for an
> > > effort to improve some of the commonly-used schema definitions. In
> > > particular, the fact that groupOfNames does not permit an empty group
> > > was felt to be a significant problem.
> > >   
> > So the discussion about this highlights the basic issues around the 
> > current approach to grouping. Fundamentally there are two classes of 
> > user for a grouping mechanism 1) those who need to know how to build 
> > and generally administer groups 2) those who need to use groups but 
> > care not a whit how they came to be. Currently, every time a new 
> > group type is invented both classes need to understand all the ins 
> > and outs of the new group type and they must agree on what those ins 
> > and outs mean.
> >
> > This is broken. Non-administrative clients should be able to write to 
> > a single group interface once and forever after be left to get on 
> > with clientship.  Innovation for the first class of user is then left 
> > to prosper without hindrance, without client breakage, and without 
> > chickens and eggs. There is a suitable way to do this: the memberof 
> > attribute, if populated it will supply all the needs of the second 
> > class of user both now and into the future, it even solves some of 
> > sticky performance problems around gathering suitable attribute 
> > values from each memberof the group. It is also agnostic to method of 
> > attaining membership, membership simply is.
>
> Ah, if only it were so easy. But will memberOf expand for recursions? 
> If user A is a member of a group B that is nested in group C, will it 
> list only group B or both group B and group C? Attacking the problem 
> from the opposite direction doesn't actually eliminate the question of 
> whether and how nesting should be handled. All of the same ambiguities 
> still exist.
Nesting of membership is a design detail of a particular grouping 
mechanism, it has no bearing on memberof since if a group is not listed 
in memberof, it the entry is not a member. This actually a supporting 
point in that the set of non-management clients don't need to care.

--
Pete

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext