Re: "uniqueMember" in "groupOfUniqueNames"

MIRCEA PANA wrote:
> 
> I'm not sure if this was already brought into the discussions but we are
> having a little compatibility trouble between a Netscape Directory 3.11
> and an X500 Directory (with LDAP interface).
> 
> The Netscape Directory 3.11 defines the "groupOfUniqueNames" objectClass
> with "MAY ...uniquemember" while the X500 Directory specifies "MUST ...
> uniqueMember" for the same objectClass. I believe that this may have
> been overlooked by Netscape during the implementation of the LDAP
> schema. RFC2256 specifies the "uniqueMember" attribute type as required
> (MUST) for the "groupOfUniqueNames" objectClass. The trouble comes with
> the various products that have been developed based on the "Netscape
> LDAP schema". They are now incompatible with the other (standard)
> Directory.
> 
> My question would be: who is right and who is wrong here?

RFC 2256 is correct.  This is a bug in our server's schema definition
files and we will address it in a future release of our server.  Thanks
for pointing it out.  Unfortunately, this bug has existed for a long
time (since our 1.0 release I think) and so I am sure some applications
intentionally or unintentionally rely on the fact that a
groupOfUniqueMembers entry need not have a uniquemember attribute.  A
similar bug exists in our definition of groupOfNames.

--

-- 
Mark Smith
iPlanet Directory Architect / Sun-Netscape Alliance
My words are my own, not my employer's.   Got LDAP?

Nested SearchRequests

Re: Nested SearchRequests

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.

RE: Nested SearchRequests

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 >> 

RE: Nested SearchRequests

> -----Original Message-----
> 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.