Re: LDAP

Julian Onions <j.onions@nexor.co.uk> Wed, 02 June 1993 08:54 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00844; 2 Jun 93 4:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00840; 2 Jun 93 4:54 EDT
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa03864; 2 Jun 93 4:54 EDT
X400-Received: by mta haig.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold 400/C=gb/; Relayed; Wed, 2 Jun 1993 09:40:29 +0100
Date: Wed, 02 Jun 1993 09:40:29 +0100
X400-Originator: osi-ds-request@cs.ucl.ac.uk
X400-Recipients: non-disclosure:;
X400-MTS-Identifier: [/PRMD=uk.ac/ADMD=gold 400/C=gb/; haig.cs.uc.032:02.05.93.08.40.29]
Priority: Non-Urgent
DL-Expansion-History: osi-ds@cs.ucl.ac.uk ; Wed, 2 Jun 1993 09:40:29 +0100;
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Julian Onions <j.onions@nexor.co.uk>
Message-ID: <11640.739010376@nexor.co.uk>
To: pays@faugeres.inria.fr
Cc: osi-ds@cs.ucl.ac.uk, tim@terminator.rs.itd.umich.edu
In-Reply-To: "739008782.21137.0-faugeres.inria.fr":
Subject: Re: LDAP
Discarded-X400-IPMS-Extensions: ccitt (0) data (9) pss (2342) (2342) (19200300) (200) (1)

> 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.

> 	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.
Agreed - but in this case you are extending the original proposal. I
saw that as only returning the matched result as an error. I see now
you want it returned in lots of cases.

> 	-> 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...).

> 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?
The former I would say, but to get it done in a timely fashion too.

>   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?
No - if you are refering to my backwards compatibility remark, you may
be misinterpreting it. It was just a comment on how small the change
was. 

> 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.

No - adding it where I did means that every result could have a
matched DN returned. This is probably not reasonable for all results.
Making it OPTIONAL means not all resultCode's need to include a DN.
Consider some of the resultCode's :-
	 authMethodNotSupported	  
	 strongAuthRequired	  
	 invalidCredentials
	 busy
	 unwillingToPerform
	 unavailable
	 operationsError
	 timeLimitExceeded
- what would a matchedDN imply in any of these cases?
Also, if you include this as a generic value, you can remove the
objectName from SearchResponse too I suspect.

I don't think I'm arguing against your algorithm, just trying to
highlight the pros & cons (and playing a little devils advocate). I
would actually like this extension in, it would allow the MHS-DS
algorithms to use LDAP efficiently. 

Julian.