[Ietf-not43] extensibility

[Michael.Dillon at radianz.com]

>This message is in the context of my being ignorant about LDAP's 
>deployment.  I'm not saying the LDAP is garbage, I'm saying that I am 
>unaware of it's advances.  Given that background ...

Well, let's get that background up to date. 

First some universities that have replaced their internal whois directory 
with LDAP directories. Read through the entire pages because there is a 
lot of useful background that is mentioned here.

http://www.uwo.ca/its/projects/ldap_phaseI.html
http://www.stanford.edu/group/dcg/pdd/projects/dirlookup/dir_require.htm

Next, naming. A lot of LDAP directories and directory tools have different 
names so you won't know that they are based on LDAP until you dig deeper. 
For instance, Microsoft calls their version Active Directory and Novell 
calls theirs Novell Directory Service. On Solaris it's the Sun ONE 
Directory Server. If you browse through some books on these topics in the 
bookstore you'll see that they are all just LDAP with some specific 
schemas and architecture. Also, since the early LDAP standards didn't 
include things like replication, these directory services all built their 
own extras.

Note that it is possible to take something like OpenLDAP and make it work 
in a SunONE or Microsoft AD environment with the right schemas
http://www.yolinux.com/TUTORIALS/LinuxTutorialLDAP-GILSchemaExtension.html
Or maybe you'd prefer to have a calendaring system integrated with LDAP?
http://www.steltor.com/notes/corptime-server/5_1/refmanual/refappe.htm#1046875
Or maybe you just want to use it to manage DNS zone files?
http://ldap2dns.tiscover.com/

Because LDAP is part of the plumbing of a directory service, it sometimes 
gets bundled together with other stuff that looks like a directory 
service, for instance JNDI is the Java Naming and Directory Interface. 
This allows a Java developer to use things like LDAP, DNS or NIS without 
needing to know the details of the individual protocols.

LDAP is used as a fundamental component of the worldwide datagrid used for 
their Monitoring and Discovery Service. This is the system that allows 
researchers to ship data to computers around the world and solve problems 
as if they have a gigantic supercomputer array of their own. They use a 
patched version of OpenLDAP. They've also published some benchmarks to 
show how scalable LDAP is.
http://www.globus.org/testing/dmark_results.html

LDAP is also part of the core "best practices" that the NSF is promoting 
to its audience of research institutes and universities. Again, they don't 
say "LDAP" because it's just part of the middleware plumbing.
http://www.nsf-middleware.org/ 
Much of this comes out of the Internet2 middleware initiative.
http://middleware.internet2.edu/ 
http://www.georgetown.edu/giia/internet2/ldap-recipe/

Wait a minute, isn't middleware just another term for those Message 
Queuing systems like MQSeries, MSMQ and TIB/Rendezvous? Yep, right you 
are. And LDAP is being used here as well
http://support.sas.com/rnd/itech/doc/messageq/common/index.html
This is the Enterprise version of gluing apps together...

So, the conclusion is that LDAP is widely used in industry and academia, 
is available in many implementations and is widely documented in books and 
on the web. There are also lots and lots of IT professionals who have 
LDAP-related skills (either programming or running servers) so that 
companies can actually hire people with experience to build anything they 
need for CRISP's LDAP directory. Oops, I forgot, we gave LDAP a new name 
too. I meant to say FIRS.

Admittedly, XML has many of the same advantages, however the halo of 
activity around XML is related to things other than building and running 
directory services. Since CRISP is fundamentally a directory service, it 
will be easier to implement if people use FIRS because then they get to 
leverage the halo of activity around LDAP.

BTW, if someone finds a need to use an XML-RPC or a SOAP interface to get 
at the FIRS service, I'm sure that it would be a trivial programming 
exercise to make a FIRS client that is an XML-RPC or SOAP service. I 
suspect that the IRIS work will be more useful if it is refocused into 
providing a SOAP interface to an underlying FIRS service.

--Michael Dillon