Re: [ldapext] Is exclude subtree useful outside of chained operations?

["Jim Sermersheim" <jimse@novell.com>]

So that's a different way of accomplishing the same results for search.
For search, I like the attribute approach better. That significantly
reduces the appeal of pulling 'exclusions' out of the chained operation.
The cases left would be non-search operations that work on a subtree.
For example, a 'deleteSubtree' operation could be augmented with
exclusions which effectively cause only a part of the subtree to be
deleted.

On the other hand, for any new subtree-oriented operations should
probably seriously consider using a search filter to specify the subtree
to be affected. So maybe there's no appeal at all in creating an
'exclude subtree' control.

Jim

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 6/30/04 5:41:30 PM >>>
At 04:13 PM 6/30/2004, Jim Sermersheim wrote:
>One of the features of the chained operation is the ability to tell
the
>receiving DSA not to search a particular subtree (or subtrees). This
>helps cut down on the problem of duplicate suearch results (10.9 of
>X.518 has a good illustration of where this is useful).
>
>I'm wondering if this ability makes sense outside of the chained
>operation (in which case we can use a control both for the chained
>operation, other operations). So for example, has the ability been
>requested to perform a subtree search, but to exclude one or more
>subtrees?

I think it would be good to allow superior/subordinate DN
matching in search filters.   Given an operational attribute
which holds a copy of the entry's DN, say entryDN, many
of the useful cases can be expressed using component
matching.  I actually having writing an I-D specifying the
entryDN and its uses (including with component matching,
possibly additional rule(s)) on my TO DO list.

Kurt 


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext