Re: LDAP Wed, 02 June 1993 08:55 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa00858; 2 Jun 93 4:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00854; 2 Jun 93 4:55 EDT
Received: from by CNRI.Reston.VA.US id aa03869; 2 Jun 93 4:54 EDT
Received: from by with local SMTP id <>; Wed, 2 Jun 1993 09:14:18 +0100
Via:; Wed, 2 Jun 1993 09:14:11 +0100
Received: from by with Internet SMTP id <>; Wed, 2 Jun 1993 09:13:55 +0100
X400-Received: by /PRMD=inria/ADMD=atlas/C=fr/; Relayed; 02 Jun 93 10:13:02+0200
Date: 02 Jun 93 10:13:02+0200
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
Subject: Re: LDAP
Message-ID: <*@MHS>

Julian you are certainly right in your comments stating that
when the tokens given by a human user are used directly to
prepare the DN used for the read in several case there will be
no great improvement

HOWEVER, let me also undermine some of your assumptions

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

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.
	Moreover, very often users will not made one single isolated
	query but several and I would appreciate in case of error
	to have a DUA which will at the UI level propose the
	last correct RDN that have been obtained from a previous
	query. Thus even if a first request may in many cases
	result is a sequence of one-level-searches, odd are non zera
	that for a following query correct RDN (say for NeXor org
	RDN) be usable again.
	-> 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


Additionaly let me ask a naive question:
  Is the goal of the IETF draft/review process to try to design
	specify the best possible protocols 
	or to protect any early investment?
  I understood that the purpose of the mandatory implementations
	enforced by the IETF process was to gain experience on the
	field and thus be able to improve the final version of
	the RFC standards, and not let the fastest implemntors
	dictate the standard to the whole community.
	Or do I have misunderstood the whole intention and process?

In practice, does your proposal (OPTIONAL matchedDN) means that
any LDAP server will be free to return or not this
service element? That would be crazy.
There is not such a large existing investment in LDAP yet
that such a minor change could not be made mandatory, if
it is felt as potentially useful.


-- PAP