Re: [ldapext] groupOfEntries object class proposal

[Steven Legg <steven.legg@eb2bcom.com>]

Andrew,

Andrew Findlay wrote:
> On Tue, Sep 18, 2007 at 09:03:25AM +1000, Luke Howard wrote:
>
> > Another thing that would be useful might be to define the behaviour of 
> > nested groups, eg. should the client expand them?
>
> A good point, but I would be wary of being too prescriptive here. Some
> servers provide an auxiliary object class that causes the groups to
> expanded server-side: that would continue to work with groupOfEntries
> (though there is a management issue with anything that triggers
> server-side tricks). Whether a *client* should expand groups will
> depend on why the client wants the group info in the first place, and I
> don't think it is necessary to force the issue one way or the other.
>
> It might be worth adding a statement that makes it clear that
> a groupOfEntries can have members of *any* type, so nested groups are
> explicitly possible. The precise semantics should be defined by the
> application schema designer.

The advantage of *not* having nested groups is that it is sufficient
to just read the values of the member attribute to determine group
membership. If there are nested groups, then it is necessary to
read each of the entries named in the values of the member attribute
to see which of them, if any, are themselves groups. That could be
a big performance hit for a group with a large set of members.

If nested groups are to be allowed, then I would rather see the
nested groups listed in a separate attribute, e.g., called nestedGroups,
so that implementations only need to read the entries that really
are nested groups.

Regards,
Steven

> > It would make sense to use this object class for rfc2307bis too 
> > (whenever that is completed :-))
>
> Maybe so, but rfc2307bis is a much more complex issue!
>
> Andrew

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