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