Subject: RE: Nested SearchRequests

From: Alan Lloyd <[email-masked]>
Date: Mon, 9 Aug 1999 12:33:35 +1000

Mircea, this seems to be the topic of a paper  we have on our web server
"opendirectory.com.au"- white papers - relational searhing over
distributed objects.

As you can see by the paper - one may require a whole series of nested
relationships..

At some stage directory services should do this - we actually prototyped
it for a specific application.

 The ITU/X.500 group is taking this up this relational access as a work
topic.

regards alan

> -----Original Message-----
> From:	MIRCEA PANA 
> Sent:	Saturday, August 07, 1999 11:22 AM
> To:	IETF LSD; IETF LDAPEXT
> Subject:	Nested SearchRequests
> 
> 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. 
>   << File: Card for Mircea Pana >>

---

From: Alan Lloyd <[email-masked]>
Date: Mon, 9 Aug 1999 13:08:54 +1000

> From:	Mark Wahl 
> Sent:	Monday, August 09, 1999 6:24 AM
> To:	MIRCEA PANA
> Cc:	IETF LSD; IETF LDAPEXT
> Subject:	Re: Nested SearchRequests
> 
> 
	snip

> 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.
> 
	Yes we have done that work - hence the paper on our web site
about embedding relational search engines in the directory Service (not
in a single LDAP server) as distributed processing modules. 
	But if you want to standardise on a distributed directory
service for LDAP  try X.500. After all LDAP standardised almost on DAP
(X.511) and the X.500 information model (X.501).. and it would save a
lot more work and you can buy it today.  :-)
	sorry - I just could not resist it.

	regards alan

> Mark Wahl, Directory Product Architect
> Innosoft International, Inc.