Re: [ldapext] groupOfEntries object class proposal

[Pete Rowley <prowley@redhat.com>]

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.

Agreeing on something like this will allow the conversation to move 
forward on the mechanisms of group membership without requiring clients 
and servers to be modified every time a new method is developed. It 
allows for both proprietary and custom grouping mechanisms without 
stepping on toes or requiring IETF sanction to be generally useful and 
so reduces the barrier to adoption. Most of all, it is a stable platform 
for interoperability for at least the second class of user.

--
Pete

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

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