Re: LDAP Comments
Steve Kille <S.Kille@isode.com> Sun, 16 May 1993 12:32 UTC
Received: from ietf.nri.reston.va.us 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 haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa01829;
16 May 93 8:32 EDT
Received: from glengoyne.isode.com by haig.cs.ucl.ac.uk with Internet SMTP
id <g.01491-0@haig.cs.ucl.ac.uk>; Sun, 16 May 1993 12:29:13 +0100
Received: from glengoyne.isode.com by glengoyne.isode.com with SMTP (PP)
id <01357-0@glengoyne.isode.com>; Sun, 16 May 1993 12:31:19 +0100
To: Christian Huitema <Christian.Huitema@sophia.inria.fr>
cc: Valdis Kletnieks <valdis@black-ice.cc.vt.edu>, pays@faugeres.inria.fr,
osi-ds@cs.ucl.ac.uk
Subject: Re: LDAP Comments
Phone: +44-71-721-7582
In-reply-to: Your message of Fri, 07 May 1993 10:51:58 +0200.
<199305070851.AA02600@mitsou.inria.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 16 May 1993 12:31:17 +0100
Message-ID: <1355.737551877@isode.com>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Steve Kille <S.Kille@isode.com>
Christian, >From: Christian Huitema <Christian.Huitema@sophia.inria.fr> >To: Valdis Kletnieks <valdis@black-ice.cc.vt.edu> >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 process. 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 Steve
- LDAP Comments Eric Rosenquist
- Re: LDAP Comments Tim Howes
- Re: LDAP Comments pays
- Re: LDAP Comments Tim Howes
- Re: LDAP Comments pays
- Re: LDAP Comments Alan Shepherd
- Re: LDAP Comments Tim Howes
- Re: LDAP Comments pays
- Re: LDAP Comments Tim Howes
- Re: LDAP Comments pays
- Re: LDAP Comments Alan Shepherd
- Re: LDAP Comments Valdis Kletnieks
- Re: LDAP Comments Tim Howes
- Re: LDAP Comments pays
- Re: LDAP Comments Christian Huitema
- Re: LDAP Comments Tim Howes
- Re: LDAP Comments Steve Kille
- Re: LDAP Comments Christian Huitema