It seems I was not very clear on what I was asking. Let me give it another shot.
We have subentries which contain subtreeSpecifications (SS). The SS is a very powerful mechanism
for selecting entries in the DIT. 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.
I was wondering if a application specific form of this could be used for dynamic groups instead of using a
simple LDAP URL.
The problem with an SS is that it's USAGE is a directoryOperation and it's base is relative to the position
of the Administrative Point (AP). What if we defined a means for applications to group together entries based
on this concept. Say we have the following objectClass for a subtreeSelector:
objectclass ( 126.96.36.199.4.1.18060.0.4.1.3.11 NAME 'subtreeSelector'
DESC 'application level mechanism for specifying subtrees with specified base'
MAY ( selectorFilter $ minimum $ maximum $ chopBefore $ chopAfter )
MUST ( cn & selectorBase )
I'm sure you can figure out what the may and must attributes correspond to along with their
characteristics: i.e. chopBefore is a distinguishedName syntax multivalued attribute etc.
So why are we (LDAP community) not leveraging something this powerful instead of using
a simple URL to define dynamic groups.
On 9/21/07, Alex Karasulu < firstname.lastname@example.org> wrote:Hi,
Any reason why LDAP never defined application level subtree specification mechanisms? Right now the subentry is used
with the a operational usage for the main subtreeSpecification attribute. Also the base is AP position relative. Why not
have an application space specification and use that for dynamic grouping?
I think Netscape family implements Roles (like dynamic groups) using Subentries. As far as I know, OpenDS implements subtreeSpecifications with RootDSE as the base relative position. But none of these are standard.Any thoughts?