Re: LDAP Comments
pays@faugeres.inria.fr Wed, 05 May 1993 14:39 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11398;
5 May 93 10:39 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11394;
5 May 93 10:39 EDT
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa11630;
5 May 93 10:39 EDT
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP
id <g.03254-0@haig.cs.ucl.ac.uk>; Wed, 5 May 1993 15:21:42 +0100
Received: from faugeres.inria.fr by bells.cs.ucl.ac.uk with Internet SMTP
id <g.01601-0@bells.cs.ucl.ac.uk>; Wed, 5 May 1993 15:21:17 +0100
X400-Received: by /PRMD=inria/ADMD=atlas/C=fr/; Relayed;
05 May 93 16:18:22+0200
Date: 05 May 93 16:18:22+0200
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: pays@faugeres.inria.fr
To: pays@faugeres.inria.fr, tim@terminator.rs.itd.umich.edu
Subject: Re: LDAP Comments
cc: rosenqui@crc.sofkin.ca, osi-ds@cs.ucl.ac.uk
Message-ID: <736611502.154.0-faugeres.inria.fr*@MHS>
> > Sorry, but I probably missed something. > > Could you elaborate a bit on this? > > Do you mean the LDAP server will convert the simplest searches > > to list/read, or do you mean that every DSA > > either have to do this > > or have to present more or less the same level of > > performance for the simplest search operations than for > > read/list. > > It could be done in the ldap server, or the searches could be left > as-is and passed to the DSA, which could attempt to optimize them or > not. As you point out, this could result in poor performance for some > implementations. Our reasoning was that the functionality of list/read > are easily implemented using search. Performance of such a search (as > for any operation), is up to a particular implementation. But the DSA > can be insulated from this somewhat if the LDAP server does the > conversion. -- Tim > > I am a bit confused abot the could (probably not enough mastering of the english language). In case you mean that it is up to any LDAP server implementation to try to optimize or not, then I strongly second rosenqui@crc.sofkin.ca in his plea to explicitely have the READ and LIST ops available criticize the current proposal No one will control by whom and how LDAP servers will be developped, thus the LDAP client developers and users will have no idea if a given request will lead to realistic or totally unrealistic interworking depending on the provider of the DSA servers being accessed. let me just give you an (hypothetical?) example: French master is a non QUIPU like DSA ie the master entries of all the Org in France are hold by the org. DSAs let suppose 1. we have a few hundreds org DSAs in France 2. a client just need to know wether a given DN is valid (eg C=FR; O=a-given-org; exist) and get the Org fax number a search-one-level base-object: C=FR; filter: Class: organization O=a-given-org; Don't use copy flag: SET would result in chaining a few hundreds DSAs (or more reaslistic in returning a few hundred referals) while a read C=FR; O=a-given-org; will only rely in one chaining from the french master to the DSA manging "a-given-org" data From a very prgmatic point of view the 1rst will never succeed while the second will be performed in a matter of milliseconds. Thus, the first choice is totally UNACCEPTABLE and cann't be included in a RFC which aims at openness. -- PAP PS: let me remind everyone that the QUIPU choice which consist in having all the master entries under a node being held by the same DSA, is 1. a very QUIPUcentric view of the X.500 world 2. is, after many thoughts, brain-damaged, when you take into account security and authentication, and will (in my mind) certainly be followed by nearly no other implementations. I am ready to bet a bottle of "faugeres" that ISODE Cons. will have to do something about this in the near to medium future. My advice, don't base any design of thsi very proprietary functionality!
- 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