You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@directory.apache.org by fe...@apache.org on 2010/08/13 23:04:28 UTC
svn commit: r985366 [2/3] - in
/directory/sandbox/felixk/apacheds-docs/src/advanced-user-guide: ./ images/
Added: directory/sandbox/felixk/apacheds-docs/src/advanced-user-guide/chapter-architecture.xml
URL: http://svn.apache.org/viewvc/directory/sandbox/felixk/apacheds-docs/src/advanced-user-guide/chapter-architecture.xml?rev=985366&view=auto
==============================================================================
--- directory/sandbox/felixk/apacheds-docs/src/advanced-user-guide/chapter-architecture.xml (added)
+++ directory/sandbox/felixk/apacheds-docs/src/advanced-user-guide/chapter-architecture.xml Fri Aug 13 21:04:27 2010
@@ -0,0 +1,2294 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under
+ the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may
+ obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to
+ in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF
+ ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under
+ the License. -->
+<chapter
+ version="5.0"
+ xmlns="http://docbook.org/ns/docbook"
+ xmlns:xlink="http://www.w3.org/1999/xlink"
+ xmlns:xi="http://www.w3.org/2001/XInclude"
+ xmlns:ns5="http://www.w3.org/2000/svg"
+ xmlns:ns4="http://www.w3.org/1998/Math/MathML"
+ xmlns:ns3="http://www.w3.org/1999/xhtml"
+ xml:lang="en">
+ <title>Architecture</title>
+ <itemizedlist>
+ <listitem>
+ <xref
+ linkend="Architectural Overview" />
+ </listitem>
+ <listitem>
+ <xref
+ linkend="Interceptors" />
+ </listitem>
+ <listitem>
+ <xref
+ linkend="The Administrative Model" />
+ </listitem>
+ <listitem>
+ <xref
+ linkend="Supported RFCs" />
+ </listitem>
+ </itemizedlist>
+ <section
+ id="Architectural Overview">
+ <title>Architectural Overview</title>
+ <section
+ id="Partitions">
+ <title>Partitions</title>
+ <para>
+ A partition is a physically distinct store for a subset of the entries contained within a DSA (Directory
+ Server/Service Agent A.K.A the LDAP server). The entries of a partition all share the same suffix which is the
+ distinguished name of the namingContext from which the stored entries in the partition are hung from the DIT. A
+ partition can be implemented using any storage mechanism or can even be backed in memory. The default storage
+ mechanism for a partition is JDBM. The addition of such a partition is described in the
+ <link
+ xlink:href="http://directory.apache.org/apacheds/1.5/apacheds-v15-basic-users-guide.html">Basic User's Guide</link>
+ . A
+ partition with a different storage mechanism simply has to implement the Partition interface and by doing so
+ can
+ be mounted in the server at it's suffix/namingContext (described
+ <link
+ xlink:href="http://cwiki.apache.org/confluence/pages/createpage.action?spaceKey=DIRxSRVx11&title=6.1.%20Implementing%20an%20alternative%20Backend&linkCreation=true&fromPageId=55216">here</link>
+ ).
+ </para>
+ <para>The server can have any number of partitions (with any implementation) attached to various namingContexts
+ which are published by the RootDSE (empty string dn "") using the namingContexts operational attribute. So if
+ you want to see the partitions served by the server you can query the RootDSE for this information. </para>
+ </section>
+ </section>
+ <section
+ id="Interceptors">
+ <title>Interceptors</title>
+ <section
+ id="What is it?">
+ <title>What is it?</title>
+ <para>The mechanism is a means for injecting and isolating orthogonal services into calls against the nexus. The
+ nexus is the hub used to route calls to partitions to perform CRUD operations upon entries. By injecting these
+ services at this level, partition implementators need not duplicate fuctionality. Services such as
+ authentication, authorization, schema checking, normalization, operational attribute maintenance and more are
+ introduced using Interceptors. By using interceptors, partition implementors need not be concerned with these
+ aspects and can focus on raw CRUD operations against their backing stores what ever they may be.</para>
+ </section>
+ <section
+ id="How does it work?">
+ <title>How does it work?</title>
+ <para>Before we talk more about interceptors we must quickly cover the JNDI provider implementation since it is
+ somewhat related.</para>
+ </section>
+ <section
+ id="JNDI Implementation">
+ <title>JNDI Implementation</title>
+ <para>
+ The JNDI implementation is composed of a set of JNDI Context implementations, a ContextFactory implementation
+ and a set of helper classes.
+ <itemizedlist>
+ <listitem>
+ <para>DeadContext</para>
+ </listitem>
+ <listitem>
+ <para>JavaLdapSupport</para>
+ </listitem>
+ <listitem>
+ <para>ServerContext</para>
+ </listitem>
+ <listitem>
+ <para>ServerDirContext</para>
+ </listitem>
+ <listitem>
+ <para>ServerLdapContext</para>
+ </listitem>
+ <listitem>
+ <para>AbstractContextFactory</para>
+ </listitem>
+ <listitem>
+ <para>CoreContextFactory</para>
+ </listitem>
+ <listitem>
+ <para>ServerDirObjectFactory</para>
+ </listitem>
+ <listitem>
+ <para>ServerDirStateFactory</para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ <para>
+ Every JNDI Context implementation in the provider holds a dedicated reference to a
+ <emphasis
+ role="bold">nexus proxy</emphasis>
+ object. This
+ proxy contains all the operations that the
+ <emphasis
+ role="bold">nexus contains</emphasis>
+ . The proxy object is at the heart of the
+ mechanism. We
+ will disuss it more after covering the rest of the JNDI
+ provider.
+ </para>
+ <para>Calls made against JNDI Contexts take relative names as arguments. These names are relative to the
+ distinguished name of the JNDI Context. Within the Context implementations these relative names are transformed
+ into absolute distinguished names. The transformed names are used to make calls against the proxy.</para>
+ <para>Additional processing may occur before or after a call is made by a context on its proxy to manage JNDI
+ provider specific functions. One such example is the handling of Java objects for serialization and the use of
+ object and state factories.</para>
+ </section>
+ <section
+ id="The nexus proxy object">
+ <title>The nexus proxy object</title>
+ <para>As mentioned above, each Context that is created has a nexus proxy. The proxy maintains a handle on the
+ context as well.</para>
+ <table
+ id="Nexus Proxy Object table">
+ <title>Nexus Proxy Object</title>
+ <tgroup
+ cols="2">
+ <tbody>
+ <row>
+ <entry>
+ <para>The primary job of the proxy is to inject Interceptor based services. It does so by invoking a
+ chain of Interceptors managed by the system. Interceptors mirror the methods that are intercepted on
+ the nexus interface. When an intercepted method is invoked on the proxy, the proxy pushes an
+ Invocation object on to the InvocationStack associated with the current executing Thread. The proxy
+ then calls the same method on a chain of Interceptors. The results of the call are returned after the
+ InvocationStack is popped.</para>
+ <para>The InvocationStack is used to track the calls being intercepted. Invocation objects pushed onto
+ the stack track the context making the call to the proxy, the name of the intercepted call and its
+ arguments. A stack is used because in the case of Triggers, stored procedures may be invoked which
+ operate against the DIT using JNDI. These JNDI calls will also be intercepted. Their Invocation object
+ will be stacked on top of the Invocation which raised the Trigger. This way identities and context of
+ operations can be tracked and used by the Trigger management system to prevent runnaway cascades or to
+ limit the cascade depth. There are other areas besides just triggers where this stack will serve a
+ purpose.</para>
+ <para>The InterceptorChain is a container of Interceptors which has the same or analogous methods as do
+ Interceptors. These are for the interceptable methods. A call against the chain invokes the first
+ Interceptor which then usually invokes the next interceptor in the chain. An Interceptor need not call
+ the next interceptor however. It can raise an exception before making the call to the next interceptor
+ or it can completely bypass the rest of the chain by just returning before calling the next
+ Interceptor. Interceptors can preprocess the arguments, or perform other tasks before they invoke the
+ next Interceptor. They can also catch exceptions raised by other downstream interceptors and respond
+ to them to handle errors. Finally they can perform post processing operations on the results of
+ returned values from downstream Interceptors.</para>
+ <para>One might ask when is the call made against the actual nexus. This happens using a special
+ Interceptor which resides at the end of the chain. It actually makes the call against the nexus and
+ returns the results.</para>
+ <warning>
+ <para>Interceptors can be seen as Servlet Filters : they can be added, removed, bypassed either by
+ configuration or, for embeded servers, on the fly.</para>
+ </warning>
+ </entry>
+ <entry>
+ <para>The following picture describe the Interceptors mechanisms :</para>
+ <figure
+ id="Interceptors figure">
+ <title>Interceptors</title>
+ <mediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/Interceptors.png" />
+ </imageobject>
+ </mediaobject>
+ </figure>
+ </entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+ </section>
+ <section
+ id="Operation handling within interceptors">
+ <title>Operation handling within interceptors</title>
+ <para>Each operation is associated with a method in each interceptors, even if it does nothing else than calling
+ the next interceptor.</para>
+ <para>The base idea is to allow pre and post actions to be executed before and after the call of the next
+ interceptors :</para>
+ <figure
+ id="Interceptor chaining">
+ <title>Interceptor chaining</title>
+ <mediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/Interceptorschaining.png" />
+ </imageobject>
+ </mediaobject>
+ </figure>
+ <para>
+ Each interceptor process the
+ <emphasis
+ role="bold">pre</emphasis>
+ action, call the next interceptor, wait for the response, execute the
+ <emphasis
+ role="bold">post</emphasis>
+ action, and returns. We have to
+ implement this chain of interceptors in a way which allows us to add new
+ interceptors, or new
+ <emphasis
+ role="bold">pre</emphasis>
+ or
+ <emphasis
+ role="bold">post</emphasis>
+ actions, without having to modify the existing code or mechanism.
+ </para>
+ </section>
+ <section
+ id="Bind Operation">
+ <title>Bind Operation</title>
+ <para>
+ The
+ <emphasis
+ role="bold">Bind</emphasis>
+ operation call the interceptor chain in the
+ <emphasis
+ role="bold">PartitionNexusProxy</emphasis>
+ class, where we can found a
+ <emphasis
+ role="bold">bind</emphasis>
+ method :
+ </para>
+ <programlisting><![CDATA[
+public void bind( LdapDN bindDn, byte[] credentials, List mechanisms, String saslAuthId,
+ Collection bypass ) throws NamingException
+ { ...
+ this.configuration.getInterceptorChain().bind( bindDn, credentials, mechanisms, saslAuthId );
+ ...
+ }
+ ]]></programlisting>
+ <para>
+ this will call the first configured interceptor from a chain which is declared in the configuration file
+ <emphasis
+ role="bold">server.xml</emphasis>
+ . The first interceptor is the
+ <emphasis
+ role="bold">NormalizationService</emphasis>
+ .
+ </para>
+ <para>The information which are passed are :</para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ The
+ <emphasis
+ role="bold">DN</emphasis>
+ used to bind
+ </para>
+ </listitem>
+ <listitem>
+ <para>The password (credentials)</para>
+ </listitem>
+ <listitem>
+ <para>The list of supported mechanisms</para>
+ </listitem>
+ <listitem>
+ <para>The SASL authent</para>
+ </listitem>
+ </itemizedlist>
+ <para>We will often use only the two first elements.</para>
+ </section>
+ <section
+ id="Normalization interceptor">
+ <title>Normalization interceptor</title>
+ <para>
+ This interceptor will just normalize the
+ <emphasis
+ role="bold">DN</emphasis>
+ used to bind. If the
+ <emphasis
+ role="bold">DN</emphasis>
+ is invalid, an exception will be thrown.
+ </para>
+ <para>It is the first interceptor in the chain because as we will manupulate the DN through all interceptors, it
+ is important that we normalize it as soon as possible.</para>
+ <para>
+ The normalized
+ <emphasis
+ role="bold">DN</emphasis>
+ will be stored in an special form, usefull for internal comparizons. This operation can be
+ costly, but as the
+ <emphasis
+ role="bold">DN</emphasis>
+ has already been parsed, this is quite efficient.
+ </para>
+ <para>We can call the next interceptor :</para>
+ </section>
+ <section
+ id="Authentication interceptor">
+ <title>Authentication interceptor</title>
+ <para>
+ We must check that this bind request is valid, that is the
+ <emphasis
+ role="bold">DN</emphasis>
+ and the associated password are known by the
+ server. We have two cases :
+ </para>
+ <orderedlist>
+ <listitem>
+ <para>The user have already been authenticated</para>
+ </listitem>
+ <listitem>
+ <para>This is the first time this user try to bind</para>
+ </listitem>
+ </orderedlist>
+ <para>
+ What we call
+ <emphasis>user</emphasis>
+ is the
+ <emphasis
+ role="bold">DN</emphasis>
+ of a known entry stored in the server.
+ </para>
+ <para>
+ In the first case, we will have to search the password in the backend, and this will be a
+ <emphasis
+ role="bold">lookup</emphasis>
+ operation, which will be applied through another chain of interceptors.
+ </para>
+ <para>
+ Let's assume we are in the second case, because if we are in the first case, we will have to ask the backend
+ about the entry which
+ <emphasis
+ role="bold">DN</emphasis>
+ is equal to the one we received, to get its associated password, thus callaing a
+ specific chain of interceptors (
+ <emphasis
+ role="bold">FINAL_INTERCEPTOR</emphasis>
+ ).
+ </para>
+ <para>
+ The password is compared using the given mechanism (which should be
+ <emphasis
+ role="bold">simple</emphasis>
+ on a new server), and if it
+ matches, we create a
+ <emphasis>principal</emphasis>
+ object which will be stored in the connection context for future usage.
+ </para>
+ <para>
+ We are done with the
+ <emphasis
+ role="bold">bind</emphasis>
+ operation.
+ </para>
+ </section>
+ <section
+ id="Add operation">
+ <title>Add operation</title>
+ <para>
+ An
+ <emphasis
+ role="bold">add</emphasis>
+ operation is more complex. What we need to do is to check if the current user has enough right to add
+ an entry,
+ and that the entry can be added.
+ </para>
+ <para>A new entry is a composition of three elements :</para>
+ <itemizedlist>
+ <listitem>
+ <para>A partition name</para>
+ </listitem>
+ <listitem>
+ <para>A path from this partition</para>
+ </listitem>
+ <listitem>
+ <para>An entry name</para>
+ </listitem>
+ </itemizedlist>
+ <para>
+ For instance, when adding an entry which
+ <emphasis
+ role="bold">DN</emphasis>
+ is cn=acme, ou=users, ou=system , we will have :
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Partition =
+ <emphasis>""ou=system"</emphasis>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Path =
+ <emphasis>"ou=users, ou=system"</emphasis>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Entry name =
+ <emphasis>"cn=acme"</emphasis>
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>The two first elements must exist in the base. We can't add an entry in an not existing partition, and we
+ can't add an entry which path is not existing.</para>
+ </section>
+ </section>
+ <section
+ id="The Administrative Model">
+ <title>The Administrative Model</title>
+ <section
+ id="Introduction model">
+ <title>Introduction</title>
+ <para>
+ Subentries are used for managing the administration of different aspects of the directory. LDAP has just
+ recently formalized the notion of subentires in
+ <link
+ xlink:href="http://www.faqs.org/rfcs/rfc3672.html">RFC 3672</link>
+ . Subentries have existed within X.500 Directories for
+ years with clear specifications for administering
+ collective attributes, schema, and access controls. With the
+ exception of managing collective attributes LDAP has
+ no equivalent
+ <emphasis
+ role="bold">yet</emphasis>
+ for administering these aspects. However
+ with RFC 3672, LDAP is on its way towards adopting and adapting these
+ mechanisms from X.500 Directories. It is
+ only a matter of time.
+ </para>
+ <para>For this reason we intend to remain ahead of the curve by implementing these aspects of administration using
+ Subentries and Administrative Areas similar to X.500 Directories.</para>
+ </section>
+ <section
+ id="What exactly are subentries?">
+ <title>What exactly are subentries?</title>
+ <para>To explain this properly we're going to need to discuss a couple other things like administrative areas (AA)
+ and administrative points (AP) within the directory. However for the impatient here's a quick attempt to
+ describe what subentries are:</para>
+ <para>Subentries are hidden leaf entries (which cannot have children). These entries immediately subordinate to an
+ administrative point (AP) within the directory. They are used to specify administrative information for a part
+ of the Directory Information Tree (DIT). Subentries can contain administrative information for aspects of access
+ control, schema administration, and collective attributes (and others which have not been defined in any
+ specification yet).</para>
+ </section>
+ <section
+ id="Administrative Areas, Entries and Points">
+ <title>Administrative Areas, Entries and Points</title>
+ <para>First some definitions as provided by X.501:</para>
+ <itemizedlist>
+ <listitem>
+ <para>11.1.1 administrative area: A subtree of the DIT considered from the perspective of administration.
+ </para>
+ </listitem>
+ <listitem>
+ <para>11.1.2 administrative entry: An entry located at an administrative point.</para>
+ </listitem>
+ <listitem>
+ <para>11.1.3 administrative point: The root vertex of an administrative area.</para>
+ </listitem>
+ <listitem>
+ <para>11.1.5 autonomous administrative area: A subtree of the DIT whose entries are all administered by the
+ same Administrative Authority. Autonomous administrative areas are non-overlapping.</para>
+ </listitem>
+ <listitem>
+ <para>11.1.11 inner administrative area: A specific administrative area whose scope is wholly contained within
+ the scope of another specific administrative area of the same type.</para>
+ </listitem>
+ <listitem>
+ <para>11.1.17 specific administrative area: A subset (in the form of a subtree) of an autonomous
+ administrative area defined for a particular aspect of administration: access control, subschema or entry
+ collection administration. When defined, specific administrative areas of a particular kind partition an
+ autonomous administrative area.</para>
+ </listitem>
+ <listitem>
+ <para>11.1.18 specific administrative point: The root vertex of a specific administrative area.</para>
+ </listitem>
+ </itemizedlist>
+ <para>Now take a step back because the above definitions are, well, from a sleep inducing spec. Let's just talk
+ about some situations.</para>
+ <para>Presume you're the uber directory administrator over at WallyWorld (a Walmart competitor). Let's say
+ WallyWorld uses their corporate directory for various things including their product catalog. As the uber admin
+ you're going to have a bunch of people wanting access, update and even administer your directory. Entire
+ departments within WallyWorld are going to want to control different parts of the directory. Sales may want to
+ manage the product catalog, while operations may want to manage information in other areas dealing with
+ suppliers and store locations. Whatever the domain some department will need to manage the information as the
+ authority.</para>
+ <para>Each department will probably designate different people to manage different aspects of their domain. You're
+ not going to want to deal with their little fiefdoms instead you can delegate the administration of access
+ control policy to a departmental contact. You will want to empower your users and administrative contacts in
+ these departments so they can do part of the job for you. Plus it's much better than having to communicate with
+ everyone in the company to meet their needs. This is where the delegation of authority comes into the picture.
+ </para>
+ <para>Usually administrators do this already to an extent without defining administrative areas. Giving users the
+ ability to change their own passwords for example is a form of delegation. This is generally a good idea because
+ you don't want to set passwords for people. First because you don't want to see the password and secondly
+ because of the management nightmare you'd have to deal with. Expand this idea out a little further and think
+ about delegating administration not of users on their passwords but of entire subtrees in the directory to
+ administrative contacts in various departments.</para>
+ <para>Do you really want to manage the corporate product catalog or just let the sales department manage it? But
+ what do we mean by manage? You want sales people to create, and delete entries but they may only trust a few
+ people to do this. Others may just view the catelog. Who are the people with add/remove powers and why should
+ you have to be involved with deciding this ever changing departmental policy? Instead you can delegate the
+ management of access controls in this area to a administrative contact in the sales department. The sales
+ contact can then administer access controls for their department. They're closer to the people in sales than you
+ are and they probably have more bandwidth to handle sales related needs than you do. Delegating authority in
+ this fashion is what X.500 engineers pioneered in the early 80's with the telecom boom in Europe. They knew
+ different authorities will want to manage different aspects of directory administration for themselves. These
+ X.500 definitions are there to be able to talk about administrative areas within the directory. Now let's get
+ back to what these things are exactly.</para>
+ <para>
+ An administrative area is some part of the directory tree that is arbitrarily defined. The tree can be split
+ into different administrative areas to delegate authority for managing various aspects of administration. For
+ example you can have a partition hanging off of
+ <emphasis
+ role="bold">'dc=example,dc=com'</emphasis>
+ with an
+ <emphasis
+ role="bold">'ou=product catalog'</emphasis>
+ area. You may
+ want this area to be managed by the sales department with respect to the content, schema, it's
+ visibility, and
+ collective attributes. Perhaps you only want to delegate only one aspect of administration ,
+ access control,
+ since you don't want people messing around with schema. To do so you can define everything under
+ <emphasis
+ role="bold">'ou=product
+ catalog'</emphasis>
+ to be an administrative area specifically for access control and delegate that aspect only.
+ In that
+ case the
+ entry,
+ <emphasis
+ role="bold">'ou=product catalog,dc=example,dc=com'</emphasis>
+ becomes an administrative entry. It is also the
+ administrative point for the area which is the tree rooted at
+ this entry.
+ </para>
+ <para>
+ Not all administrative areas are equal. There are really two kinds :
+ <emphasis
+ role="bold">autonomous</emphasis>
+ and
+ <emphasis
+ role="bold">inner</emphasis>
+ areas. Autonomous
+ areas are areas of administration that cannot overlap. Meaning someone is assigned as the
+ supreme authority for
+ that subtree. Inner areas are, as their name suggests, nested administrative areas within
+ autonomous areas and
+ other inner areas. Yes, you can nest these inner areas as deep as you like. You may be
+ asking yourself what the
+ point to all this is. Well, say you're the supreme admin of admins. You delegate the
+ authority to manage access
+ control for the corporate catalog to the sales admin. That admin may in turn decide to
+ delegate yet another area
+ of the catalog to another contact within a different department. You delegate access
+ control management to the
+ sales admin over the product catalog. The sales admin realizes that the job is way
+ bigger than he can manage so
+ he delegates administration of subtrees in the catalog to various contacts in
+ different departments. For example
+ regions of the catalog under
+ <emphasis
+ role="bold">'ou=electronics'</emphasis>
+ and
+ <emphasis
+ role="bold">'ou=produce'</emphasis>
+ may be delegated to different contacts in their
+ respective departments. However the sales admin still reserves
+ the ability to override access controls in the
+ catalog. The sales admin can change who manages access controls
+ for different parts of the catalog. This chain
+ of delegation is possible using inner administrative areas.
+ </para>
+ </section>
+ <section
+ id="How are administrative areas defined?">
+ <title>How are administrative areas defined?</title>
+ <para>Usually an entry is selected as the administrative point and marked with an operational attribute. The
+ attributeType of the operational attribute is 'administrativeRole'. This attribute can have the following
+ values:</para>
+ <table
+ id="Administrative areas table">
+ <title>Administrative areas</title>
+ <tgroup
+ cols="2">
+ <thead>
+ <row>
+ <entry>OID</entry>
+ <entry>NAME</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>2.5.23.1</entry>
+ <entry>autonomousArea</entry>
+ </row>
+ <row>
+ <entry>2.5.23.2</entry>
+ <entry>accessControlSpecificArea</entry>
+ </row>
+ <row>
+ <entry>2.5.23.3</entry>
+ <entry>accessControlInnerArea</entry>
+ </row>
+ <row>
+ <entry>2.5.23.4</entry>
+ <entry>subschemaAdminSpecificArea</entry>
+ </row>
+ <row>
+ <entry>2.5.23.5</entry>
+ <entry>collectiveAttributeSpecificArea</entry>
+ </row>
+ <row>
+ <entry>2.5.23.6</entry>
+ <entry>collectiveAttributeInnerArea</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+ <para>
+ As you can see, 3 aspects,
+ <emphasis
+ role="bold">schema</emphasis>
+ ,
+ <emphasis
+ role="bold">collective attributes</emphasis>
+ , and
+ <emphasis
+ role="bold">access control</emphasis>
+ are considered. An autonomous
+ administrative area can hence be considered with respect to all three specific
+ aspect of administration. If an
+ AP is marked as an autonomousArea it generally means that administration of all
+ aspects are allowed by the
+ authority. If marked with a specific aspect then only that aspect of administration is
+ delegated. The
+ administrativeRole operational attribute is multivalued so the uber admin can delegate any number
+ of specific
+ administration aspects as he likes.
+ </para>
+ <para>Also notice that two aspects, collective attribute and access controls, allow administrative points to be
+ inner areas. Delegated authorities for these two aspects can create inner administrative areas to further
+ delegate their administrative powers. The schema aspect unlike the others cannot have inner areas because of
+ potential conflicts this may cause which would lead to data integrity issues. For this reason only the authority
+ of an automomous area can manage schema for the entire subtree.</para>
+ <para>An autonomous administrative area (AAA) includes the AP and spans all descendants below the AP down to the
+ leaf entries of the subtree with one exception. If another AAA, let's call it AAA' (prime) is present and rooted
+ below the first AAA then the first AAA does not include the entries of AAA'. Translation: an AAA spans down
+ until other AAAs or leaf entries are encountered within the subtree. This is due to the fact that AAAs do not
+ overlap as do inner AAs (IAA).</para>
+ </section>
+ <section
+ id="Subentries under an IAA or an AAA">
+ <title>Subentries under an IAA or an AAA</title>
+ <para>
+ Subentries hold administrative information for an IAA or an AAA. These entries are of the objectClass
+ 'subentry'. The subentry must contain two attributes: a
+ <emphasis
+ role="bold">commonName</emphasis>
+ and a
+ <emphasis
+ role="bold">subtreeSpecification</emphasis>
+ . The commonName
+ (or cn) is used as the subentry's rdn attribute. The subtreeSpecification describes the
+ collection of entries
+ within the AA (IAA or AAA) that the administrative instruction applies to.
+ </para>
+ <para>A subtree specification uses various parameters described below to define the set of entries. Note that
+ entries need not exist for them to be included in the collection on addition.</para>
+ </section>
+ <section
+ id="Base parameter">
+ <title>Base parameter</title>
+ <para>
+ This is the relative name of the root vertex of the subtree relative to the AP. So if the AP is
+ <emphasis
+ role="bold">'ou=system'</emphasis>
+ and the base is
+ <emphasis
+ role="bold">'ou=users'</emphasis>
+ , the subtree begins at
+ <emphasis
+ role="bold">'ou=users,ou=system'</emphasis>
+ . The base can be any length of name
+ components including 0 where it's the empty name "". In this case, the
+ subtree begins at the AP,
+ <emphasis
+ role="bold">'ou=system'</emphasis>
+ in
+ the example above.
+ </para>
+ </section>
+ <section
+ id="Chop parameters">
+ <title>Chop parameters</title>
+ <para>Chop specification parameters define specific nodes to be excluded from the collection as well as how deep
+ the subtree spans and even where it starts relative to the base.</para>
+ <section
+ id="chopBefore and chopAfter">
+ <title>chopBefore and chopAfter</title>
+ <para>These parameters are names relative to the root vertex of the subtree, hence they are relative to the base
+ parameter. They specify whether or not an entry and its descendants are to be excluded from the collection.
+ </para>
+ <para>
+ When
+ <emphasis
+ role="bold">chopBefore</emphasis>
+ is used, the entry specified is excluded from the collection. When
+ <emphasis
+ role="bold">chopAfter</emphasis>
+ is used the
+ entry is included however all descendants below the entry are excluded.
+ </para>
+ </section>
+ <section
+ id="minimum and maximum">
+ <title>minimum and maximum</title>
+ <para>The minimum parameter describes the minimum number of name components (arc) between the base and the
+ target entry required to include entries within the selection. The maximum parameter describes the maximum arc
+ length between the base and the target allowed before entries are excluded from the collection.</para>
+ </section>
+ </section>
+ <section
+ id="Specification filter parameter">
+ <title>Specification filter parameter</title>
+ <para>
+ The specification filter is a unique beast. It's a filter like a search filter, however its syntax and
+ expressivity is radically different. Think of a specification filter as a simplified form of search filters
+ where all terms only test the objectClass attribute and only equality checks can be performed. Oh and yes, you
+ do have logical operators like
+ <emphasis
+ role="bold">and</emphasis>
+ ,
+ <emphasis
+ role="bold">or</emphasis>
+ and
+ <emphasis
+ role="bold">not</emphasis>
+ .
+ </para>
+ <para>So with a filter you have the ability to "refine" the subtree already specified with chop, and base
+ parameters. This "refinement" makes it so the collection is not really a contiguous subtree of entries but a
+ possibly disconnected set of selected based on the objectClass characteristics of entries. This feature of a
+ subtreeSpecification is very powerful. For example, I can define a subtree to cover a region of an AA yet
+ include only inetOrgPersons within this region.</para>
+ <info>
+ <title>Specification Filter in 1.5+</title>
+ <para>Starting with version 1.5 of ApacheDS, the specificationFilter component can be given as a regular search
+ filter. The refinement syntax is still valid but the regular search filter is a much more powerful scheme.
+ This new capability is beyond the RFC specification. To keep your administrative data compatible with other
+ servers (although non supporting RFC3672 yet) you may want to use the old scheme.</para>
+ </info>
+ </section>
+ <section
+ id="Subentry types in ApacheDS">
+ <title>Subentry types in ApacheDS</title>
+ <para>Different subentry objectClasses exist for applying different aspects of administration to the entry
+ collection described by their subtreeSpecification attribute. By the way the subtreeSpecification attribute is
+ single valued so there can only be one in a subentry. However you can have several subentries of various kinds
+ under an AP. Furthermore their collections can intersect.</para>
+ <para>The kinds of subentries allowed though are limited by the administrativeRole of the AP. If the AP is for an
+ access control AA then you can't add a subentry to it for schema administration. The AP must have the role for
+ schema administration as well to allow both types of subentries.</para>
+ <para>
+ ApacheDS does not manage schema using subentries in the formal X.500 sense right now. There is a single
+ global
+ subentry defined at
+ <emphasis
+ role="bold">'cn=schema'</emphasis>
+ for the entire DSA. The schema is static and cannot be updated at runtime
+ even by the administrator. Pretty rough
+ for now but it's the only lagging subsystem. We'll of course make sure
+ this subsystem catches up.
+ </para>
+ <para>
+ ApacheDS does however manage collective attributes using subentries. An AP that takes the administrativeRole
+ for
+ managing collective attributes can have subentries added. These subentries are described in greater detail
+ here:
+ <xref
+ linkend="Collective Attributes" />
+ . In short, collective attributes added to subentries show up within entries included by the
+ subtreeSpecification. Adding, removing, and modifying the values of collective attributes within the subentries
+ instantly manifest changes in the entries selected by the subtreeSpecification. Again consult
+ <xref
+ linkend="Collective Attributes" />
+ for a
+ hands on explanation of how to use this feature.
+ </para>
+ <para>
+ ApacheDS performs access control and allows delegation using subentries, AAAs, and IAAs. ApacheDS uses the
+ Basic
+ Access Control Scheme from X.501 to manage access control. By default this subsystem is deactivated
+ because it
+ locks down everything except access by the admin. More information about hands on use is available
+ here:
+ <xref
+ linkend="Authorization" />
+ However to summarize its association with subentries, access control information (ACI) can
+ be added to subentries
+ under an AP for access control AAs. When one or more ACI are added in this fashion, the
+ access rules of the ACI
+ set apply to all entries selected by the subtreeSpecification. Even with this powerful
+ feature individual entries
+ can have ACI added to them for controlling access to them. Also there are things you
+ can do with ACI added to
+ subentries that cannot be done with entry level ACI. For example you cannot allow entry
+ addition with entry ACI.
+ You must use subtreeSpecifications to define where entries may be added because those
+ entries and their parents
+ may not exist yet.
+ </para>
+ </section>
+ <section
+ id="How to specify a subentry's subtreeSpecification">
+ <title>How to specify a subentry's subtreeSpecification</title>
+ <para>The best way to demonstrate subtreeSpecification values are through examples. Here's the simplest filter of
+ them all:</para>
+ <programlisting><![CDATA[
+{} ]]></programlisting>
+ <para>This basically selects the entire contiguous subtree below the AP. The base is the empty name and it's
+ rooted at the AP.</para>
+ <para>Next step let's add a base:</para>
+ <programlisting><![CDATA[
+{ base "ou=users" }
+ ]]></programlisting>
+ <para>
+ If this is the subtreeSpecification under the AP,
+ <emphasis
+ role="bold">'ou=system'</emphasis>
+ , then it selects every entry under
+ <emphasis
+ role="bold">'ou=users,ou=system'</emphasis>
+ .
+ </para>
+ <para>OK that was easy so now let's slice and dice the tree now using the minimum and maximum chop parameters.
+ </para>
+ <programlisting><![CDATA[
+{ minimum 3, maximum 5 }
+ ]]></programlisting>
+ <para>
+ This selects all entries below
+ <emphasis
+ role="bold">'ou=system'</emphasis>
+ which have a DN size equal to 3 name components, but no more than
+ 5. So for example
+ <emphasis
+ role="bold">'uid=jdoe,ou=users,ou=system'</emphasis>
+ would be included but
+ <emphasis
+ role="bold">'uid=jack,ou=do,ou=not,ou=select,ou=users,ou=system'</emphasis>
+ would not be included. Let's continue and combine the base
+ with just a minimum parameter:
+ </para>
+ <programlisting><![CDATA[
+{ base "ou=users", minimum 4 }
+ ]]></programlisting>
+ <para>
+ Here the subtree starts at
+ <emphasis
+ role="bold">'ou=users,ou=system'</emphasis>
+ if the subentry subordinates to the AP at
+ <emphasis
+ role="bold">'ou=system'</emphasis>
+ . The
+ user
+ <emphasis
+ role="bold">'uid=jdoe,ou=deepenough,ou=users,ou=system'</emphasis>
+ is selected by the spec where as
+ <emphasis
+ role="bold">'uid=jbean,ou=users,ou=system'</emphasis>
+ is not.
+ </para>
+ <para>It's time to add some chop exclusions:</para>
+ <programlisting><![CDATA[
+{
+ base "ou=users",
+ minimum 4,
+ specificExclusions { chopBefore: "ou=untrusted" }
+}
+ ]]></programlisting>
+ <para>
+ Again if placed at the AP 'ou=system' this subtree would begin at
+ <emphasis
+ role="bold">'ou=users,ou=system'</emphasis>
+ . It would not include
+ users that subordinate to it though because of the minimum constraint since these users
+ would have 3 components
+ in their DN. The specific exclusions prevent
+ <emphasis
+ role="bold">'ou=untrusted,ou=users,ou=system'</emphasis>
+ and all its descendants from
+ being included in the collection. However
+ <emphasis
+ role="bold">'uid=jbean,ou=trusted,ou=users,ou=system'</emphasis>
+ would be included since it
+ meets the minimum requirement, is a descendant of
+ <emphasis
+ role="bold">'ou=users,ou=system'</emphasis>
+ and is not under the excluded DN,
+ <emphasis
+ role="bold">'ou=untrusted,ou=users,ou=system'</emphasis>
+ .
+ </para>
+ <para>Note that you can add as many exclusions as you like by comma delimiting them. For example:</para>
+ <programlisting><![CDATA[
+{
+ base "ou=users",
+ minimum 4,
+ specificExclusions { chopBefore: "ou=untrusted", chopAfter: "ou=ugly", chopBefore: "ou=bad" }
+}
+ ]]></programlisting>
+ <para>The final example includes a refinement. Again any combination of chop, filter and base parameters can be
+ used. The following refinement makes sure the users selected are of the objectClass inetOrgPerson and
+ specialUser where the OID for the specialUser class is 32.5.2.1 (fictitious).</para>
+ <programlisting><![CDATA[
+{
+ base "ou=users",
+ minimum 4,
+ specificExclusions { chopBefore: "ou=untrusted", chopAfter: "ou=ugly", chopBefore: "ou=bad" }
+ specificationFilter and:{ item:32.5.2.1, item:inetOrgPerson }
+}
+ ]]></programlisting>
+ <para>
+ If you'd like to see the whole specification of the grammar used for the subtreeSpecification take a look at
+ Appendix A in
+ <link
+ xlink:href="http://www.faqs.org/rfcs/rfc3672.html">RFC 3672</link>
+ .
+ </para>
+ </section>
+ <section
+ id="Future Possibilities">
+ <title>Future Possibilities</title>
+ <para>
+ In the immediate future we intend to introduce
+ <xref
+ linkend="LDAP Triggers" />
+ , stored procedures and views into ApacheDS.
+ Subentries will play a critical role in the administration and
+ application of these features. For example a
+ Trigger specification need not include information on what entries
+ it applies to since the subtreeSpecification
+ handles this. The question of "on what" a trigger applies to is
+ nicely disassociated from the "which operation"
+ part of the specification. This makes for much better reuse of
+ triggers. It also allows for the pin point
+ application of triggers to entries in the DIT. Likewise a view itself
+ will be defined by a specification. A view
+ for example in a subentry can define a region of the tree that does
+ not exist but is shadowed from another
+ region all together. The possibilities here are limitless.
+ </para>
+ <para>Of course we will revamp the schema subsystem of ApacheDS to use subentries in AAA to manage the schema in
+ effect within different regions of the DIT. Today most LDAP servers just have a global scheme in effect for the
+ entire DIT served by a DSA. We don't think that is reasonable at all. So expect some serious advances in the
+ design of a new schema subsystem based on subentries.</para>
+ <para>Replication is yet another excellent candidate for using subentries. Replication of specific collections of
+ entries can be managed for each cluster rather than replicating the entire DIT served by a DSA to replicas. This
+ way we don't only control what is replicated but we can also control how and where it is replicated.</para>
+ </section>
+ <section
+ id="Conclusions">
+ <title>Conclusions</title>
+ <para>
+ ApacheDS has implemented subentries for the administration of various aspects of the directory and gains
+ several
+ powerful features as a result: namely precision application of control to entry collections and the
+ ability to
+ delegate administrative authority. For details on the administration of each aspect using subentries
+ (
+ <link
+ xlink:href="http://cwiki.apache.org/confluence/pages/createpage.action?spaceKey=DIRxSRVx11&title=Collective&linkCreation=true&fromPageId=55219">Collective</link>
+ and
+ <xref
+ linkend="Authorization" />
+ ) please see the respective documentation.
+ </para>
+ <para>As ApacheDS progresses it will gain an immense advantage from subentries. Both for existing LDAP features
+ like scheme and for new experimental features like triggers, and replication.</para>
+ </section>
+ </section>
+ <section
+ id="Supported RFCs">
+ <title>Supported RFCs</title>
+ <para>
+ Here is a list of all LDAP related RFCs (grey and marked
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ are obsoleted RFCs) in the current 1.5 version of
+ ADS. The flag
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/check.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ is used for implemented RFCs into ADS. The flag
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/warning.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ is
+ used for partially implemented RFCs into ADS .
+ The flag
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/error.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ is used for RFC not supported by ADS :
+ </para>
+ <table
+ id="LDAP related RFCs table">
+ <title>LDAP related RFCs</title>
+ <tgroup
+ cols="3">
+ <thead>
+ <row>
+ <entry>RFC num</entry>
+ <entry>status</entry>
+ <entry>Description</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>RFC 1274</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>The COSINE and Internet X.500 Schema.</entry>
+ </row>
+ <row>
+ <entry>RFC 1485</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>A String Representation of Distinguished Names (OSI-DS 23 (v5)).</entry>
+ </row>
+ <row>
+ <entry>RFC 1487</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>X.500 Lightweight Directory Access Protocol</entry>
+ </row>
+ <row>
+ <entry>RFC 1558</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>A String Representation of LDAP Search Filters.</entry>
+ </row>
+ <row>
+ <entry>RFC 1777</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Lightweight Directory Access Protocol.</entry>
+ </row>
+ <row>
+ <entry>RFC 1779</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>A String Representation of Distinguished Names.</entry>
+ </row>
+ <row>
+ <entry>RFC 1823</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>The LDAP Application Program Interface.</entry>
+ </row>
+ <row>
+ <entry>RFC 1959</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>An LDAP URL Format.</entry>
+ </row>
+ <row>
+ <entry>RFC 1960</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>A String Representation of LDAP Search Filters.</entry>
+ </row>
+ <row>
+ <entry>RFC 2164</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Use of an X.500/LDAP directory to support MIXER address mapping.</entry>
+ </row>
+ <row>
+ <entry>RFC 2247</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Using Domains in LDAP/X.500 Distinguished Names.</entry>
+ </row>
+ <row>
+ <entry>RFC 2251</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/check.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Lightweight Directory Access Protocol (v3).</entry>
+ </row>
+ <row>
+ <entry>RFC 2252</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/check.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Lightweight Directory Access Protocol (v3)| Attribute Syntax Definitions.</entry>
+ </row>
+ <row>
+ <entry>RFC 2253</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/check.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Lightweight Directory Access Protocol (v3)| UTF-8 String Representation of Distinguished Names.
+ </entry>
+ </row>
+ <row>
+ <entry>RFC 2254</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/check.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>The String Representation of LDAP Search Filters.</entry>
+ </row>
+ <row>
+ <entry>RFC 2255</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/check.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>The LDAP URL Format.</entry>
+ </row>
+ <row>
+ <entry>RFC 2256</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/check.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>A Summary of the X.500(96) User Schema for use with LDAPv3.</entry>
+ </row>
+ <row>
+ <entry>RFC 2307</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>An Approach for Using LDAP as a Network Information Service.</entry>
+ </row>
+ <row>
+ <entry>RFC 2559</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2.</entry>
+ </row>
+ <row>
+ <entry>RFC 2587</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Internet X.509 Public Key Infrastructure LDAPv2 Schema.</entry>
+ </row>
+ <row>
+ <entry>RFC 2596</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Use of Language Codes in LDAP</entry>
+ </row>
+ <row>
+ <entry>RFC 2649</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>An LDAP Control and Schema for Holding Operation Signatures.</entry>
+ </row>
+ <row>
+ <entry>RFC 2657</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>LDAPv2 Client vs. the Index Mesh.</entry>
+ </row>
+ <row>
+ <entry>RFC 2696</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/warning.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>LDAP Control Extension for Simple Paged Results Manipulation.</entry>
+ </row>
+ <row>
+ <entry>RFC 2713</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Schema for Representing Java(tm) Objects in an LDAP Directory.</entry>
+ </row>
+ <row>
+ <entry>RFC 2714</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Schema for Representing CORBA Object References in an LDAP Directory.</entry>
+ </row>
+ <row>
+ <entry>RFC 2739</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Calendar Attributes for vCard and LDAP.</entry>
+ </row>
+ <row>
+ <entry>RFC 2798</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/check.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Definition of the inetOrgPerson LDAP Object Class.</entry>
+ </row>
+ <row>
+ <entry>RFC 2820</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Access Control Requirements for LDAP</entry>
+ </row>
+ <row>
+ <entry>RFC 2829</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Authentication Methods for LDAP</entry>
+ </row>
+ <row>
+ <entry>RFC 2830</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Lightweight Directory Access Protocol (v3)| Extension for Transport Layer Security.</entry>
+ </row>
+ <row>
+ <entry>RFC 2849</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/check.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>The LDAP Data Interchange Format (LDIF) - Technical Specification.</entry>
+ </row>
+ <row>
+ <entry>RFC 2891</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>LDAP Control Extension for Server Side Sorting of Search Results.</entry>
+ </row>
+ <row>
+ <entry>RFC 2926</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Conversion of LDAP Schemas to and from SLP Templates.</entry>
+ </row>
+ <row>
+ <entry>RFC 3045</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/check.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Storing Vendor Information in the LDAP root</entry>
+ </row>
+ <row>
+ <entry>RFC 3062</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>LDAP Password Modify Extended Operation.</entry>
+ </row>
+ <row>
+ <entry>RFC 3088</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>OpenLDAP Root Service An experimental LDAP referral service.</entry>
+ </row>
+ <row>
+ <entry>RFC 3112</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>LDAP Authentication Password Schema.</entry>
+ </row>
+ <row>
+ <entry>RFC 3296</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/check.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Named Subordinate References in Lightweight Directory Access Protocol (LDAP) Directories.</entry>
+ </row>
+ <row>
+ <entry>RFC 3377</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/check.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Lightweight Directory Access Protocol (v3)| Technical Specification.</entry>
+ </row>
+ <row>
+ <entry>RFC 3383</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access
+ Protocol (LDAP).</entry>
+ </row>
+ <row>
+ <entry>RFC 3384</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Lightweight Directory Access Protocol (version 3) Replication Requirements.</entry>
+ </row>
+ <row>
+ <entry>RFC 3663</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Domain Administrative Data in Lightweight Directory Access Protocol (LDAP).</entry>
+ </row>
+ <row>
+ <entry>RFC 3671</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/check.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Collective Attributes in the Lightweight Directory Access Protocol (LDAP).</entry>
+ </row>
+ <row>
+ <entry>RFC 3672</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/check.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Subentries in the Lightweight Directory Access Protocol (LDAP).</entry>
+ </row>
+ <row>
+ <entry>RFC 3673</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/check.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>All Operational Attributes</entry>
+ </row>
+ <row>
+ <entry>RFC 3674</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Feature Discovery in Lightweight Directory Access Protocol (LDAP).</entry>
+ </row>
+ <row>
+ <entry>RFC 3687</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Lightweight Directory Access Protocol (LDAP) and X.500 Component Matching Rules.</entry>
+ </row>
+ <row>
+ <entry>RFC 3698</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Lightweight Directory Access Protocol (LDAP): Additional Matching Rules.</entry>
+ </row>
+ <row>
+ <entry>RFC 3703</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Policy Core Lightweight Directory Access ProTocol (LDAP) Schema.</entry>
+ </row>
+ <row>
+ <entry>RFC 3712</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Lightweight Directory Access Protocol (LDAP): Schema for Printer Services.</entry>
+ </row>
+ <row>
+ <entry>RFC 3771</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>The Lightweight Directory Access Protocol (LDAP) Intermediate Response Message.</entry>
+ </row>
+ <row>
+ <entry>RFC 3727</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>ASN.1 Module Definition for the LDAP and X.500 Component Matching Rules.</entry>
+ </row>
+ <row>
+ <entry>RFC 3771</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>The Lightweight Directory Access Protocol (LDAP) Intermediate Response Message.</entry>
+ </row>
+ <row>
+ <entry>RFC 3829</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Lightweight Directory Access Protocol (LDAP) Authorization Identity Request and Response Controls.
+ </entry>
+ </row>
+ <row>
+ <entry>RFC 3866</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Language Tags and Ranges in the Lightweight Directory Access Protocol (LDAP).</entry>
+ </row>
+ <row>
+ <entry>RFC 3876</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Returning Matched Values with the Lightweight Directory Access Protocol version 3 (LDAPv3).</entry>
+ </row>
+ <row>
+ <entry>RFC 3909</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Lightweight Directory Access Protocol (LDAP) Cancel Operation.</entry>
+ </row>
+ <row>
+ <entry>RFC 3928</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP).</entry>
+ </row>
+ <row>
+ <entry>RFC 4104</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Policy Core Extension Lightweight Directory Access Protocol Schema (PCELS).</entry>
+ </row>
+ <row>
+ <entry>RFC 4370</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/error.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Lightweight Directory Access Protocol (LDAP) Proxied Authorization Control.</entry>
+ </row>
+ <row>
+ <entry>RFC 4373</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Lightweight Directory Access Protocol (LDAP) Bulk Update/Replication Protocol (LBURP).</entry>
+ </row>
+ <row>
+ <entry>RFC 4403</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Lightweight Directory Access Protocol (LDAP) Schema for Universal Description, Discovery, and
+ Integration version 3 (UDDIv3).</entry>
+ </row>
+ <row>
+ <entry>RFC 4510</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/check.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map.</entry>
+ </row>
+ <row>
+ <entry>RFC 4511</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/check.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Lightweight Directory Access Protocol (LDAP): The Protocol.</entry>
+ </row>
+ <row>
+ <entry>RFC 4512</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/check.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Lightweight Directory Access Protocol (LDAP): Directory Information Models.</entry>
+ </row>
+ <row>
+ <entry>RFC 4513</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/check.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms.</entry>
+ </row>
+ <row>
+ <entry>RFC 4514</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/check.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names.</entry>
+ </row>
+ <row>
+ <entry>RFC 4515</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/check.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters.</entry>
+ </row>
+ <row>
+ <entry>RFC 4516</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/check.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator.</entry>
+ </row>
+ <row>
+ <entry>RFC 4517</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/check.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules.</entry>
+ </row>
+ <row>
+ <entry>RFC 4518</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/check.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation.</entry>
+ </row>
+ <row>
+ <entry>RFC 4519</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/check.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Lightweight Directory Access Protocol (LDAP): Schema for User Applications.</entry>
+ </row>
+ <row>
+ <entry>RFC 4520</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access
+ Protocol (LDAP).</entry>
+ </row>
+ <row>
+ <entry>RFC 4521</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Considerations for Lightweight Directory Access Protocol (LDAP) Extensions.</entry>
+ </row>
+ <row>
+ <entry>RFC 4522</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Lightweight Directory Access Protocol (LDAP): The Binary Encoding Option.</entry>
+ </row>
+ <row>
+ <entry>RFC 4523</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates.</entry>
+ </row>
+ <row>
+ <entry>RFC 4524</entry>
+ <entry>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/lightbulb_on.gif" />
+ </imageobject>
+ </inlinemediaobject>
+ </entry>
+ <entry>COSINE LDAP/X.500 Schema.</entry>
+ </row>
+ <row>
[... 144 lines stripped ...]