Register a directory OID or Prefix

Introduction

Novell no longer maintains a vendor-accessible Directory OID/Prefix Registry to generate Class and an Attribute OIDs based on Novell's address space. OIDs may be obtained from ANSI, IANA, or any other ISO Name Registration Authority.

The reason for registering schema extensions is to resolve the possibility of schema collisions caused by duplicate schema names with different definition structures, and to promote developers to create technology forums to define industry-standard schema to be considered for inclusion into the base schema. If schema registry recommendations are followed, porting applications to future schema architectures will be eased.

Novell recommends that you register an extension whenever you need to modify the Novell base schema. When you register, you select a unique prefix, and are assigned an ASN1 ID (or OID) that you can use. With these two elements, your extensions are assured of some important features.

One, they won't be in conflict with other registered extensions
and two, you are assured of a valid and unique OID

Assigned ANSI or IANA OIDs or some child of an ANSI or IANA OID may be associated with a name prefix. If application for an OID is in process, the OID field may be left blank on the application for a name prefix. Then when the OID is obtained, the OID can be associated with the name prefix. Once the prefix and subarc are recorded, you can create as many class and attribute extensions as needed.

Name prefix registration allows a developer to immediately design and implement schema extensions that are unique in Novell eDirectory with the current schema definitions. A name prefix may be up to 8 alpha-numeric characters. Name prefixes are requested by the registrar upon application (see attached name prefix application form,) but must be applicable to the name of your product, business, or technology forum. Previously registered name prefixes will generally be rejected so that name prefixes will not be registered to two different entities.

Naming and OID sequence recommendations

In the past, Novell has recommended a naming style with schema extensions that created invalid schema names for LDAP. The new recommendation allows only alpha-numeric characters, and a hyphen if necessary. The first character must be an alphabetic character. In the past the recommendation included colons, spaces and underscores, and these characters are not supported in LDAP naming standards. If they are used, mappings will have to be made using valid names in order to provide LDAP access. Schema names in versions of eDirectory from 8.38 on are automatically mapped if the naming is appropriate. Novell also recommends following the LDAP conventions for case. Although names are case insensitive for search purposes, they are stored and returned the way they are entered. Novell recommends an all-lowercase prefix, then a mixed case name. As an example, a company called Cool Stuff Engineering might request a prefix of cse, and create a schema class for their gadget object. The class name would be cseCoolGadget.

The OIDs (also known as ASN1 IDs) are used to identify schema elements. The importance for them in the directory is increasing. OIDs are stored in Novell eDirectory (and other directories supporting LDAP) using BER encoding (Basic encoding rules.)

What does a valid OID look like?

The following is an example of an OID registered by Novell with field designations:

2 16 840 1 113719 2 78 4 12 1
2 (joint-iso-ccitt)
16 (country)
840 (us)
1 (organization)
113719 (Novell)
2 (external applications)
78 (unique subarc)
4 (attribute) / 5 (syntax) / 6 (class) /100 (LDAP Extensions) /101 (LDAP Controls)
12 (number)
1 (version)

The number a developer is assigned would be 2 16 840 1 113719 2 xxx. Novell recommends that you use the 4 and the 6 following the unique subarc number to identify which of your extensions are classes (6) or attributes (4). Novell does not allow new syntaxes to be dynamically added to the schema, so the 5 is not generally used. After this point it is up to the developer to assign and maintain the subsequent numbers. Generally the next number is used to assign attributes and classes sequentially, and the final number is used as a version number to control revisions and changes to the extensions. Novell recommends starting the attribute and class count with 1 (not 0) and leaving the version field for the first release blank (don't use zero) and then using 1 for the first revision.

Notes on schema extensions

Schema changes are not always easily removed, and therefore design and experimentation should take place in a test environment, in case you want (or need) to start over. Attributes can only be removed if they are not used in a class definition. If you add attributes to Novell base classes, you will not be able to remove them. Classes can be removed as long as there are no objects instantiated of that class type. Novell base schema cannot be removed.

Tools for extending the schema

Classes and attributes can be added one at a time using the Schema Manager tool within ConsoleOne. There are also several methods for adding multiple extensions at once. It can be done programmatically using LDAP APIs (C or JAVA), JNDI (from NJCL or with the LDAP service provider), and eDirectory C APIs. It can also be done using an LDIF file and the Novell Import Convert Export utility, or with an ldapmodify utility. With eDirectory 8.5, Novell recommends using the command line version of the Novell Import Convert Export utility.

Use existing schema whenever possible

There are ways to avoid making unnecessary schema extensions. This is important, because the schema has to be synchronized throughout the directory tree, and performance can eventually be impacted if the schema becomes too large. Up-front design is very important when making schema extensions. Evaluate what classes and attributes will be needed. Then go through the base schema and see what is already in place that may meet your needs. There may be many attributes that could be used in custom classes. There is no limitation to how many classes can use any one attribute. Also check to see if there is a class that is similar to your needs, and either derive from that class, or use auxiliary classes to augment it to fulfill your class needs. The Novell schema documentation is available online for your reference.

Auxiliary Classes

Auxiliary classes are newly implemented in eDirectory and are supported in LDAP. Novell recommends using auxiliary classes whenever possible, especially when adding attributes to base schema classes. An auxiliary class is a collection of attributes that does not require class inheritance. Auxiliary classes (or aux classes) are added to objects that are already created from existing classes, rather than adding the attributes directly to the class. If an attribute or multiple attributes need to be added to existing objects, but only on some objects of that class, rather than all objects of that class, then auxiliary classes are very useful.

Hints

When you add your schema extensions using a tool that reads from a file or through a small program, be sure you add the attributes first. Otherwise if you create your classes first, the add will fail because the attributes declared in the class definition aren't in the schema.

When you make revisions or additions to your product and you extend a class that you created to contain additional attributes, perform the addition of those attributes as a modify schema operation. DO NOT perform that operation as part of the original add that you did. If you are updating a tree that already has your schema extensions, the add will fail because the class already exists, but the definition you are giving it is not identical to what is already there, and then you will not get your new attributes added to the class. If you do your extensions as an add that is identical to your original add, and then a modify that adds your new attributes, the add will cover the cases that the product has not previously been installed, and then the new attributes will be added, too.

Registration

Novell no longer maintains a vendor-accessible Directory OID/Prefix Registry to generate Class and an Attribute OIDs based on Novells address space. Vendors can obtain a base OID directly from any ISO Name Registration Authority. We encourage you to search the Internet for a complete list of selections. Some examples include:

You can also research current OID registrations from the Alvestrand OID lookup service.