Re: LDAP Comments

Steve Kille <> Sun, 16 May 1993 12:32 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa10323; 16 May 93 8:32 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10319; 16 May 93 8:32 EDT
Received: from by CNRI.Reston.VA.US id aa01829; 16 May 93 8:32 EDT
Received: from by with Internet SMTP id <>; Sun, 16 May 1993 12:29:13 +0100
Received: from by with SMTP (PP) id <>; Sun, 16 May 1993 12:31:19 +0100
To: Christian Huitema <>
cc: Valdis Kletnieks <>,,
Subject: Re: LDAP Comments
Phone: +44-71-721-7582
In-reply-to: Your message of Fri, 07 May 1993 10:51:58 +0200. <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 16 May 1993 12:31:17 +0100
Message-ID: <>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Steve Kille <>


 >From:  Christian Huitema <>
 >To:    Valdis Kletnieks <>
 >Subject: Re: LDAP Comments
 >Date:  Fri, 07 May 93 10:51:58 +0200

 >Just a note on the discussion of LIST + READ vs SEARCH. First, two facts:
 > (1) It is true that READ can be emulated by "search base object with
 >     Filter: object-class present". It would not make much difference on
 >     the DSA side, needs almost the same number of data base accesses and
 >     exactly the same number of chainings. The same is also true for the
 >     COMPARE operation, setting the filter to the required comparison.
 > (2) It is FALSE to believe that LIST can be equated by "search one level
 >     with Filter: object-class present, return only names". The LIST results
 >     can be returned with minimal duplications -- only need to know the RDNs
 >     of the subordinate entries. The SEARCH result need to access the content
 >     of the entry, hence require to either duplicate all subordinate entries
 >     on the DSA holding the base name or to chain the SEARCH request to all
 >     DSAs holding subordinate information. Or to recognize the particular
 >     kind of "match all" filters, and convert search to list in the DSA -- but
 >     that is hardly a standard feature!

You are wrong on 2).   The operations are equivalent, and cane
therefore be implemented with the same level of efficiency.   

There are two aspcts relating to the ommission of list.   The first is
that it can be emulated.   The second is that whilst most early DUAs
use list, most "second generation" DUAs do not.  The reason is that
the list operation returns only the RDN.  This is just not enough
information to return to the user.   At the very least, you need
object class information, and usually enough other information so that
you get a neat one line per entry display.

Given the goals of LDAP, it seemed to be a useful simplification to
omit LIST.

 >By the way. LDAP is been advanced to "proposed internet standard" status by
 >the IESG, but the discussion seem to indicate that there is no formal
 >agreement in the working group. Do you expect that there will be serious
 >modifications and that the protocol should be resubmitted?

There was extensive discussion, and a formal agreement at the OSI-DS WG.  

I do not expect serious modification, although I could see some
small upgrades as:
  1) There are more independent implementations
  2) More experience in general
  3) X/.500(93) starts to appear
Certainly no changes which would require resetting the standards

If there is real demand, it would be trivial to add a list operation,
or a note indicating that the server should implement the search
equivalent to list by use of the X.500 list operation.   I see no need
to make this change.

 >Christian Huitema