>It's essentially a means to group entries > together and much more powerful > than what is currently used in practice for dynamic groups: dynamic groups > uses an LDAP URL to > dynamically select the users for inclusion in the group. >
Ok, I think I better understand what you are saying now. I've seen a lot of different group structures in directories. From the simplest static group to overly complex combinations of custom group entries and custom az modules for applications. The issue (or non issue depending on how you look at it) is that a group is simply a directory object. What gives a group power is how the application deals with the information. The moral here being that if you have some alternate idea of how to specify a group, i'm sure there are infinite ways of specifying how to group users together but can the application interpret that information? For instance a dynamic group is much easier to manage in many ways then a static group but applications don't generally know how to compare a user against an ldap url. Thats why many virtual directories have dynamic group plugins to make dynamic groups work and act like static groups. So if you were to pair this group specification idea with an interceptor that made it work like a static group you might be on to something. The answer to 'why dont we do it' is that applications need to be able to consume it. There is no az mechanism in a directory that can hide the implementation. Authorization is left to the applications that are accessing the directory. Marc
