site/src/site/oldxdocs/project-proposal.html - directory-project - Git at Google

 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
 <!-- saved from url=(0067)http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheDirectoryProject -->
 <HTML><HEAD><TITLE>Apache Wiki: ApacheDirectoryProject</TITLE>
 <META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
 <META content="MSHTML 6.00.2800.1276" name=GENERATOR></HEAD>
 <BODY text=black vLink=purple link=blue bgColor=white>
 <H1><A href="http://nagoya.apache.org/wiki/apachewiki.cgi?HomePage"><IMG
 alt=[Home] src="./images/asf_logo_wide.gif" border=0></A><A
 href="http://nagoya.apache.org/wiki/apachewiki.cgi?search=ApacheDirectoryProject">ApacheDirectoryProject</A></H1><A
 href="http://nagoya.apache.org/wiki/apachewiki.cgi?HomePage">HomePage</A> | <A
 href="http://nagoya.apache.org/wiki/apachewiki.cgi?RecentChanges">RecentChanges</A>
 | <A
 href="http://nagoya.apache.org/wiki/apachewiki.cgi?action=editprefs">Preferences</A><BR>
 <HR>

 <H1>Proposal for an Apache Directory Project</H1><EM>10 Sept 2003, Alex Karasulu
 (aok123@bellsouth.net) LDAPd Group Founder</EM>
 <HR>

 <P>
 <P>
 <P><STRONG>Section 0 : Rationale</STRONG>
 <P>The geometric growth of networks, services, distributed systems, and their
 components has brought about a revival of interest in directories. Directories
 are no longer considered commodity products used to store a phone book or list
 of users. Directories and LDAP have grown into a critical technology that will
 inevitably become a cornerstone of distributed systems. Several software giants
 like BEA, SUN, and Microsoft have already demonstrated their belief in this
 outcome by heavily integrating their products with directories. Directory and
 naming systems are being used in everything from a simplified form for J2EE
 configuration to full-blown enterprise directories, within identity management
 systems and distributed computing platforms like JINI.
 <P>
 <P>The overhead of managing several copies of relatively static information
 across systems and enterprises is daunting and introduces the potential for data
 inconsistency. The frequently replicated user and group tables in almost every
 database driven application alone is a testament to this fact. When multiple
 systems have to inter operate, they must share access to common information, and
 directories are the best storage paradigm for rapidly accessing this type of
 data. Whether the information to be stored, is a component's configuration, a
 user's security profile, a business rule or a business process, directories are
 the place to store it for centralized management, and distribution across
 systems.
 <P>To date, a fully compliant pure Java open source LDAPv3 server has not yet
 been written. This is partially due to the fact that a practical stateful
 protocol server in Java was virtually impossible until the introduction of the
 NIO packages in the 1.4 SDK. LDAP, as a stateful protocol, manages client state
 through a TCP socket connection. The socket connection persists through several
 client requests and server responses tying them together under a logical session
 or conversation. Before the introduction of non-blocking IO in the NIO packages
 of the 1.4 SDK, a thread had to be dedicated to each socket to detect IO. A
 stateful protocol server written completely in Java, would have needed as many
 active threads as the number of concurrent clients. Theoretically, scalability
 would have been very poor; the performance curve would be asymptotic, degrading
 rapidly with an increase in the number of concurrent connections. To scale pure
 Java statefull protocol server implementations had to wait until the Merlin
 release of the JDK.
 <P>Furthermore, no embeddable pure Java LDAPv3 server has yet been written and
 made freely available. We believe the embedding of LDAP servers into existing
 mail, application and web servers to be the next logical steps in the
 progression and integration of LDAP. Several commercial examples can already be
 sited: Microsoft Exchange and BEA Weblogic Server. The management benefits of
 coupling these servers with an LDAP server are beyond the scope of this proposal
 and left to the imagination of the reader. However, the synergy between embedded
 LDAP servers and other flagship Apache servers would lead to greater economies
 of scale for the Apache server suite and reduce the overhead of management for
 the Apache software user community.
 <P>LDAP directories are specialized databases, however unlike their RDBMS
 counterparts, LDAP directories are fairly new and for this reason lack rich
 integration features. High on the list of features lacking in LDAP servers are
 stored procedures and triggers. Triggers and Java stored procedures would expand
 the horizon of LDAP in itself even without the benefits of Java. Triggers and
 stored procedures would alleviate ugly workarounds which currently using polling
 and meta directories. These features alone would attract groups within the LDAP
 and Java communities to band together and support the Apache LDAP Project.
 <P>LDAP is both a network line protocol and a hierarchical relational database.
 Some might even argue that LDAP is object oriented. Regardless, the
 implementation of an LDAP server is not a trivial matter. LDAP code bases
 written in native languages have to be ported to run on different platforms.
 Conditional complies in C based implementations were shown to considerably
 reduce the maintainability of code bases. The complexity of a database, a
 network line protocol and conditional compilation together have resulted in
 reduced maintainability for C based LDAP servers. Also the learning curve and
 hence barrier to entry for developers is greater. These complications would not
 exist for a Java based LDAP server that is written once and can run anywhere.
 <P>The Apache Foundation supports several component container projects which
 provide the proper foundation for a Java LDAP directory server. Apache also
 supports several server side application containers which can realize
 significant functional enhancements by employing an LDAP directory server. Also
 LDAP requiring organizations today must settle for less than optimal
 implementations and often have to pay as high as a dollar per entry to directory
 enable their applications. The Apache LDAP Project would solve these problems by
 providing a free robust LDAPv3 implementation in a standalone configuration or
 an embeddable configuration for use in all Apache servers and other third party
 products.
 <P>Our goal is to produce a community of developers with backgrounds in LDAP,
 X.500, Database Engineering and JNDI tasked with the development of pure Java
 LDAPv3 Clients, APIs, JNDI providers and LDAPv3 compliant servers with the
 aforementioned features. The produced software will be ASF licensed. Where
 applicable the best available ASF/BSD licensed code will be reused and new code
 will be added to complete the LDAPv3 protocol as defined in <A
 href="http://www.ietf.org/rfc/rfc3377.txt">[RFC 3377]</A> and its associated 8
 RFCs listed below:
 <P>
 <UL>
   <LI><A href="http://www.ietf.org/rfc/rfc2251.txt">[RFC2251]</A> Lightweight
   Directory Access Protocol (v3): LDAP on-the-wire protocol
   <LI><A href="http://www.ietf.org/rfc/rfc2252.txt">[RFC2252]</A> Lightweight
   Directory Access Protocol (v3): Attribute Syntax Definitions
   <LI><A href="http://www.ietf.org/rfc/rfc2253.txt">[RFC2253]</A> Lightweight
   Directory Access Protocol (v3): UTF-8 String Representation of DNs
   <LI><A href="http://www.ietf.org/rfc/rfc2254.txt">[RFC2254]</A> The String
   Representation of LDAP Search Filters
   <LI><A href="http://www.ietf.org/rfc/rfc2255.txt">[RFC2255]</A> The LDAP URL
   Format
   <LI><A href="http://www.ietf.org/rfc/rfc2256.txt">[RFC2256]</A> A Summary of
   the X.500(96) User Schema for use with LDAPv3
   <LI><A href="http://www.ietf.org/rfc/rfc2829.txt">[RFC2829]</A> Authentication
   Methods for LDAP
   <LI><A href="http://www.ietf.org/rfc/rfc2830.txt">[RFC2830]</A> Lightweight
   Directory Access Protocol (v3): Extension for Transport Layer Security
 </LI></UL>
 <P>Additionally, the schema objects specified within the following RFCs will be
 defined for use and partial or full complaince will be met where relavent to the
 project:
 <P>
 <UL>
   <LI><A href="http://www.ietf.org/rfc/rfc1274.txt">[RFC1274]</A> The COSINE and
   Internet X.500 Schema
   <LI><A href="http://www.faqs.org/rfcs/rfc1804.html">[RFC1804]</A> Schema
   Publishing in X.500 Directory
   <LI><A href="http://www.ietf.org/rfc/rfc2079.txt">[RFC2079]</A> Definition of
   an X.500 Attribute Type and an Object Class to Hold Uniform Resource
   Identifiers (URIs)
   <LI><A href="http://www.ietf.org/rfc/rfc2247.txt">[RFC2247]</A> Using Domains
   in LDAP/X.500 Distinguished Names
   <LI><A href="http://www.ietf.org/rfc/rfc2293.txt">[RFC2293]</A> Representing
   Tables and Subtrees in the X.500 Directory
   <LI><A href="http://www.ietf.org/rfc/rfc2294.txt">[RFC2294]</A> Representing
   the O/R Address hierarchy in the X.500 Directory Information Tree
   <LI><A href="http://www.ietf.org/rfc/rfc2307.txt">[RFC2307]</A> An Approach
   for Using LDAP as a Network Information Service
   <LI><A href="http://www.ietf.org/rfc/rfc2377.txt">[RFC2377]</A> Naming Plan
   for Internet Directory-Enabled Applications
   <LI><A href="http://www.ietf.org/rfc/rfc2587.txt">[RFC2587]</A> Internet X.509
   Public Key Infrastructure LDAPv2 Schema
   <LI><A href="http://www.ietf.org/rfc/rfc2589.txt">[RFC2589]</A> Lightweight
   Directory Access Protocol (v3): Extensions for Dynamic Directory Services
   <LI><A href="http://www.ietf.org/rfc/rfc2596.txt">[RFC2596]</A> Use of
   Language Codes in LDAP
   <LI><A href="http://www.ietf.org/rfc/rfc2649.txt">[RFC2649]</A> An LDAP
   Control and Schema for Holding Operation Signatures
   <LI><A href="http://www.ietf.org/rfc/rfc2696.txt">[RFC2696]</A> LDAP Control
   Extension for Simple Paged Results Manipulation
   <LI><A href="http://www.ietf.org/rfc/rfc2713.txt">[RFC2713]</A> Schema for
   Representing Java(tm) Objects in an LDAP Directory
   <LI><A href="http://www.ietf.org/rfc/rfc2714.txt">[RFC2714]</A> Schema for
   Representing CORBA Object References in an LDAP Directory
   <LI><A href="http://www.ietf.org/rfc/rfc2798.txt">[RFC2798]</A> Definition of
   the inetOrgPerson<A
   href="http://nagoya.apache.org/wiki/apachewiki.cgi?action=edit&amp;id=OrgPerson">?</A>
   LDAP Object Class
   <LI><A href="http://www.ietf.org/rfc/rfc2829.txt">[RFC2829]</A> Authentication
   Methods for LDAP
   <LI><A href="http://www.ietf.org/rfc/rfc2830.txt">[RFC2830]</A> Lightweight
   Directory Access Protocol (v3): Extension for Transport Layer Security
   <LI><A href="http://www.ietf.org/rfc/rfc2849.txt">[RFC2849]</A> The LDAP Data
   Interchange Format (LDIF) - Technical Specification
   <LI><A href="http://www.ietf.org/rfc/rfc2891.txt">[RFC2891]</A> LDAP Control
   Extension for Server Side Sorting of Search Results
   <LI><A href="http://www.ietf.org/rfc/rfc3045.txt">[RFC3045]</A> Storing Vendor
   Information in the LDAP root DSE
   <LI><A href="http://www.ietf.org/rfc/rfc3062.txt">[RFC3062]</A> LDAP Password
   Modify Extended Operation
   <LI><A href="http://www.ietf.org/rfc/rfc3088.txt">[RFC3088]</A> OpenLDAP<A
   href="http://nagoya.apache.org/wiki/apachewiki.cgi?action=edit&amp;id=OpenLDAP">?</A>
   Root Service An experimental LDAP referral service
   <LI><A href="http://www.ietf.org/rfc/rfc3112.txt">[RFC3112]</A> LDAP
   Authentication Password Schema
   <LI><A href="http://www.ietf.org/rfc/rfc3296.txt">[RFC3296]</A> Named
   Subordinate References in Lightweight Directory Access Protocol (LDAP)
   Directories
   <LI><A href="http://www.ietf.org/rfc/rfc3383.txt">[RFC3383]</A> Internet
   Assigned Numbers Authority (IANA) considerations for the Lightweight Directory
   Access Protocol (LDAP) </LI></UL>
 <P>
 <P><STRONG>Section 0.1 : Criteria</STRONG>
 <P>We feel that this project has a good chance for success as the following
 project aspects are carefully considered :
 <P><EM>Meritocracy:</EM> The project will be meritocratic - the usual Apache
 meritocracy rules would apply.
 <P><EM>Community:</EM> The user community for this project is potentially
 massive. The initial developer community for this project consists of developers
 from Apache and LDAPd projects. The aim is for this community to grow
 considerably once this project enters the incubator.
 <P><EM>Core Developers:</EM> The initial developers are listed further below
 within this document and consist of some existing Apache committers together
 with committers from the LDAPd Group.
 <P><EM>Alignment:</EM> There is clear alignment with many existing Apache
 projects. From Jakarta projects such as Tomcat, James and Slide for embedding
 LDAP. The LDAP DSML standards will eventually require the use of several XML
 projects. Other projects like OpenJms<A
 href="http://nagoya.apache.org/wiki/apachewiki.cgi?action=edit&amp;id=OpenJms">?</A>,
 which currently are not Apache projects but very well may be in the future will
 be used for things like replication. Jdbm likewise is used for building Btree
 based indices for custom databases. Also projects like Apache Xindice may be
 leveraged for an XML based backend or for DSML enabling subsystems of an LDAP
 server.
 <P>We see the Apache Directory Project as a separate project to existing Apache
 projects, serving several roles
 <UL>
   <LI>Home for Apache Directory Client APIs and Client Scripts
   <LI>Home for Apache JNDI Providers for Various Directory Namespaces
   <LI>Home for Apache Directory Servers
   <LI>May also become home to an ASN.1 Encoding/Decoding<A
   href="http://nagoya.apache.org/wiki/apachewiki.cgi?action=edit&amp;id=ApacheDirectoryProject/Decoding">?</A>
   Library </LI></UL>
 <P>
 <P><STRONG>Section 0.2 : Warning Signs</STRONG>
 <P>We feel this project has a good chance for success as the following warning
 signs do not apply to the project we are proposing:
 <P><EM>Orphaned products:</EM> This project is starting with an existing code
 base which using lots of the high quality open source code out there which is
 ASF/BSD licensed.
 <P><EM>Inexperience with open source:</EM> The initial community is made up of
 existing Apache and LDAPd Group committers exclusively so the open source
 experience is there to varying degrees.
 <P><EM>Reliance on salaried developers:</EM> None of the initial developers are
 currently paid to work on the Directory Project.
 <P><EM>No ties to other Apache products:</EM> The Apache Directory Project is
 complementary to existing technologies at Apache. LDAPd currently uses Avalon
 and will eventually be used by james. LDAPd will eventually integrate into
 Geronimo. The Apache Directory Project will integrate with, and possibly
 subsume, Jakarta Commons Naming.
 <P><EM>A fascination with the Apache brand:</EM> The committers are interested
 in developing a healthy open source community around ASF/BSD licensed directory
 servers and their clients along with other JNDI accessible name spaces. Is
 Apache the right place? We think it is. Several Apache folks have already shown
 interest in LDAPd, the seed code base to be used for this project. In fact the
 LDAPd Group was initially approached by Apache to submit an Incubator proposal.
 LDAPd Group members voted unanimously to donate the code to Apache in an effort
 to build the next flagship server at Apache and much more.
 <P>
 <P><STRONG>Section 1 : Scope of the Project</STRONG>
 <P>There are multiple goals for this Apache project:
 <P>
 <UL>
   <LI>Promote a healthy open source community!
   <LI>Promote a language agnostic environment for both client side and server
   side endeavors.
   <LI>A one stop location for all directory and naming needs on any platform or
   any language.
   <UL>
     <LI>client APIs
     <LI>clients
     <LI>JNDI providers for Java and other namespaces.
     <LI>May also include an LDAP protocol correctness and stress testing suite
     in the future. </LI></UL>
   <LI>Provide servers in embeddable configurations.
   <LI>Provide servers in standalone configurations as UNIX daemons or NT
   Services.
   <LI>Provide support for Directory Server embedding or integration with
   existing Apache servers like httpd, Slide, Tomcat, James and Geronimo.
 </LI></UL>
 <P>
 <P><STRONG>Section 2 : Initial Source</STRONG>
 <P>The initial code base from which to create the Apache Directory repository is
 contained mostly at Sourceforge under the LDAPd project accessible <A
 href="http://sourceforge.net/projects/ldapd">[here]</A>. This code base must
 assign copyright to the Apache Software Foundation. The code base will need to
 be licensed under The Apache Software Foundation license. The license file in
 every subproject will be changed to the Apache license. The current license is
 already an Apache "style" license, so this change is basically a change to name
 The ASF as the owner.
 <P>The proposed TLP (after incubation) would have an one or more directory
 servers with multiple datastore backends, a JNDI context for J2EE configuration,
 JNDI service provider(s) for LDAP and other transports, State and Object
 Factories suitable for use in the various Context/DirContext<A
 href="http://nagoya.apache.org/wiki/apachewiki.cgi?action=edit&amp;id=ApacheDirectoryProject/DirContext">?</A>
 implementations, etc.
 <P>Beside source code the LDAPd Group must transfer its IANA assigned ASN.1
 Object Identifier to Apache Software Foundation.
 <P><STRONG>Section 3 : ASF Resources to be Created</STRONG>
 <P><EM>Section 3.1 : Mailing Lists</EM>
 <P>
 <UL>
   <LI>directory-dev@incubator.apache.org </LI></UL>
 <P><EM>Section 3.2 : CVS Repositories</EM>
 <P>
 <UL>
   <LI>incubator-directory </LI></UL>
 <P><EM>Section 3.3 : Bugzilla or (preferably) Jira</EM>
 <P>
 <UL>
   <LI>directory </LI></UL>
 <P>
 <P><STRONG>Section 4 : Initial Set of Committers</STRONG>
 <P>All contributors must sign and submit a Contributors License Agreement. The
 following individuals are the contributors, and have signed and sent the
 agreement at one time or another:
 <P>
 <UL>
   <LI>Alex Karasulu
   <LI>Phil Steitz
   <LI>Robb Penoyer
   <LI>Noel Bergman
   <LI>Jeff Machols
   <LI>Henri Yandell
   <LI>Wes McKean<A
   href="http://nagoya.apache.org/wiki/apachewiki.cgi?action=edit&amp;id=McKean">?</A>
   </LI></UL>
 <P>
 <P><STRONG>Section 5 : Apache Sponsoring Individuals</STRONG>
 <P>
 <UL>
   <LI>Nicola Ken Barozzi (Apache Incubator)
   <LI>Noel J. Bergman (Apache James)
   <LI>Henri Yandell (Jakarta Commons Naming)
   <LI>Stephen McConnell<A
   href="http://nagoya.apache.org/wiki/apachewiki.cgi?action=edit&amp;id=McConnell">?</A>
   (Apache Avalon)
   <LI>James Strachan (Apache Geronimo) </LI></UL>
 <P>
 <P><STRONG>Section 6 : Incubation Exit Criteria</STRONG>
 <P>We feel this project should exit the incubator to a TLP using the domain name
 directory.apache.org should the following goals be met:
 <P><EM>Technical Goals:</EM>
 <P>
 <UL>
   <LI>Clean status with Apaches Continuous Integration System
   <LI>Website cross reference to existing Apache literature with respect to
   rules and regulations
   <LI>At a minimum a beta release and/or a series of Release Candidates for a
   directory server and its clients.
   <LI>At least one server that complies with <A
   href="http://www.ietf.org/rfc/rfc2251.txt">[RFC2251]</A> </LI></UL>
 <P><EM>Non-Technical Goals:</EM>
 <P>
 <UL>
   <LI>List presence and monitoring in wider Apache communities
   <LI>Website cross reference to existing Apache literarature with respect to
   rules and regulations
   <LI>Initial integration plan and cooperation with Geronimo, and James
   <LI>Member presence on the licensing@apache list
   <LI>More Apache or non-Apache committers who are actively modifying source
   code </LI></UL>
 <HR>

 <FORM action=apachewiki.cgi method=post><A
 href="http://nagoya.apache.org/wiki/apachewiki.cgi?HomePage">HomePage</A> | <A
 href="http://nagoya.apache.org/wiki/apachewiki.cgi?RecentChanges">RecentChanges</A>
 | <A
 href="http://nagoya.apache.org/wiki/apachewiki.cgi?action=editprefs">Preferences</A><BR><A
 href="http://nagoya.apache.org/wiki/apachewiki.cgi?action=edit&amp;id=ApacheDirectoryProject">Edit
 text of this page</A> | <A
 href="http://nagoya.apache.org/wiki/apachewiki.cgi?action=history&amp;id=ApacheDirectoryProject">View
 other revisions</A><BR>Last edited September 30, 2003 7:59 am <A
 href="http://nagoya.apache.org/wiki/apachewiki.cgi?action=browse&amp;diff=1&amp;id=ApacheDirectoryProject">(diff)</A><BR>Search:
 <INPUT name=search><INPUT type=hidden value=1 name=dosearch>
 </FORM></BODY></HTML>
	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
	<!-- saved from url=(0067)http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheDirectoryProject -->
	<HTML><HEAD><TITLE>Apache Wiki: ApacheDirectoryProject</TITLE>
	<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
	<META content="MSHTML 6.00.2800.1276" name=GENERATOR></HEAD>
	<BODY text=black vLink=purple link=blue bgColor=white>
	<H1><A href="http://nagoya.apache.org/wiki/apachewiki.cgi?HomePage"><IMG
	alt=[Home] src="./images/asf_logo_wide.gif" border=0></A><A
	href="http://nagoya.apache.org/wiki/apachewiki.cgi?search=ApacheDirectoryProject">ApacheDirectoryProject</A></H1><A
	href="http://nagoya.apache.org/wiki/apachewiki.cgi?HomePage">HomePage</A> \| <A
	href="http://nagoya.apache.org/wiki/apachewiki.cgi?RecentChanges">RecentChanges</A>
	\| <A
	href="http://nagoya.apache.org/wiki/apachewiki.cgi?action=editprefs">Preferences</A><BR>
	<HR>

	<H1>Proposal for an Apache Directory Project</H1><EM>10 Sept 2003, Alex Karasulu
	(aok123@bellsouth.net) LDAPd Group Founder</EM>
	<HR>

	<P>
	<P>
	<P><STRONG>Section 0 : Rationale</STRONG>
	<P>The geometric growth of networks, services, distributed systems, and their
	components has brought about a revival of interest in directories. Directories
	are no longer considered commodity products used to store a phone book or list
	of users. Directories and LDAP have grown into a critical technology that will
	inevitably become a cornerstone of distributed systems. Several software giants
	like BEA, SUN, and Microsoft have already demonstrated their belief in this
	outcome by heavily integrating their products with directories. Directory and
	naming systems are being used in everything from a simplified form for J2EE
	configuration to full-blown enterprise directories, within identity management
	systems and distributed computing platforms like JINI.
	<P>
	<P>The overhead of managing several copies of relatively static information
	across systems and enterprises is daunting and introduces the potential for data
	inconsistency. The frequently replicated user and group tables in almost every
	database driven application alone is a testament to this fact. When multiple
	systems have to inter operate, they must share access to common information, and
	directories are the best storage paradigm for rapidly accessing this type of
	data. Whether the information to be stored, is a component's configuration, a
	user's security profile, a business rule or a business process, directories are
	the place to store it for centralized management, and distribution across
	systems.
	<P>To date, a fully compliant pure Java open source LDAPv3 server has not yet
	been written. This is partially due to the fact that a practical stateful
	protocol server in Java was virtually impossible until the introduction of the
	NIO packages in the 1.4 SDK. LDAP, as a stateful protocol, manages client state
	through a TCP socket connection. The socket connection persists through several
	client requests and server responses tying them together under a logical session
	or conversation. Before the introduction of non-blocking IO in the NIO packages
	of the 1.4 SDK, a thread had to be dedicated to each socket to detect IO. A
	stateful protocol server written completely in Java, would have needed as many
	active threads as the number of concurrent clients. Theoretically, scalability
	would have been very poor; the performance curve would be asymptotic, degrading
	rapidly with an increase in the number of concurrent connections. To scale pure
	Java statefull protocol server implementations had to wait until the Merlin
	release of the JDK.
	<P>Furthermore, no embeddable pure Java LDAPv3 server has yet been written and
	made freely available. We believe the embedding of LDAP servers into existing
	mail, application and web servers to be the next logical steps in the
	progression and integration of LDAP. Several commercial examples can already be
	sited: Microsoft Exchange and BEA Weblogic Server. The management benefits of
	coupling these servers with an LDAP server are beyond the scope of this proposal
	and left to the imagination of the reader. However, the synergy between embedded
	LDAP servers and other flagship Apache servers would lead to greater economies
	of scale for the Apache server suite and reduce the overhead of management for
	the Apache software user community.
	<P>LDAP directories are specialized databases, however unlike their RDBMS
	counterparts, LDAP directories are fairly new and for this reason lack rich
	integration features. High on the list of features lacking in LDAP servers are
	stored procedures and triggers. Triggers and Java stored procedures would expand
	the horizon of LDAP in itself even without the benefits of Java. Triggers and
	stored procedures would alleviate ugly workarounds which currently using polling
	and meta directories. These features alone would attract groups within the LDAP
	and Java communities to band together and support the Apache LDAP Project.
	<P>LDAP is both a network line protocol and a hierarchical relational database.
	Some might even argue that LDAP is object oriented. Regardless, the
	implementation of an LDAP server is not a trivial matter. LDAP code bases
	written in native languages have to be ported to run on different platforms.
	Conditional complies in C based implementations were shown to considerably
	reduce the maintainability of code bases. The complexity of a database, a
	network line protocol and conditional compilation together have resulted in
	reduced maintainability for C based LDAP servers. Also the learning curve and
	hence barrier to entry for developers is greater. These complications would not
	exist for a Java based LDAP server that is written once and can run anywhere.
	<P>The Apache Foundation supports several component container projects which
	provide the proper foundation for a Java LDAP directory server. Apache also
	supports several server side application containers which can realize
	significant functional enhancements by employing an LDAP directory server. Also
	LDAP requiring organizations today must settle for less than optimal
	implementations and often have to pay as high as a dollar per entry to directory
	enable their applications. The Apache LDAP Project would solve these problems by
	providing a free robust LDAPv3 implementation in a standalone configuration or
	an embeddable configuration for use in all Apache servers and other third party
	products.
	<P>Our goal is to produce a community of developers with backgrounds in LDAP,
	X.500, Database Engineering and JNDI tasked with the development of pure Java
	LDAPv3 Clients, APIs, JNDI providers and LDAPv3 compliant servers with the
	aforementioned features. The produced software will be ASF licensed. Where
	applicable the best available ASF/BSD licensed code will be reused and new code
	will be added to complete the LDAPv3 protocol as defined in <A
	href="http://www.ietf.org/rfc/rfc3377.txt">[RFC 3377]</A> and its associated 8
	RFCs listed below:
	<P>
	<UL>
	<LI><A href="http://www.ietf.org/rfc/rfc2251.txt">[RFC2251]</A> Lightweight
	Directory Access Protocol (v3): LDAP on-the-wire protocol
	<LI><A href="http://www.ietf.org/rfc/rfc2252.txt">[RFC2252]</A> Lightweight
	Directory Access Protocol (v3): Attribute Syntax Definitions
	<LI><A href="http://www.ietf.org/rfc/rfc2253.txt">[RFC2253]</A> Lightweight
	Directory Access Protocol (v3): UTF-8 String Representation of DNs
	<LI><A href="http://www.ietf.org/rfc/rfc2254.txt">[RFC2254]</A> The String
	Representation of LDAP Search Filters
	<LI><A href="http://www.ietf.org/rfc/rfc2255.txt">[RFC2255]</A> The LDAP URL
	Format
	<LI><A href="http://www.ietf.org/rfc/rfc2256.txt">[RFC2256]</A> A Summary of
	the X.500(96) User Schema for use with LDAPv3
	<LI><A href="http://www.ietf.org/rfc/rfc2829.txt">[RFC2829]</A> Authentication
	Methods for LDAP
	<LI><A href="http://www.ietf.org/rfc/rfc2830.txt">[RFC2830]</A> Lightweight
	Directory Access Protocol (v3): Extension for Transport Layer Security
	</LI></UL>
	<P>Additionally, the schema objects specified within the following RFCs will be
	defined for use and partial or full complaince will be met where relavent to the
	project:
	<P>
	<UL>
	<LI><A href="http://www.ietf.org/rfc/rfc1274.txt">[RFC1274]</A> The COSINE and
	Internet X.500 Schema
	<LI><A href="http://www.faqs.org/rfcs/rfc1804.html">[RFC1804]</A> Schema
	Publishing in X.500 Directory
	<LI><A href="http://www.ietf.org/rfc/rfc2079.txt">[RFC2079]</A> Definition of
	an X.500 Attribute Type and an Object Class to Hold Uniform Resource
	Identifiers (URIs)
	<LI><A href="http://www.ietf.org/rfc/rfc2247.txt">[RFC2247]</A> Using Domains
	in LDAP/X.500 Distinguished Names
	<LI><A href="http://www.ietf.org/rfc/rfc2293.txt">[RFC2293]</A> Representing
	Tables and Subtrees in the X.500 Directory
	<LI><A href="http://www.ietf.org/rfc/rfc2294.txt">[RFC2294]</A> Representing
	the O/R Address hierarchy in the X.500 Directory Information Tree
	<LI><A href="http://www.ietf.org/rfc/rfc2307.txt">[RFC2307]</A> An Approach
	for Using LDAP as a Network Information Service
	<LI><A href="http://www.ietf.org/rfc/rfc2377.txt">[RFC2377]</A> Naming Plan
	for Internet Directory-Enabled Applications
	<LI><A href="http://www.ietf.org/rfc/rfc2587.txt">[RFC2587]</A> Internet X.509
	Public Key Infrastructure LDAPv2 Schema
	<LI><A href="http://www.ietf.org/rfc/rfc2589.txt">[RFC2589]</A> Lightweight
	Directory Access Protocol (v3): Extensions for Dynamic Directory Services
	<LI><A href="http://www.ietf.org/rfc/rfc2596.txt">[RFC2596]</A> Use of
	Language Codes in LDAP
	<LI><A href="http://www.ietf.org/rfc/rfc2649.txt">[RFC2649]</A> An LDAP
	Control and Schema for Holding Operation Signatures
	<LI><A href="http://www.ietf.org/rfc/rfc2696.txt">[RFC2696]</A> LDAP Control
	Extension for Simple Paged Results Manipulation
	<LI><A href="http://www.ietf.org/rfc/rfc2713.txt">[RFC2713]</A> Schema for
	Representing Java(tm) Objects in an LDAP Directory
	<LI><A href="http://www.ietf.org/rfc/rfc2714.txt">[RFC2714]</A> Schema for
	Representing CORBA Object References in an LDAP Directory
	<LI><A href="http://www.ietf.org/rfc/rfc2798.txt">[RFC2798]</A> Definition of
	the inetOrgPerson<A
	href="http://nagoya.apache.org/wiki/apachewiki.cgi?action=edit&id=OrgPerson">?</A>
	LDAP Object Class
	<LI><A href="http://www.ietf.org/rfc/rfc2829.txt">[RFC2829]</A> Authentication
	Methods for LDAP
	<LI><A href="http://www.ietf.org/rfc/rfc2830.txt">[RFC2830]</A> Lightweight
	Directory Access Protocol (v3): Extension for Transport Layer Security
	<LI><A href="http://www.ietf.org/rfc/rfc2849.txt">[RFC2849]</A> The LDAP Data
	Interchange Format (LDIF) - Technical Specification
	<LI><A href="http://www.ietf.org/rfc/rfc2891.txt">[RFC2891]</A> LDAP Control
	Extension for Server Side Sorting of Search Results
	<LI><A href="http://www.ietf.org/rfc/rfc3045.txt">[RFC3045]</A> Storing Vendor
	Information in the LDAP root DSE
	<LI><A href="http://www.ietf.org/rfc/rfc3062.txt">[RFC3062]</A> LDAP Password
	Modify Extended Operation
	<LI><A href="http://www.ietf.org/rfc/rfc3088.txt">[RFC3088]</A> OpenLDAP<A
	href="http://nagoya.apache.org/wiki/apachewiki.cgi?action=edit&id=OpenLDAP">?</A>
	Root Service An experimental LDAP referral service
	<LI><A href="http://www.ietf.org/rfc/rfc3112.txt">[RFC3112]</A> LDAP
	Authentication Password Schema
	<LI><A href="http://www.ietf.org/rfc/rfc3296.txt">[RFC3296]</A> Named
	Subordinate References in Lightweight Directory Access Protocol (LDAP)
	Directories
	<LI><A href="http://www.ietf.org/rfc/rfc3383.txt">[RFC3383]</A> Internet
	Assigned Numbers Authority (IANA) considerations for the Lightweight Directory
	Access Protocol (LDAP) </LI></UL>
	<P>
	<P><STRONG>Section 0.1 : Criteria</STRONG>
	<P>We feel that this project has a good chance for success as the following
	project aspects are carefully considered :
	<P><EM>Meritocracy:</EM> The project will be meritocratic - the usual Apache
	meritocracy rules would apply.
	<P><EM>Community:</EM> The user community for this project is potentially
	massive. The initial developer community for this project consists of developers
	from Apache and LDAPd projects. The aim is for this community to grow
	considerably once this project enters the incubator.
	<P><EM>Core Developers:</EM> The initial developers are listed further below
	within this document and consist of some existing Apache committers together
	with committers from the LDAPd Group.
	<P><EM>Alignment:</EM> There is clear alignment with many existing Apache
	projects. From Jakarta projects such as Tomcat, James and Slide for embedding
	LDAP. The LDAP DSML standards will eventually require the use of several XML
	projects. Other projects like OpenJms<A
	href="http://nagoya.apache.org/wiki/apachewiki.cgi?action=edit&id=OpenJms">?</A>,
	which currently are not Apache projects but very well may be in the future will
	be used for things like replication. Jdbm likewise is used for building Btree
	based indices for custom databases. Also projects like Apache Xindice may be
	leveraged for an XML based backend or for DSML enabling subsystems of an LDAP
	server.
	<P>We see the Apache Directory Project as a separate project to existing Apache
	projects, serving several roles
	<UL>
	<LI>Home for Apache Directory Client APIs and Client Scripts
	<LI>Home for Apache JNDI Providers for Various Directory Namespaces
	<LI>Home for Apache Directory Servers
	<LI>May also become home to an ASN.1 Encoding/Decoding<A
	href="http://nagoya.apache.org/wiki/apachewiki.cgi?action=edit&id=ApacheDirectoryProject/Decoding">?</A>
	Library </LI></UL>
	<P>
	<P><STRONG>Section 0.2 : Warning Signs</STRONG>
	<P>We feel this project has a good chance for success as the following warning
	signs do not apply to the project we are proposing:
	<P><EM>Orphaned products:</EM> This project is starting with an existing code
	base which using lots of the high quality open source code out there which is
	ASF/BSD licensed.
	<P><EM>Inexperience with open source:</EM> The initial community is made up of
	existing Apache and LDAPd Group committers exclusively so the open source
	experience is there to varying degrees.
	<P><EM>Reliance on salaried developers:</EM> None of the initial developers are
	currently paid to work on the Directory Project.
	<P><EM>No ties to other Apache products:</EM> The Apache Directory Project is
	complementary to existing technologies at Apache. LDAPd currently uses Avalon
	and will eventually be used by james. LDAPd will eventually integrate into
	Geronimo. The Apache Directory Project will integrate with, and possibly
	subsume, Jakarta Commons Naming.
	<P><EM>A fascination with the Apache brand:</EM> The committers are interested
	in developing a healthy open source community around ASF/BSD licensed directory
	servers and their clients along with other JNDI accessible name spaces. Is
	Apache the right place? We think it is. Several Apache folks have already shown
	interest in LDAPd, the seed code base to be used for this project. In fact the
	LDAPd Group was initially approached by Apache to submit an Incubator proposal.
	LDAPd Group members voted unanimously to donate the code to Apache in an effort
	to build the next flagship server at Apache and much more.
	<P>
	<P><STRONG>Section 1 : Scope of the Project</STRONG>
	<P>There are multiple goals for this Apache project:
	<P>
	<UL>
	<LI>Promote a healthy open source community!
	<LI>Promote a language agnostic environment for both client side and server
	side endeavors.
	<LI>A one stop location for all directory and naming needs on any platform or
	any language.
	<UL>
	<LI>client APIs
	<LI>clients
	<LI>JNDI providers for Java and other namespaces.
	<LI>May also include an LDAP protocol correctness and stress testing suite
	in the future. </LI></UL>
	<LI>Provide servers in embeddable configurations.
	<LI>Provide servers in standalone configurations as UNIX daemons or NT
	Services.
	<LI>Provide support for Directory Server embedding or integration with
	existing Apache servers like httpd, Slide, Tomcat, James and Geronimo.
	</LI></UL>
	<P>
	<P><STRONG>Section 2 : Initial Source</STRONG>
	<P>The initial code base from which to create the Apache Directory repository is
	contained mostly at Sourceforge under the LDAPd project accessible <A
	href="http://sourceforge.net/projects/ldapd">[here]</A>. This code base must
	assign copyright to the Apache Software Foundation. The code base will need to
	be licensed under The Apache Software Foundation license. The license file in
	every subproject will be changed to the Apache license. The current license is
	already an Apache "style" license, so this change is basically a change to name
	The ASF as the owner.
	<P>The proposed TLP (after incubation) would have an one or more directory
	servers with multiple datastore backends, a JNDI context for J2EE configuration,
	JNDI service provider(s) for LDAP and other transports, State and Object
	Factories suitable for use in the various Context/DirContext<A
	href="http://nagoya.apache.org/wiki/apachewiki.cgi?action=edit&id=ApacheDirectoryProject/DirContext">?</A>
	implementations, etc.
	<P>Beside source code the LDAPd Group must transfer its IANA assigned ASN.1
	Object Identifier to Apache Software Foundation.
	<P><STRONG>Section 3 : ASF Resources to be Created</STRONG>
	<P><EM>Section 3.1 : Mailing Lists</EM>
	<P>
	<UL>
	<LI>directory-dev@incubator.apache.org </LI></UL>
	<P><EM>Section 3.2 : CVS Repositories</EM>
	<P>
	<UL>
	<LI>incubator-directory </LI></UL>
	<P><EM>Section 3.3 : Bugzilla or (preferably) Jira</EM>
	<P>
	<UL>
	<LI>directory </LI></UL>
	<P>
	<P><STRONG>Section 4 : Initial Set of Committers</STRONG>
	<P>All contributors must sign and submit a Contributors License Agreement. The
	following individuals are the contributors, and have signed and sent the
	agreement at one time or another:
	<P>
	<UL>
	<LI>Alex Karasulu
	<LI>Phil Steitz
	<LI>Robb Penoyer
	<LI>Noel Bergman
	<LI>Jeff Machols
	<LI>Henri Yandell
	<LI>Wes McKean<A
	href="http://nagoya.apache.org/wiki/apachewiki.cgi?action=edit&id=McKean">?</A>
	</LI></UL>
	<P>
	<P><STRONG>Section 5 : Apache Sponsoring Individuals</STRONG>
	<P>
	<UL>
	<LI>Nicola Ken Barozzi (Apache Incubator)
	<LI>Noel J. Bergman (Apache James)
	<LI>Henri Yandell (Jakarta Commons Naming)
	<LI>Stephen McConnell<A
	href="http://nagoya.apache.org/wiki/apachewiki.cgi?action=edit&id=McConnell">?</A>
	(Apache Avalon)
	<LI>James Strachan (Apache Geronimo) </LI></UL>
	<P>
	<P><STRONG>Section 6 : Incubation Exit Criteria</STRONG>
	<P>We feel this project should exit the incubator to a TLP using the domain name
	directory.apache.org should the following goals be met:
	<P><EM>Technical Goals:</EM>
	<P>
	<UL>
	<LI>Clean status with Apaches Continuous Integration System
	<LI>Website cross reference to existing Apache literature with respect to
	rules and regulations
	<LI>At a minimum a beta release and/or a series of Release Candidates for a
	directory server and its clients.
	<LI>At least one server that complies with <A
	href="http://www.ietf.org/rfc/rfc2251.txt">[RFC2251]</A> </LI></UL>
	<P><EM>Non-Technical Goals:</EM>
	<P>
	<UL>
	<LI>List presence and monitoring in wider Apache communities
	<LI>Website cross reference to existing Apache literarature with respect to
	rules and regulations
	<LI>Initial integration plan and cooperation with Geronimo, and James
	<LI>Member presence on the licensing@apache list
	<LI>More Apache or non-Apache committers who are actively modifying source
	code </LI></UL>
	<HR>

	<FORM action=apachewiki.cgi method=post><A
	href="http://nagoya.apache.org/wiki/apachewiki.cgi?HomePage">HomePage</A> \| <A
	href="http://nagoya.apache.org/wiki/apachewiki.cgi?RecentChanges">RecentChanges</A>
	\| <A
	href="http://nagoya.apache.org/wiki/apachewiki.cgi?action=editprefs">Preferences</A><BR><A
	href="http://nagoya.apache.org/wiki/apachewiki.cgi?action=edit&id=ApacheDirectoryProject">Edit
	text of this page</A> \| <A
	href="http://nagoya.apache.org/wiki/apachewiki.cgi?action=history&id=ApacheDirectoryProject">View
	other revisions</A><BR>Last edited September 30, 2003 7:59 am <A
	href="http://nagoya.apache.org/wiki/apachewiki.cgi?action=browse&diff=1&id=ApacheDirectoryProject">(diff)</A><BR>Search:
	<INPUT name=search><INPUT type=hidden value=1 name=dosearch>
	</FORM></BODY></HTML>