ApacheDS Features

The Apache Directory Server is an embeddable LDAP server implemented in pure Java. It has several features that make it unique among LDAP servers. Some of these featurea are as follows:

• Designed as an LDAP and X.500 platform; plugable components and subsystems make ApacheDS extremely modular and ideal for experiments with various aspects of the LDAP protocol.
• The server’s frontend is completely separable from its backend and vice-versa making it very flexible for implementing virtual directories, proxy servers and gateways to X.500 directories.
• Several backends can be implemented and plugged into the server’s partition nexus. The server supports a BTree based partition out of the box but any backing store can be used to implement a partition as long as it conforms to interfaces.
• The server exposes aspects of administration via a special system backend. LDAP can be used to manage these concerns through the system naming context at ou=system.
• The server contains a server side JNDI LDAP provider as the facade for the entire backend subsystem. JNDI operations are directly translated by this provider into operations against the nexus and the target partitions storing server entries.
• The server’s networking code, MINA (Multipurpose Infrastructure for Network Applications) was designed for pluggable protocol providers, of all sorts and not just LDAP. MINA gives ApacheDS the ability to handle large amounts of concurrency.
• LDAP Stored Procedures and Triggers are scheduled for the next major version of ApacheDS.
• LDAPv3 compatible certified by the OpenGroup

OID assignements Scheme

OID strings are unique numeric identifiers based off of a hierarchical numeric namespace controlled by a central authority on the Internet: IANA (Internet Assigned Numbers Authority).

IANA allows companies and organizations to register for a specific OID base called an enterprise number. There can only be one IANA Enterprise Number per organization.

The ASF’s Enterprise Number

Apache has such an enterprise number. You can look at the IANA assigned numbers here. Here’s the record in this database for the Apache Software Foundation:

Apache Software Foundation

18060
  The Apache Software Foundation
    Alex Karasulu
      akarasulu@apache.org

This means the ASF can use the following unique OID base 1.3.6.1.4.1.18060 for any of it’s needs. However we internal here at the ASF need some kind of scheme for assigning these numbers internally so we do not have collisions.

Current Assignments

Here’s what we’ve assigned to date:

Each contact person is the authority for assigning unique OID values and ranges to projects or persons. Contact that person for more assignments.

Making Assignments

Contacts may wonder what scheme is best for making assignments. There is no rule for doing this. However some would recommend assigning the first digit past the enterprise number of an organization to be for identifying a protocol. Obviously we did not do this for Apache. The reason for this is because we feel it’s better to model the assignments based on the structure of the organization since these are private ranges and need not conform to a global convention.

However this still does not tell us how contacts should make assignments. I think this is up to you. Perhaps a good example will be how the Directory TLP does things which is somewhat specific to their products and the nature of their products.

Assignment Scheme For Apache Directory

The ninth component in the OID could be reserved for subprojects like ApacheDS and Triplesec. This might be more attractive in TLPs with many subprojects because a single authority or contact can be used for a specific subproject. So here could be one assignment scheme:

Here’s how the ApacheDS OID is branched off:

The ninth component in the OID could be reserved for subprojects like ApacheDS and Triplesec. This might be more attractive in TLPs with many subprojects because a single authority or contact can be used for a specific subproject. So here could be one assignment scheme:

where X is a unique number associated with one of the specific ApacheDS schema.

NOTE: dITContentRules do not have their own OID, rather they reference the OID of the structural objectClass they influence. The same sort of situation exists for matchingRuleUse which uses the OID of the matchingRule it is associated with.

And here are the schema OIDs (where the X is substituted by the proper number):

(Some of those schema are long gone, but the assignement is still existing)

OID’s for ApacheDS specific controls

Here are the new OIDs used:

OID’s for the extended operations

Here are the new OIDs used: