Attribute Types #

Attribute types define the set of attributes that may be used in the server and how operations involving that attribute should be conducted. Among other things, it combines an LDAPSyntaxes and set of matching rules with a unique OID and human-readable names.

The Attribute Type Description Format #

The attribute type description format is described in RFC 4512, section 4.1.2. The definition is as follows:

AttributeTypeDescription = LPAREN WSP 
numericoid ; object identifier 
[ SP "NAME" SP qdescrs ] ; short names (descriptors) 
[ SP "DESC" SP qdstring ] ; description 
[ SP "OBSOLETE" ] ; not active 
[ SP "SUP" SP oid ] ; supertype 
[ SP "EQUALITY" SP oid ] ; equality matching rule 
[ SP "ORDERING" SP oid ] ; ordering matching rule 
[ SP "SUBSTR" SP oid ] ; substrings matching rule 
[ SP "SYNTAX" SP noidlen ] ; value syntax 
[ SP "SINGLE-VALUE" ] ; single-value 
[ SP "COLLECTIVE" ] ; collective 
[ SP "NO-USER-MODIFICATION" ] ; not user modifiable 
[ SP "USAGE" SP usage ] ; usage 
extensions WSP RPAREN ; extensions 

usage = "userApplications" / ; user 
"directoryOperation" / ; directory operational 
"distributedOperation" / ; DSA-shared operational 
"dSAOperation" ; DSA-specific operational 

Elements of AttributeTypes#

Object Identifier #

The Object Identifier is a mandatory numeric OID used to uniquely identify the attribute type in the server. Although the specification requires a numeric OID, some LDAP Server Implementations also allow a non-numeric OID for the purpose of convenience. In this case, the non-numeric OID is typically the same as the name of the attribute type followed by the string "-oid".

Short Names (descriptors)#

The OPTIONAL Short Names (descriptors) is a set of human-readable name Attribute-Names that may also be used to refer to the AttributeTypes.

Description (DESC) #

An OPTIONAL human-readable description. If there is a description, then it should be enclosed in single quotation marks.

Not Active#

An optional not active or OBSOLETE flag that may be used to indicate whether the attribute type is active. If an attribute type is marked as "OBSOLETE", then it means that it should not be referenced by any new elements created in the DSA.

Supertype #

An optional reference to the superior attribute type. If there is a superior type, then it may be referenced by either its OID or any of its human-readable names.

Equality Matching Rule #

An optional equality matching rule definition. If a specific equality matching rule is provided, then it may be referenced by either its OID or any of its human-readable names. If no equality matching rule is given, then the attribute type will use the default equality matching rule for the associated attribute syntax. If the attribute syntax does not have a default equality matching rule, then equality matching operations will not be allowed for attributes of that type.

Ordering matching rule #

An optional ordering matching rule definition. If a specific ordering matching rule is provided, then it may be referenced by either its OID or any of its human-readable names. If no ordering matching rule is given, then the attribute type will use the default ordering matching rule for the associated attribute syntax. If the attribute syntax does not have a default ordering matching rule, then ordering matching operations will not be allowed for attributes of that type.

Substring matching rule #

An optional substring matching rule definition. If a specific substring matching rule is provided, then it may be referenced by either its OID or any of its human-readable names. If no substring matching rule is given, then the attribute type will use the default substring matching rule for the associated attribute syntax. If the attribute syntax does not have a default substring matching rule, then substring matching operations will not be allowed for attributes of that type.

Attribute Syntax #

An optional attribute syntax for use with the attribute type. If it is provided, then it should be given as a numeric OID. The syntax identifier may also optionally contain an integer value enclosed in curly braces directly following the OID (without any spaces between the last digit of the OID and the opening curly brace), which may be used to suggest a minimum upper bound on the length of values for attributes of that type. OpenDS does not enforce any maximum length restrictions for attribute values, so if a length is given then it will be ignored.

SINGLE-VALUE Flag #

An optional SINGLE-VALUE flag, which indicates that attributes of that type will only be allowed to have a single value in any entry in which they appear. If this flag is not present in the attribute type description, then attributes of that type will be allowed to have multiple distinct values in the same entry.

COLLECTIVE Flag #

