Ldap Schema Viewer
Objectclass : subschema
ID: 2.5.20.1
The ldapSyntaxes operational attribute may also be present in subschema entries.
BNC Syntax: 2.5.20.1 NAME 'subschema' AUXILIARY MAY ( dITStructureRules $ nameForms $ ditContentRules $ objectClasses $ attributeTypes $ matchingRules $ matchingRuleUse )
rfc2252
Attributes:
May Have:
Comments
Description:
These attributes are located in the subschema entry. All servers SHOULD recognize their name, although typically only X.500 servers will implement their functionality.
BNC Syntax: 2.5.21.1 NAME 'dITStructureRules' EQUALITY integerFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.17 USAGE directoryOperation
rfc2252
ID : 1.3.6.1.4.1.1466.115.121.1.17
Values with this syntax are encoded according to the following BNF:
DITStructureRuleDescription = "(" whsp
ruleidentifier whsp ; DITStructureRule identifier
[ "NAME" qdescrs ]
[ "DESC" qdstring ]
[ "OBSOLETE" whsp ]
"FORM" woid whsp ; NameForm
[ "SUP" ruleidentifiers whsp ] ; superior DITStructureRules
")"
ruleidentifier = integer
ruleidentifiers = ruleidentifier |
"(" whsp ruleidentifierlist whsp ")"
ruleidentifierlist = [ ruleidentifier *( ruleidentifier ) ]
BNC Syntax: 1.3.6.1.4.1.1466.115.121.1.17 DESC `DIT Structure Rule 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.29 NAME 'integerFirstComponentMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
rfc2252
Description:
These attributes are located in the subschema entry. All servers SHOULD recognize their name, although typically only X.500 servers will implement their functionality.
BNC Syntax: 2.5.21.7 NAME 'nameForms' EQUALITY objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.35 USAGE directoryOperation
rfc2252
ID : 1.3.6.1.4.1.1466.115.121.1.35
Values in this syntax are encoded according to the following BNF. Implementors should note that future versions of this document may have expanded this BNF to include additional terms.
NameFormDescription = "(" whsp
numericoid whsp ; NameForm identifier
[ "NAME" qdescrs ]
[ "DESC" qdstring ]
[ "OBSOLETE" whsp ]
"OC" woid ; Structural ObjectClass
"MUST" oids ; AttributeTypes
[ "MAY" oids ] ; AttributeTypes
whsp ")"
BNC Syntax: 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form 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
Description:
These attributes are located in the subschema entry. All servers SHOULD recognize their name, although typically only X.500 servers will implement their functionality.
BNC Syntax: 2.5.21.2 NAME 'dITContentRules' EQUALITY objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.16 USAGE directoryOperation
rfc2252
ID : 1.3.6.1.4.1.1466.115.121.1.16
Values in this syntax are encoded according to the following BNF. Implementors should note that future versions of this document may have expanded this BNF to include additional terms.
DITContentRuleDescription = "("
numericoid ; Structural ObjectClass identifier
[ "NAME" qdescrs ]
[ "DESC" qdstring ]
[ "OBSOLETE" ]
[ "AUX" oids ] ; Auxiliary ObjectClasses
[ "MUST" oids ] ; AttributeType identifiers
[ "MAY" oids ] ; AttributeType identifiers
[ "NOT" oids ] ; AttributeType identifiers
")"
BNC Syntax: 1.3.6.1.4.1.1466.115.121.1.16 DESC 'DIT Content Rule 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
Description:
This attribute is typically located in the subschema entry.
BNC Syntax: 2.5.21.6 NAME 'objectClasses' EQUALITY objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.37 USAGE directoryOperation
rfc2252
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
Description:
This attribute is typically located in the subschema entry.
BNC Syntax: 2.5.21.5 NAME 'attributeTypes' EQUALITY objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.3 USAGE directoryOperation
rfc2252
ID : 1.3.6.1.4.1.1466.115.121.1.3
Servers SHOULD recognize all the syntaxes described in this section. For example,
( 2.5.4.0 NAME `objectClass`
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
The AttributeTypeDescription is encoded according to the following BNF, and the productions for oid, qdescrs and qdstring are given in section 4.1. Implementors should note that future versions of this document may have expanded this BNF to include additional terms.
Terms which begin with the characters "X-" are reserved for private experiments, and MUST be followed by a .
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
Description:
This attribute is typically located in the subschema entry.
Matching rules are used by servers to compare attribute values against assertion values when performing Search and Compare operations. They are also used to identify the value to be added or deleted when modifying entries, and are used when comparing a purported distinguished name with the name of an entry.
Most of the attributes given in this document will have an equality matching rule defined.
Matching rule descriptions are written according to the following BNF. Implementors should note that future versions of this document may have expanded this BNF to include additional terms. Terms whose identifier begins with "X-" are reserved for private experiments, and MUST be followed by a encoding.
MatchingRuleDescription = "(" whsp
numericoid whsp ; MatchingRule identifier
[ "NAME" qdescrs ]
[ "DESC" qdstring ]
[ "OBSOLETE" whsp ]
"SYNTAX" numericoid
whsp ")"
Values of the matchingRuleUse list the attributes which are suitable for use with an extensible matching rule.
MatchingRuleUseDescription = "(" whsp
numericoid whsp ; MatchingRule identifier
[ "NAME" qdescrs ]
[ "DESC" qdstring ]
[ "OBSOLETE" ]
"APPLIES" oids ; AttributeType identifiers
whsp ")"
Servers which support matching rules and the extensibleMatch SHOULD implement all the matching rules in section 8.
Servers MAY implement additional matching rules not listed in this document, and if they do so, MUST publish the definitions of the matching rules in the matchingRules attribute of their subschema entries. If the server supports the extensibleMatch, then the server MUST publish the relationship between the matching rules and attributes in the matchingRuleUse attribute.
For example, a server which implements a privately-defined matching rule for performing sound-alike matches on Directory String-valued attributes would include the following in the subschema entry (1.2.3.4.5 is an example, the OID of an actual matching rule would be different):
matchingRule: ( 1.2.3.4.5 NAME `soundAlikeMatch`
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
If this matching rule could be used with the attributes 2.5.4.41 and 2.5.4.15, the following would also be present:
matchingRuleUse: ( 1.2.3.4.5 APPLIES (2.5.4.41 $ 2.5.4.15) )
A client could then make use of this matching rule by sending a search operation in which the filter is of the extensibleMatch choice, the matchingRule field is "soundAlikeMatch", and the type field is "2.5.4.41" or "2.5.4.15".
BNC Syntax: 2.5.21.4 NAME 'matchingRules' EQUALITY objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.30 USAGE directoryOperation
rfc2252
ID : 1.3.6.1.4.1.1466.115.121.1.30
Values of type matchingRules are encoded as strings according to the BNF given in section 4.5.
BNC Syntax: 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule 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
Description:
This attribute is typically located in the subschema entry.
Matching rules are used by servers to compare attribute values against assertion values when performing Search and Compare operations. They are also used to identify the value to be added or deleted when modifying entries, and are used when comparing a purported distinguished name with the name of an entry.
Most of the attributes given in this document will have an equality matching rule defined.
Matching rule descriptions are written according to the following BNF. Implementors should note that future versions of this document may have expanded this BNF to include additional terms. Terms whose identifier begins with "X-" are reserved for private experiments, and MUST be followed by a encoding.
MatchingRuleDescription = "(" whsp
numericoid whsp ; MatchingRule identifier
[ "NAME" qdescrs ]
[ "DESC" qdstring ]
[ "OBSOLETE" whsp ]
"SYNTAX" numericoid
whsp ")"
Values of the matchingRuleUse list the attributes which are suitable for use with an extensible matching rule.
MatchingRuleUseDescription = "(" whsp
numericoid whsp ; MatchingRule identifier
[ "NAME" qdescrs ]
[ "DESC" qdstring ]
[ "OBSOLETE" ]
"APPLIES" oids ; AttributeType identifiers
whsp ")"
Servers which support matching rules and the extensibleMatch SHOULD implement all the matching rules in section 8.
Servers MAY implement additional matching rules not listed in this document, and if they do so, MUST publish the definitions of the matching rules in the matchingRules attribute of their subschema entries. If the server supports the extensibleMatch, then the server MUST publish the relationship between the matching rules and attributes in the matchingRuleUse attribute.
For example, a server which implements a privately-defined matching rule for performing sound-alike matches on Directory String-valued attributes would include the following in the subschema entry (1.2.3.4.5 is an example, the OID of an actual matching rule would be different):
matchingRule: ( 1.2.3.4.5 NAME `soundAlikeMatch`
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
If this matching rule could be used with the attributes 2.5.4.41 and 2.5.4.15, the following would also be present:
matchingRuleUse: ( 1.2.3.4.5 APPLIES (2.5.4.41 $ 2.5.4.15) )
A client could then make use of this matching rule by sending a search operation in which the filter is of the extensibleMatch choice, the matchingRule field is "soundAlikeMatch", and the type field is "2.5.4.41" or "2.5.4.15".
BNC Syntax: 2.5.21.8 NAME 'matchingRuleUse' EQUALITY objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.31 USAGE directoryOperation
rfc2252
ID : 1.3.6.1.4.1.1466.115.121.1.31
Matching rules are used by servers to compare attribute values against assertion values when performing Search and Compare operations. They are also used to identify the value to be added or deleted when modifying entries, and are used when comparing a purported distinguished name with the name of an entry.
Most of the attributes given in this document will have an equality matching rule defined.
Matching rule descriptions are written according to the following BNF. Implementors should note that future versions of this document may have expanded this BNF to include additional terms. Terms whose identifier begins with "X-" are reserved for private experiments, and MUST be followed by a encoding.
MatchingRuleDescription = "(" whsp
numericoid whsp ; MatchingRule identifier
[ "NAME" qdescrs ]
[ "DESC" qdstring ]
[ "OBSOLETE" whsp ]
"SYNTAX" numericoid
whsp ")"
Values of the matchingRuleUse list the attributes which are suitable for use with an extensible matching rule.
MatchingRuleUseDescription = "(" whsp
numericoid whsp ; MatchingRule identifier
[ "NAME" qdescrs ]
[ "DESC" qdstring ]
[ "OBSOLETE" ]
"APPLIES" oids ; AttributeType identifiers
whsp ")"
Servers which support matching rules and the extensibleMatch SHOULD implement all the matching rules in section 8.
Servers MAY implement additional matching rules not listed in this document, and if they do so, MUST publish the definitions of the matching rules in the matchingRules attribute of their subschema entries. If the server supports the extensibleMatch, then the server MUST publish the relationship between the matching rules and attributes in the matchingRuleUse attribute.
For example, a server which implements a privately-defined matching rule for performing sound-alike matches on Directory String-valued attributes would include the following in the subschema entry (1.2.3.4.5 is an example, the OID of an actual matching rule would be different):
matchingRule: ( 1.2.3.4.5 NAME 'soundAlikeMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
If this matching rule could be used with the attributes 2.5.4.41 and 2.5.4.15, the following would also be present:
matchingRuleUse: ( 1.2.3.4.5 APPLIES (2.5.4.41 $ 2.5.4.15) )
A client could then make use of this matching rule by sending a search operation in which the filter is of the extensibleMatch choice, the matchingRule field is "soundAlikeMatch", and the type field is "2.5.4.41" or "2.5.4.15".
BNC Syntax: 1.3.6.1.4.1.1466.115.121.1.31 DESC 'Matching Rule Use 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
|