draft-findlay-ldap-groupofentries-00.txt discussion summary 2007-09-24
======================================================================
On September 17th I introduced an I-D to create an LDAP group class
that was capable of representing an empty group. The initial proposal
was for the smallest possible change from the existing groupOfNames
class.
Most people who joined the discussion on ldapext@ietf.org were broadly
in support of allowing empty groups, though some thought that any
changes away from the status quo were doomed to fail.
Howard Chu pointed out that groupOfUniqueNames is even worse than
groupOfNames as the LDAP syntax for the nameAndOptionalUID attribute
type cannot be parsed reliably.
Kurt Zeilenga provided much detailed editorial advice, and posed a
question about how to handle groups where the DSA is unwilling or
unable to return some or all member names.
Luke Howard suggested that the behaviour of nested groups should be
defined. I was initially against an explicit definition, but was soon
persuaded that there could be significant performance and security
problems with ad-hoc nesting. At this point the discussion moved
almost entirely to the consideration of nesting issues.
Pete Rowley wanted an interface to be used by read-only clients to find
out what groups a particular entry is a member of without caring about
how the groups are defined. He suggested a memberOf attribute (presumably
server-maintained) for this purpose. Michael Liben also liked this
approach.
Simo Sorce proposed a control for server-side group expansion, and
Michael Ströder suggested that an extended operation for asking specific
membership questions would be better. Howard Chu suggested that any such
operation would need a depth limit parameter.
Steven Legg proposed directMember and nestedGroups attributes, and
Michael Ströder suggested that these might be a sufficient set to
describe nested groups. I wondered whether nested groups should be split
into those that could in turn have their own nested groups and those
that could not, but Simo Sorce thought that people would never choose
to use the more restrictive case. I was initially against dropping the
original 'member' attribute, but Steven pointed out that having a new
directMember attribute would allow people to define their own group
classes and still take advantage of defined nesting semantics.
Current situation
=================
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.
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.
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 am willing to co-ordinate work on (1) and (2). Are there volunteers
to take on the others?
Andrew