ID : 1.3.6.1.4.1.1466.115.121.1.37
The format for representation of object classes is defined in X.501 [3]. In general every entry will contain an abstract class ("top" or "alias"), at least one structural object class, and zero or more auxiliary object classes. Whether an object class is abstract, structural or auxiliary is defined when the object class identifier is assigned. An object class definition should not be changed without having a new identifier assigned to it.
Object class descriptions are written according to the following BNF. Implementors should note that future versions of this document may expand this definition to include additional terms. Terms whose identifier begins with "X-" are reserved for private experiments, and MUST be followed by a encoding.
ObjectClassDescription = "(" whsp
numericoid whsp ; ObjectClass identifier
[ "NAME" qdescrs ]
[ "DESC" qdstring ]
[ "OBSOLETE" whsp ]
[ "SUP" oids ] ; Superior ObjectClasses
[ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ]
; default structural
[ "MUST" oids ] ; AttributeTypes
[ "MAY" oids ] ; AttributeTypes
whsp ")"
These are described as sample values for the subschema "objectClasses" attribute for a server which implements the LDAP schema. While lines have been folded for readability, the values transferred in protocol would not contain newlines.
Servers SHOULD implement all the object classes referenced in section 7, except for extensibleObject, which is optional. Servers MAY implement additional object classes not listed in this document, and if they do so, MUST publish the definitions of the classes in the objectClasses attribute of their subschema entries.
Schema developers MUST NOT create object class definitions whose names conflict with attributes defined for use with LDAP in existing standards-track RFCs.
BNC Syntax: 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description'
rfc2252
Description:
Servers which allow subschema entries to be modified by clients MUST
support the following matching rules, as they are the equality
matching rules for several of the subschema attributes.
Implementors should note that the assertion syntax of these matching
rules, an INTEGER or OID, is different from the value syntax of
attributes for which this is the equality matching rule.
If the client supplies an extensible filter using an
objectIdentifierFirstComponentMatch whose matchValue is in the
"descr" form, and the OID is not recognized by the server, then the
filter is Undefined.
BNC Syntax: 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
rfc2252