Why do we need the LDAP protocol?
I do see that it's very difficult to use X.500 as it is defined
in the standards. The major problems I see are:
- the use of the OSI stack
- the very complicated programming interface (XDS/XOM)
I think these (may be others) have been reasons to develop LDAP.
But there could be another approach:
Why not putting the X.500 protocol directly on IP (let's say TCP/IP)?
Why not just remove the use of the OSI stack?
I would call these protocols: IPDAP, IPDSP, ...
IPDAP, ... would solve the first problem mentioned above and would have some
advantages:
- no need for a second standard
I think it's very difficult to keep the LDAP standard synchronized
with the X.500 series. Whenever there are changes to X.500 (i.e.
1993 standard; v3 certificates, ...) or the implementers guide
or whatever the LDAP standard has to be rewritten as well.
- full support of X.500 services
The LDAP protocol was designed as a lightweight version of DAP
(1988). There is no leightweight server-server protocol (X.500: DSP).
There is also no server-server protocol concerning shadowing
(X.500 1993: DISP, DOP). (There is - slurpd; but it's different
from X.500 1993). There are other features of the 1993 standard
not (yet?) supported by ldapd or slapd.
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
client but it would be accessable for the server. There are
probably other good reasons for DSP.
There are other X.500 features (Bind with X.509 certificates,
signed requests/results, ...) not (yet?) supported by
the LDAP protocol.
- no need for a "translater" between LDAP and X.500
A X.500 server would be able to serve both DAP clients an IPDAP
clients with the same code. It just listens on two ports - OSI
port (102) and IPDAP port -, extracts the user data and then
uses the same code to serve the request.
So I think an X.500 product vendor could integrate IPDAP, ...
very easily.
The impact on an IPDAP client would be that it needs to have a
full ASN.1 BER encoding/decoding library. This shouldn't be that
difficult - LBER is already there.
I'm sure that I'm not the first one having this idea. So: Who knows
disadvantages of this approach?
The second problem - programming interface: I know that it's much easier
to write LDAP applications than to use XDS/XOM. I know that there
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?
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, ...).
So it seems easier to me to work with one standard instead of
having two of them.
I'd really appreciate to receive many comments on this proposal.
Regards,
Jochen.
------------
Dr. Jochen Keutel currently at: Deutsche Telekom
duerr com-soft IZ Darmstadt
Phone: +49 6151 818 579
e-mail: keutel@u9ytb.iz-darmstadt.telekom.de
100.37805@germanynet.de
X.400 : /C=de/A=dbp/P=telekom400/O=dmst03/OU1=08/S=osys-02
WWW : http://www.geocities.com/WallStreet/3454