directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From fel...@apache.org
Subject svn commit: r985366 [2/3] - in /directory/sandbox/felixk/apacheds-docs/src/advanced-user-guide: ./ images/
Date Fri, 13 Aug 2010 21:04:28 GMT
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&amp;title=6.1.%20Implementing%20an%20alternative%20Backend&amp;linkCreation=true&amp;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&amp;title=Collective&amp;linkCreation=true&amp;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 ...]


Mime
View raw message