[ Crossposted with a purpose... please read on. -jeff ]
Jochen Keutel wrote:
> Why do we need the LDAP protocol?
We need lightweight data access methods because the baggage they leave
behind from X.500 is better left behind. (Please don't let this become
a flame war -- you need to understand that this document is my
technical assesment.)
You cite some parts of the X.500 world that are not well tracked by
LDAP. If you wanted LDAP to replace X.500 feature for feature, yes,
you'd need to implement them. But LDAP is lightweight, that's in it's
name. LDAP will likely never directly do server-server communication,
shadowing, etc.
With respect to your comments, here's where I stand, as an implementor
of an alternative to X.500 (I work on Whois++ and CIP, and I'm
familiar with work progressing to tie LDAP into CIP).
> - no need for a second standard
A second standard is just what we've needed for a long time, and it
now what we have, in the form of Whois++, LDAP, and Ph. We need all of
these, because diversity encourages creativity, and because not all
technologies fit all applications.
> The LDAP protocol was designed as a lightweight version of DAP
> (1988). There is no leightweight server-server protocol (X.500: DSP).
> I think there is a real need for support of DSP. It's not
> sufficient to return referrals to the client - it might be that
> the DSA the referral points to is not accessable for the
In the fully connected Internet world where LDAP was designed,
implemented and deployed, chaining is not necessary, and it's an
unfair burden to put on servers. Servers should be optimized for serving
instead of proxying. If you _really_need_ to hide an LDAP server
behind a firewall and you'd like to use chaining to allow the Internet
to access it, then _you_ can write a proxy. So far, people haven't
needed it, so it hasn't been written.
You also mentioned shadowing. With all of the data access protocols I
mentioned, shadowing is possible on an ad hoc basis between consenting
administrators using external means. Is it clean and elegant? No. Does
it work inside the existing protocol? No. Does it get the job done and
keep the state of the art advancing? Yes. The philosophy exhibited
here is "build cool structres out of little easy to understand
pieces", which runs contrary to a fair amount of the X.500
underpinnings (which I belive is "provide for all contingencies and
every requested feature at the cost of implementation difficulty"). I
don't know which philosophy is better, but I know using the X.500
philosophy with LDAP and friends is asking for trouble -- they simply
come from different worlds.
> There are other X.500 features (Bind with X.509 certificates,
> signed requests/results, ...) not (yet?) supported by
> the LDAP protocol.
Yes, LDAP doesn't support everything X.500 does. If you want full
X.500, then you'll probably have to try compiling ISODE. Good luck.
> is a new X/Open standard: XFN (Federated Naming). So I don't know what's
> better: the (may be slightly modified) LDAP programming interface
> or XFN. Any comments?
I have no experience with either. In general, I believe it's more
important to worry about the complexity of the protocol and the
architecture than the complexity of the interface provided. If you
don't like the interface but you can't understand the protocol without
a raft of special tools, you are stuck. If you can poke at example
servers, try the protocol yourself, etc, you can probably whip up a
nice little API that suits your purposes. (This is one reason whay I
don't think it's a big problem that there are not API's generally
available for Whois++ and Ph.)
> To be clear: I really like the LDAP protocol. But I also see that
> LDAP - as it is - can't be a stand-alone directory service. You'll
> always need a X.500 server (or something similar - Novell, Banyan, ...).
It's not at all clear to me that we need a monolithic solution. I
agree than LDAP can't exist in a vacuum. However, I think that
whatever we use to tie LDAP servers together (what I think you are
proposing to do with IPDSP and friends) should be general purpose in
nature. This allows it to tie LDAP to Whois++, and to X.500, and to
Ph, and other protocols not even designed yet. And if we really put
our minds to it, we might be able to leverage this same technology
outside of the directory services field to tie other data access
protocols together. This is what CIP is all about, and that's why I
am not personally interested in walking down the X.500 road anymore.
For more info on CIP, subscribe to the "find@bunyip.com" mailing list
via majordomo@bunyip.com. There are two Internet drafts available
(though one is not archived yet). I can send them both to interested
people by e-mail, until they are available via FTP from Internic.
--
Jeff Allen <jeff@bunyip.com> | For information about Bunyip
Bunyip Information Systems, Inc. | send e-mail to <info@bunyip.com>