An optional COLLECTIVE Flag, which indicates that the attributes of that type are assigned their values by virtue in their membership in some collection. Collective attributes are described in RFC 3671 (Collective Attributes in LDAP).

NO-USER-MODIFICATION Flag #

An optional NO-USER-MODIFICATION Flag, which indicates that values of attributes of that type cannot be modified by external clients (i.e., the values may only be modified by internal processing within the server).

Attribute Usage Flags #

An optional Attribute Usage Flags specification, which may indicate how the attribute type is to be used.

extensions for the attribute type #

An optional set of Extended Flags for the AttributeTypes.
  • X-ORIGIN -- Provides information about where the attribute type is defined (e.g., whether it came from a particular RFC or Internet Draft, etc.
  • X-SCHEMA-FILE -- Indicates which schema file contains the attribute type definition (this is generally used for internal purposes only and does not get exposed to clients).
  • X-APPROX -- Indicates which approximate matching rule should be used for the attribute type. If this is specified, then its value should be the name or OID of a registered approximate matching rule.

A AttributeTypes Example#

For example, the following is the attribute type description for the standard uid attribute type:
 
( 0.9.2342.19200300.100.1.1 NAME 'uid' EQUALITY caseIgnoreMatch 
SUBSTR caseIgnoreSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} 
X-ORIGIN 'RFC 1274' ) 

In this case, the OID is "0.9.2342.19200300.100.1.1". There is a single human-readable name of "uid". The caseIgnoreMatch rule should be used for equality matching, and the caseIgnoreSubstringsMatch rule should be used for substring matching. The attribute type uses the directory string syntax with a suggested minimum upper bound of 256 characters, and the attribute type definition was taken from RFC 1274. There is no description or superior type specified. The attribute type is not marked OBSOLETE, SINGLE-VALUE, COLLECTIVE, or NO-USER-MODIFICATION. There is no ordering matching rule specified, which means that the server will fall back on the default ordering rule used by the directory string syntax, and there is no X-APPROX extension to specify the approximate matching rule so the default approximate rule for the directory string syntax will be used there as well.

Attribute Type Inheritance #

As noted above, one attribute type can reference another as its superior class. This has two primary effects:
  • The matching rule and attribute syntax specifications from the superior attribute type may be inherited by the subordinate type if it does not override the superior definition. For example, if the superior attribute type uses the "IA5 String" syntax, then the subordinate attribute type will also use the IA5 String syntax unless its definition overrides that by specifying an alternate syntax. According to the specification in RFC 4512, section 2.5.1, an attribute type may have a different syntax than its superior type only if the syntax for the subordinate type is a refinement of (i.e., allows a subset of the values of) the syntax for the superior attribute type.
  • The OID and/or any of the human-readable names associated with the superior attribute type may be used to collectively reference all of the subordinate types. For example, the name attribute type is referenced as the superior type for the cn, sn, c, l, st, o, ou, title, givenName, initials, generationQualifier, and dmdName attribute types. Therefore, a filter of "(name=test)" should match an entry if any attribute with one of those types has a value of "test".

It is not allowed for a subordinate attribute type to have a different usage than its superior type. That is, if the superior type is "userApplications", then the subordinate type must also be "userApplications". Similarly, if a superior type is declared COLLECTIVE then the subtype must also be COLLECTIVE, but if the superior type is not COLLECTIVE, then the subordinate type must also not be COLLECTIVE.

My Attribute Template for this Wiki#

I try to implemente AttributeTypes definitions using a consistent manner:
!! Attribute Definition
The [{$pagename}] [AttributeTypes] is defined as:
* [OID] of [] 
* [NAME|Attribute-Name]: [{$pagename}]
* DESC: 
* [OBSOLETE flag] (only if present)
* [Supertype]: 
** (only if present)
* [EQUALITY]: []
* [ORDERING]: []
* SYNTAX: []
* [SINGLE-VALUE] (only if present)
* [NO-USER-MODIFICATION] (only if present)
* USAGE [DirectoryOperation] 
* [Extended Flags]: 
** (only if present)

More Information #

There might be more information for this subject on one of the following:

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-49) was last changed on 08-Aug-2017 09:36 by jim