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:
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.
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.
An optional human-readable description. If there is a description, then it should be enclosed in single quotation marks.
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.
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.
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.
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.
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.
An optional set of extensions for the object class. The directory server currently uses the following extensions for object classes:
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).
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:
( 18.104.22.168 NAME 'person' SUP top STRUCTURAL MUST ( sn $ cn ) MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) X-ORIGIN 'RFC 4519' )
In this case, the OID is 22.214.171.124. 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.