Exit Print View

Sun OpenDS Standard Edition 2.2 Architectural Reference

Get PDF Book Print View
 

Document Information

1.  Introduction

2.  The Directory Server Access Control Model

3.  Understanding the Directory Server Schema

Understanding Matching Rules

Matching Rule Description Format

Commonly Used Matching Rules

Relative Time Matching Rules

Partial Date Or Time Matching Rules

Value Normalization

Understanding Attribute Syntaxes

The Attribute Syntax Description Format

Commonly Used Attribute Syntaxes

The Pattern-Matching Syntax Extension

The Enumeration Syntax Extension

Substitution Syntax Extension

Understanding Attribute Types

Attribute Type Description Format

Attribute Type Inheritance

Attribute Type Implementation

Understanding Object Classes

Object Class Description Format

Object Class Kinds

Object Class Inheritance

Directory Server Object Class Implementation

Understanding Name Forms

Name Form Description Format

Understanding DIT Content Rules

DIT Content Rule Description Format

DIT Content Rule Implementation

Understanding DIT Structure Rules

DIT Structure Rule Description Format

DIT Structure Rules and Multiple Schemas

Understanding Matching Rule Uses

4.  Directory Server Index Databases

5.  Understanding Directory Server Plug-Ins

6.  Directory Server Replication

7.  Directory Server Root Users and the Privilege Subsystem

8.  Supported Controls and Operations

Object Class Description Format

The object class description format is described in RFC 4512, section 4.1.1.

ObjectClassDescription = LPAREN WSP
numericoid                 ; object identifier
[ SP "NAME" SP qdescrs ]   ; short names (descriptors)
[ SP "DESC" SP qdstring ]  ; description
[ SP "OBSOLETE" ]          ; not active
[ SP "SUP" SP oids ]       ; superior object classes
[ SP kind ]                ; kind of class
[ SP "MUST" SP oids ]      ; attribute types
[ SP "MAY" SP oids ]       ; attribute types
extensions WSP RPAREN
kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"

The object class description includes these elements:

numericoid

The numeric OID used to uniquely identify the object class in the directory server. Although the specification requires a numeric OID, the directory server also allows a non-numeric OID for the purpose of convenience and better compatibility with the Sun Java System directory server. In this case, the non-numeric OID should be the same as the name of the object class followed by the string -oid.

NAME

An optional set of human-readable names that can be used to refer to the object class. If there is a single name, then it should be enclosed in single quotes. If there are multiple names, then they should each be enclosed in single quotes separated by spaces, and the entire set of names should be enclosed in parentheses.

DESC

An optional human-readable description. If there is a description, then it should be enclosed in single quotation marks.

OBSOLETE

An optional OBSOLETE flag that can be used to indicate whether the object class is active. If an object class is marked as OBSOLETE, then it should not be referenced by any new elements created in the directory server.

SUP

An optional set of one or more superior classes for the object class. Note that although technically the specification allows an object class to have multiple superior classes, the directory server currently only supports a single superior class. In this case, the SUP keyword should be followed by a space and the name or OID of the superior class. If there are multiple superior classes, then they should be separated by dollar signs and the entire set of superior classes should be enclosed in parentheses.

kind

An optional keyword that specifies the kind of object class that is being defined. If this is specified, then it must be one of ABSTRACT, STRUCTURAL, or AUXILIARY. If no value is specified, then the object class is considered STRUCTURAL.

MUST

An optional set of attribute types for attributes that are required to be present (that is, have at least one value) in entries with that object class. If there is only a single required attribute, then the MUSTkeyword should be followed by the name or OID of that attribute type. If there are multiple required attribute types, then they should be separated by dollar signs and the entire set of required attribute types should be enclosed in parentheses.

MAY

An optional set of optional attribute types for attributes that are allowed (but not required) to be present in entries with that object class. If there is only a single optional attribute, then the MAYkeyword should be followed by the name or OID of that attribute type. If there are multiple optional attribute types, then they should be separated by dollar signs and the entire set of optional attribute types should be enclosed in parentheses.

extensions

An optional set of extensions for the object class. The directory server currently uses the following extensions for object classes:

X-ORIGIN

Provides information about where the object class is defined (for example, whether it came from a particular RFC or Internet Draft or if it is defined within the project).

X-SCHEMA-FILE

Indicates which schema file contains the object class definition (This extension is generally used for internal purposes only and is exposed to clients.)

For example, the following is the object class description for the standard person object class:

( 2.5.6.6 NAME 'person' SUP top STRUCTURAL MUST ( sn $ cn )
MAY ( userPassword $ telephoneNumber $ seeAlso $ description )
X-ORIGIN 'RFC 4519' )

In this case, the OID is 2.5.6.6. There is a single human-readable name of person. The superior class is top. The kind is STRUCTURAL. Any entry containing the person object class is required to include the sn and cn attributes and is allowed to include the userPassword, telephoneNumber, seeAlso, and description attributes. The object class definition is taken from RFC 4519. There is no description, and the object class is not considered OBSOLETE.