AKBKHOME Consulting Services Available : Linux, Embedded Linux, PHP and PHP-GTK, just Contact me at alan@akbkhome.com 
LDAP Schema | PHP Code doc | AKBK Home >>> Projects | Phpmole IDE | Diary | Photos  
search for in

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

Your email address:
Add Your comments:

Attribute: dITStructureRules

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

Syntax: `DIT

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

Equality Matching: integerFirstComponentMatch

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


Attribute: nameForms

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

Syntax: Name Form Description

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

Equality Matching: objectIdentifierFirstComponentMatch

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


Attribute: dITContentRules

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

Syntax: DIT Content Rule Description

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

Equality Matching: objectIdentifierFirstComponentMatch

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


Attribute: objectClasses

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

Syntax: Object Class Description

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

Equality Matching: objectIdentifierFirstComponentMatch

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


Attribute: attributeTypes

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

Syntax: Attribute Type Description

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

Equality Matching: objectIdentifierFirstComponentMatch

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


Attribute: matchingRules

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

Syntax: Matching Rule Description

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

Equality Matching: objectIdentifierFirstComponentMatch

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


Attribute: matchingRuleUse

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

Syntax: Matching Rule Use Description

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

Equality Matching: objectIdentifierFirstComponentMatch

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


Contact me at alan@akbkhome.com - especially if you have some work for me :)