I'd like to stop this argument now by saying you are both right. *) LDAP is a protocol, not an implementation. The back-end can be anything... even monkeys with pencil and paper. *) Michael's point about doing things differently and hopefully in a better way does not hinge on technology... it is a matter of will. The technology exists. *) In order to run an efficient public-facing LDAP server that scales to the order needed by many but not all, off-the-shelf vendor software will not suffice. *) LDAP in its current form does not contain the operations or data types needed by this community. However, it is an extensible protocol and anyone with a source-available or pluggable implementation will not be starting from scratch. *) Having to extend the protocol means that generic clients are of limited use but not unuseable. *) As Stephane said, there are a number of people looking at this in the IETF CRISP working group. And LDAP is one of the proposed solutions. -andy bmanning@karoshi.com wrote:
Too many features layered on a single tool. Haq the tool and the dependencies will cripple your service offering.
LDAP is not a tool, it is a protocol that can be used by many tools to communicate in the same way that many servers (BIND, NSD, DJBDNS, MS-DNS, QuickDNS) can use the DNS protocol to communicate with countless clients (Netscape, sendmail, ...).
tool in the generic sense. too many things that depend on LDAP for proper functioning -will- make LDAP a tempting target.
-- Andrew Newton