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: Wed, 05 May 1993 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!