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