Servers SHOULD recognize all the syntaxes described in this section. For example,
.
AttributeTypeDescription = "(" whsp
numericoid whsp ; AttributeType identifier
[ "NAME" qdescrs ] ; name used in AttributeType
[ "DESC" qdstring ] ; description
[ "OBSOLETE" whsp ]
[ "SUP" woid ] ; derived from this other
; AttributeType
[ "EQUALITY" woid ; Matching Rule name
[ "ORDERING" woid ; Matching Rule name
[ "SUBSTR" woid ] ; Matching Rule name
[ "SYNTAX" whsp noidlen whsp ] ; see section 4.3
[ "SINGLE-VALUE" whsp ] ; default multi-valued
[ "COLLECTIVE" whsp ] ; default not collective
[ "NO-USER-MODIFICATION" whsp ]; default user modifiable
[ "USAGE" whsp AttributeUsage ]; default userApplications
whsp ")"
AttributeUsage =
"userApplications" /
"directoryOperation" /
"distributedOperation" / ; DSA-shared
"dSAOperation" ; DSA-specific, value depends on server
Servers are not required to provide the same or any text in the description part of the subschema values they maintain. Servers SHOULD provide at least one of the "SUP" and "SYNTAX" fields for each AttributeTypeDescription.
BNC Syntax: 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type 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