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