[ldapext] Summary of group discussion
Andrew Findlay <andrew.findlay@skills-1st.co.uk> Mon, 24 September 2007 19:44 UTC
Return-path: <ldapext-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZtqz-0004Dg-Vz; Mon, 24 Sep 2007 15:44:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZtqx-0003zN-AS for ldapext@ietf.org; Mon, 24 Sep 2007 15:44:23 -0400
Received: from [84.45.68.116] (helo=dog.ourshack.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZtql-0003Cg-Q1 for ldapext@ietf.org; Mon, 24 Sep 2007 15:44:19 -0400
Received: from 88-97-25-132.dsl.zen.co.uk ([88.97.25.132] helo=tile.skills-1st.co.uk) by dog.ourshack.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from <andrew.findlay@skills-1st.co.uk>) id 1IZtqL-00084z-Nk for ldapext@ietf.org; Mon, 24 Sep 2007 20:43:45 +0100
Received: from andrew by tile.skills-1st.co.uk with local (Exim 4.63) (envelope-from <andrew.findlay@skills-1st.co.uk>) id 1IZtqI-0002aC-3T for ldapext@ietf.org; Mon, 24 Sep 2007 20:43:42 +0100
Date: Mon, 24 Sep 2007 20:43:42 +0100
From: Andrew Findlay <andrew.findlay@skills-1st.co.uk>
To: LDAP Extensions list <ldapext@ietf.org>
Message-ID: <20070924194342.GA9926@tile.skills-1st.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.5.13 (2006-08-11)
X-SA-Exim-Connect-IP: 88.97.25.132
X-SA-Exim-Mail-From: andrew.findlay@skills-1st.co.uk
X-SA-Exim-Scanned: No (on dog.ourshack.com); SAEximRunCond expanded to false
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
Subject: [ldapext] Summary of group discussion
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>, <mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>, <mailto:ldapext-request@ietf.org?subject=subscribe>
Errors-To: ldapext-bounces@ietf.org
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 -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | ----------------------------------------------------------------------- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext
- [ldapext] Summary of group discussion Andrew Findlay
- Re: [ldapext] Summary of group discussion Howard Chu
- Re: [ldapext] Summary of group discussion Ludovic Poitou
- Re: [ldapext] Summary of group discussion Jaimon Jose
- Re: [ldapext] Summary of group discussion Jaimon Jose
- Re: [ldapext] Summary of group discussion Pete Rowley
- Re: [ldapext] Summary of group discussion Jaimon Jose
- Re: [ldapext] Summary of group discussion Pete Rowley
- Re: [ldapext] Summary of group discussion Gavin Henry
- Re: [ldapext] Summary of group discussion Keutel, Jochen
- Re: [ldapext] Summary of group discussion Howard Chu
- Re: [ldapext] Summary of group discussion Howard Chu
- Re: [ldapext] Summary of group discussion Michael Ströder
- Re: [ldapext] Summary of group discussion Howard Chu
- Re: [ldapext] Summary of group discussion Kurt Zeilenga