Andrew Findlay wrote:
It seems to me that we now have these threads of development:
1) A new structural group class that can represent empty groups.
This could go forward with the existing ambiguous member
attribute or it could become the basis of a group
representation with more carefully defined semantics using
directMember.
2) A new auxiliary class and one or more attributes to represent
groups that may contain other groups. For this to make much
sense it would require the well-defined version of (1).
In (1) and (2) I see the definitions of the attributes being
the key, and would avoid requiring the use of the object
classes to obtain the defined semantics.
I think you should avoid dwelling on this last point. It just confuses
the issue. It seems certain that we're defining new attributes, and
therefore at least a new objectclass is needed to make use of them. Also
the notion of placing all the semantics solely in the attribute begs the
question "is a group with no members no longer a group?" (Yes, it's a
silly question, but it can be easily avoided by not focusing too much on
the attribute.)
3) A new control or extended operation so that a client can ask
the server to do the heavy lifting involved with nested
groups.
4) A new server-maintained attribute called memberOf to give an
alternative way for clients to ask for membership information.
AD already has such an attribute, and Pierangelo Masarati
recently proposed one for OpenLDAP so there may be useful
existing work to build on.
Pierangelo's code is already released in OpenLDAP 2.4.5.
5) A document explaining why groupOfUniqueNames,
uniqueMember and nameAndOptionalUID are bad, possibly leading
to them being deprecated in the next revision of the core LDAP
standards.
I'll write this up.