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