draft-ietf-ldapbis-syntaxes-03.txt   draft-ietf-ldapbis-syntaxes-04.txt 
INTERNET-DRAFT K. Dally, Editor
Intended Category: Standard Track The MITRE Corp.
Expires: 4 May 2003 S. Legg
Obsoletes: RFC 2252, RFC 2256 ADACEL
4 November 2002
LDAP: Syntaxes INTERNET-DRAFT S. Legg, Editor
<draft-ietf-ldapbis-syntaxes-03> draft-ietf-ldapbis-syntaxes-04.txt Adacel Technologies
Intended Category: Standard Track K. Dally
Obsoletes: RFC 2252, RFC 2256 The MITRE Corp.
20 December 2002
LDAP: Syntaxes and Matching Rules
Copyright (C) The Internet Society (2002). All Rights Reserved.
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. all provisions of Section 10 of RFC 2026.
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as a Standard Track document.
Distribution of this memo is unlimited. Technical discussion of
this document will take place on the IETF LDAP Revision Working
Group (LDAPbis) mailing list <ietf-ldapbis@openldap.org>. Please
send editorial comments directly to the editor <kdally@mitre.org>.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as
Drafts. Internet-Drafts are draft documents valid for a maximum of Internet-Drafts.
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts as Internet-Drafts are draft documents valid for a maximum of six months
reference material or to cite them other than as "work in progress." and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. The list of http://www.ietf.org/ietf/1id-abstracts.txt
Internet-Draft Shadow Directories can be accessed at
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright 2002, The Internet Society. All Rights Reserved. This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as a Standard Track document.
Distribution of this document is unlimited. Technical discussion of
this document should take place on the IETF LDAP Revision Working
Group (LDAPbis) mailing list <ietf-ldapbis@openldap.org>. Please
send editorial comments directly to the editor
<steven.legg@adacel.com.au>.
Please see the Copyright section near the end of this document for This Internet-Draft expires on 20 June 2003.
more information.
Abstract Abstract
The Lightweight Directory Access Protocol (LDAP) [Protocol] provides Each attribute stored in a Lightweight Directory Access Protocol
for exchanging AttributeValue fields in protocol. This document (LDAP) directory, and whose values may be transfered in the LDAP
defines a set of syntaxes for LDAP, rules by which attribute values protocol, has a defined syntax which constrains the structure and
of these syntaxes are represented in the LDAP protocol, and the format of its values. The comparison semantics for values of a
matching rules which specify how values are compared. Also, this syntax are not part of the syntax definition but are instead provided
document indicates the syntax support requirements on LDAP servers. through separately defined matching rules. Matching rules specify an
The syntaxes and matching rules defined in this document are used in argument, an assertion value, which also has a defined syntax. This
schema definition documents to specify attribute types. document defines a base set of syntaxes and matching rules for use in
defining attributes for LDAP directories.
[Editor's note: This document is a modified version of parts of
RFC 2252 and RFC 2256, in order to bring then up to date. This
action is part of the maintenance activity that is needed in order
to progress LDAP (v3) to Draft Standard. The changes are described
in Annex C of this document. Open items are listed in Annex B.
End of Editor's note]
Table of Contents
Status of this Memo....................................................1
Abstract...............................................................2
1. Overview...........................................................5
2. General Issues.....................................................5
2.1 Notation..........................................................5
2.2 Syntaxes..........................................................5
2.2.1 LDAP-Specific Encodings.........................................6
2.2.2 Syntaxes Implementation Status..................................6
2.2.3 Syntax Object Identifiers.......................................6
2.2.4 Syntax Description..............................................6
2.3 Matching Rules....................................................7
2.3.1 Matching Rules Implementation Status............................7
2.3.2 Matching Rule Description.......................................7
3. Syntaxes...........................................................8
3.1 Attribute Type Description........................................8
3.2 Bit String........................................................8
3.3 Boolean...........................................................8
3.4 Country String....................................................9
3.5 Delivery Method...................................................9
3.6 Directory String..................................................9
3.7 DIT Content Rule Description.....................................10
3.8 DIT Structure Rule Description...................................11
3.9 DN...............................................................11
3.10 Enhanced Guide...................................................12
3.11 Facsimile Telephone Number.......................................12
3.12 Fax..............................................................13
3.13 Generalized Time.................................................13
3.14 Guide............................................................13
3.15 IA5 String.......................................................14
3.16 Integer..........................................................14
3.17 JPEG.............................................................14
3.18 LDAP Syntax Description..........................................15
3.19 Matching Rule Description........................................15
3.20 Matching Rule Use Description....................................15
3.21 MHS OR Address...................................................15
3.22 Name and Optional UID............................................16
3.23 Name Form Description............................................16
3.24 Numeric String...................................................16
3.25 Object Class Description.........................................17
3.26 Octet String.....................................................17
3.27 OID..............................................................17
3.28 Other Mailbox....................................................18
3.29 Postal Address...................................................18
3.30 Presentation Address.............................................19
3.31 Printable String.................................................21
3.32 Substring Assertion .......................................21
3.33 Telephone Number.................................................21
3.34 Teletex Terminal Identifier......................................22
3.35 Telex Number.....................................................22
3.36 UTC Time.........................................................23
4. Matching Rules....................................................23
4.1 bitStringMatch...................................................23
4.2 caseExactIA5Match................................................23
4.3 caseIgnoreIA5Match...............................................24
4.4 caseIgnoreListMatch..............................................24
4.5 caseIgnoreMatch..................................................24
4.6 caseIgnoreOrderingMatch..........................................24
4.7 caseIgnoreSubstringsMatch........................................25
4.8 distinguishedNameMatch...........................................25
4.9 generalizedTimeMatch.............................................25
4.10 generalizedTimeOrderingMatch.....................................25
4.11 integerFirstComponentMatch.......................................25
4.12 integerMatch.....................................................26
4.13 numericStringMatch...............................................26
4.14 numericStringSubstringsMatch.....................................26
4.15 objectIdentifierFirstComponentMatch..............................26
4.16 objectIdentifierMatch............................................26
4.17 octetStringMatch.................................................27
4.18 presentationAddressMatch.........................................27
4.19 protocolInformationMatch.........................................27
4.20 telephoneNumberMatch.............................................28
4.21 telephoneNumberSubstringsMatch...................................28
4.22 uniqueMemberMatch................................................28
5. Security Considerations...........................................28
5.1 Disclosure.......................................................28
5.2 Security Information Syntaxes....................................28
5.3 Securing the Directory...........................................29
6. Acknowledgements..................................................29
7. Authors' Addresses................................................29
8. References........................................................30
8.1 Normative........................................................30
8.2 Informative......................................................31
9. Full Copyright Statement..................... .....................31
Annex A Object Identifiers for Syntaxes..............................32 1. Table of Contents
Annex B Topics to be Addressed in This Document......................33
Annex C Change Log...................................................34
1. Overview Abstract ...................................................... 1
1. Table of Contents ............................................. 3
2. Introduction .................................................. 4
3. Conventions ................................................... 5
4. Syntaxes ...................................................... 5
4.1 General Considerations .................................... 5
4.2 Common Definitions ........................................ 6
4.3 Syntax Definitions ........................................ 7
4.3.1 Attribute Type Description ........................... 7
4.3.2 Bit String ........................................... 7
4.3.3 Boolean .............................................. 8
4.3.4 Country String ....................................... 8
4.3.5 Delivery Method ...................................... 9
4.3.6 Directory String ..................................... 9
4.3.7 DIT Content Rule Description ......................... 10
4.3.8 DIT Structure Rule Description ....................... 11
4.3.9 DN ................................................... 11
4.3.10 Enhanced Guide ...................................... 12
4.3.11 Facsimile Telephone Number .......................... 13
4.3.12 Fax ................................................. 13
4.3.13 Generalized Time .................................... 14
4.3.14 Guide ............................................... 15
4.3.15 IA5 String .......................................... 15
4.3.16 Integer ............................................. 16
4.3.17 JPEG ................................................ 16
4.3.18 LDAP Syntax Description ............................. 16
4.3.19 Matching Rule Description ........................... 17
4.3.20 Matching Rule Use Description ....................... 17
4.3.21 Name and Optional UID ............................... 18
4.3.22 Name Form Description ............................... 18
4.3.23 Numeric String ...................................... 19
4.3.24 Object Class Description ............................ 19
4.3.25 Octet String ........................................ 20
4.3.26 OID ................................................. 20
4.3.27 Other Mailbox ....................................... 20
4.3.28 Postal Address ...................................... 21
4.3.29 Printable String .................................... 22
4.3.30 Substring Assertion ................................. 22
4.3.31 Telephone Number .................................... 23
4.3.32 Teletex Terminal Identifier ......................... 24
4.3.33 Telex Number ........................................ 24
4.3.34 UTC Time ............................................ 25
5. Matching Rules ................................................ 26
5.1 General Considerations .................................... 26
5.2 Matching Rule Definitions ................................. 27
5.2.1 bitStringMatch ....................................... 27
5.2.2 caseExactIA5Match .................................... 28
5.2.3 caseIgnoreIA5Match ................................... 28
5.2.4 caseIgnoreIA5SubstringsMatch ......................... 29
5.2.5 caseIgnoreListMatch .................................. 29
5.2.6 caseIgnoreMatch ...................................... 30
5.2.7 caseIgnoreOrderingMatch .............................. 30
5.2.8 caseIgnoreSubstringsMatch ............................ 31
5.2.9 distinguishedNameMatch ............................... 31
5.2.10 generalizedTimeMatch ................................ 32
5.2.11 generalizedTimeOrderingMatch ........................ 32
5.2.12 integerFirstComponentMatch .......................... 32
5.2.13 integerMatch ........................................ 33
5.2.14 numericStringMatch .................................. 33
5.2.15 numericStringSubstringsMatch ........................ 34
5.2.16 objectIdentifierFirstComponentMatch ................. 34
5.2.17 objectIdentifierMatch ............................... 35
5.2.18 octetStringMatch .................................... 35
5.2.19 telephoneNumberMatch ................................ 36
5.2.20 telephoneNumberSubstringsMatch ...................... 36
5.2.21 uniqueMemberMatch ................................... 37
6. Security Considerations ....................................... 37
7. Acknowledgements .............................................. 38
8. IANA Considerations ........................................... 38
9. Normative References .......................................... 39
10. Informative References ....................................... 40
11. Authors' Addresses ........................................... 41
12. Copyright Notice ............................................. 41
Appendix A. Summary of Syntax Object Identifiers ................. 42
Appendix B. Changes from RFC 2252 & RFC 2256 ..................... 43
This document defines part of the framework for developing schemas 2. Introduction
for directories accessible via the Lightweight Directory Access
Protocol (LDAP) [Protocol].
Schema is the collection of attribute type definitions, object class Each attribute stored in a Lightweight Directory Access Protocol
definitions and other information which specify the entries and their (LDAP) directory [ROADMAP], and whose values may be transfered in the
contents that a server holds. A server uses schema to determine how LDAP protocol [PROT], has a defined syntax (i.e. data type) which
to match a filter or attribute value assertion (in a compare constrains the structure and format of its values. The comparison
operation) against the attributes of an entry, and whether to permit semantics for values of a syntax are not part of the syntax
add and modify operations. This document specifies syntaxes, which definition but are instead provided through separately defined
are used in defining attribute types, and matching rules. matching rules. Matching rules specify an argument, an assertion
value, which also has a defined syntax. This document defines a base
set of syntaxes and matching rules for use in defining attributes for
LDAP directories.
Therefore, Section 2 states the general requirements and notation Readers are advised to familiarize themselves with the Directory
for definition of syntaxes and matching rules. Information Models [MODELS] before reading the rest of this document.
Section 4 provides definitions for the base set of LDAP syntaxes.
Section 5 provides definitions for the base set of matching rules for
LDAP.
Section 3 lists syntaxes and section 4 contains matching rules. This document is a integral part of the LDAP technical specification
[ROADMAP] which obsoletes the previously defined LDAP technical
specification [RFC3377] in its entirety.
Additional documents define schemas for representing real-world Sections 4, 5 and 7 of RFC 2252 [RFC2252] are obsoleted by [MODELS].
objects as directory entries. See [Models], sections 2.4.1 and 2.6 The remainder of RFC 2252 is obsoleted by this document. Sections 6
and [Schema] for the definitions of user objects and attributes from and 8 of RFC 2256 are obsoleted by this document. The changes from
[X.501], [X.520], and [X.521]. RFC 2252 and RFC 2256 [RFC2256] are described in Appendix B of this
document.
2. General Issues 3. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119]. document are to be interpreted as described in RFC 2119 [KEYWORD].
This document describes the syntaxes of data conveyed in an
Internet protocol.
Implementors are strongly advised to first read the description of
how schema is represented in X.501 [X.501] before reading the rest
of this document.
2.1 Notation
For the purposes of defining attribute syntaxes and matching rules,
Augmented Backus-Naur Form (ABNF) is used. The ABNF productions
used in this document are used by other documents in the LDAP set
and are listed in [Models].
The schema definitions provided in this document are line-wrapped
for readability.
In addition, the following ABNF productions are used in this Syntax definitions are written according to the <SyntaxDescription>
document: ABNF [ABNF] rule specified in [MODELS], and matching rule definitions
are written according to the <MatchingRuleDescription> ABNF rule
specified in [MODELS], except that the syntax and matching rule
definitions provided in this document are line-wrapped for
readability. When such definitions are transfered as attribute
values in the LDAP protocol (e.g. as values of the ldapSyntaxes and
matchingRules attributes [MODELS] respectively) then those values
would not contain line breaks.
2.2 Syntaxes 4. Syntaxes
This section defines general requirements for LDAP attribute Syntax definitions constrain the structure of attribute values stored
syntaxes. All documents defining attribute syntaxes for use with in an LDAP directory, and determine the representation of attribute
LDAP are expected to conform to these requirements. Syntaxes are and assertion values transfered in the LDAP protocol.
also defined for matching rules whose assertion value syntax is
different from the attribute value syntax.
2.2.1 LDAP-Specific Encodings Syntaxes that are required for directory operation, or that are in
common use, are specified in this section. Servers SHOULD recognize
all the syntaxes listed in this document, but are NOT REQUIRED to
otherwise support them, and MAY recognise or support other syntaxes.
However, the definition of additional arbitrary syntaxes is
discouraged since it will hinder interoperability. Client and server
implementations typically do not have the ability to dynamically
recognize new syntaxes.
In [Protocol], the encoding of the LDAP protocol is specified. The 4.1 General Considerations
protcol encapsulates values of attributes in many places. In this The description of each syntax specifies how attribute or assertion
specification, the encoding of the values is specified, as part of values conforming to the syntax are to be represented when transfered
each syntax definition. These value encoding rules are termed in the LDAP protocol [PROT]. This representation is referred to as
"LDAP-specific encodings". The LDAP-specific encoding of a value is the LDAP-specific encoding to distinguish it from other methods of
what is transmitted in the protocol. encoding attribute values (e.g. the BER encoding [BER] used by X.500
[X.500] directories).
The LDAP-specific encoding of a given attribute syntax always The LDAP-specific encoding of a given attribute syntax always
produces octet-aligned values. To the greatest extent possible, the produces octet-aligned values. To the greatest extent possible,
LDAP-specific encoding of a value is supposed to be usable for encoding rules for LDAP syntaxes should produce character strings
display purposes. In particular, encoding rules for attribute
syntaxes defining non-binary values are supposed to produce strings
that can be displayed with little or no translation by clients that can be displayed with little or no translation by clients
implementing LDAP. There are a few cases (e.g., audio) however, implementing LDAP. However, clients MUST NOT assume that the
when it is not sensible to produce a human-readable representation. LDAP-specific encoding of a value of an unrecognized syntax is a
human-readable character string. There are a few cases (e.g. the
2.2.2 Syntaxes Implementation Status JPEG syntax) when it is not reasonable to produce a human-readable
representation.
Clients and servers need not implement all the syntaxes listed in
section 3, and MAY implement other syntaxes.
Clients MUST NOT assume that the LDAP-specific encoding of a value Each LDAP syntax is uniquely identified with an object identifier
of an unrecognized syntax is a human-readable character string. [ASN.1] represented in the dotted-decimal format (short descriptive
names are not defined for syntaxes). These object identifiers are
not intended to be displayed to users. The object identifiers for
the syntaxes defined in this document are summarized in Appendix A.
Other documents define additional attribute syntaxes. However, the A suggested minimum upper bound on the number of characters in an
definition of additional arbitrary syntaxes is strongly deprecated attribute value with a string-based syntax, or the number of octets
since it will hinder interoperability. Today's client and server in a value for all other syntaxes, MAY be indicated by appending the
implementations generally do not have the ability to dynamically bound inside of curly braces following the syntax's OBJECT IDENTIFIER
recognize new syntaxes. in an attribute type definition (see the <noidlen> rule in [MODELS]).
Such a bound is not considered part of the syntax identifier.
2.2.3 Syntax Object Identifiers For example, "1.3.6.1.4.1.1466.115.121.1.15{64}" in an attribute
definition suggests that the directory server will allow a value of
the attribute to be up to 64 characters long, although it may allow
longer character strings. Note that a single character of the
Directory String syntax can be encoded in more than one octet since
UTF-8 [UTF-8] is a variable-length encoding. Therefore a 64
character string may be more than 64 octets in length.
In an LDAP schema, a syntax is named by the Object Identifier (OID) 4.2 Common Definitions
assigned to it.
Syntaxes that are currently in use in the user schema specification The following ABNF rules are used in a number of the syntax
[Schema] and the models specification [Models] are specified in this definitions in Section 4.3.
document in section 3. The object identifiers assigned to these
syntaxes are listed in Annex A.
2.2.4 Syntax Description PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN /
PLUS / COMMA / HYPHEN / DOT / EQUALS /
SLASH / COLON / QUESTION / SPACE
PrintableString = 1*PrintableCharacter
IA5String = *(%x00-7F)
HEX-DIGIT = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
; N.B. allows upper and lower case
SLASH = %x2F ; forward slash ("/")
COLON = %x3A ; colon (":")
QUESTION = %x3F ; question mark ("?")
The SyntaxDescription ABNF specified in [Models] is the method used The <OCTET>, <ALPHA>, <DIGIT>, <SQUOTE>, <LPAREN>, <RPAREN>, <PLUS>,
in this document to define the values for each syntax. <COMMA>, <HYPHEN>, <DOT>, <EQUALS> and <SPACE> rules are defined in
[MODELS].
For example, the syntax description of the INTEGER syntax for whole 4.3 Syntax Definitions
number values is:
( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' ) 4.3.1 Attribute Type Description
2.3 Matching Rules A value of the Attribute Type Description syntax is the definition of
an attribute type. The LDAP-specific encoding of a value of this
syntax is defined by the <AttributeTypeDescription> rule in [MODELS].
For example, the following definition of the createTimestamp
attribute type from [MODELS] is also a value of the Attribute Type
Description syntax (note: line breaks have been added for readability
- they are not part of the value when transfered in protocol).
The matching rules specified in this document are defined in ( 2.5.18.1 NAME 'createTimestamp'
Section 4. EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
Matching rules are used by servers to compare attribute values The LDAP definition for the Attribute Type Description syntax is:
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 the user schema [Schema] have an ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' )
equality matching rule defined.
...An OID is assigned to a matching rule when it is defined. A This syntax corresponds to the AttributeTypeDescription ASN.1 type
matching rule definition ought not be changed without having a new from [X.501].
OID assigned to it.
2.3.1 Matching Rules Implementation Status 4.3.2 Bit String
Servers which support matching rules and the extensibleMatch SHOULD A value of the Bit String syntax is a sequence of binary digits. The
implement all the matching rules in section 4. LDAP-specific encoding of a value of this syntax is defined by the
following ABNF:
Servers MUST publish in the matchingRules attribute, the definitions BitString = SQUOTE *binary-digit SQUOTE "B"
of matching rules referenced by values of the attributeTypes and binary-digit = "0" / "1"
matchingRuleUse attributes in the same subschema entry. Other The <SQUOTE> rule is defined in [MODELS].
unreferenced matching rules MAY be published in the matchingRules
attribute.
If the server supports the extensibleMatch, then the server MAY use Example:
the matchingRuleUse attribute to indicate the applicability of '0101111101'B
selected matching rules to designated attribute types in an
extensibleMatch.
2.3.2 Matching Rule Description The LDAP definition for the Bit String syntax is:
The SyntaxDescription ABNF specified in [Models] is the method used ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' )
The Matching Rule descriptions are specified according to the
MatchingRule ABNF specified in [Models].
3. Syntaxes This syntax corresponds to the BIT STRING ASN.1 type from [ASN.1].
3.1 Attribute Type Description 4.3.3 Boolean
A value in this syntax is a definition of an attribute type A value of the Boolean syntax is one of the Boolean values, true or
according to the ABNF given [Models]. The LDAP-specific encoding is false. The LDAP-specific encoding of a value of this syntax is
the character codes in UTF-8 which correspond to the characters in defined by the following ABNF:
the definition.
This syntax is the form in which schema attribute types are Boolean = "TRUE" / "FALSE"
published in the directory in a subentry. The following syntax
description gives the OID assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' ) The LDAP definition for the Boolean syntax is:
For example, this is the definition from [User] of the ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' )
businessCategory attribute type:
( 2.5.4.15 NAME 'businessCategory' This syntax corresponds to the BOOLEAN ASN.1 type from [ASN.1].
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
The syntax type for the businessCategory Attribute Type is Directory 4.3.4 Country String
String.
This example definition is a value of the Attribute Type Description A value of the Country String syntax is one of the two-character
syntax. The LDAP-specific encoding of this value is the definition codes from ISO 3166 [ISO3166] for representing a country. The
itself. LDAP-specific encoding of a value of this syntax is defined by the
following ABNF:
3.2 Bit String CountryString = 2(PrintableCharacter)
A value in this syntax is a value of the BIT STRING data type from The <PrintableCharacter> rule is defined in Section 4.2.
ASN.1 [X.680]. The following syntax description gives the OID
assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' ) Examples:
US
AU
The LDAP-specific encoding of a value is the following ABNF: The LDAP definition for the Country String syntax is:
bitstring = SQUOTE *binary-digit SQUOTE "B" ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' )
binary-digit = "0" / "1" This syntax corresponds to the following ASN.1 type from [X.520]:
Example: '0101111101'B PrintableString (SIZE (2)) -- IS 3166 codes only
3.3 Boolean 4.3.5 Delivery Method
A value in this syntax is a value of the BOOLEAN data type from A value of the Delivery Method syntax is a sequence of items that
ASN.1 [X.680]. That is, there are exactly two values: one value indicate, in preference order, the service(s) by which an entity is
representing logically true, and the other representing logically willing and/or capable of receiving messages. The LDAP-specific
false. The following syntax description gives the OID assigned to encoding of a value of this syntax is defined by the following ABNF:
this syntax:
( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' ) DeliveryMethod = pdm *( WSP DOLLAR WSP pdm )
The LDAP-specific encoding of a value is the following ABNF: pdm = "any" / "mhs" / "physical" / "telex" / "teletex" /
"g3fax" / "g4fax" / "ia5" / "videotex" / "telephone"
boolean = "TRUE" / "FALSE" The <WSP> and <DOLLAR> rules are defined in [MODELS].
3.4 Country String Example:
telephone $ videotex
A value in this syntax is two ASN.1 [X.680] printable string characters The LDAP definition for the Delivery Method syntax is:
representing a country. The permitted values are as listed in
ISO 3166 [ISO3166]. The following syntax description gives the OID
assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' ) ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' )
The LDAP-specific encoding of a value is the following ABNF: This syntax corresponds to the following ASN.1 type from [X.520]:
CountryString = ALPHA ALPHA SEQUENCE OF INTEGER {
any-delivery-method (0),
mhs-delivery (1),
physical-delivery (2),
telex-delivery (3),
teletex-delivery (4),
g3-facsimile-delivery (5),
g4-facsimile-delivery (6),
ia5-terminal-delivery (7),
videotex-delivery (8),
telephone-delivery (9) }
Example: US 4.3.6 Directory String
3.5 Delivery Method A value of the Directory String syntax is a string of one or more
arbitrary characters from the Universal Character Set (UCS) [UCS]. A
zero length character string is not permitted. The LDAP-specific
encoding of a value of this syntax is the UTF-8 encoding [UTF-8] of
the character string. Such encodings conform to the following ABNF:
A value in this syntax is a set of the ASN.1 [X.680] enumerated DirectoryString = 1*UTF8
INTEGER values that indicates, in preference order, the service(s) The <UTF8> rule is defined in [MODELS].
by which the user, represented by the entry, is willing and/or
capable of receiving messages.
The following syntax description gives the OID assigned to this Example:
syntax: This is a value of Directory String containing #!%#@.
( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' ) Servers and clients MUST be prepared to receive arbitrary UCS code
points, including code points outside the range of printable ASCII
and code points not presently assigned to any character.
The LDAP-specific encoding of a value is the following ABNF: Attribute type definitions using the Directory String syntax should
not restrict the format of Directory String values, e.g. by requiring
that the character string conforms to specific patterns described by
ABNF. A new syntax should be defined in such cases.
delivery-value = pdm / ( WSP pdm SP DOLLAR SP delivery-value ) The LDAP definition for the Directory String syntax is:
pdm = "any" / "mhs" / "physical" / "telex" / "teletex" / ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )
"g3fax" / "g4fax" / "ia5" / "videotex" / "telephone"
Example: telephone $ videotex This syntax corresponds to the DirectoryString parameterized ASN.1
type from [X.520].
3.6 Directory String The DirectoryString ASN.1 type allows a choice between the
TeletexString, PrintableString or UniversalString ASN.1 types from
[ASN.1]. However, note that the chosen alternative is not indicated
in the LDAP-specific encoding of a Directory String value.
A value in this syntax is a value of one of the TeletexString, Implementations which convert Directory String values from the
PrintableString or UniversalString data types from ASN.1 [X.680]. LDAP-specific encoding to the BER encoding used by X.500 must choose
The minimum length of a Directory String value is one character, that an alternative that permits the particular characters in the string,
is, the string cannot be 'empty'. The following syntax description and must convert the characters from the UTF-8 encoding into the
gives the OID assigned to this syntax: character encoding of the chosen alternative.
( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' ) When converting Directory String values from the BER encoding to the
The LDAP-specific encoding of a value is the character string itself. LDAP-specific encoding the characters must be converted from the
character encoding of the chosen alternative into the UTF-8 encoding.
Note: The form of DirectoryString is not indicated in protocol. 4.3.7 DIT Content Rule Description
Servers which convert to DAP MUST choose an appropriate form.
Servers MUST NOT reject values merely because they contain legal
Unicode characters outside of the range of printable ASCII.
Servers and clients MUST be prepared to receive arbitrary Unicode A value of the DIT Content Rule Description syntax is the definition
characters, including characters not presently assigned to any of a DIT content rule. The LDAP-specific encoding of a value of this
character set. syntax is defined by the <DITContentRuleDescription> rule in
[MODELS].
Example: Example:
This is a string of DirectoryString containing #!%#@. ( 2.5.6.4 DESC 'content rule for organization'
NOT ( x121Address $ telexNumber ) )
For characters in the PrintableString form, the value in the native Note: a line break has been added for readability - it is not part of
LDAP encoding is the value itself. the value.
If the string is in the TeletexString form, then the characters are The LDAP definition for the DIT Content Rule Description syntax is:
transliterated to their equivalents in UniversalString, and encoded
in UTF-8 [RFC2044].
If the string is in the UniversalString or BMPString forms [ISO10646], ( 1.3.6.1.4.1.1466.115.121.1.16
UTF-8 is the LDAP-specific encoding. DESC 'DIT Content Rule Description' )
3.7 DIT Content Rule Description This syntax corresponds to the DITContentRuleDescription ASN.1 type
from [X.501].
The following syntax description gives the OID assigned to this 4.3.8 DIT Structure Rule Description
syntax:
( 1.3.6.1.4.1.1466.115.121.1.16 DESC 'DIT Content Rule A value of the DIT Structure Rule Description syntax is the
Description' ) definition of a DIT structure rule. The LDAP-specific encoding of a
value of this syntax is defined by the <DITStructureRuleDescription>
rule in [MODELS].
This syntax is the form in which schema content rules are published Example:
in the directory in a subentry. ( 2 DESC 'organization structure rule' FORM 2.5.15.3 )
A value in this syntax is a definition of a DIT content rule The LDAP definition for the DIT Structure Rule Description syntax is:
according to the ABNF in [Models].
The native LDAP encoding of a value is the character string ( 1.3.6.1.4.1.1466.115.121.1.17
(DirectoryString) itself. DESC 'DIT Structure Rule Description' )
Note: The form of DirectoryString is not indicated in protocol, This syntax corresponds to the DITStructureRuleDescription ASN.1 type
unless the ;binary option is used (see [Prot]). Servers which from [X.501].
convert to DAP MUST choose an appropriate form. Servers MUST NOT
reject values merely because they contain legal Unicode characters
outside of the range of printable ASCII.
Servers and clients MUST be prepared to receive arbitrary Unicode 4.3.9 DN
characters, including characters not presently assigned to any
character set.
Example: A value of the DN syntax is the (purported) distinguished name of an
This is a string of DirectoryString containing #!%#@. entry [MODELS]. The LDAP-specific encoding of a value of this syntax
is defined by the <distinguishedName> rule in [LDAPDN].
For characters in the PrintableString form, the value in the native Examples (from [LDAPDN]):
LDAP encoding is the value itself. UID=jsmith,DC=example,DC=net
OU=Sales+CN=J. Smith,DC=example,DC=net
CN=John Smith\, III,DC=example,DC=net
CN=Before\0dAfter,DC=example,DC=net
1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com
CN=Lu\C4\8Di\C4\87
If it is in the TeletexString form, then the characters are The LDAP definition for the DN syntax is:
transliterated to their equivalents in UniversalString, and encoded
in UTF-8 [UTF-8].
If it is in the UniversalString or BMPString forms [ISO10646], UTF-8 ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' )
is the native LDAP encoding. The DN syntax corresponds to the DistinguishedName ASN.1 type from
[X.501]. Note that a BER encoded distinguished name (as used by
X.500) re-encoded into the LDAP-specific encoding is not necessarily
reversible to the original BER encoding since the chosen string type
in any DirectoryString components of the distinguished name is not
indicated in the LDAP-specific encoding of the distinguished name
(see Section 4.3.6).
3.8 DIT Structure Rule Description 4.3.10 Enhanced Guide
The following syntax description gives the OID assigned to this A value of the Enhanced Guide syntax suggests criteria, which consist
syntax: of combinations of attribute types and filter operators, to be used
in constructing filters to search for entries of particular object
classes. The Enhanced Guide syntax improves upon the Guide syntax by
allowing the recommended depth of the search to be specified.
( 1.3.6.1.4.1.1466.115.121.1.17 DESC 'DIT Structure Rule The LDAP-specific encoding of a value of this syntax is defined by
Description' ) the following ABNF:
This syntax is the form in which schema structure rules are published EnhancedGuide = object-class SHARP WSP criteria WSP
in the directory in a subentry. SHARP WSP subset
object-class = WSP oid WSP
subset = "baseobject" / "oneLevel" / "wholeSubtree"
A value in the DIT Structure Rule Description syntax is a definition criteria = and-term *( BAR and-term )
of a schema Structure Rule according to the ABNF in [Models]. and-term = term *( AMPERSAND term )
term = EXCLAIM term /
attributetype DOLLAR match-type /
LPAREN criteria RPAREN /
true /
false
match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX"
true = "?true"
false = "?false"
BAR = %x7C ; vertical bar ("|")
AMPERSAND = %x26 ; ampersand ("&")
EXCLAIM = %x21 ; exclamation mark ("!")
The LDAP-specific encoding is the character codes in UTF-8 [UTF-8] The <SHARP>, <WSP>, <oid>, <LPAREN>, <RPAREN>, <attributetype> and
which correspond to the characters in the structure rule definition. <DOLLAR> rules are defined in [MODELS].
3.9 DN The LDAP definition for the Enhanced Guide syntax is:
A value in the Distinguished Name syntax is a structured set of the ( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' )
ASN.1 [X.680] data types that are included in the DirectoryString
syntax. The following syntax description gives the OID assigned to
this syntax:
( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' ) Example:
The LDAP-specific encoding of a value is defined in [LDAPDN]. Note person#(sn$EQ)#oneLevel
that the LDAP-specific encoding is not reversible to the original BER
encoding used in X.500 for Distinguished Names, as the CHOICE of any
DirectoryString element in an RDN is not evident in the LDAP-specific
encoding.. See the note in section 3.7.
Examples (from [LDAPDN]): The Enhanced Guide syntax corresponds to the EnhancedGuide ASN.1 type
from [X.520]. The EnhancedGuide type references the Criteria ASN.1
type, also from [X.520]. The <true> rule above represents an empty
"and" expression in a value of the Criteria type. The <false> rule
above represents an empty "or" expression in a value of the Criteria
type.
CN=Steve Kille,O=Isode Limited,C=GB 4.3.11 Facsimile Telephone Number
OU=Sales+CN=J. Smith,O=Widget Inc.,C=US A value of the Facsimile Telephone Number syntax is a subscriber
number of a facsimile device on the public switched telephone
network. The LDAP-specific encoding of a value of this syntax is
defined by the following ABNF:
CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB fax-number = telephone-number *( DOLLAR fax-parameter )
telephone-number = PrintableString
fax-parameter = "twoDimensional" /
"fineResolution" /
"unlimitedLength" /
"b4Length" /
"a3Width" /
"b4Width" /
"uncompressed"
CN=Before\0DAfter,O=Test,C=GB The <telephone-number> is a string of printable characters that
1.1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB complies with the internationally agreed format for representing
international telephone numbers [E.123]. The <PrintableString> rule
is defined in Section 4.2. The <DOLLAR> rule is defined in [MODELS].
SN=Lu\C4\8Di\C4\87 The LDAP definition for the Facsimile Telephone Number syntax is:
3.10 Enhanced Guide ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number')
A value in the Enhanced Guide syntax is the matching criteria and The Facsimile Telephone Number syntax corresponds to the
scope of operation in an Enhanced Filter. FacsimileTelephoneNumber ASN.1 type from [X.520].
The following syntax description gives the OID assigned to this syntax: 4.3.12 Fax
( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' ) A value of the Fax syntax is an image which is produced using the
Group 3 facsimile process [FAX] to duplicate an object, such as a
memo. The LDAP-specific encoding of a value of this syntax is the
string of octets for a Group 3 Fax image as defined in [FAX].
The LDAP-specific encoding of a value is defined by the The LDAP definition for the Fax syntax is:
following ABNF:
EnhancedGuide = SP oid WSP SHARP WSP criteria WSP SHARP ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' )
WSP subset
subset = "baseobject" / "oneLevel" / "wholeSubtree" The ASN.1 type corresponding to the Fax syntax is defined as follows,
assuming EXPLICIT TAGS:
criteria = or-term / LPAREN or-term RPAREN Fax ::= CHOICE {
g3-facsimile [3] G3FacsimileBodyPart
}
or-term = and-term *( "|" and-term ) The G3FacsimileBodyPart ASN.1 type is defined in [X.420].
and-term = not-term *( "&" not-term ) 4.3.13 Generalized Time
not-term = "!" not-term / A value of the Generalized Time syntax is a character string
attributetype DOLLAR match-type / representing a date and time. The LDAP-specific encoding of a value
LPAREN or-term RPAREN / of this syntax is a restriction of the format defined in [ISO8601],
"?true" / ; and is described by the following ABNF:
"?false"
match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX" century = 2(%x30-39) ; "00" to "99"
year = 2(%x30-39) ; "00" to "99"
month = ( %x30 %x31-39 ) ; "01" (January) to "09"
/ ( %x31 %x30-32 ) ; "10" to "12"
day = ( %x30 %x31-39 ) ; "01" to "09"
/ ( %x31-32 %x30-39 ) ; "10" to "29"
/ ( %x32 %x30-31 ) ; "30" to "31"
hour = ( %x30-31 %x30-39 ) / ( %x32 %x30-33 ) ; "00" to "23"
minute = %x30-36 %x30-39 ; "00" to "59"
second = %x30-36 %x30-39 ; "00" to "59"
The ?true term alternative represents an empty "and" in the Criteria. GeneralizedTime = century year month day hour
The ?false alternative represents an empty "or" in the Criteria. [ minute [ second ] ] [ fraction ]
g-time-zone
fraction = ( DOT / COMMA ) 1*(%x30-39)
g-time-zone = %x5A ; "Z"
/ g-differential
g-differential = ( MINUS / PLUS ) hour [ minute ]
MINUS = %x2D ; minus sign ("-")
Example: The <DOT>, <COMMA> and <PLUS> rules are defined in [MODELS].
person#(sn)#oneLevel The time value represents coordinated universal time (equivalent to
Greenwich Mean Time) if the "Z" form of <g-time-zone> is used,
otherwise the value represents a local time in the time zone
indicated by <g-differential>. In the latter case, coordinated
universal time can be calculated by subtracting the differential from
the local time. The "Z" form of <g-time-zone> SHOULD be used in
preference to <g-differential>.
3.11 Facsimile Telephone Number Examples:
199412161032Z
199412160532-0500
A value in the Facsimile Telephone Number syntax is a subscriber Both example values represent the same coordinated universal time:
number on the (public) telephone network of a facsimile device. The 40:32 am, December 16, 1994.
telephone number is a character string based on E.123 [E.123]. The
character string type is the PrintableString data type from
ASN.1 [X.680]. The following syntax description gives the OID
assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number') The LDAP definition for the Generalized Time syntax is:
The LDAP-specific encoding of a value is defined by the
following ABNF:
fax-number = printablestring [ "$" faxparameters ] ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' )
; telephone number, possibly followed by facsimile
; parameters
printablestring = 1*p This syntax corresponds to the GeneralizedTime ASN.1 type from
[ASN.1], with the constraint that local time without a differential
SHALL NOT be used.
p = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN / PLUS / COMMA / 4.3.14 Guide
HYPHEN / DOT / EQUALS / SLASH / COLON / QUESTION / SPACE
faxparameters = faxparm / ( faxparm "$" faxparameters ) A value of the Guide syntax suggests criteria, which consist of
combinations of attribute types and filter operators, to be used in
constructing filters to search for entries of particular object
classes. The Guide syntax is obsolete and should not be used for
defining new attribute types.
faxparm = "twoDimensional" / "fineResolution" / "unlimitedLength" The LDAP-specific encoding of a value of this syntax is defined by
/ "b4Length" / "a3Width" / "b4Width" / "uncompressed" the following ABNF:
3.12 Fax Guide = [ object-class SHARP ] criteria
A value in the Fax syntax is an image which is produced using the The <object-class> and <criteria> rules are defined in Section
Group 3 facsimile process [Fax] to duplicate an object, such as 4.3.10. The <SHARP> rule is defined in [MODELS].
a memo.
The following syntax description gives the OID assigned to this The LDAP definition for the Guide syntax is:
syntax:
( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' ) ( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' )
Values in this syntax are expressed as octet strings containing The Guide syntax corresponds to the Guide ASN.1 type from [X.520].
Group 3 Fax images as defined in [Fax].
3.13 Generalized Time 4.3.15 IA5 String
A value in the Generalized Time syntax is a date and time. The year A value of the IA5 String syntax is a string of zero, one or more
is given as a four-digit number. The following syntax description characters from International Alphabet 5 (IA5) [T.50], the
gives the OID assigned to this syntax: international version of the ASCII character set. The LDAP-specific
encoding of a value of this syntax is the unconverted string of
characters, which conforms to the <IA5String> rule in Section 4.2.
( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' ) The LDAP definition for the IA5 String syntax is:
The LDAP-specific encoding is a value of the GeneralizedTime data type ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )
from ASN.1 [X.680]. Time zone MUST be present and SHOULD be GMT (Z).
Example: This syntax corresponds to the IA5String ASN.1 type from [ASN.1].
199412161032Z means 10:32 a.m. Dec. 16, 1994 in the Greenwich
Mean Time time zone.
3.14 Guide 4.3.16 Integer
A value in the Guide syntax is the matching criteria in a Filter. A value of the Integer syntax is a whole number of unlimited
magnitude. The LDAP-specific encoding of a value of this syntax is
the optionally signed decimal digit character string representation
of the number (so, for example, the number 1321 is represented by the
character string "1321"). The encoding is defined by the following
ABNF:
The following syntax description gives the OID assigned to this Integer = [ HYPHEN ] number
syntax:
( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' ) The <HYPHEN> and <number> rules are defined in [MODELS].
The Guide syntax is not intended to be used for defining new
attributes. It is important for backwards compatibility with LDAP
systems that implement an earlier version of LDAP [RFC1778].
The LDAP-specific encoding of a value is defined by the The LDAP definition for the Integer syntax is:
following ABNF:
guide-value = [ object-class "#" ] criteria ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' )
object-class = SP oid This syntax corresponds to the INTEGER ASN.1 type from [ASN.1].
The criteria production is defined in the Enhanced Guide syntax in 4.3.17 JPEG
section 3.11.
3.15 IA5 String A value of the JPEG syntax is an image in the JPEG File Interchange
Format (JFIF), as described in [JPEG]. The LDAP-specific encoding of
a value of this syntax is the sequence of octets of the JFIF encoding
of the image.
A value in the IA5 String syntax is a value of the IA5String data The LDAP definition for the JPEG syntax is:
type from ASN.1 [X.680]. International Alphabet 5 (IA5) [IA5] is the
international version of the ASCII character set.
The following syntax description gives the OID assigned to this ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' )
syntax:
( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'IA5 String' ) The JPEG syntax corresponds to the following ASN.1 type:
The LDAP-specific encoding of a value in this syntax is the character JPEG ::= OCTET STRING (CONSTRAINED BY
string value itself. { -- contents octets are an image in the --
-- JPEG File Interchange Format -- })
3.16 Integer 4.3.18 LDAP Syntax Description
A value in the INTEGER syntax is a whole number as specified in the A value of the LDAP Syntax Description syntax is the description of
INTEGER data type from ASN.1 [X.680]. an LDAP syntax. The LDAP-specific encoding of a value of this syntax
is defined by the <SyntaxDescription> rule in [MODELS].
The following syntax description gives the OID assigned to this The LDAP definition for the LDAP Syntax Description syntax is:
syntax:
( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' ) ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' )
The LDAP-specific encoding of a value is the decimal representation of The above LDAP definition for the LDAP Syntax Description syntax is
the value, with each decimal digit represented by the its character itself a legal value of the LDAP Syntax Description syntax.
equivalent. So, the number 1321 is represented by the character
string "1321".
3.17 JPEG The ASN.1 type corresponding to the LDAP Syntax Description syntax is
defined as follows, assuming EXPLICIT TAGS:
A value in the JPEG syntax is an image produced according to LDAPSyntaxDescription ::= SEQUENCE {
specific rules for light values. The following syntax description identifier OBJECT IDENTIFIER,
gives the OID assigned to this syntax: description DirectoryString { ub-schema } OPTIONAL }
( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' ) The DirectoryString parameterized ASN.1 type is defined in [X.520].
The value of ub-schema is implementation defined.
The LDAP-specific encoding of a value is an octet string of the 4.3.19 Matching Rule Description
light values representing the image.
3.18 LDAP Syntax Description A value of the Matching Rule Description syntax is the definition of
a matching rule. The LDAP-specific encoding of a value of this
syntax is defined by the <MatchingRuleDescription> rule in [MODELS].
A value in the LDAP Syntax Description syntax is a definition of a Example:
LDAP syntax description according to the ABNF given in [MODELS]. ( 2.5.13.2 NAME 'caseIgnoreMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
This syntax is the form in which schema syntax descriptions are Note: a line break has been added for readability - it is not part of
published in the directory in a subentry. The following syntax the syntax.
description gives the OID assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' ) The LDAP definition for the Matching Rule Description syntax is:
Note that, in X.520 [Attr], syntaxes are not labeled distinctly ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' )
with respect to attributes.
The LDAP-specific encoding is the character codes in UTF-8 [ISO10646] This syntax corresponds to the MatchingRuleDescription ASN.1 type
which correspond to the characters in the definition. from [X.501].
3.19 Matching Rule Description 4.3.20 Matching Rule Use Description
A value in the Matching Rule Description syntax is a definition of A value of the Matching Rule Use Description syntax indicates the
a matching rule according to the ABNF given in [MODELS]. This syntax attribute types to which a matching rule may be applied in an
is the form in which schema matching rules are published in the extensibleMatch search filter [PROT]. The LDAP-specific encoding of
directory in a subentry. The following syntax definition gives the a value of this syntax is defined by the <MatchingRuleUseDescription>
OID assigned to this syntax: rule in [MODELS].
( 1.3.6.1.4.1.1466.115.121.1.31 DESC 'Matching Rule Description' ) Example:
The LDAP-specific encoding is the character codes in UTF-8 [ISO10646] ( 2.5.13.16 APPLIES ( givenName $ surname ) )
which correspond to the characters in the definition of a Matching
Rule.
3.20 Matching Rule Use Description The LDAP definition for the Matching Rule Use Description syntax is:
A value in the Matching Rule Use Description syntax is a definition ( 1.3.6.1.4.1.1466.115.121.1.31
of a matching Rule and the attribute types with which the rule could DESC 'Matching Rule Use Description' )
be used in an extensibleMatch search filter. The values are
specified according to the ABNF given in [MODELS]. The following
syntax description gives the OID assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.31 DESC 'Matching Rule Use This syntax corresponds to the MatchingRuleUseDescription ASN.1 type
Description' ) from [X.501].
This syntax is the form in which schema matching rule usage 4.3.21 Name and Optional UID
permissions are published in the directory in a subentry.
The LDAP-specific encoding is the character codes in UTF-8 [ISO10646] A value of the Name and Optional UID syntax is the distinguished name
which correspond to the characters in the definition. [MODELS] of an entity optionally accompanied by a unique identifier
that serves to differentiate the entity from others with an identical
distinguished name.
3.21 MHS OR Address The LDAP-specific encoding of a value of this syntax is defined by
the following ABNF:
A value in the MHS OR Address syntax is the addressing information of NameAndOptionalUID = distinguishedName [ SHARP BitString ]
a user of an X.400 messaging service. The LDAP-specific encoding is
defined in RFC 1327 [RFC1327].
The following syntax description gives the OID assigned to this The <BitString> rule is defined in Section 4.3.2. The
syntax: <distinguishedName> rule is defined in [LDAPDN]. The <SHARP> rule is
defined in [MODELS].
( 1.3.6.1.4.1.1466.115.121.1.33 DESC 'MHS OR Address' ) Note that although the '#' character may occur in the string
representation of a distinguished name, no additional escaping of
this character is performed when a <distinguishedName> is encoded in
a <NameAndOptionalUID>.
3.22 Name and Optional UID Example:
1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B
A value of the Name and Optional UID (Unique IDentifier) syntax is a The LDAP definition for the Name and Optional UID syntax is:
Distinguished Name as defined in section 3.9 plus a bit string
that differentiates the value from otherwise identical names. The following syntax description gives the OID assigned to this
syntax:
( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' ) ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' )
The LDAP-specific encoding of a value is the following ABNF: This syntax corresponds to the NameAndOptionalUID ASN.1 type from
[X.520].
NameAndOptionalUID = DistinguishedName [ "#" bitstring ] 4.3.22 Name Form Description
Although the '#' character could occur in a string representation of A value of the Name Form Description syntax is the definition of a
a distinguished name, no additional special quoting is done. name form, which regulates how entries may be named. The
LDAP-specific encoding of a value of this syntax is defined by the
<NameFormDescription> rule in [MODELS].
Example: Example:
1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B ( 2.5.15.3 NAME 'orgNameForm' OC organization MUST o )
3.23 Name Form Description The LDAP definition for the Name Form Description syntax is:
A value in the Name Form Description syntax is a definition of a ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' )
Name Form according to the ABNF given in [MODELS].
A value indicates the one or more attributes in an entry type (e.g., This syntax corresponds to the NameFormDescription ASN.1 type from
person, device) that are used as the Relative Distinguished Name of [X.501].
the entrY.
This syntax is the form in which schema name forms are published in 4.3.23 Numeric String
the directory. The LDAP-specific encoding of a value is the
character codes in UTF-8 [ISO10646] which correspond to the
characters in the definition.
The following syntax description gives the OID assigned to this A value of the Numeric String syntax is a sequence of one or more
syntax: numerals and spaces. The LDAP-specific encoding of a value of this
syntax is the unconverted string of characters, which conforms to the
following ABNF:
( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' ) NumericString = 1*(DIGIT / SPACE)
3.24 Numeric String The <DIGIT> and <SPACE> rules are defined in [MODELS].
A value in the Numeric String syntax is a series of numerals and Example:
spaces as specified in the NumericString data type from 15 079 672 281
ASN.1 [X.680]. The following string states the OID assigned to
this syntax: The LDAP definition for the Numeric String syntax is:
( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' ) ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' )
The representation of a string in this syntax is the string value
itself.
Example: 1997 This syntax corresponds to the NumericString ASN.1 type from [ASN.1].
3.25 Object Class Description 4.3.24 Object Class Description
A value in this syntax is a character string which expresses the A value of the Object Class Description syntax is the definition of
definition of an object class according to the ABNF given in an object class. The LDAP-specific encoding of a value of this
[MODELS]. This syntax is the form in which schema object classes syntax is defined by the <ObjectClassDescription> rule in [MODELS].
are published in the directory in a subentry. The following string
states the OID assigned to this syntax: Example:
( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c
MAY ( searchGuide $ description ) )
Note: a line break has been added for readability - it is not part of
the syntax.
The LDAP definition for the Object Class Description syntax is:
( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' ) ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' )
For example, the character string below specifies the country object This syntax corresponds to the ObjectClassDescription ASN.1 type from
class, which requires the c (country name) attribute and allows the [X.501].
searchGuide and description attributes. All of these schema
elements are specified in [Schema].
( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c 4.3.25 Octet String
MAY ( searchGuide $ description ) )
3.26 Octet String A value of the Octet String syntax is a sequence of zero, one or more
arbitrary octets. The LDAP-specific encoding of a value of this
syntax is the unconverted sequence of octets, which conforms to the
following ABNF:
A value in the Octet String syntax is a value of the OCTET STRING OctetString = *OCTET
data type from ASN.1 [X.680]. The following string states the OID
assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' ) The <OCTET> rule is defined in [MODELS]. Values of this syntax are
not generally human-readable.
Values in this syntax are written as a series of 8-bit values, The LDAP definition for the Octet String syntax is:
according to the octet string value notation specified in [X.680].
In the case of character strings, the characters themselves could be
written.
Example: ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' )
secret
3.27 OID This syntax corresponds to the OCTET STRING ASN.1 type from [ASN.1].
A value in the Object Identifier syntax is a series of integers, 4.3.26 OID
ordered as specified in the OBJECT IDENTIFIER data type from ASN.1
[X.680]. The following string states the OID assigned to this
syntax:
( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' ) A value of the OID syntax is an object identifier; a sequence of two
or more non-negative integers that uniquely identify some object or
item of specification. Many of the object identifiers used in LDAP
also have IANA registered names [RFC3383].
Values in this syntax are expressed according to the ABNF in The LDAP-specific encoding of a value of this syntax is defined by
[MODELS], section 1.3 for "oid". the <oid> rule in [MODELS].
Examples: 1.2.3.4 Examples:
1.2.3.4
cn cn
3.28 Other Mailbox The LDAP definition for the OID syntax is:
A value in the Other Mailbox syntax gives a mail system name with ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' )
the name of a mailbox in the system. The following string states
the OID assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' ) This syntax corresponds to the OBJECT IDENTIFIER ASN.1 type from
[ASN.1].
Values in this syntax are written according to the following ABNF: 4.3.27 Other Mailbox
A value of the Other Mailbox syntax identifies an electronic mailbox,
in a particular named mail system. The LDAP-specific encoding of a
value of this syntax is defined by the following ABNF:
otherMailbox = mailbox-type DOLLAR mailbox OtherMailbox = mailbox-type DOLLAR mailbox
mailbox-type = PrintableString
mailbox = IA5String
mailbox-type = printableString The <mailbox-type> rule represents the type of mail system in which
the mailbox resides, for example "MCIMail", and <mailbox> is the
actual mailbox in the mail system described by <mailbox-type>. The
<PrintableString> and <IA5String> rules are defined in Section 4.2.
The <DOLLAR> rule is defined in [MODELS].
mailbox = <an encoded IA5 String> The LDAP definition for the Other Mailbox syntax is:
The printableString production is defined in section 3.11. ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' )
In the above, mailbox-type represents the type of mail system in The ASN.1 type corresponding to the Other Mailbox syntax is defined
which the mailbox resides, for example "MCIMail"; and mailbox is as follows, assuming EXPLICIT TAGS:
the actual mailbox in the mail system defined by mailbox-type.
The representation of a string in this syntax is the string value OtherMailbox ::= SEQUENCE {
itself. mailboxType PrintableString,
mailbox IA5String
}
3.29 Postal Address 4.3.28 Postal Address
A value in the Postal Address syntax is a series of strings which A value of the Postal Address syntax is a series of strings which
form an address in a physical mail system. The following string form an address in a physical mail system.
states the OID assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' ) The LDAP-specific encoding of a value of this syntax is defined by
the following ABNF:
Values in this syntax are written according to the following ABNF: PostalAddress = line *( DOLLAR line )
line = 1*line-char
line-char = %x00-23
/ (%x5C "24") ; escaped "$"
/ %x25-5B
/ (%x5C "5C") ; escaped "\"
/ %x5D-7F
/ UTFMB
postal-address = dstring *( DOLLAR dstring ) Each <line> of a postal address value is encoded as a UTF-8 [UTF-8]
string except that "\" and "$" characters, if they occur in the line,
are escaped by a "\" character followed by the two hexadecimal digit
code for the character. The <HEX-DIGIT> rule is defined in Section
4.2. The <DOLLAR> and <UTFMB> rules are defined in [MODELS].
In the above, each dstring component of a postal address value is Many servers limit the postal address to no more than six lines of no
written as a value of type Directory String syntax. Backslashes and more than thirty characters each.
dollar characters, if they occur in the component, are quoted as
described in [MODELS]. Many servers limit the postal address to
six lines of up to thirty characters.
Example: Example:
1234 Main St.$Anytown, CA 12345$USA 1234 Main St.$Anytown, CA 12345$USA
\241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA
3.30 Presentation Address The LDAP definition for the Postal Address syntax is:
A value in the Presentation Address syntax is an OSI Application ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' )
Layer address of a remote application. Logically, a presentation
address consists of:
o A presentation selector This syntax corresponds to the PostalAddress ASN.1 type from [X.520],
i.e.
o A session selector PostalAddress ::= SEQUENCE SIZE(1..ub-postal-line) OF
DirectoryString(ub-postal-string)
o A transport selector 4.3.29 Printable String
o A set of network addresses A value of the Printable String syntax is a string of latin
alphabetic, numeric, and (limited) punctuation characters as
specified by the <PrintableCharacter> rule in Section 4.2.
The following string states the OID assigned to this syntax: The LDAP-specific encoding of a value of this syntax is the
unconverted string of characters, which conforms to the
<PrintableString> rule in Section 4.2.
( 1.3.6.1.4.1.1466.115.121.1.43 DESC 'Presentation Address' ) Example:
This is a PrintableString.
Values in this syntax are written according to the following ABNF: The LDAP definition for the PrintableString syntax is:
presentation-address = [[[ psel "/" ] ssel "/" ] tsel "/" ] ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )
network-address-list
psel = selector This syntax corresponds to the PrintableString ASN.1 type from
ssel = selector [ASN.1].
tsel = selector
network-address-list = network-address USCORE 4.3.30 Substring Assertion
network-address-list / network-address
network-address = "NS" PLUS dothexstring A value of the Substring Assertion syntax is a sequence of zero, one
/ afi PLUS idi [ PLUS dsp ] or more character substrings used as an argument for substring
/ idp PLUS hexstring extensible matching of character string attribute values, i.e. as the
matchValue of a MatchingRuleAssertion [PROT]. Each substring is a
string of one or more arbitrary characters from the Universal
Character Set (UCS) [UCS]. A zero length substring is not permitted.
The first (NS) alternative is the Concrete Binary Representation. The LDAP-specific encoding of a value of this syntax is defined by
It is the compact encoding. the following ABNF:
The afi alternative is a user-oriented representation of a network SubstringAssertion = [ initial ] any [ final ]
address.
The idp alternative is a form of network-address included for initial = substring
compatibility with ISO 8348 [ISO8348]. any = ASTERISK *(substring ASTERISK)
final = substring
ASTERISK = %x2A ; asterisk ("*")
selector = DQUOTE otherstring DQUOTE substring = 1*substring-character
/ SHARP numericstring substring-character = %x00-29
/ SQUOTE hexstring "'H" / (%x5C "2A") ; escaped "*"
/ "" / %x2B-5B
/ (%x5C "5C") ; escaped "\"
/ %x5D-7F
/ UTFMB
The otherstring alternative for the selector is IA5 characters. Each <substring> of a Substring Assertion value is encoded as a UTF-8
[UTF-8] string, except that "\" and "*" characters, if they occur in
the substring, are escaped by a "\" character followed by the two
hexadecimal digit code for the character.
The "" alternative for the selector expresses the case where the The Substring Assertion syntax is used only as the syntax of
selector is present, but Empty. assertion values in the extensible match. It is not used as an
attribute syntax, or in the SubstringFilter [PROT].
idp = numericstring The LDAP definition for the Substring Assertion syntax is:
dsp = "d" numericstring
/ "x" dothexstring
/ "l" otherstring
/ "RFC-1006" PLUS prefix PLUS ip [ PLUS port [ PLUS tset ]]
/ "X.25(80)" PLUS prefix PLUS dte [ PLUS cudf-or-pid PLUS
hexstring ]
/ "ECMA-117-Binary" PLUS hexstring PLUS hexstring PLUS
hexstring / "ECMA-117-Decimal" PLUS numericstring PLUS
numericstring PLUS numericstring
The d alternative is the Abstract Decimal form of the Domain ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' )
Specific Part (dsp) in a network address.
The x alternative is the Abstract Binary form of the dsp in a This syntax corresponds to the SubstringAssertion ASN.1 type from
network address. [X.520].
The l alternative is IA5 characters and is only meaningful locally. 4.3.31 Telephone Number
idi = numericstring A value of the Telephone Number syntax is a string of printable
characters that complies with the internationally agreed format for
representing international telephone numbers [E.123].
afi = "X121" / "DCC" / "TELEX" / "PSTN" / "ISDN" / "ICD" / "LOCAL" The LDAP-specific encoding of a value of this syntax is the
unconverted string of characters, which conforms to the
<PrintableString> rule in Section 4.2.
prefix = DIGIT DIGIT Example: +1 512 315 0280
The LDAP definition for the Telephone Number syntax is:
ip = numericstring ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' )
; dotted decimal form (e.g., 10.0.0.6) or
domain (e.g., twg.com)
port = numericstring The Telephone Number syntax corresponds to the following ASN.1 type
from [X.520]:
tset = numericstring PrintableString (SIZE(1..ub-telephone-number))
dte = numericstring The value of ub-telephone-number is implementation defined.
cudf-or-pid = "CUDF" / "PID" 4.3.32 Teletex Terminal Identifier
other = keychar / PLUS / DOT A value of this syntax specifies the identifier and (optionally)
parameters of a teletex terminal.
domainchar = keychar / DOT The LDAP-specific encoding of a value of this syntax is defined by
the following ABNF:
hexoctet = HEX HEX teletex-id = ttx-term *(DOLLAR ttx-param)
ttx-term = PrintableString ; terminal identifier
ttx-param = ttx-key COLON ttx-value ; parameter
ttx-key = "graphic" / "control" / "misc" / "page" / "private"
ttx-value = *ttx-value-char
decimal-octet = 1*3DIGIT ttx-value-char = %x00-23
/ (%x5C "24") ; escaped "$"
/ %x25-5B
/ (%x5C "5C") ; escaped "\"
/ %x5D-FF
otherstring = other otherstring / other The <PrintableString> and <COLON> rules are defined in Section 4.2.
The <DOLLAR> rule is defined in [MODELS].
domainstring = domainchar otherstring / domainchar The LDAP definition for the Teletex Terminal Identifier syntax is:
hexstring = hexoctet hexstring / hexoctet ( 1.3.6.1.4.1.1466.115.121.1.51
DESC 'Teletex Terminal Identifier' )
dotstring = decimaloctet DOT dotstring / This syntax corresponds to the TeletexTerminalIdentifier ASN.1 type
decimaloctet DOT decimaloctet from [X.520].
dothexstring = dotstring / hexstring 4.3.33 Telex Number
3.31 Printable String A value of the Telex Number syntax specifies the telex number,
country code and answerback code of a telex terminal.
A value in the Printable String syntax is a series of alphabetic, The LDAP-specific encoding of a value of this syntax is defined by
numeric, and (limited) punctuation characters as specified in the the following ABNF:
PrintableString data type from ASN.1 [X.680] and in production p of
section 3.11. Values in this syntax are expressed as the string
itself. The following string states the OID assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' ) telex-number = actual-number DOLLAR country-code
DOLLAR answerback
actual-number = PrintableString
country-code = PrintableString
answerback = PrintableString
Example: This is a PrintableString. The <PrintableString> rule is defined in Section 4.2. The <DOLLAR>
rule is defined in [MODELS].
3.32 Substring Assertion The LDAP definition for the Telex Number syntax is:
The Substring Assertion syntax is used in rules which can be used in ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' )
substrings and extensible matching rules. When using a substrings
assertion, substrings components are provided in a SubstringFilter
sequence. The following string states the OID assigned to this
syntax:
( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' ) This syntax corresponds to the TelexNumber ASN.1 type from [X.520].
When using a matching rule assertion, substring components are 4.3.34 UTC Time
encoded according to the following ABNF and provided as the
matchValue of the MatchingRuleAssertion:
substring = [initial] any [final] A value of the UTC Time syntax is a character string representing a
date and time to a precision of one minute or one second. The year
is given as a two-digit number. The LDAP-specific encoding of a
value of this syntax follows the format defined in [ASN.1] for the
UTCTime type and is described by the following ABNF:
initial = value UTCTime = year month day hour minute [ second ]
[ u-time-zone ]
u-time-zone = %x5A ; "Z"
/ u-differential
u-differential = ( MINUS / PLUS ) hour minute
any = "*" *(value "*") The <year>, <month>, <day>, <hour>, <minute>, <second> and <MINUS>
rules are defined in Section 4.3.13. The <DOLLAR> rule is defined in
[MODELS].
final = value The time value represents coordinated universal time if the "Z" form
of <u-time-zone> is used, otherwise the value represents a local
time. In the latter case, if <u-differential> is provided then
coordinated universal time can be calculated by subtracting the
differential from the local time. The <u-time-zone> SHOULD be
present in time values and the "Z" form of <u-time-zone> SHOULD be
used in preference to <u-differential>.
The <value> production is a UTF-8 [ISO10646] string. If a backslash or The LDAP definition for the UTC Time syntax is:
asterix character is present in a production of <value>, it is
quoted as described in [MODELS].
3.33 Telephone Number ( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' )
Note: This syntax is deprecated in favor of the Generalized Time
syntax.
A value in the telephone number syntax is the series of characters The UTC Time syntax corresponds to the UTCTime ASN.1 type from
that express a number (address) assigned to a telephone system [ASN.1].
subscriber. The following string states the OID assigned to this
syntax:
( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' ) 5. Matching Rules
Values in this syntax are written as if they were ASN.1 [X.680] Matching rules are used by directory implementations to compare
Printable String types. Telephone numbers are defined in X.520 attribute values against assertion values when performing Search and
[X.520] to comply with the internationally agreed format for Compare operations [PROT]. They are also used when comparing a
expressing international telephone numbers in Recommendation purported distinguished name [MODELS] with the name of an entry.
E.123 [E.123]. When modifying entries, matching rules are used to identify values to
be deleted and to prevent an attribute from containing two equal
values.
The representation of a string in this syntax is the string value Matching rules that are required for directory operation, or that are
itself. in common use, are specified in this section.
Example: +1 512 315 0280 5.1 General Considerations
3.34 Teletex Terminal Identifier A matching rule is applied to attribute values through an
AttributeValueAssertion or MatchingRuleAssertion [PROT]. The
conditions under which an AttributeValueAssertion or
MatchingRuleAssertion evaluates to Undefined are specified in [PROT].
If an assertion is not Undefined then the result of the assertion is
the result of applying the selected matching rule. A matching rule
evaluates to TRUE, and in some cases Undefined, as specified in the
description of the matching rule, otherwise it evaluates to FALSE.
A value in this syntax is a string of characters that express the Each assertion contains an assertion value. The definition of each
identifier value assigned to a teletex service subscriber. The matching rule specifies the syntax for the assertion value. The
following string states the OID assigned to this syntax: syntax of the assertion value is typically, but not necessarily, the
same as the syntax of the attribute values to which the matching rule
may be applied. Note that the AssertionValue in a SubstringFilter
[PROT] MUST conform to the assertion syntax of the equality matching
rule for the attribute type rather than the assertion syntax of the
substrings matching rule for the attribute type. The entire
SubstringFilter is converted into an assertion value of the
substrings matching rule prior to applying the rule.
( 1.3.6.1.4.1.1466.115.121.1.51 DESC 'Teletex Terminal The description of each matching rule indicates whether the rule is
Identifier' ) suitable for use as the equality matching rule (EQUALITY), ordering
matching rule (ORDERING) or substrings matching rule (SUBSTR) in an
attribute type definition [MODELS].
Values in this syntax are written according to the following ABNF: Each matching rule is uniquely identified with an object identifier.
teletex-id = ttx-term 0*("$" ttx-param) The definition of a matching rule should not be subsequently changed.
If a change is desirable then a new matching rule with a different
object identifier should be defined instead.
ttx-term = printablestring Servers SHOULD implement all the matching rules in Section 5.2.
Servers MAY implement additional matching rules.
ttx-param = ttx-key ":" ttx-value Servers which implement the extensibleMatch filter SHOULD allow the
matching rules listed in Section 5.2 to be used in the
extensibleMatch filter and SHOULD allow matching rules to be used
with all attribute types known to the server, where the assertion
syntax of the matching rule is the same as the value syntax of the
attribute.
ttx-key = "graphic" / "control" / "misc" / "page" / "private" Servers MUST publish in the matchingRules attribute, the definitions
of matching rules referenced by values of the attributeTypes and
matchingRuleUse attributes in the same subschema entry. Other
unreferenced matching rules MAY be published in the matchingRules
attribute.
ttx-value = octetstring If the server supports the extensibleMatch filter, then the server
MAY use the matchingRuleUse attribute to indicate the applicability
(in an extensibleMatch filter) of selected matching rules to
nominated attribute types.
In the above, the first printablestring is the encoding of the first 5.2 Matching Rule Definitions
portion of the teletex terminal identifier to be encoded, and the
subsequent 0 or more octetstrings are subsequent portions of the
teletex terminal identifier.
The representation of a string in this syntax is the string value When evaluating the caseExactIA5Match, caseIgnoreIA5Match,
itself. caseIgnoreIA5SubstringsMatch, caseIgnoreListMatch, caseIgnoreMatch,
caseIgnoreOrderingMatch and caseIgnoreSubstringsMatch matching rules
multiple adjoining whitespace characters are treated the same as an
individual space, and leading and trailing whitespace is ignored.
3.35 Telex Number 5.2.1 bitStringMatch
A value in the Telex Number syntax is the number assigned to a telex The bitStringMatch rule compares an assertion value of the Bit String
system subscriber with the country and answerback values indicated. syntax to an attribute value of a syntax (e.g. the Bit String syntax)
whose corresponding ASN.1 type is BIT STRING.
The following string states the OID assigned to this syntax: If the corresponding ASN.1 type of the attribute syntax does not have
a named bit list (which is the case for the Bit String syntax) then
the rule evaluates to TRUE if and only if the attribute value has the
same number of bits as the assertion value and the bits match on a
bitwise basis.
( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' ) If the corresponding ASN.1 type does have a named bit list then
bitStringMatch operates as above except that trailing zero bits in
the attribute and assertion values are treated as absent.
Values in this syntax are written according to the following ABNF: The LDAP definition for the bitStringMatch rule is:
telex-number = actual-number "$" country "$" answerback ( 2.5.13.16 NAME 'bitStringMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
actual-number = printablestring The bitStringMatch rule is an equality matching rule.
country = printablestring 5.2.2 caseExactIA5Match
answerback = printablestring The caseExactIA5Match rule compares an assertion value of the IA5
In the above, actual-number is the syntactic representation of the String syntax to an attribute value of a syntax (e.g the IA5 String
number portion of the TELEX number being written, country is the syntax) whose corresponding ASN.1 type is IA5String.
TELEX country code, and answerback is the answerback code of a TELEX
terminal.
The representation of a string in this syntax is the string value The rule evaluates to TRUE if and only if the attribute value and the
itself. assertion value have the same number of characters and corresponding
characters are the same. Letter case is significant in the
comparison.
3.36 UTC Time The LDAP definition for the caseExactIA5Match rule is:
A value in the UTC Time syntax is a date and time indicating accuracy ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match'
to minute or second. The year is given as a two-digit number. The SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
following string states the OID assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' ) The caseExactIA5Match rule is an equality matching rule.
Values in this syntax are written as if they were printable strings, 5.2.3 caseIgnoreIA5Match
formulated as specified for the UTCTime data type in ASN.1 [X.680].
It is strongly suggested that GMT time be used.
Note: This syntax is deprecated in favor of the Generalized Time The caseIgnoreIA5Match rule compares an assertion value of the IA5
syntax. String syntax to an attribute value of a syntax (e.g the IA5 String
syntax) whose corresponding ASN.1 type is IA5String.
4. Matching Rules The rule evaluates to TRUE if and only if the attribute value and the
assertion value have the same number of characters and corresponding
characters are the same, ignoring the case of letters.
When performing the caseExactMatch, caseIgnoreMatch, The LDAP definition for the caseIgnoreIA5Match rule is:
caseIgnoreListMatch, telephoneNumberMatch, caseExactIA5Match and
caseIgnoreIA5Match, multiple adjoining whitespace characters are
treated the same as an individual space, and leading and trailing
whitespace is ignored.
4.1 bitStringMatch ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
The following ABNF associates the bitStringMatch rule with the Bit The caseIgnoreIA5Match rule is an equality matching rule.
String syntax:
( 2.5.13.16 NAME 'bitStringMatch' 5.2.4 caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 ) ; Bit String
This matching rule is used to test equality. The caseIgnoreIA5SubstringsMatch rule compares an assertion value of
the Substring Assertion syntax to an attribute value of a syntax (e.g
the IA5 String syntax) whose corresponding ASN.1 type is IA5String.
4.2 caseExactIA5Match The rule evaluates to TRUE if and only if the substrings of the
assertion value match disjoint portions of the attribute value in the
order of the substrings in the assertion value, and an <initial>
substring, if present, matches the beginning of the attribute value,
and a <final> substring, if present, matches the end of the attribute
value. A substring matches a portion of the attribute value if
corresponding characters are the same, ignoring the case of letters.
The following ABNF associates the caseExactIA5Match rule with the IA5 ( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch'
String syntax: SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' The caseIgnoreIA5SubstringsMatch rule is a substrings matching rule.
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) ; IA5 String
This matching rule is used to test equality. 5.2.5 caseIgnoreListMatch
4.3 caseIgnoreIA5Match The caseIgnoreListMatch rule compares an assertion value that is a
sequence of strings to an attribute value of a syntax (e.g. the
Postal Address syntax) whose corresponding ASN.1 type is a sequence
of the DirectoryString ASN.1 type.
The following ABNF associates the caseIgnoreIA5Match rule with the The rule evaluates to TRUE if and only if the attribute value and the
IA5 String syntax: assertion value have the same number of strings and corresponding
strings (by position) match according to the caseIgnoreMatch matching
rule.
( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' In [X.520] the assertion syntax for this matching rule is defined to
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) ; IA5 String be:
This matching rule is used to test equality. SEQUENCE OF DirectoryString {ub-match}
4.4 caseIgnoreListMatch i.e. different from the corresponding type for the Postal Address
syntax. The choice of the Postal Address syntax for the assertion
syntax of the caseIgnoreListMatch in LDAP should not be seen as
limiting the matching rule to only apply to attributes with the
Postal Address syntax.
The ABNF below associates the caseIgnoreListMatch rule with the The LDAP definition for the caseIgnoreListMatch rule is:
Postal Address syntax. The X.520 [X.520] syntax for this matching
rule is a SEQUENCE Of DirectoryString. Since the Postal Address
syntax is such a sequence, it is used in defining the matching rule
for LDAP, although the matching rule can be used with any SEQUENCE
OF DirectoryString syntax/assertion.
( 2.5.13.11 NAME 'caseIgnoreListMatch' ( 2.5.13.11 NAME 'caseIgnoreListMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) ; Postal Address SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
The caseIgnoreListMatch rule is an equality matching rule.
This matching rule is used to test equality. 5.2.6 caseIgnoreMatch
4.5 caseIgnoreMatch The caseIgnoreMatch rule compares an assertion value of the Directory
String syntax to an attribute value of a syntax (e.g. the Directory
String, Printable String, Country String or Telephone Number syntax)
whose corresponding ASN.1 type is DirectoryString or one of its
alternative string types, e.g. PrintableString.
The following ABNF associates the caseIgnoreMatch rule with the The rule evaluates to TRUE if and only if the attribute value and the
Directory String syntax: assertion value have the same number of characters and corresponding
characters are the same, ignoring the case of letters.
The LDAP definition for the caseIgnoreMatch rule is:
( 2.5.13.2 NAME 'caseIgnoreMatch' ( 2.5.13.2 NAME 'caseIgnoreMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) ; Directory String SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
This matching rule is used to test equality. The caseIgnoreMatch rule is an equality matching rule.
4.6 caseIgnoreOrderingMatch 5.2.7 caseIgnoreOrderingMatch
The following ABNF associates the caseIgnoreOrderingMatch rule with The caseIgnoreOrderingMatch rule compares an assertion value of the
the Directory String syntax: Directory String syntax to an attribute value of a syntax (e.g. the
Directory String, Printable String, Country String or Telephone
Number syntax) whose corresponding ASN.1 type is DirectoryString or
one of its alternative string types.
The rule evaluates to TRUE if, and only if, in the normal collation
order for the attribute syntax after lower-case letters in both the
attribute and assertion values have been replaced by their upper-case
equivalents, the attribute value appears earlier than the assertion
value, i.e. the attribute value is "less than" the assertion value.
The collation order for values of the DirectoryString syntax is
implementation-defined. [Editor's note: this will be specified by a
stringprep profile before final publication.]
The LDAP definition for the caseIgnoreOrderingMatch rule is:
( 2.5.13.3 NAME 'caseIgnoreOrderingMatch' ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) ; Directory String SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
This matching rule is used to test inequality, i.e., greaterOrEqual The caseIgnoreOrderingMatch rule is an ordering matching rule.
or lessOrEqual.
The sort ordering for a caseIgnoreOrderingMatch is implementation- 5.2.8 caseIgnoreSubstringsMatch
dependent.
4.7 caseIgnoreSubstringsMatch The caseIgnoreSubstringsMatch rule compares an assertion value of the
Substring Assertion syntax to an attribute value of a syntax (e.g.
the Directory String, Printable String, Country String or Telephone
Number syntax) whose corresponding ASN.1 type is DirectoryString or
one of its alternative string types.
The following ABNF associates the caseIgnoreSubstringsMatch rule with The rule evaluates to TRUE if and only if the substrings of the
the Substring Assertion: assertion value match disjoint portions of the attribute value in the
order of the substrings in the assertion value, and an <initial>
substring, if present, matches the beginning of the attribute value,
and a <final> substring, if present, matches the end of the attribute
value. A substring matches a portion of the attribute value if
corresponding characters are the same, ignoring the case of letters.
The LDAP definition for the caseIgnoreSubstringsMatch rule is:
( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) ; Substring Assertion SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
This matching rule is used to test substrings equality. The caseIgnoreSubstringsMatch rule is a substrings matching rule.
4.8 distinguishedNameMatch 5.2.9 distinguishedNameMatch
The following ABNF associates the distinguishedNameMatch rule with The distinguishedNameMatch rule compares an assertion value of the DN
the DN syntax: syntax to an attribute value of a syntax (e.g. the DN syntax) whose
corresponding ASN.1 type is DistinguishedName.
The rule evaluates to TRUE if and only if the attribute value and the
assertion value have the same number of RDNs and corresponding RDNs
(by position) are the same. An RDN of the assertion value is the
same as an RDN of the attribute value if and only if they have the
same number of attribute value assertions (AVAs) and each AVA of the
first RDN is the same as the AVA of the second RDN with the same
attribute type. The order of the AVAs is not significant. Also note
that a particular attribute type may appear in at most one AVA in an
RDN. Two AVAs with the same attribute type are the same if their
values are equal according to the equality matching rule of the
attribute type. If one or more of the AVA comparisons evaluate to
Undefined and the remaining AVA comparisons return TRUE then the
distinguishedNameMatch rule evaluates to Undefined.
The LDAP definition for the distinguishedNameMatch rule is:
( 2.5.13.1 NAME 'distinguishedNameMatch' ( 2.5.13.1 NAME 'distinguishedNameMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) ; DN SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
The distinguishedNameMatch rule is an equality matching rule.
This matching rule is used to test equality. 5.2.10 generalizedTimeMatch
4.9 generalizedTimeMatch The generalizedTimeMatch rule compares an assertion value of the
Generalized Time syntax to an attribute value of a syntax (e.g the
Generalized Time syntax) whose corresponding ASN.1 type is
GeneralizedTime.
The following ABNF associates the generalizedTimeMatch rule with the The rule evaluates to TRUE if and only if the attribute value
Generalized Time syntax: represents the same universal coordinated time as the assertion
value. If a time is specified with the minutes or seconds absent
then the number of minutes or seconds (respectively) is assumed to be
zero.
The LDAP definition for the generalizedTimeMatch rule is:
( 2.5.13.27 NAME 'generalizedTimeMatch' ( 2.5.13.27 NAME 'generalizedTimeMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) ; Generalized Time SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
This matching rule is used to test equality. The generalizedTimeMatch rule is an equality matching rule.
4.10 generalizedTimeOrderingMatch 5.2.11 generalizedTimeOrderingMatch
The generalizedTimeMatch rule compares the time ordering of an
assertion value of the Generalized Time syntax to an attribute value
of a syntax (e.g the Generalized Time syntax) whose corresponding
ASN.1 type is GeneralizedTime.
The rule evaluates to TRUE if and only if the attribute value
represents a universal coordinated time which is earlier than the
universal coordinated time represented by the assertion value.
The LDAP definition for the generalizedTimeOrderingMatch rule is:
( 2.5.13.28 NAME 'generalizedTimeOrderingMatch' ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) ; Generalized Time SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
This matching rule is used to test inequality, i.e., greaterOrEqual The generalizedTimeOrderingMatch rule is an ordering matching rule.
or lessOrEqual.
4.11 integerFirstComponentMatch 5.2.12 integerFirstComponentMatch
The following ABNF associates the integerFirstComponentMatch rule The integerFirstComponentMatch rule compares an assertion value of
with the INTEGER syntax: the Integer syntax to an attribute value of a syntax (e.g the DIT
Structure Rule Description syntax) whose corresponding ASN.1 type is
a SEQUENCE with a mandatory first component of the INTEGER ASN.1
type.
Note that the assertion syntax of this matching rule differs from the
attribute syntax of attributes for which this is the equality
matching rule.
The rule evaluates to TRUE if and only if the assertion value and the
first component of the attribute value are the same integer value.
The LDAP definition for the integerFirstComponentMatch matching rule
is:
( 2.5.13.29 NAME 'integerFirstComponentMatch' ( 2.5.13.29 NAME 'integerFirstComponentMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) ; INTEGER SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
Implementors, note that the assertion syntax of this matching The integerFirstComponentMatch rule is an equality matching rule.
rule, an INTEGER, is different from the value syntax of attributes When using integerFirstComponentMatch to compare two attribute values
for which this is the equality matching rule. (of an applicable syntax), an assertion value must first be derived
from one of the attribute values. An assertion value can be derived
from an attribute value by taking the first component of that
attribute value.
This matching rule is used to test equality with the first component 5.2.13 integerMatch
in a compound syntax.
4.12 integerMatch The integerMatch rule compares an assertion value of the Integer
syntax to an attribute value of a syntax (e.g the Integer syntax)
whose corresponding ASN.1 type is INTEGER.
The following ABNF associates the integerMatch rule with the INTEGER The rule evaluates to TRUE if and only if the attribute value and the
syntax: assertion value are the same integer value.
The LDAP definition for the integerMatch matching rule is:
( 2.5.13.14 NAME 'integerMatch' ( 2.5.13.14 NAME 'integerMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) ; INTEGER SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
This matching rule is used to test equality. The integerMatch rule is an equality matching rule.
4.13 numericStringMatch 5.2.14 numericStringMatch
The following ABNF associates the numericStringMatch rule with the The numericStringMatch rule compares an assertion value of the
Numeric String syntax: Numeric String syntax to an attribute value of a syntax (e.g the
Numeric String syntax) whose corresponding ASN.1 type is
NumericString.
The rule evaluates to TRUE if and only if the attribute value and the
assertion value are the same string of numerals, ignoring any space
characters.
The LDAP definition for the numericStringMatch matching rule is:
( 2.5.13.8 NAME 'numericStringMatch' ( 2.5.13.8 NAME 'numericStringMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) ; Numeric String SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
This matching rule is used to test equality. The numericStringMatch rule is an equality matching rule.
4.14 numericStringSubstringsMatch 5.2.15 numericStringSubstringsMatch
The numericStringSubstringsMatch rule compares an assertion value of
the Substring Assertion syntax to an attribute value of a syntax (e.g
the Numeric String syntax) whose corresponding ASN.1 type is
NumericString.
The rule evaluates to TRUE if and only if the substrings of the
assertion value match disjoint portions of the attribute value in the
order of the substrings in the assertion value, and an <initial>
substring, if present, matches the beginning of the attribute value,
and a <final> substring, if present, matches the end of the attribute
value. A substring matches a portion of the attribute value if
corresponding characters are the same, ignoring any space characters.
( 2.5.13.10 NAME 'numericStringSubstringsMatch' ( 2.5.13.10 NAME 'numericStringSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) ; Substring Assertion SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
This matching rule is used to test substrings equality. The numericStringSubstringsMatch rule is a substrings matching rule.
4.15 objectIdentifierFirstComponentMatch 5.2.16 objectIdentifierFirstComponentMatch
The following ABNF associates the The objectIdentifierFirstComponentMatch rule compares an assertion
objectIdentifierFirstComponentMatch rule with the OID syntax: value of the OID syntax to an attribute value of a syntax (e.g the
Attribute Type Description, DIT Content Rule Description, LDAP Syntax
Description, Matching Rule Description, Matching Rule Use
Description, Name Form Description or Object Class Description
syntax) whose corresponding ASN.1 type is a SEQUENCE with a mandatory
first component of the OBJECT IDENTIFIER ASN.1 type.
( 2.5.13.31 NAME 'objectIdentifierFirstComponentMatch' Note that the assertion syntax of this matching rule differs from the
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) ; OID attribute syntax of attributes for which this is the equality
matching rule.
If the client supplies an extensible filter using an The rule evaluates to TRUE if and only if the assertion value matches
objectIdentifierFirstComponentMatch whose matchValue is in the the first component of the attribute value using the rules of
"descr" form, and the OID is not recognized by the server, then the objectIdentifierMatch.
filter is Undefined.
This matching rule is used to test equality with the first component The LDAP definition for the objectIdentifierFirstComponentMatch
in a compound syntax. matching rule is:
4.16 objectIdentifierMatch ( 2.5.13.31 NAME 'objectIdentifierFirstComponentMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
The following ABNF associates the objectIdentifierMatch rule with the The objectIdentifierFirstComponentMatch rule is an equality matching
OID syntax: rule. When using objectIdentifierFirstComponentMatch to compare two
attribute values (of an applicable syntax), an assertion value must
first be derived from one of the attribute values. An assertion
value can be derived from an attribute value by taking the first
component of that attribute value.
( 2.5.13.0 NAME 'objectIdentifierMatch' 5.2.17 objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) ; OID
This matching rule is used to test equality. The objectIdentifierMatch rule compares an assertion value of the OID
syntax to an attribute value of a syntax (e.g the OID syntax) whose
corresponding ASN.1 type is OBJECT IDENTIFIER.
Implementors, note that the assertion syntax of this matching The rule evaluates to TRUE if and only if the assertion value and the
rule, an OID, is different from the value syntax of attributes for attribute value represent the same object identifier, that is, the
which this is the equality matching rule. same sequence of integers, whether represented explicitly in the
<numericoid> form of <oid> or implicitly in the <descr> form (see
[MODELS]).
If the client supplies a filter using an objectIdentifierMatch whose If an LDAP client supplies an assertion value in the <descr> form,
matchValue oid is in the "descr" form, and the oid is not recognized and the chosen descriptor is not recognized by the server, then the
by the server, then the filter is Undefined. objectIdentifierMatch rule evaluates to Undefined.
4.17 octetStringMatch The LDAP definition for the objectIdentifierMatch matching rule is:
Servers which implement the extensibleMatch filter SHOULD allow the ( 2.5.13.0 NAME 'objectIdentifierMatch'
matching rule listed in this section to be used in the SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
extensibleMatch. In general these servers SHOULD allow matching
rules to be used with all attribute types known to the server, when
the assertion syntax of the matching rule is the same as the value
syntax of the attribute.
The Octet String Match rule compares for equality an asserted octet The objectIdentifierMatch rule is an equality matching rule.
string with an attribute value of type OCTET STRING.
The strings match if they are the same length and corresponding 5.2.18 octetStringMatch
octets are identical.
The following ABNF associates the octetStringMatch rule with The octetStringMatch rule compares an assertion value of the Octet
the OCTET STRING syntax: String syntax to an attribute value of a syntax (e.g the Octet String
or JPEG syntax) whose corresponding ASN.1 type is the OCTET STRING
ASN.1 type.
The rule evaluates to TRUE if and only if the attribute value and the
assertion value are the same length and corresponding octets (by
position) are the same.
The LDAP definition for the octetStringMatch matching rule is:
( 2.5.13.17 NAME 'octetStringMatch' ( 2.5.13.17 NAME 'octetStringMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
4.18 presentationAddressMatch The octetStringMatch rule is an equality matching rule.
The following ABNF associates the presentationAddressMatch rule with
the Presentation Address syntax:
( 2.5.13.22 NAME 'presentationAddressMatch' 5.2.19 telephoneNumberMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.43 ) ; Presentation Address
This matching rule is used to test equality. The telephoneNumberMatch rule compares an assertion value of the
Telephone Number syntax to an attribute value of a syntax (e.g the
Telephone Number syntax) whose corresponding ASN.1 type is a
PrintableString representing a telephone number.
4.19 protocolInformationMatch The rule evaluates to TRUE if and only if the attribute value and the
assertion value have the same number of characters and corresponding
characters are the same, ignoring the case of letters, and ignoring
space and `-' characters.
The following ABNF associates the protocolInformationMatch rule with The LDAP definition for the telephoneNumberMatch matching rule is:
the Protocol Information syntax:
( 2.5.13.24 NAME 'protocolInformationMatch' ( 2.5.13.20 NAME 'telephoneNumberMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.42 ) ; Protocol Information SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
This matching rule is used to test equality. The telephoneNumberMatch rule is an equality matching rule.
4.20 telephoneNumberMatch 5.2.20 telephoneNumberSubstringsMatch
The following ABNF associates the telephoneNumberMatch rule with the The telephoneNumberSubstringsMatch rule compares an assertion value
Telephone Number syntax: of the Substring Assertion syntax to an attribute value of a syntax
(e.g the Telephone Number syntax) whose corresponding ASN.1 type is a
PrintableString representing a telephone number.
( 2.5.13.20 NAME 'telephoneNumberMatch' The rule evaluates to TRUE if and only if the substrings of the
SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) ; Telephone Number assertion value match disjoint portions of the attribute value in the
order of the substrings in the assertion value, and an <initial>
substring, if present, matches the beginning of the attribute value,
and a <final> substring, if present, matches the end of the attribute
value. A substring matches a portion of the attribute value if
corresponding characters are the same, ignoring the case of letters,
and ignoring space and `-' characters.
This matching rule is used to test equality. The LDAP definition for the telephoneNumberSubstringsMatch matching
rule is:
4.21 telephoneNumberSubstringsMatch ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
The following ABNF associates the telephoneNumberSubstringsMatch rule The telephoneNumberSubstringsMatch rule is a substrings matching
with the Substring Assertion syntax: rule.
( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch' 5.2.21 uniqueMemberMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) ; Substring Assertion
This matching rule is used to test substrings equality. The uniqueMemberMatch rule compares an assertion value of the Name
And Optional UID syntax to an attribute value of a syntax (e.g the
Name And Optional UID syntax) whose corresponding ASN.1 type is
NameAndOptionalUID.
4.22 uniqueMemberMatch The rule evaluates to TRUE if and only if the <distinguishedName>
components of the assertion value and attribute value match according
to the distinguishedNameMatch rule and the <BitString> component is
absent from the attribute value or matches the <BitString> component
of the assertion value according to the bitStringMatch rule.
The following ABNF associates the uniqueMemberMatch rule with the The LDAP definition for the uniqueMemberMatch matching rule is:
Name and Optional UID syntax:
( 2.5.13.23 NAME 'uniqueMemberMatch' ( 2.5.13.23 NAME 'uniqueMemberMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 ) ; Name And Optional UID SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
This matching rule is used to test equality. The uniqueMemberMatch rule is an equality matching rule.
5. Security Considerations 6. Security Considerations
5.1 Disclosure In general, the LDAP-specific encodings for syntaxes defined in this
document do not define canonical encodings. That is, a
transformation from an LDAP-specific encoding into some other
encoding (e.g. BER) and back into the LDAP-specific encoding will not
necessarily reproduce exactly the original octets of the
LDAP-specific encoding. Therefore an LDAP-specific encoding should
not be used where a canonical encoding is required.
Attributes of directory entries are used to provide descriptive Furthermore, the LDAP-specific encodings do not necessarily enable an
information about the real-world objects they represent, which can alternative encoding of values of the Directory String and DN
be people, organizations or devices. Most countries have privacy syntaxes to be reconstructed, e.g. a transformation from DER to
laws regarding the publication of information about people. LDAP-specific encoding and back to DER may not reproduce the original
DER encoding. Therefore LDAP-specific encodings should not be used
where reversibility to DER is needed, e.g. for the verification of
digital signatures. Instead, DER or a DER-reversible encoding should
be used.
5.2 Security Information Syntaxes When interpreting security-sensitive fields, and in particular fields
used to grant or deny access, implementations MUST ensure that any
matching rule comparisons are done on the underlying abstract value,
regardless of the particular encoding used.
Several X.500 attributes, such as, the userCertificate attribute, 7. Acknowledgements
are used to include key-based security information in directory
entries. The attribute syntaxes for these attributes are:
Certificate This document is an revision of RFC 2252 by M. Wahl, A. Coulbeck, T.
CertificateList Howes, and S. Kille. RFC 2252 was a product of the IETF ASID Working
CertificatePair Group.
SupportedAlgorithm
These syntaxes are specified for LDAP by the PKIX Working Group, and This document is based upon input of the IETF LDAPBIS working group.
so, are not included in this document. The authors wish to thank J. Sermersheim and K. Zeilenga for their
significant contribution to this revision.
The ABNF specifications of "User Certificate", "Authority Revocation 8. IANA Considerations
List", and "Certificate Pair" in RFC 1778 [RFC1778] are not to
be used.
5.3 Securing the Directory It is requested that the Internet Assigned Numbers Authority (IANA)
update the LDAP descriptors registry as indicated by the following
two templates:
In order to protect the directory and its contents, strong Subject: Request for LDAP Descriptor Registration Update
authentication MUST have been used to identify the Client when an Descriptor (short name): see comment
update operation is requested. Object Identifier: see comment
Person & email address to contact for further information:
Steven Legg <steven.legg@adacel.com.au>
Usage: see comment
Specification: RFC XXXX
Author/Change Controller: IESG
Comments:
6. Acknowledgements The following descriptors (short names) should be updated to refer
to RFC XXXX.
This document is an update of RFC 2252 by M. Wahl, A. Coulbeck, NAME Type OID
T. Howes, and S. Kille. RFC 2252 was a product of the IETF ASID ------------------------------------------------------------------
Working Group. bitStringMatch M 2.5.13.16
caseExactIA5Match M 1.3.6.1.4.1.1466.109.114.1
caseIgnoreIA5Match M 1.3.6.1.4.1.1466.109.114.2
caseIgnoreListMatch M 2.5.13.11
caseIgnoreMatch M 2.5.13.2
caseIgnoreOrderingMatch M 2.5.13.3
caseIgnoreSubstringsMatch M 2.5.13.4
distinguishedNameMatch M 2.5.13.1
generalizedTimeMatch M 2.5.13.27
generalizedTimeOrderingMatch M 2.5.13.28
integerFirstComponentMatch M 2.5.13.29
integerMatch M 2.5.13.14
numericStringMatch M 2.5.13.8
numericStringSubstringsMatch M 2.5.13.10
objectIdentifierFirstComponentMatch M 2.5.13.31
octetStringMatch M 2.5.13.17
telephoneNumberMatch M 2.5.13.20
telephoneNumberSubstringsMatch M 2.5.13.21
uniqueMemberMatch M 2.5.13.23
This document is based upon input of the IETF LDAPBIS working group. The descriptor for the object identifier 2.5.13.0 was incorrectly
The authors wish to thank J. Sermersheim and K. Zeilenga for their registered as objectIdentifiersMatch (extraneous `s') in RFC 3383.
significant contribution to this update. It should be changed to the following with a reference to RFC
XXXX.
7. Authors' Addresses NAME Type OID
------------------------------------------------------------------
objectIdentifierMatch M 2.5.13.0
Kathy Dally Subject: Request for LDAP Descriptor Registration
The MITRE Corp. Descriptor (short name): caseIgnoreIA5SubstringsMatch
7515 Colshire Dr., ms-W650 Object Identifier: 1.3.6.1.4.1.1466.109.114.3
McLean VA 22102 Person & email address to contact for further information:
USA Steven Legg <steven.legg@adacel.com.au>
Usage: other (M)
Specification: RFC XXXX
Author/Change Controller: IESG
Phone: +1 703 883 6058 9. Normative References
Fax: +1 703 883 7142
Email: kdally@mitre.org
Steven Legg [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
Adacel Technologies Ltd. Requirement Levels", BCP 14, RFC 2119, March 1997.
405-409 Ferntree Gully Road
Mount Waverley, Victoria 3149
AUSTRALIA
Phone: +61 3 9451 2107 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Fax: +61 3 9541 2121 Specifications: ABNF", RFC 2234, November 1997.
EMail: steven.legg@adacel.com.au
8. References [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998.
8.1 Normative [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64, RFC
3383, September 2002.
[ABNF] Crocker, D., Overell, P., "Augmented BNF for Syntax [LDAPDN] Zeilenga, K., "LDAP: String Representation of
Specifications: ABNF", RFC 2234, November 1997 Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work
in progress, August 2002.
[PROT] Sermersheim, J., "LDAP: The Protocol", draft-ietf-ldapbis-
protocol-xx.txt, a work in progress, December 2002.
[E.123] Notation for national and international telephone numbers, [E.123] Notation for national and international telephone numbers,
ITU-T Recommendation E.123, 1988. ITU-T Recommendation E.123, 1988.
[IA5] International Reference Alphabet (IRA) (Formerly International [FAX] Standardization of Group 3 facsimile apparatus for
Alphabet No. 5 or IA5) Information Technology - 7-Bit Coded document transmission - Terminal Equipment and Protocols
Character Set for Information Interchange, ITU-T Recommendation for Telematic Services, ITU-T Recommendation T.4, 1993
T.50, 1992
[ISO3166] ISO 3166, "Codes for the representation of names [T.50] International Reference Alphabet (IRA) (Formerly
of countries". International Alphabet No. 5 or IA5) Information
Technology - 7-Bit Coded Character Set for Information
Interchange, ITU-T Recommendation T.50, 1992
[ISO10646] Universal Multiple-Octet Coded Character Set (UCS) - [X.420] ITU-T Recommendation X.420 (1996) | ISO/IEC 10021-7:1997,
Architecture and Basic Multilingual Plane, Information Technology - Message Handling Systems (MHS):
ISO/IEC 10646-1: 1993 (with amendments). Interpersonal messaging system
[JPEG] JPEG File Interchange Format (Version 1.02). Eric Hamilton, [X.501] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994,
C-Cube Microsystems, Milpitas, CA, September 1, 1992. Information Technology - Open Systems Interconnection -
The Directory: Models
[LDAPDN] K. Zeilenga (editor), "LDAP: String Representation of [X.520] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994,
Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, (a Information Technology - Open Systems Interconnection -
work in progress). The Directory: Selected attribute types
[Protocol] J. Sermersheim (editor), "LDAP: The Protocol", [ASN.1] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998
draft-ietf-ldapbis-protocol-xx.txt, a work in progress. Information Technology - Abstract Syntax Notation One
(ASN.1): Specification of basic notation
[RFC1327] Hardcastle-Kille, S., "Mapping between X.400(1988)/ [ISO3166] ISO 3166, "Codes for the representation of names of
ISO 10021 and RFC 822", RFC 1327, May 1992. countries".
[RFC2044] Yergeau, F., "UTF-8, a transformation format of Unicode [UCS] Universal Multiple-Octet Coded Character Set (UCS) -
and ISO 10646", RFC 2044, October 1996. Architecture and Basic Multilingual Plane, ISO/IEC
10646-1: 1993 (with amendments).
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [JPEG] JPEG File Interchange Format (Version 1.02). Eric
Requirement Levels", RFC 2119, March 1997. Hamilton, C-Cube Microsystems, Milpitas, CA, September 1,
1992.
[RFC 2256] draft-ietf-ldapbis-user-schema-xx, replacement for Wahl, M., 10. Informative References
"A Summary of the X.500(96) User Schema for use with LDAPv3",
RFC 2256, December 1997.
[T.4] Standardization of Group 3 facsimile apparatus for document [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
transmission - Terminal Equipment and Protocols for Telematic "Lightweight Directory Access Protocol (v3): Attribute
Services, ITU-T Recommendation T.4, 1993 Syntax Definitions", RFC 2252, December 1997.
[X.501] The Directory: Models, ITU-T Recommendation X.501, 1993. [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use
with LDAPv3", RFC 2256, December 1997.
[X.520] The Directory: Selected Attribute Types. ITU-T [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
Recommendation X.520, 1993. Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[X.680] Information Technology - Abstract Syntax Notation One [X.500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
(ASN.1): Specification of Basic Notation, ITU-T Recommendation Information Technology - Open Systems Interconnection -
X.680, 1994 The Directory: Overview of concepts, models and services
8.2 Informative References [BER] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998
Information Technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)
[ISO8348] Information technology -- Open Systems Interconnection -- 11. Authors' Addresses
Network Service Definition, ISO/IEC 8348:1996
[RFC1777] Yeong, W., Howes, T., Kille, S., "Lightweight Directory Steven Legg
Access Protocol", RFC 1777, March 1995 Adacel Technologies Ltd.
405-409 Ferntree Gully Road
Mount Waverley, Victoria 3149
AUSTRALIA
[RFC1778] Howes, T., Kille, S., Yeong, W., Robbins, C., "The Phone: +61 3 9451 2107
String Representation of Standard Attribute Syntaxes", RFC 1778, Fax: +61 3 9541 2121
March 1995. Email: steven.legg@adacel.com.au
[RFC2253] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory Kathy Dally
Access Protocol (v3): UTF-8 String Representation of The MITRE Corp.
Distinguished Names", RFC 2253, December 1997. 7515 Colshire Dr., ms-W650
McLean VA 22102
USA
9. Full Copyright Statement Phone: +1 703 883 6058
Fax: +1 703 883 7142
Email: kdally@mitre.org
12. Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph are
are included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other followed, or as required to translate it into languages other than
than English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Annex A Object Identifiers of Syntaxes Appendix A. Summary of Syntax Object Identifiers
This list contains the object identifiers for the syntaxes used in The following list summarizes the object identifiers assigned to the
this specification and in the user schema specification [User]. syntaxes defined in this document.
Syntax of Value Represented OBJECT IDENTIFIER Syntax OBJECT IDENTIFIER
===================================================================== ==============================================================
Attribute Type Description 1.3.6.1.4.1.1466.115.121.1.3 Attribute Type Description 1.3.6.1.4.1.1466.115.121.1.3
Bit String 1.3.6.1.4.1.1466.115.121.1.6 Bit String 1.3.6.1.4.1.1466.115.121.1.6
Boolean 1.3.6.1.4.1.1466.115.121.1.7 Boolean 1.3.6.1.4.1.1466.115.121.1.7
Country String 1.3.6.1.4.1.1466.115.121.1.11 Country String 1.3.6.1.4.1.1466.115.121.1.11
Delivery Method 1.3.6.1.4.1.1466.115.121.1.14 Delivery Method 1.3.6.1.4.1.1466.115.121.1.14
Directory String 1.3.6.1.4.1.1466.115.121.1.15 Directory String 1.3.6.1.4.1.1466.115.121.1.15
DIT Content Rule Description 1.3.6.1.4.1.1466.115.121.1.16 DIT Content Rule Description 1.3.6.1.4.1.1466.115.121.1.16
DIT Structure Rule Description 1.3.6.1.4.1.1466.115.121.1.17 DIT Structure Rule Description 1.3.6.1.4.1.1466.115.121.1.17
DN 1.3.6.1.4.1.1466.115.121.1.12 DN 1.3.6.1.4.1.1466.115.121.1.12
Enhanced Guide 1.3.6.1.4.1.1466.115.121.1.21 Enhanced Guide 1.3.6.1.4.1.1466.115.121.1.21
Facsimile Telephone Number 1.3.6.1.4.1.1466.115.121.1.22 Facsimile Telephone Number 1.3.6.1.4.1.1466.115.121.1.22
Fax 1.3.6.1.4.1.1466.115.121.1.23 Fax 1.3.6.1.4.1.1466.115.121.1.23
Generalized Time 1.3.6.1.4.1.1466.115.121.1.24 Generalized Time 1.3.6.1.4.1.1466.115.121.1.24
Guide 1.3.6.1.4.1.1466.115.121.1.25 Guide 1.3.6.1.4.1.1466.115.121.1.25
IA5 String 1.3.6.1.4.1.1466.115.121.1.26 IA5 String 1.3.6.1.4.1.1466.115.121.1.26
INTEGER 1.3.6.1.4.1.1466.115.121.1.27 Integer 1.3.6.1.4.1.1466.115.121.1.27
JPEG 1.3.6.1.4.1.1466.115.121.1.28 JPEG 1.3.6.1.4.1.1466.115.121.1.28
LDAP Syntax Description 1.3.6.1.4.1.1466.115.121.1.54 LDAP Syntax Description 1.3.6.1.4.1.1466.115.121.1.54
Matching Rule Description 1.3.6.1.4.1.1466.115.121.1.31 Matching Rule Description 1.3.6.1.4.1.1466.115.121.1.30
Matching Rule Use Description 1.3.6.1.4.1.1466.115.121.1.31 Matching Rule Use Description 1.3.6.1.4.1.1466.115.121.1.31
MHS OR Address 1.3.6.1.4.1.1466.115.121.1.33
Name And Optional UID 1.3.6.1.4.1.1466.115.121.1.34 Name And Optional UID 1.3.6.1.4.1.1466.115.121.1.34
Name Form Description 1.3.6.1.4.1.1466.115.121.1.35 Name Form Description 1.3.6.1.4.1.1466.115.121.1.35
Numeric String 1.3.6.1.4.1.1466.115.121.1.36 Numeric String 1.3.6.1.4.1.1466.115.121.1.36
Object Class Description 1.3.6.1.4.1.1466.115.121.1.37 Object Class Description 1.3.6.1.4.1.1466.115.121.1.37
Octet String 1.3.6.1.4.1.1466.115.121.1.40 Octet String 1.3.6.1.4.1.1466.115.121.1.40
OID 1.3.6.1.4.1.1466.115.121.1.38 OID 1.3.6.1.4.1.1466.115.121.1.38
Other Mailbox 1.3.6.1.4.1.1466.115.121.1.39 Other Mailbox 1.3.6.1.4.1.1466.115.121.1.39
Postal Address 1.3.6.1.4.1.1466.115.121.1.41 Postal Address 1.3.6.1.4.1.1466.115.121.1.41
Presentation Address 1.3.6.1.4.1.1466.115.121.1.43
Printable String 1.3.6.1.4.1.1466.115.121.1.44 Printable String 1.3.6.1.4.1.1466.115.121.1.44
Substring Assertion 1.3.6.1.4.1.1466.115.121.1.58 Substring Assertion 1.3.6.1.4.1.1466.115.121.1.58
Telephone Number 1.3.6.1.4.1.1466.115.121.1.50 Telephone Number 1.3.6.1.4.1.1466.115.121.1.50
Teletex Terminal Identifier 1.3.6.1.4.1.1466.115.121.1.51 Teletex Terminal Identifier 1.3.6.1.4.1.1466.115.121.1.51
Telex Number 1.3.6.1.4.1.1466.115.121.1.52 Telex Number 1.3.6.1.4.1.1466.115.121.1.52
UTC Time 1.3.6.1.4.1.1466.115.121.1.53 UTC Time 1.3.6.1.4.1.1466.115.121.1.53
Annex B Topics Yet To Be Addressed In This Document
This appendix is provided for informational purposes only, it is not
a normative part of this specification.
APPEARED: -00
Paragraph 2.2.3 - Should any syntaxes listed in the table be removed?
Should any new syntaxes be added?
RESOLUTION: Cannot add syntaxes. Moving the table to an annex keeps
a record of the OIDS that have been assigned. Deleted unspecified
syntaxes from the list. APPLIED: -02
APPEARED: -00
Paragraph 2.2.4 - Should attribute syntaxes be allowed to be referenced
by a common name, and if so, where should the name come from?
RESOLUTION: Rejected because of adding functionality. APPLIED: -01
APPEARED: -00
How does the data model draft <draft-wahl-ladpv3-defns-01.txt> affect
this draft?
RESOLUTION: It does not. The draft was preliminary to the revised
Schema and Protocol I-Ds. APPLIED: -01
APPEARED: -00
Section 3 - Should all listed syntaxes from paragraph 2.2.3 be
detailed in this section? Nearly half the listed syntaxes are not
referenced in this section.
RESOLUTION: No, because many are not being used, currently.
APPLIED: -01
APPEARED: -01
Section 4 - Should all of the X.520(1993) matching rules be included?
In particular, how about caseExactMatch? Also, should
octetStringMatch be moved from updated RFC 2256?
RESOLUTION: caseExactMatch not included. octetStringMatch moved to
this document. APPLIED: -01
APPEARED: -00
Section 6 - Recognized list of Object classes needs to be reconciled
with updated RFC 2256 and the data model draft.
RESOLUTION: Not necessary. APPLIED: -01
APPEARED: -00
Section 7 - Proper security statement needs to be formulated.
RESOLUTION: Text has been expanded since RFC 2252, but needs
more work. APPLIED:
Annex C Change Log
This annex lists the changes that have been made from RFC 2252 to
this specification.
This annex is provided for informational purposes only. It is not
a normative part of this specification. Items 32 - end are new in
the -02 version of this document.
-00 changes
1. Removed the IESG Note.
2. Changed "types" to "syntaxes" in the last sentence of the
Abstract. Also, added to the last sentence in order to
indicate that syntaxes are not the only schema elements
defined in this document.
3. Reorganized the sections so that:
* the schema element categories are specified in the
order in which they build on one another: syntaxes,
matching rules, attributes, object classes
* within each category the elements are specified in
alphbetical order
4. Added an "Implementation Status" paragraph for each element,
gathering the conformance statements.
5. Clarified schema description in the Overview.
6. Changed the "Common Encoding Aspects" section title to
"Notation" and made corresponding changes throughout the
document. The purpose being to relegate all encoding issues
to the Protocol specification [Protocol].
7. Added a MUST statement regarding the syntaxes required of
servers.
8. Expanded the discussion of each of the syntaxes in section 3.
9. Added examples to some of the syntax descriptions.
10. Added NAME option to the syntax description ABNF
in 2.2.4.
RESCINDED IN -01!!
11. Added a note deprecating the UTCTime attribute syntax
description in 3.41
12. In the ABNF of the MatchingRuleDescription in paragraph 2.3.2,
replaced "numericoid" with "oid".
13. In paragraph 2.4.1, replaced the conformance statement about
attributes in 2256 with a reference.
14. Added caseIgnoreIA5Match as the EQUALITY matching rule for
the altServer attribute type ABNF in paragraph 5.1. Note that
this could be caseExactIA5Match instead. SHOULD IT BE??
RESCINDED IN -01
15. In paragraphs 5.10 and 5.11, changed "the MODIFY operation"
to "LDAP update operations"
16. Added distinguishedNameMatch as the EQUALITY matching rule Appendix B. Changes from RFC 2252 & RFC 2256
for the namingContexts attribute type ABNF in paragraph 5.13.
RESCINDED IN -01
17. Reworded paragraph 5.15. This annex lists the significant differences between this
specification and RFC 2252 and Sections 6 and 8 of RFC 2256.
18. Added distinguishedNameMatch as the EQUALITY matching rule This annex is provided for informational purposes only. It is not a
for the namingContexts attribute type ABNF in paragraph 5.13. normative part of this specification.
RESCINDED IN -01 1. The IESG Note has been removed.
19. Added integerMatch as the EQUALITY and integerOrderingMatch 2. The major part of Sections 4, 5 and 7 has been moved to [MODELS]
as the Ordering matching rules for the supportedLDAPVersion and revised. Changes to the parts of these sections moved to
attribute type ABNF in paragraph 5.18. [MODELS] are detailed in [MODELS].
RESCINDED IN -01 3. BNF descriptions of syntax formats have been replaced by ABNF
[ABNF] specifications.
20. Added caseIgnoreMatch as the EQUALITY matching rule for the 4. The ambiguous statement in RFC 2252, Section 4.3 regarding the
supportedSASLMechanisms attribute type ABNF in paragraph 5.19. use of a backslash quoting mechanism to escape separator symbols
Note that this could be caseExactMatch instead. SHOULD has been removed. The escaping mechanism is now explicitly
IT BE?? represented in the ABNF for the syntaxes where this provision
applies.
RESCINDED IN -01 5. The description of each of the LDAP syntaxes has been expanded so
that they are less dependent on knowledge of X.500 for
interpretation.
21. Made corrections to the ABNF in paragraph 3.12. 6. The relationship of LDAP syntaxes to corresponding ASN.1 type
definitions has been made explicit.
22. Added the seven syntax definitions from RFC 2256 and ordered 7. The set of characters allowed in a <PrintableString> (formerly
the definitions alphabetically. <printablestring>) has been corrected to align with the
PrintableString ASN.1 type in [ASN.1]. Specifically, the double
quote character has been removed and the single quote character
and equals sign have been added.
23. Changed the "Bibliography" section title to "References". 8. Values of the Directory String, Printable String and Telephone
Number syntaxes are now required to have at least one character.
24. Replaced the X.208 reference with one to X.680(1994), since 9. The <DITContentRuleDescription>, <NameFormDescription> and
X.680 is the ASN.1 referred to in the X.500(1993)-series. <DITStructureRuleDescription> rules have been moved to [MODELS].
-01 changes 10. The corresponding ASN.1 type for the Other Mailbox syntax has
been incorporated from RFC 1274.
25. Moved the table listing the syntaxes and their oids from 11. A corresponding ASN.1 type for the LDAP Syntax Description syntax
paragraph 2.2.3 to a new Annex A. has been invented.
REMOVED SYNTAXES NOT DEFINED IN THIS I-D FROM THE LIST - 02 12. The Binary syntax has been removed because it was not adequately
specified, implementations with different incompatible
interpretations exist, and it was confused with the ;binary
transfer encoding.
26. Moved the specification of the octetStringMatch matching rule 13. All discussion of transfer options, including the ";binary"
from RFC 2256 to section 4 of this document. option, has been removed. All imperatives regarding binary
transfer of values have been removed.
27. Throughout this I-D, cleaned up whitespace in the ABNF definitions. 14. The Delivery Method, Enhanced Guide, Guide, Octet String, Teletex
Terminal Identifier and Telex Number syntaxes from RFC 2256 have
been incorporated.
28. In Section 2.1: 15. The <criteria> rule for the Enhanced Guide and Guide syntaxes has
* Corrected the characters defined in the p rule to match been extended to accommodate empty "and" and "or" expressions.
the PrintableString syntax.
* Deleted the letterstring rule.
* Modified the utf8 and dstring rules according to a
suggestion from K. Zeilenga.
* Deleted ";" from the keychar rule, which affects the
anhstring, keystring, and descr rules.
* Removed the length option from the numericoid rule
29. In section 2.2, deleted the sentence about needing a new OID 16. An encoding for the <ttx-value> rule in the Teletex Terminal
when a syntax is modified. Identifier syntax has been defined.
30. In section 2.2, replaced the editor's proposal and subject 17. The PKI-related syntaxes (Certificate, Certificate List and
text with explanation of the LDAP-specific encoding of Certificate Pair from RFC 2252, and Supported Algorithm syntax
attribute values. from RFC 2256) have been removed. They are to be reintroduced in
PKIX documents.
31. Removed section 2.2.2 (and renumbered the remainder of 18. The MHS OR Address syntax has been removed since its
section 2.2), leaving the description of binary encoding to specification (in RFC 2156) is not at draft standard maturity.
the protocol I-D.
-02 changes 19. The DL Submit Permission syntax has been removed as it depends on
the MHS OR Address syntax.
32. Revised specifications to use ABNF [ABNF] instead of BNF 20. The Presentation Address syntax has been removed since its
throughout the document. specification (in RFC 1278) is not at draft standard maturity.
33. Removed embedded comments from the ABNF productions 21. The ACI Item, Access Point, Audio, Data Quality, DSA Quality, DSE
throughout the document. Type, LDAP Schema Description, Master And Shadow Access Points,
Modify Rights, Protocol Information, Subtree Specification,
Supplier Information, Supplier Or Consumer and Supplier And
Consumer syntaxes have been removed. These syntaxes are
referenced in RFC 2252, but not defined.
34. Removed the Binary syntax because it was not adequately 22. The LDAP Schema Definition syntax (defined in RFC 2927) and the
specified, implementations with different interpretations Mail Preference syntax have been removed on the grounds that they
exist, and it was confused with the ;binary transfer encoding. are out of scope for a core specification.
35. Removed the syntaxes, which are not defined in this document, 23. The description of each of the matching rules has been expanded
from the list in Annex A. Consult RFC 2252 for the so that they are less dependent on knowledge of X.500 for
assignments made previously for syntaxes that have not been interpretation.
defined to date.
36. Inserted the specification of the octetstring production, from 24. The caseIgnoreIA5SubstringsMatch matching rule from RFC 2798 has
RFC 2234 [ABNF].j been added.
37. Cleaned up the references; adopted word instead of number
tags; split Section 10 into normative and informative
subsections.
38. Inserted ABNF from RFC 1278 in place of a reference. 25. The caseIgnoreIA5SubstringsMatch, caseIgnoreOrderingMatch and
caseIgnoreSubstringsMatch matching rules have been added to the
list of matching rules for which the provisions for handling
leading, trailing and multiple adjoining whitespace characters
apply. This is consistent with the definitions of these matching
rules in X.500. The telephoneNumberMatch rule has been removed
from the list since it completely ignores all space characters.
39. Deleted the certificate-related syntaxes and noted in the 26. The specification of the octetStringMatch matching rule from RFC
Security Considerations (Section 7) that they are covered 2256 has been added to this document.
in PKIX WG documents.
-03 changes 27. The presentationAddressMatch matching rule has been removed as it
depends on an assertion syntax (Presentation Address) that is not
at draft standard maturity.
40. Removed all discussion of transfer options and the binary option. 28. The protocolInformationMatch matching rule has been removed as it
depends on an undefined assertion syntax (Protocol Information).
41. Aligned the text to the [MODELS] document. 29. The definitive reference for ASN.1 has been changed from X.208 to
X.680 since X.680 is the version of ASN.1 referred to by X.500.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/