Re: LDAP
pays@faugeres.inria.fr Wed, 02 June 1993 08:55 UTC
Received: from ietf.nri.reston.va.us 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 haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa03869; 2 Jun 93 4:54 EDT
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.01683-0@haig.cs.ucl.ac.uk>; Wed, 2 Jun 1993 09:14:18 +0100
Via: uk.ac.nsfnet-relay; Wed, 2 Jun 1993 09:14:11 +0100
Received: from faugeres.inria.fr by sun3.nsfnet-relay.ac.uk with Internet SMTP id <sg.12264-0@sun3.nsfnet-relay.ac.uk>; 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: Wed, 02 Jun 1993 10:13:02 +0200
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: pays@faugeres.inria.fr
To: j.onions@nexor.co.uk, pays@faugeres.inria.fr
Subject: Re: LDAP
cc: osi-ds@cs.ucl.ac.uk, tim@terminator.rs.itd.umich.edu
Message-ID: <739008782.21137.0-faugeres.inria.fr*@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. regards, -- PAP
- LDAP Erik Huizer
- Re: LDAP pays
- Re: LDAP Tim Howes
- Re: LDAP Tim Howes
- Re: LDAP pays
- Re: LDAP Christian Huitema
- Re: LDAP Julian Onions
- Re: LDAP Julian Onions
- Re: LDAP pays
- Re: LDAP Mark Prior
- Re: LDAP Tim Howes
- Re: LDAP Christian Huitema
- Re: LDAP Tim Howes
- Re: LDAP Edwards Reed
- Re: LDAP Tim Howes
- Re: LDAP Tim Howes
- Re: LDAP Brien L. Wheeler
- Re: LDAP Steve Kille