Re: LDAP Comments
pays@faugeres.inria.fr Fri, 07 May 1993 09:58 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01138;
7 May 93 5:58 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01134;
7 May 93 5:58 EDT
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa03455;
7 May 93 5:57 EDT
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP
id <g.04620-0@haig.cs.ucl.ac.uk>; Wed, 5 May 1993 21:10:18 +0100
Via: uk.ac.nsfnet-relay; Wed, 5 May 1993 21:09:53 +0100
Received: from faugeres.inria.fr by sun3.nsfnet-relay.ac.uk with Internet SMTP
id <g.03797-0@sun3.nsfnet-relay.ac.uk>;
Wed, 5 May 1993 21:09:24 +0100
X400-Received: by /PRMD=inria/ADMD=atlas/C=fr/; Relayed;
05 May 93 22:07:46+0200
Date: 05 May 93 22:07:46+0200
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: pays@faugeres.inria.fr
To: a.shepherd@nexor.co.uk, pays@faugeres.inria.fr
Subject: Re: LDAP Comments
cc: osi-ds@cs.ucl.ac.uk, rosenqui@crc.sofkin.ca,
tim@terminator.rs.itd.umich.edu
Message-ID: <736632466.8939.0-faugeres.inria.fr*@MHS>
fully agreed about what was said search is a valid an even probably the most important operation -> thus every DSA has to perform well with such operations fully agreed too pizarro has to be improved a lot Quipu way of handling knowledge has to be changed fundamentaly In fact, as far as I know, all and evry implementation I have some knowledge of, has to be improved, improved a lot, to cope with all the usage we have in mind. the only thing I do not accept is to appear as a Pizarro zelot, fighting against QUIPU or any other implementation. and this for many reasons: my task is to take into account heterogeneity and produce hints and recommandations so that future releases from every provider behave "decently" I have no control over the planned evolution of Pizarro, which is in the hand of one research team for one part and a company on the other part. With this in mind, I think that we could agree that there are some holes in the standard, and that in order for X.500 to succeed is, up to a certain point, to achieve some consensus between all X.500 designers/developers so that interworking has a chance. It is vital for X.500. Later on, but later on only, there will be competition between implementation, and market will decide. We are all to be aware 1. that there not yet a real market for X.500, with real money for the vendors, so that it would be a suicide to try too early to go that fight for market way. 2. that we are still ina pilot phase (no matter how successful it might prove today) and that the role of a pilot is to derive the real requirements for the next phase. All vendors and developers have to gain from the experience gained during this pilot, and please keep in mind I am not one of them (vendor). last point: what I really want to avoid is to have DS client developers to use search operations, when a simple read (or a base object-search) could do the trick. My experience has proven, that probably due to the particular strengh of QUIPU to cope with one-level-search many tools have been developed over the assumption that this is a costless operation, and this resulted in poor operational interworking. Of course when search is the appropriate operation, it HAS to be used, and this puts a strong requirement on the developers best regards, -- PAP
- LDAP Comments Eric Rosenquist
- Re: LDAP Comments Tim Howes
- Re: LDAP Comments pays
- Re: LDAP Comments Tim Howes
- Re: LDAP Comments pays
- Re: LDAP Comments Alan Shepherd
- Re: LDAP Comments Tim Howes
- Re: LDAP Comments pays
- Re: LDAP Comments Tim Howes
- Re: LDAP Comments pays
- Re: LDAP Comments Alan Shepherd
- Re: LDAP Comments Valdis Kletnieks
- Re: LDAP Comments Tim Howes
- Re: LDAP Comments pays
- Re: LDAP Comments Christian Huitema
- Re: LDAP Comments Tim Howes
- Re: LDAP Comments Steve Kille
- Re: LDAP Comments Christian Huitema