Rep (2) : LDAP

Ascan Woermann <> Wed, 02 June 1993 20:21 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa14902; 2 Jun 93 16:21 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14898; 2 Jun 93 16:21 EDT
Received: from by CNRI.Reston.VA.US id aa10598; 2 Jun 93 16:21 EDT
X400-Received: by mta in / 400/C=gb/; Relayed; Wed, 2 Jun 1993 20:31:29 +0100
Date: Wed, 2 Jun 1993 20:31:29 +0100
X400-Recipients: non-disclosure:;
X400-MTS-Identifier: [/ 400/C=gb/; haig.cs.uc.314:]
Priority: Non-Urgent
DL-Expansion-History: ; Wed, 2 Jun 1993 20:31:29 +0100;
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Ascan Woermann <>
Message-ID: <73904944211322woer*/S=Woermann/OU=OSI/O=E3X/PRMD=E3X/ADMD=atlas/C=FR/@MHS>
To: Julian Onions <>,,,
In-Reply-To: "11640.739010376(a)":
References: "":
Subject: Rep (2) : LDAP

> > 1. LDAP will not only be used for UFN queries, there will be plenty
> > 	of other usage (eg what Tim has done with mail500
> > 	and plenty of gateways)
> > 	-> thus LDAP should not be designed with only UFN in mind
> True. But in these applications, they are likely to use DN's direct
> anyway rather than searches to resolve them.
> > 2. Even with UFN like interfaces, nothing prevents the X.500 client
> > 	to be a little less dumb and for example
> > 	be able to replace in the read England by GB or france by FR
> > 	and even more to record after a first query the exact RDN
> > 	for Nexor organisation.
> In that case you are slowly importing the whole X.500 DIT into the
> application! If it knows that UK and GB are equivalent, and Nexor &
> Nexor Ltd are too, very soon you won't need a DSA at all.

Uhmm, ..., a UFN-style algorithm that exploits name error information in 
the way Paul-Andre explained, provides a single "lookup" function (& a single
button on your UI) that may conveniently be used by a wide range of users 
from novices to experts without significantly penalising either end of the 

> > 	-> I would hate to see LDAP spec limit the inventiveness
> > 	or cleverness of X.500 clients designers and implementors
> > 	because it lacks a few features
> Yes - but you have to balance things. You can put this same argument
> to any extension to the LDAP protocol. (Lets add an XXX argument to
> all operations - not to do so might limit some implementors...).
Whilst not wanting to unbalance things, I'll put forward a proposal for
an enhancement to future versions of LDAP: a connectionless mode of operation.
I'd understood this to be in the protocol, but evidently misinterpreted some
of the mail exchanges on this list. The class of application that would 
benefit from such functionality, does a lookup for what should be public 
information only occasionally or infrequently and requires high performance. 
I think this is an aspect where LDAP can offer real value vs. DAP.

Ascan Woermann