Re: groups, rfc

["Brett @Google" <brett.maxfield@gmail.com>]

On Thu, Oct 2, 2008 at 2:26 PM, Howard Chu <hyc@symas.com> wrote:
> I was dusting off some of the last rfc2307bis revisions Luke sent me, and
> then remembered how much of a mess we still have with groups. Here are some
> ideas I'm toying with, would like some feedback before drafting for
> IETF-LDAPext.
>
> We already know that groupOfUniqueNames is misleading and should be avoided.
> The big problem with groupOfNames is that member is required. So my first
> thought was a new groupOfMembers objectclass where member is optional (MAY
> instead of MUST).
>

> Along the way I was thinking that perhaps a different concept was needed
> here, like setOfNames instead. The main thinking being:
>   sets implicitly have unique membership
>   sets may be empty
>   sets may be comprised of other sets

I think this is a good idea, but for the concept to be accurate, i'm
assuming if you had two members, such as :

ldap:///ou=foo,o=bar?entryDN?subtree?(deptCode=XYZ)
ldap:///ou=foo,o=bar?entryDN?subtree?(deptCode=ABC)

The idea above is just to play devils advocate, i.e. what if somebody
is in both groups, the proposed solution then would (to maintain the
set paradigm) need to remove the duplicate dn's. If it was not
described as a "set" then you could just leave the duplicates for a
simpler implementation.

> This gives us a clean, consistent syntax and semantic for grouping behavior.
> It doesn't make our lives any easier as far as indexing and optimizing the
> dynamic characteristics, but it's a start. Thoughts?

It would be nice if the underlying group linkage were abstracted away
from using the dn exclusively.

One thing that is currently an occasional bain, is group membership
which is only specified by dn as the underlying linking attribute,
especially in a highly dynamic tree structure that is being revised or
changed (either small or large) every few months. Any group whose
members are specified by dn are broken whenever any part of that DN 's
components are restructured / moved or renamed.

Any highly structured organisation which is large enough for this to
be a problem, is also very likely going to have it's own unique
identifiers (employee number etc.,) which would already be suitable
for linking users to groups, rather than being forced to link
users/groups by dn which is subject to change.

It would therefore be nice to be able to abstract the underlying
membership linkage for a group without being forced to use dn's as the
user/group linking paradygm. This does not necessarily imply changing
the dn as seen by the client, as when group members are being mapped
from the dynamic list, it could just present the dn, no matter what
was used internally

This does mean that the presented dn's will automatically reflect
structure changes, if the underlying unique name matching attribute
has not actually changed. This implies that groups can use some more
immediately useful or efficient underlying linkage, even if dns are
still presented to and accepted from, the ldap client.

Cheers
Brett