RE: LDAP Observation

[Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>]

 Mark - a couple of points here. The basis for the debate is that LDAP
is a single server access protocol with many single server oddities and
a pile of many disjointed specs - and that X.500 is a distributed system
that has put features in its access protocol to deal with the features
of replication and distribution.

To cite a test of a protocol that did not work too well between
companies a year or so ago as the basis that the system engineering is
wrong is not very useful.

One can have a bad standard with a bad or good implementation
one can have a good standard with a bad or good implementation
Its the scope that the standard from a system perspective that will
dictate its utility.

A standard as most will understand is about 20% of a product - ie the
product needs packaging, user features, config stuff, etc.

LDAP standards cover about 10% of X.500 and the easy part to say the
least. Therefore an X.500 product with DAP and LDAP access that provides
distribution and replication - (without the LDAP configuration army to
replicate everything to everywhere as need by LDAP serevrs),  I would
consider as a System with utility that has a 700% (roughly) greater
solution space to that provide by LDAP only solutions.

I find that when a customer wants to move to distributed information
infrastructures - one can get into the weeds with LDAP and addresss book
servers or one can say X.500 provides a far greater solution space with
the emphasis on serious scaleable, distributed information systems.



LDAP - well many said (and to paraphrase LDAP/X.500 with the telephone
system) that the "telephone system" with all its distribution and
switching and global numbers was all to complicated. But instead we will
make a telephone and its access wire.
However to connect these things up we have to hand configure everything
and anything and  everywhere as the system grows. (the telephone
configuration army!)

If the X.500 system design and issues are deemed to complex to start
with, then what does one do about the system.
The Hype that LDAP will replace X.500 is a joke - a telephone can not
replace the telephone network.

However, someone somewhere has to design the telephone
network...Otherwise and we are seeing LDAP is very constrained to local
use.
In my book X.500 did that system design over 10 years ago - and the LDAP
work has continually proved that what was put in X.500 still holds very
true.

As said some time ago 
a) with LDAP - one can re invent X.500 one sentence at a time or
b) one can avoid X.500 one sentence at a time. 
The first case is futile and the second case will go not very far.


As said, the more one packs around LDAP (which is 10% of X.500 - with as
many pages of text and specs) the worse it will get.

How many bells does one want on a telephone?


regards alan

ie. distributed systems, particularly object oriented distributed
systems is a complex problem that wont be fixed with a simple solution
or a system design - 

ie. the LDAP approach to building a "distributed" information
infrastructure is a non starter. OR one cannot design a global telephone
system based on the engineering principles and methodologies of a making
a telephone.

Reality MODE
Customers want scaleable information infrastructures and that includes
moving to object oriented approaches - X.500 directory systems are
object oriented distributed name based transaction systems - that have
DSP for chaining, mutual authentication and domain based access
controls, etc.



----------
From: Mark Wahl
To: Alan Lloyd
Cc: ''Colin Robbins' '; ''IETF LDAP Extensions WG ' '
Sent: 10/5/98 4:53:30 AM
Subject: Re: LDAP Observation


> However. being an optimist - the more proprietary, complex, optioned
up
> and non interoperable - and costlier to run and entrenched on single
> servers, LDAP gets, the easier it is to deploy X.500.

Be careful with your comparison.  I have never seen any test or
deployment in 
which DISP interoperability among major X.500 vendors actually was
achieved.
When, for example, an ICL-based, an ISODE-based and a DataCraft-based
product 
are interconnected, what is the subset of X.500 that works
transparently?

DANTE carried out several attempts in 1996 and 1997 to get X.500(93) 
interoperability.  The quotes below are from the report located at 
http://www.dante.net/np/93pilot/phase2-results.html

 snip

The X.500 numbers were from the 1993 edition. When will the 1997 X.500 
documents be published, how many pages will they be, and when might
there be 
interoperabilty between vendors using X.500(97) features?

Just curious,

Mark Wahl, Directory Product Architect
Innosoft International, Inc.