Subject: Nested SearchRequests

From: "MIRCEA PANA" <[email-masked]>
Date: Fri, 06 Aug 1999 21:22:17 -0400

I would like to make a suggestion for extending the LDAP SearchRequest
to allow nested SearchRequest (a similar extension may be imagined for
the CompareRequest as well). I am not sure if this kind of extension
would be in accordance with the LDAPv3 spec. or if it is feasible at
this point but I find it really useful. ...and if the following does not
make any sense, please forgive my ignorance.

Many Directory enabled applications have to perform multiple
SearchRequest before they get to the data they actually want to use. So
in order to minimize both the processing time and the data volume on the
wire they should be able to construct more complex searches. It is true
that each search request would take longer to process but I believe that
the overall processing time may be improved.

For example a mail distribution app. would:
1. Search for one (or more) "groupOfUniqueNames" and return its
"uniqueMember" values
2. For each value from 1.: Search (scope=base) in all the DN.s (values
from previous. search) and get their "mail" values
3. Send an e-mail to all the resulting addresses.

If nested SearchRequest would be allowed in the baseObject, the same
application would perform just one search in the Directory:
Search {
scope=base
searchBase=each uniqueMember from {
           ^^^^^^^^^^^^^^^^^^^^^^
                       Search {
                       scope=sub
                       searchBase=allMyDIT
                       filter=(cn=myMailGroup)
                       attributes=uniqueMember
                       }
    }
filter=(mail=*)
attributes=mail
}
and then use the returned "mail" values to send its message to.

The filter could also be extended to include nested SearchRequest. In
the following example the (hypothetical) LDAP client searches for all
the e-mail addresses of the people managed by IT managers:
Search {
scope=sub
searchBase=allMyDIT
filter=(&(employeenumber=*)
             (manager=any DN from {
                      ^^^^^^^^^^^^
                         Search {
                         scope=sub
                         searchBase=allMyDIT
                         filter=(department=IT)
                         attributes=1.1
                         }
                     }
                 )
            )
attributes=mail
}

I would like to know what other people think about the usefulness and
feasibility of such an extension to LDAPv3.

Thanks,
Mircea.

---

From: Mark Wahl <[email-masked]>
Date: Sun, 08 Aug 1999 15:23:41 -0500

There is interest in developing query expression extensions for LDAP to allow
for more processing on the server side.  Most of the approaches are at the 
propose/research/expermiment state.  While the goal of reducing the amount of
round trips the client must perform is a good one, this topic has tended to 
lead to a number of questions, now all of which have yet been answered, such
as:
 1 how to perform these operations efficiently when more than one server holds
   the scope of the search?
 2 how to deal with arbitrary levels of recursion and identifying intermediate
   nodes (e.g. find all entries E1 which have an attribute A1 with a value 
   which point at entries E2 which have an attribute A2 with a value which point 
   at entries which have a value which points back at the same entry in E1,
   and return the entries which have any DN-valued attribute that points at 
   entries E2)
 3 how does this integrate with the work being done to have server-side 
   consistency checking (often called business rule logic) of adds and modifies
 4 how does a client interrogate the server to determine the kinds of more 
   advanced processing it can perform, and how would a client operate if 
   some but not all servers holding the DIT can perform this processing?

Traditional SQL based systems have focussed on 2, and while there has been 
research in RDBMS systems on 1 and 3 I do not yet believe we are yet ready to 
standardize on an approach for a distributed directory service based on LDAP.

Mark Wahl, Directory Product Architect
Innosoft International, Inc.

---

From: "Ryan Moats" <[email-masked]>
Date: Mon, 9 Aug 1999 08:59:20 -0500

I've dropped the forwarding to LSD, because this
really (IMHO) is a topic for LDAPEXT.

Anyway, we've been thinking about this as well.
I would point interested readers to our "first
step" in this direction: the dereferencing match,
draft-moats-ldap-dereference-match-00.txt.  We are
working towards a second draft, based on list
comments to the first one, and it should be
available by the beginning to mid September.

Ryan Moats