Re: LDAP Comments

Christian Huitema <> Fri, 07 May 1993 10:03 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa01225; 7 May 93 6:03 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01221; 7 May 93 6:03 EDT
Received: from by CNRI.Reston.VA.US id aa03639; 7 May 93 6:03 EDT
Received: from by with local SMTP id <>; Fri, 7 May 1993 09:49:21 +0100
Received: from by with Internet SMTP id <>; Fri, 7 May 1993 09:49:04 +0100
Received: by (5.65c/IDA-1.2.8) id AA02600; Fri, 7 May 1993 10:51:59 +0200
Message-Id: <>
To: Valdis Kletnieks <>
Subject: Re: LDAP Comments
In-Reply-To: Your message of "05 May 93 16:33:42." <9305052033.AA12979(l)a(r)>
Date: Fri, 07 May 93 10:51:58 +0200
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Christian Huitema <>

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!

The duplication of subordinate entries is mandated by the QUIPU
implementation. It is allowed, but not mandated, by X.500, and should
indeed be supported by all software. However, duplication is not only a
software problem. It has consequences on the maintenance procedures (need to
update the copies regularly), on the access control (don't necessary want to
give full copies of sensitive attributes to a top level DSA), and also on the
cost of running the main DSA. Equating LIST and SEARCH is thus a fallacy.

That LIST and SEARCH are not equal does not mean that you have to implement
both, however. We have to weight the advantages of a separate LIST operation
and of a simple software implementation with only one access procedure instead
of four. If you consider that there are many installation that will refuse to
serve listings for security and resource control reasons, and that would
refuse to perform both LIST and "loose SEARCH" operations, you may conclude
that LDAP is a better protocol without it...

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?

Christian Huitema