draft-ietf-ldapbis-syntaxes-11.txt   rfc4517.txt 
INTERNET-DRAFT S. Legg Network Working Group S. Legg, Ed.
draft-ietf-ldapbis-syntaxes-11.txt eB2Bcom Request for Comments: 4517 eB2Bcom
Intended Category: Standards Track 23 June 2005 Obsoletes: 2252, 2256 June 2006
Obsoletes: RFC 2252, RFC 2256 Updates: RFC 3698 Updates: 3698
Category: Standards Track
Lightweight Directory Access Protocol (LDAP): Lightweight Directory Access Protocol (LDAP):
Syntaxes and Matching Rules Syntaxes and Matching Rules
Copyright (C) The Internet Society (2005). All Rights Reserved. Status of This Memo
Status of this Memo
By submitting this Internet-draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
By submitting this Internet-draft, I accept the provisions of Section
3 of BCP 78.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
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
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at This document specifies an Internet standards track protocol for the
http://www.ietf.org/shadow.html Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
This document is intended to be, after appropriate review and Copyright Notice
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@eb2bcom.com>.
This Internet-Draft expires on 23 December 2005. Copyright (C) The Internet Society (2006).
Abstract Abstract
Each attribute stored in a Lightweight Directory Access Protocol Each attribute stored in a Lightweight Directory Access Protocol
(LDAP) directory, and whose values may be transfered in the LDAP (LDAP) directory, whose values may be transferred in the LDAP
protocol, has a defined syntax which constrains the structure and protocol, has a defined syntax that constrains the structure and
format of its values. The comparison semantics for values of a format of its values. The comparison semantics for values of a
syntax are not part of the syntax definition but are instead provided syntax are not part of the syntax definition but are instead provided
through separately defined matching rules. Matching rules specify an through separately defined matching rules. Matching rules specify an
argument, an assertion value, which also has a defined syntax. This argument, an assertion value, which also has a defined syntax. This
document defines a base set of syntaxes and matching rules for use in document defines a base set of syntaxes and matching rules for use in
defining attributes for LDAP directories. defining attributes for LDAP directories.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions .....................................................4
3. Syntaxes . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Syntaxes ........................................................4
3.1. General Considerations . . . . . . . . . . . . . . . . . 6 3.1. General Considerations .....................................5
3.2. Common Definitions . . . . . . . . . . . . . . . . . . . 7 3.2. Common Definitions .........................................5
3.3. Syntax Definitions . . . . . . . . . . . . . . . . . . . 7 3.3. Syntax Definitions .........................................6
3.3.1. Attribute Type Description . . . . . . . . . . . 7 3.3.1. Attribute Type Description ..........................6
3.3.2. Bit String . . . . . . . . . . . . . . . . . . . 8 3.3.2. Bit String ..........................................6
3.3.3. Boolean. . . . . . . . . . . . . . . . . . . . . 8 3.3.3. Boolean .............................................7
3.3.4. Country String . . . . . . . . . . . . . . . . . 8 3.3.4. Country String ......................................7
3.3.5. Delivery Method. . . . . . . . . . . . . . . . . 9 3.3.5. Delivery Method .....................................8
3.3.6. Directory String . . . . . . . . . . . . . . . . 9 3.3.6. Directory String ....................................8
3.3.7. DIT Content Rule Description . . . . . . . . . . 10 3.3.7. DIT Content Rule Description ........................9
3.3.8. DIT Structure Rule Description . . . . . . . . . 11 3.3.8. DIT Structure Rule Description .....................10
3.3.9. DN . . . . . . . . . . . . . . . . . . . . . . . 11 3.3.9. DN .................................................10
3.3.10. Enhanced Guide . . . . . . . . . . . . . . . . . 12 3.3.10. Enhanced Guide ....................................11
3.3.11. Facsimile Telephone Number . . . . . . . . . . . 13 3.3.11. Facsimile Telephone Number ........................12
3.3.12. Fax. . . . . . . . . . . . . . . . . . . . . . . 13 3.3.12. Fax ...............................................12
3.3.13. Generalized Time . . . . . . . . . . . . . . . . 14 3.3.13. Generalized Time ..................................13
3.3.14. Guide. . . . . . . . . . . . . . . . . . . . . . 15 3.3.14. Guide .............................................14
3.3.15. IA5 String . . . . . . . . . . . . . . . . . . . 16 3.3.15. IA5 String ........................................15
3.3.16. Integer. . . . . . . . . . . . . . . . . . . . . 16 3.3.16. Integer ...........................................15
3.3.17. JPEG . . . . . . . . . . . . . . . . . . . . . . 16 3.3.17. JPEG ..............................................15
3.3.18. LDAP Syntax Description. . . . . . . . . . . . . 17 3.3.18. LDAP Syntax Description ...........................16
3.3.19. Matching Rule Description. . . . . . . . . . . . 17 3.3.19. Matching Rule Description .........................16
3.3.20. Matching Rule Use Description. . . . . . . . . . 18 3.3.20. Matching Rule Use Description .....................17
3.3.21. Name and Optional UID. . . . . . . . . . . . . . 18 3.3.21. Name and Optional UID .............................17
3.3.22. Name Form Description. . . . . . . . . . . . . . 19 3.3.22. Name Form Description .............................18
3.3.23. Numeric String . . . . . . . . . . . . . . . . . 19 3.3.23. Numeric String ....................................18
3.3.24. Object Class Description . . . . . . . . . . . . 19 3.3.24. Object Class Description ..........................18
3.3.25. Octet String . . . . . . . . . . . . . . . . . . 20 3.3.25. Octet String ......................................19
3.3.26. OID. . . . . . . . . . . . . . . . . . . . . . . 20 3.3.26. OID ...............................................19
3.3.27. Other Mailbox. . . . . . . . . . . . . . . . . . 21 3.3.27. Other Mailbox .....................................20
3.3.28. Postal Address . . . . . . . . . . . . . . . . . 21 3.3.28. Postal Address ....................................20
3.3.29. Printable String . . . . . . . . . . . . . . . . 22 3.3.29. Printable String ..................................21
3.3.30. Substring Assertion. . . . . . . . . . . . . . . 23 3.3.30. Substring Assertion ...............................22
3.3.31. Telephone Number . . . . . . . . . . . . . . . . 23 3.3.31. Telephone Number ..................................23
3.3.32. Teletex Terminal Identifier. . . . . . . . . . . 24 3.3.32. Teletex Terminal Identifier .......................23
3.3.33. Telex Number . . . . . . . . . . . . . . . . . . 25 3.3.33. Telex Number ......................................24
3.3.34. UTC Time . . . . . . . . . . . . . . . . . . . . 25 3.3.34. UTC Time ..........................................24
4. Matching Rules . . . . . . . . . . . . . . . . . . . . . . . . 26 4. Matching Rules .................................................25
4.1. General Considerations . . . . . . . . . . . . . . . . . 26 4.1. General Considerations ....................................25
4.2. Matching Rule Definitions. . . . . . . . . . . . . . . . 28 4.2. Matching Rule Definitions .................................27
4.2.1. bitStringMatch . . . . . . . . . . . . . . . . . 28 4.2.1. bitStringMatch .....................................27
4.2.2. booleanMatch . . . . . . . . . . . . . . . . . . 29 4.2.2. booleanMatch .......................................28
4.2.3. caseExactIA5Match. . . . . . . . . . . . . . . . 29 4.2.3. caseExactIA5Match ..................................28
4.2.4. caseExactMatch . . . . . . . . . . . . . . . . . 30 4.2.4. caseExactMatch .....................................29
4.2.5. caseExactOrderingMatch . . . . . . . . . . . . . 30 4.2.5. caseExactOrderingMatch .............................29
4.2.6. caseExactSubstringsMatch . . . . . . . . . . . . 31 4.2.6. caseExactSubstringsMatch ...........................30
4.2.7. caseIgnoreIA5Match . . . . . . . . . . . . . . . 31 4.2.7. caseIgnoreIA5Match .................................30
4.2.8. caseIgnoreIA5SubstringsMatch . . . . . . . . . . 32 4.2.8. caseIgnoreIA5SubstringsMatch .......................31
4.2.9. caseIgnoreListMatch. . . . . . . . . . . . . . . 32 4.2.9. caseIgnoreListMatch ................................31
4.2.10. caseIgnoreListSubstringsMatch. . . . . . . . . . 33 4.2.10. caseIgnoreListSubstringsMatch .....................32
4.2.11. caseIgnoreMatch. . . . . . . . . . . . . . . . . 33 4.2.11. caseIgnoreMatch ...................................33
4.2.12. caseIgnoreOrderingMatch. . . . . . . . . . . . . 34 4.2.12. caseIgnoreOrderingMatch ...........................33
4.2.13. caseIgnoreSubstringsMatch. . . . . . . . . . . . 34 4.2.13. caseIgnoreSubstringsMatch .........................34
4.2.14. directoryStringFirstComponentMatch . . . . . . . 35 4.2.14. directoryStringFirstComponentMatch ................34
4.2.15. distinguishedNameMatch . . . . . . . . . . . . . 36 4.2.15. distinguishedNameMatch ............................35
4.2.16. generalizedTimeMatch . . . . . . . . . . . . . . 36 4.2.16. generalizedTimeMatch ..............................36
4.2.17. generalizedTimeOrderingMatch . . . . . . . . . . 37 4.2.17. generalizedTimeOrderingMatch ......................36
4.2.18. integerFirstComponentMatch . . . . . . . . . . . 37 4.2.18. integerFirstComponentMatch ........................36
4.2.19. integerMatch . . . . . . . . . . . . . . . . . . 38 4.2.19. integerMatch ......................................37
4.2.20. integerOrderingMatch . . . . . . . . . . . . . . 38 4.2.20. integerOrderingMatch ..............................37
4.2.21. keywordMatch . . . . . . . . . . . . . . . . . . 38 4.2.21. keywordMatch ......................................38
4.2.22. numericStringMatch . . . . . . . . . . . . . . . 39 4.2.22. numericStringMatch ................................38
4.2.23. numericStringOrderingMatch . . . . . . . . . . . 39 4.2.23. numericStringOrderingMatch ........................39
4.2.24. numericStringSubstringsMatch . . . . . . . . . . 40 4.2.24. numericStringSubstringsMatch ......................39
4.2.25. objectIdentifierFirstComponentMatch. . . . . . . 40 4.2.25. objectIdentifierFirstComponentMatch ...............40
4.2.26. objectIdentifierMatch. . . . . . . . . . . . . . 41 4.2.26. objectIdentifierMatch .............................40
4.2.27. octetStringMatch . . . . . . . . . . . . . . . . 41 4.2.27. octetStringMatch ..................................41
4.2.28. octetStringOrderingMatch . . . . . . . . . . . . 42 4.2.28. octetStringOrderingMatch ..........................41
4.2.29. telephoneNumberMatch . . . . . . . . . . . . . . 42 4.2.29. telephoneNumberMatch ..............................42
4.2.30. telephoneNumberSubstringsMatch . . . . . . . . . 43 4.2.30. telephoneNumberSubstringsMatch ....................42
4.2.31. uniqueMemberMatch. . . . . . . . . . . . . . . . 44 4.2.31. uniqueMemberMatch .................................43
4.2.32. wordMatch. . . . . . . . . . . . . . . . . . . . 44 4.2.32. wordMatch .........................................44
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 44 5. Security Considerations ........................................44
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45 6. Acknowledgements ...............................................44
7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 45 7. IANA Considerations ............................................45
Appendix A. Summary of Syntax Object Identifiers . . . . . . . . . 47 8. References .....................................................46
Appendix B. Changes from RFC 2252. . . . . . . . . . . . . . . . . 48 8.1. Normative References ......................................46
Normative References . . . . . . . . . . . . . . . . . . . . . . . 50 8.2. Informative References ....................................48
Informative References . . . . . . . . . . . . . . . . . . . . . . 52 Appendix A. Summary of Syntax Object Identifiers ..................49
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 53 Appendix B. Changes from RFC 2252 .................................49
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 53
1. Introduction 1. Introduction
Each attribute stored in a Lightweight Directory Access Protocol Each attribute stored in a Lightweight Directory Access Protocol
(LDAP) directory [ROADMAP], and whose values may be transfered in the (LDAP) directory [RFC4510], whose values may be transferred in the
LDAP protocol [PROT], has a defined syntax (i.e., data type) which LDAP protocol [RFC4511], has a defined syntax (i.e., data type) that
constrains the structure and format of its values. The comparison constrains the structure and format of its values. The comparison
semantics for values of a syntax are not part of the syntax semantics for values of a syntax are not part of the syntax
definition but are instead provided through separately defined definition but are instead provided through separately defined
matching rules. Matching rules specify an argument, an assertion matching rules. Matching rules specify an argument, an assertion
value, which also has a defined syntax. This document defines a base value, which also has a defined syntax. This document defines a base
set of syntaxes and matching rules for use in defining attributes for set of syntaxes and matching rules for use in defining attributes for
LDAP directories. LDAP directories.
Readers are advised to familiarize themselves with the Directory Readers are advised to familiarize themselves with the Directory
Information Models [MODELS] before reading the rest of this document. Information Models [RFC4512] before reading the rest of this
Section 3 provides definitions for the base set of LDAP syntaxes. document. Section 3 provides definitions for the base set of LDAP
Section 4 provides definitions for the base set of matching rules for syntaxes. Section 4 provides definitions for the base set of
LDAP. matching rules for LDAP.
This document is a integral part of the LDAP technical specification This document is an integral part of the LDAP technical specification
[ROADMAP] which obsoletes the previously defined LDAP technical [RFC4510], which obsoletes the previously defined LDAP technical
specification [RFC3377] in its entirety. specification, RFC 3377, in its entirety.
Sections 4, 5 and 7 of RFC 2252 [RFC2252] are obsoleted by [MODELS]. Sections 4, 5, and 7 of RFC 2252 are obsoleted by [RFC4512]. The
The remainder of RFC 2252 is obsoleted by this document. Sections 6 remainder of RFC 2252 is obsoleted by this document. Sections 6 and
and 8 of RFC 2256 [RFC2256] are obsoleted by this document. The 8 of RFC 2256 are obsoleted by this document. The remainder of RFC
remainder of RFC 2256 is obsoleted by [SCHEMA] and [MODELS]. All but 2256 is obsoleted by [RFC4519] and [RFC4512]. All but Section 2.11
Section 2.11 of RFC 3698 [RFC3698] is obsoleted by this document. of RFC 3698 is obsoleted by this document.
A number of schema elements which were included in the previous A number of schema elements that were included in the previous
revision of the LDAP technical specification are not included in this revision of the LDAP technical specification are not included in this
revision of LDAP. Public Key Infrastructure schema elements are now revision of LDAP. Public Key Infrastructure schema elements are now
specified in [LDAP-PKI]. Unless reintroduced in future technical specified in [RFC4523]. Unless reintroduced in future technical
specifications, the remainder are to be considered Historic. specifications, the remainder are to be considered Historic.
The changes with respect to RFC 2252 are described in Appendix B of The changes with respect to RFC 2252 are described in Appendix B of
this document. this document.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
document are to be interpreted as described in BCP 14, RFC 2119 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
[KEYWORD]. [RFC2119].
Syntax definitions are written according to the <SyntaxDescription> Syntax definitions are written according to the <SyntaxDescription>
ABNF [ABNF] rule specified in [MODELS], and matching rule definitions ABNF [RFC4234] rule specified in [RFC4512], and matching rule
are written according to the <MatchingRuleDescription> ABNF rule definitions are written according to the <MatchingRuleDescription>
specified in [MODELS], except that the syntax and matching rule ABNF rule specified in [RFC4512], except that the syntax and matching
definitions provided in this document are line-wrapped for rule definitions provided in this document are line-wrapped for
readability. When such definitions are transfered as attribute readability. When such definitions are transferred as attribute
values in the LDAP protocol (e.g., as values of the ldapSyntaxes and values in the LDAP protocol (e.g., as values of the ldapSyntaxes and
matchingRules attributes [MODELS] respectively) then those values matchingRules attributes [RFC4512], respectively), then those values
would not contain line breaks. would not contain line breaks.
3. Syntaxes 3. Syntaxes
Syntax definitions constrain the structure of attribute values stored Syntax definitions constrain the structure of attribute values stored
in an LDAP directory, and determine the representation of attribute in an LDAP directory, and determine the representation of attribute
and assertion values transfered in the LDAP protocol. and assertion values transferred in the LDAP protocol.
Syntaxes that are required for directory operation, or that are in Syntaxes that are required for directory operation, or that are in
common use, are specified in this section. Servers SHOULD recognize common use, are specified in this section. Servers SHOULD recognize
all the syntaxes listed in this document, but are not required to all the syntaxes listed in this document, but are not required to
otherwise support them, and MAY recognise or support other syntaxes. otherwise support them, and MAY recognise or support other syntaxes.
However, the definition of additional arbitrary syntaxes is However, the definition of additional arbitrary syntaxes is
discouraged since it will hinder interoperability. Client and server discouraged since it will hinder interoperability. Client and server
implementations typically do not have the ability to dynamically implementations typically do not have the ability to dynamically
recognize new syntaxes. recognize new syntaxes.
3.1. General Considerations 3.1. General Considerations
The description of each syntax specifies how attribute or assertion The description of each syntax specifies how attribute or assertion
values conforming to the syntax are to be represented when transfered values conforming to the syntax are to be represented when
in the LDAP protocol [PROT]. This representation is referred to as transferred in the LDAP protocol [RFC4511]. This representation is
the LDAP-specific encoding to distinguish it from other methods of referred to as the LDAP-specific encoding to distinguish it from
encoding attribute values (e.g., the Basic Encoding Rules (BER) other methods of encoding attribute values (e.g., the Basic Encoding
encoding [BER] used by X.500 [X.500] directories). Rules (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, produces octet-aligned values. To the greatest extent possible,
encoding rules for LDAP syntaxes should produce character strings encoding rules for LDAP syntaxes should produce character 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. However, clients MUST NOT assume that the implementing LDAP. However, clients MUST NOT assume that the LDAP-
LDAP-specific encoding of a value of an unrecognized syntax is a specific encoding of a value of an unrecognized syntax is a human-
human-readable character string. There are a few cases (e.g., the readable character string. There are a few cases (e.g., the JPEG
JPEG syntax) when it is not reasonable to produce a human-readable syntax) when it is not reasonable to produce a human-readable
representation. representation.
Each LDAP syntax is uniquely identified with an object identifier Each LDAP syntax is uniquely identified with an object identifier
[ASN.1] represented in the dotted-decimal format (short descriptive [ASN.1] represented in the dotted-decimal format (short descriptive
names are not defined for syntaxes). These object identifiers are names are not defined for syntaxes). These object identifiers are
not intended to be displayed to users. The object identifiers for not intended to be displayed to users. The object identifiers for
the syntaxes defined in this document are summarized in Appendix A. the syntaxes defined in this document are summarized in Appendix A.
A suggested minimum upper bound on the number of characters in an A suggested minimum upper bound on the number of characters in an
attribute value with a string-based syntax, or the number of octets attribute value with a string-based syntax, or the number of octets
in a value for all other syntaxes, MAY be indicated by appending the in a value for all other syntaxes, MAY be indicated by appending the
bound inside of curly braces following the syntax's OBJECT IDENTIFIER bound inside of curly braces following the syntax's OBJECT IDENTIFIER
in an attribute type definition (see the <noidlen> rule in [MODELS]). in an attribute type definition (see the <noidlen> rule in
Such a bound is not considered part of the syntax identifier. [RFC4512]). Such a bound is not considered part of the syntax
identifier.
For example, "1.3.6.1.4.1.1466.115.121.1.15{64}" in an attribute 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 definition suggests that the directory server will allow a value of
the attribute to be up to 64 characters long, although it may allow the attribute to be up to 64 characters long, although it may allow
longer character strings. Note that a single character of the longer character strings. Note that a single character of the
Directory String syntax can be encoded in more than one octet since Directory String syntax can be encoded in more than one octet, since
UTF-8 [UTF8] is a variable-length encoding. Therefore a 64 character UTF-8 [RFC3629] is a variable-length encoding. Therefore, a 64-
string may be more than 64 octets in length. character string may be more than 64 octets in length.
3.2. Common Definitions 3.2. Common Definitions
The following ABNF rules are used in a number of the syntax The following ABNF rules are used in a number of the syntax
definitions in Section 3.3. definitions in Section 3.3.
PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN / PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN /
PLUS / COMMA / HYPHEN / DOT / EQUALS / PLUS / COMMA / HYPHEN / DOT / EQUALS /
SLASH / COLON / QUESTION / SPACE SLASH / COLON / QUESTION / SPACE
PrintableString = 1*PrintableCharacter PrintableString = 1*PrintableCharacter
IA5String = *(%x00-7F) IA5String = *(%x00-7F)
SLASH = %x2F ; forward slash ("/") SLASH = %x2F ; forward slash ("/")
COLON = %x3A ; colon (":") COLON = %x3A ; colon (":")
QUESTION = %x3F ; question mark ("?") QUESTION = %x3F ; question mark ("?")
The <ALPHA>, <DIGIT>, <SQUOTE>, <LPAREN>, <RPAREN>, <PLUS>, <COMMA>, The <ALPHA>, <DIGIT>, <SQUOTE>, <LPAREN>, <RPAREN>, <PLUS>, <COMMA>,
<HYPHEN>, <DOT>, <EQUALS> and <SPACE> rules are defined in [MODELS]. <HYPHEN>, <DOT>, <EQUALS>, and <SPACE> rules are defined in
[RFC4512].
3.3. Syntax Definitions 3.3. Syntax Definitions
3.3.1. Attribute Type Description 3.3.1. Attribute Type Description
A value of the Attribute Type Description syntax is the definition of A value of the Attribute Type Description syntax is the definition of
an attribute type. The LDAP-specific encoding of a value of this an attribute type. The LDAP-specific encoding of a value of this
syntax is defined by the <AttributeTypeDescription> rule in [MODELS]. syntax is defined by the <AttributeTypeDescription> rule in
[RFC4512].
For example, the following definition of the createTimestamp For example, the following definition of the createTimestamp
attribute type from [MODELS] is also a value of the Attribute Type attribute type from [RFC4512] is also a value of the Attribute
Description syntax (note: line breaks have been added for Type Description syntax. (Note: Line breaks have been added for
readability - they are not part of the value when transfered in readability; they are not part of the value when transferred in
protocol). protocol.)
( 2.5.18.1 NAME 'createTimestamp' ( 2.5.18.1 NAME 'createTimestamp'
EQUALITY generalizedTimeMatch EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE NO-USER-MODIFICATION SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation ) USAGE directoryOperation )
The LDAP definition for the Attribute Type Description syntax is: The LDAP definition for the Attribute Type Description syntax is:
skipping to change at page 8, line 15 skipping to change at page 7, line 5
3.3.2. Bit String 3.3.2. Bit String
A value of the Bit String syntax is a sequence of binary digits. The A value of the Bit String syntax is a sequence of binary digits. The
LDAP-specific encoding of a value of this syntax is defined by the LDAP-specific encoding of a value of this syntax is defined by the
following ABNF: following ABNF:
BitString = SQUOTE *binary-digit SQUOTE "B" BitString = SQUOTE *binary-digit SQUOTE "B"
binary-digit = "0" / "1" binary-digit = "0" / "1"
The <SQUOTE> rule is defined in [MODELS]. The <SQUOTE> rule is defined in [RFC4512].
Example: Example:
'0101111101'B '0101111101'B
The LDAP definition for the Bit String syntax is: The LDAP definition for the Bit String syntax is:
( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' ) ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' )
This syntax corresponds to the BIT STRING ASN.1 type from [ASN.1]. This syntax corresponds to the BIT STRING ASN.1 type from [ASN.1].
skipping to change at page 8, line 43 skipping to change at page 7, line 33
The LDAP definition for the Boolean syntax is: The LDAP definition for the Boolean syntax is:
( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' ) ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' )
This syntax corresponds to the BOOLEAN ASN.1 type from [ASN.1]. This syntax corresponds to the BOOLEAN ASN.1 type from [ASN.1].
3.3.4. Country String 3.3.4. Country String
A value of the Country String syntax is one of the two-character A value of the Country String syntax is one of the two-character
codes from ISO 3166 [ISO3166] for representing a country. The codes from ISO 3166 [ISO3166] for representing a country. The LDAP-
LDAP-specific encoding of a value of this syntax is defined by the specific encoding of a value of this syntax is defined by the
following ABNF: following ABNF:
CountryString = 2(PrintableCharacter) CountryString = 2(PrintableCharacter)
The <PrintableCharacter> rule is defined in Section 3.2. The <PrintableCharacter> rule is defined in Section 3.2.
Examples: Examples:
US US
AU AU
skipping to change at page 9, line 28 skipping to change at page 8, line 17
A value of the Delivery Method syntax is a sequence of items that A value of the Delivery Method syntax is a sequence of items that
indicate, in preference order, the service(s) by which an entity is indicate, in preference order, the service(s) by which an entity is
willing and/or capable of receiving messages. The LDAP-specific willing and/or capable of receiving messages. The LDAP-specific
encoding of a value of this syntax is defined by the following ABNF: encoding of a value of this syntax is defined by the following ABNF:
DeliveryMethod = pdm *( WSP DOLLAR WSP pdm ) DeliveryMethod = pdm *( WSP DOLLAR WSP pdm )
pdm = "any" / "mhs" / "physical" / "telex" / "teletex" / pdm = "any" / "mhs" / "physical" / "telex" / "teletex" /
"g3fax" / "g4fax" / "ia5" / "videotex" / "telephone" "g3fax" / "g4fax" / "ia5" / "videotex" / "telephone"
The <WSP> and <DOLLAR> rules are defined in [MODELS]. The <WSP> and <DOLLAR> rules are defined in [RFC4512].
Example: Example:
telephone $ videotex telephone $ videotex
The LDAP definition for the Delivery Method syntax is: The LDAP definition for the Delivery Method syntax is:
( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' ) ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' )
This syntax corresponds to the following ASN.1 type from [X.520]: This syntax corresponds to the following ASN.1 type from [X.520]:
skipping to change at page 10, line 4 skipping to change at page 8, line 41
physical-delivery (2), physical-delivery (2),
telex-delivery (3), telex-delivery (3),
teletex-delivery (4), teletex-delivery (4),
g3-facsimile-delivery (5), g3-facsimile-delivery (5),
g4-facsimile-delivery (6), g4-facsimile-delivery (6),
ia5-terminal-delivery (7), ia5-terminal-delivery (7),
videotex-delivery (8), videotex-delivery (8),
telephone-delivery (9) } telephone-delivery (9) }
3.3.6. Directory String 3.3.6. Directory String
A value of the Directory String syntax is a string of one or more A value of the Directory String syntax is a string of one or more
arbitrary characters from the Universal Character Set (UCS) [UCS]. A arbitrary characters from the Universal Character Set (UCS) [UCS]. A
zero length character string is not permitted. The LDAP-specific zero-length character string is not permitted. The LDAP-specific
encoding of a value of this syntax is the UTF-8 encoding [UTF8] of encoding of a value of this syntax is the UTF-8 encoding [RFC3629] of
the character string. Such encodings conform to the following ABNF: the character string. Such encodings conform to the following ABNF:
DirectoryString = 1*UTF8 DirectoryString = 1*UTF8
The <UTF8> rule is defined in [MODELS]. The <UTF8> rule is defined in [RFC4512].
Example: Example:
This is a value of Directory String containing #!%#@. This is a value of Directory String containing #!%#@.
Servers and clients MUST be prepared to receive arbitrary UCS code Servers and clients MUST be prepared to receive arbitrary UCS code
points, including code points outside the range of printable ASCII points, including code points outside the range of printable ASCII
and code points not presently assigned to any character. and code points not presently assigned to any character.
Attribute type definitions using the Directory String syntax should Attribute type definitions using the Directory String syntax should
not restrict the format of Directory String values, e.g., by not restrict the format of Directory String values, e.g., by
skipping to change at page 10, line 34 skipping to change at page 9, line 25
described by ABNF. A new syntax should be defined in such cases. described by ABNF. A new syntax should be defined in such cases.
The LDAP definition for the Directory String syntax is: The LDAP definition for the Directory String syntax is:
( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' ) ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )
This syntax corresponds to the DirectoryString parameterized ASN.1 This syntax corresponds to the DirectoryString parameterized ASN.1
type from [X.520]. type from [X.520].
The DirectoryString ASN.1 type allows a choice between the The DirectoryString ASN.1 type allows a choice between the
TeletexString, PrintableString or UniversalString ASN.1 types from TeletexString, PrintableString, or UniversalString ASN.1 types from
[ASN.1]. However, note that the chosen alternative is not indicated [ASN.1]. However, note that the chosen alternative is not indicated
in the LDAP-specific encoding of a Directory String value. in the LDAP-specific encoding of a Directory String value.
Implementations which convert Directory String values from the Implementations that convert Directory String values from the LDAP-
LDAP-specific encoding to the BER encoding used by X.500 must choose specific encoding to the BER encoding used by X.500 must choose an
an alternative that permits the particular characters in the string, alternative that permits the particular characters in the string and
and must convert the characters from the UTF-8 encoding into the must convert the characters from the UTF-8 encoding into the
character encoding of the chosen alternative. When converting character encoding of the chosen alternative. When converting
Directory String values from the BER encoding to the LDAP-specific Directory String values from the BER encoding to the LDAP-specific
encoding the characters must be converted from the character encoding encoding, the characters must be converted from the character
of the chosen alternative into the UTF-8 encoding. These conversions encoding of the chosen alternative into the UTF-8 encoding. These
SHOULD be done in a manner consistent with the Transcode step of the conversions SHOULD be done in a manner consistent with the Transcode
string preparation algorithms [PREP] for LDAP. step of the string preparation algorithms [RFC4518] for LDAP.
3.3.7. DIT Content Rule Description 3.3.7. DIT Content Rule Description
A value of the DIT Content Rule Description syntax is the definition A value of the DIT Content Rule Description syntax is the definition
of a DIT (Directory Information Tree) content rule. The of a DIT (Directory Information Tree) content rule. The LDAP-
LDAP-specific encoding of a value of this syntax is defined by the specific encoding of a value of this syntax is defined by the
<DITContentRuleDescription> rule in [MODELS]. <DITContentRuleDescription> rule in [RFC4512].
Example: Example:
( 2.5.6.4 DESC 'content rule for organization' ( 2.5.6.4 DESC 'content rule for organization'
NOT ( x121Address $ telexNumber ) ) NOT ( x121Address $ telexNumber ) )
Note: a line break has been added for readability - it is not part Note: A line break has been added for readability; it is not part
of the value. of the value.
The LDAP definition for the DIT Content Rule Description syntax is: The LDAP definition for the DIT Content Rule Description syntax is:
( 1.3.6.1.4.1.1466.115.121.1.16 ( 1.3.6.1.4.1.1466.115.121.1.16
DESC 'DIT Content Rule Description' ) DESC 'DIT Content Rule Description' )
This syntax corresponds to the DITContentRuleDescription ASN.1 type This syntax corresponds to the DITContentRuleDescription ASN.1 type
from [X.501]. from [X.501].
3.3.8. DIT Structure Rule Description 3.3.8. DIT Structure Rule Description
A value of the DIT Structure Rule Description syntax is the A value of the DIT Structure Rule Description syntax is the
definition of a DIT structure rule. The LDAP-specific encoding of a definition of a DIT structure rule. The LDAP-specific encoding of a
value of this syntax is defined by the <DITStructureRuleDescription> value of this syntax is defined by the <DITStructureRuleDescription>
rule in [MODELS]. rule in [RFC4512].
Example: Example:
( 2 DESC 'organization structure rule' FORM 2.5.15.3 ) ( 2 DESC 'organization structure rule' FORM 2.5.15.3 )
The LDAP definition for the DIT Structure Rule Description syntax is: The LDAP definition for the DIT Structure Rule Description syntax is:
( 1.3.6.1.4.1.1466.115.121.1.17 ( 1.3.6.1.4.1.1466.115.121.1.17
DESC 'DIT Structure Rule Description' ) DESC 'DIT Structure Rule Description' )
This syntax corresponds to the DITStructureRuleDescription ASN.1 type This syntax corresponds to the DITStructureRuleDescription ASN.1 type
from [X.501]. from [X.501].
3.3.9. DN 3.3.9. DN
A value of the DN syntax is the (purported) distinguished name (DN) A value of the DN syntax is the (purported) distinguished name (DN)
of an entry [MODELS]. The LDAP-specific encoding of a value of this of an entry [RFC4512]. The LDAP-specific encoding of a value of this
syntax is defined by the <distinguishedName> rule from the string syntax is defined by the <distinguishedName> rule from the string
representation of distinguished names [LDAPDN]. representation of distinguished names [RFC4514].
Examples (from [LDAPDN]): Examples (from [RFC4514]):
UID=jsmith,DC=example,DC=net UID=jsmith,DC=example,DC=net
OU=Sales+CN=J. Smith,DC=example,DC=net OU=Sales+CN=J. Smith,DC=example,DC=net
CN=John Smith\, III,DC=example,DC=net CN=John Smith\, III,DC=example,DC=net
CN=Before\0dAfter,DC=example,DC=net CN=Before\0dAfter,DC=example,DC=net
1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com 1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com
CN=Lu\C4\8Di\C4\87 CN=Lu\C4\8Di\C4\87
The LDAP definition for the DN syntax is: The LDAP definition for the DN syntax is:
( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' ) ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' )
skipping to change at page 12, line 50 skipping to change at page 11, line 39
LPAREN criteria RPAREN / LPAREN criteria RPAREN /
true / true /
false false
match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX" match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX"
true = "?true" true = "?true"
false = "?false" false = "?false"
BAR = %x7C ; vertical bar ("|") BAR = %x7C ; vertical bar ("|")
AMPERSAND = %x26 ; ampersand ("&") AMPERSAND = %x26 ; ampersand ("&")
EXCLAIM = %x21 ; exclamation mark ("!") EXCLAIM = %x21 ; exclamation mark ("!")
The <SHARP>, <WSP>, <oid>, <LPAREN>, <RPAREN>, <attributetype> and The <SHARP>, <WSP>, <oid>, <LPAREN>, <RPAREN>, <attributetype>, and
<DOLLAR> rules are defined in [MODELS]. <DOLLAR> rules are defined in [RFC4512].
The LDAP definition for the Enhanced Guide syntax is: The LDAP definition for the Enhanced Guide syntax is:
( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' ) ( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' )
Example: Example:
person#(sn$EQ)#oneLevel person#(sn$EQ)#oneLevel
The Enhanced Guide syntax corresponds to the EnhancedGuide ASN.1 type The Enhanced Guide syntax corresponds to the EnhancedGuide ASN.1 type
from [X.520]. The EnhancedGuide type references the Criteria ASN.1 from [X.520]. The EnhancedGuide type references the Criteria ASN.1
type, also from [X.520]. The <true> rule above represents an empty type, also from [X.520]. The <true> rule, above, represents an empty
"and" expression in a value of the Criteria type. The <false> rule "and" expression in a value of the Criteria type. The <false> rule,
above represents an empty "or" expression in a value of the Criteria above, represents an empty "or" expression in a value of the Criteria
type. type.
3.3.11. Facsimile Telephone Number 3.3.11. Facsimile Telephone Number
A value of the Facsimile Telephone Number syntax is a subscriber A value of the Facsimile Telephone Number syntax is a subscriber
number of a facsimile device on the public switched telephone number of a facsimile device on the public switched telephone
network. The LDAP-specific encoding of a value of this syntax is network. The LDAP-specific encoding of a value of this syntax is
defined by the following ABNF: defined by the following ABNF:
fax-number = telephone-number *( DOLLAR fax-parameter ) fax-number = telephone-number *( DOLLAR fax-parameter )
skipping to change at page 13, line 39 skipping to change at page 12, line 28
"fineResolution" / "fineResolution" /
"unlimitedLength" / "unlimitedLength" /
"b4Length" / "b4Length" /
"a3Width" / "a3Width" /
"b4Width" / "b4Width" /
"uncompressed" "uncompressed"
The <telephone-number> is a string of printable characters that The <telephone-number> is a string of printable characters that
complies with the internationally agreed format for representing complies with the internationally agreed format for representing
international telephone numbers [E.123]. The <PrintableString> rule international telephone numbers [E.123]. The <PrintableString> rule
is defined in Section 3.2. The <DOLLAR> rule is defined in [MODELS]. is defined in Section 3.2. The <DOLLAR> rule is defined in
[RFC4512].
The LDAP definition for the Facsimile Telephone Number syntax is: The LDAP definition for the Facsimile Telephone Number syntax is:
( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number') ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number')
The Facsimile Telephone Number syntax corresponds to the The Facsimile Telephone Number syntax corresponds to the
FacsimileTelephoneNumber ASN.1 type from [X.520]. FacsimileTelephoneNumber ASN.1 type from [X.520].
3.3.12. Fax 3.3.12. Fax
A value of the Fax syntax is an image which is produced using the A value of the Fax syntax is an image that is produced using the
Group 3 facsimile process [FAX] to duplicate an object, such as a 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 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]. string of octets for a Group 3 Fax image as defined in [FAX].
The LDAP definition for the Fax syntax is: The LDAP definition for the Fax syntax is:
( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' ) ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' )
The ASN.1 type corresponding to the Fax syntax is defined as follows, The ASN.1 type corresponding to the Fax syntax is defined as follows,
assuming EXPLICIT TAGS: assuming EXPLICIT TAGS:
skipping to change at page 14, line 51 skipping to change at page 13, line 42
second = ( %x30-35 %x30-39 ) ; "00" to "59" second = ( %x30-35 %x30-39 ) ; "00" to "59"
leap-second = ( %x36 %x30 ) ; "60" leap-second = ( %x36 %x30 ) ; "60"
fraction = ( DOT / COMMA ) 1*(%x30-39) fraction = ( DOT / COMMA ) 1*(%x30-39)
g-time-zone = %x5A ; "Z" g-time-zone = %x5A ; "Z"
/ g-differential / g-differential
g-differential = ( MINUS / PLUS ) hour [ minute ] g-differential = ( MINUS / PLUS ) hour [ minute ]
MINUS = %x2D ; minus sign ("-") MINUS = %x2D ; minus sign ("-")
The <DOT>, <COMMA> and <PLUS> rules are defined in [MODELS]. The <DOT>, <COMMA>, and <PLUS> rules are defined in [RFC4512].
The above ABNF allows character strings which do not represent valid The above ABNF allows character strings that do not represent valid
dates (in the Gregorian calendar) and/or valid times (e.g., February dates (in the Gregorian calendar) and/or valid times (e.g., February
31, 1994). Such character strings SHOULD be considered invalid for 31, 1994). Such character strings SHOULD be considered invalid for
this syntax. this syntax.
The time value represents coordinated universal time (equivalent to The time value represents coordinated universal time (equivalent to
Greenwich Mean Time) if the "Z" form of <g-time-zone> is used, Greenwich Mean Time) if the "Z" form of <g-time-zone> is used;
otherwise the value represents a local time in the time zone otherwise, the value represents a local time in the time zone
indicated by <g-differential>. In the latter case, coordinated indicated by <g-differential>. In the latter case, coordinated
universal time can be calculated by subtracting the differential from universal time can be calculated by subtracting the differential from
the local time. The "Z" form of <g-time-zone> SHOULD be used in the local time. The "Z" form of <g-time-zone> SHOULD be used in
preference to <g-differential>. preference to <g-differential>.
If <minute> is omitted then <fraction> represents a fraction of an If <minute> is omitted, then <fraction> represents a fraction of an
hour, otherwise if <second> and <leap-second> are omitted then hour; otherwise, if <second> and <leap-second> are omitted, then
<fraction> represents a fraction of a minute, otherwise <fraction> <fraction> represents a fraction of a minute; otherwise, <fraction>
represents a fraction of a second. represents a fraction of a second.
Examples: Examples:
199412161032Z 199412161032Z
199412160532-0500 199412160532-0500
Both example values represent the same coordinated universal time: Both example values represent the same coordinated universal time:
10:32 AM, December 16, 1994. 10:32 AM, December 16, 1994.
The LDAP definition for the Generalized Time syntax is: The LDAP definition for the Generalized Time syntax is:
skipping to change at page 15, line 52 skipping to change at page 14, line 42
constructing filters to search for entries of particular object constructing filters to search for entries of particular object
classes. The Guide syntax is obsolete and should not be used for classes. The Guide syntax is obsolete and should not be used for
defining new attribute types. defining new attribute types.
The LDAP-specific encoding of a value of this syntax is defined by The LDAP-specific encoding of a value of this syntax is defined by
the following ABNF: the following ABNF:
Guide = [ object-class SHARP ] criteria Guide = [ object-class SHARP ] criteria
The <object-class> and <criteria> rules are defined in Section The <object-class> and <criteria> rules are defined in Section
3.3.10. The <SHARP> rule is defined in [MODELS]. 3.3.10. The <SHARP> rule is defined in [RFC4512].
The LDAP definition for the Guide syntax is: The LDAP definition for the Guide syntax is:
( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' ) ( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' )
The Guide syntax corresponds to the Guide ASN.1 type from [X.520]. The Guide syntax corresponds to the Guide ASN.1 type from [X.520].
3.3.15. IA5 String 3.3.15. IA5 String
A value of the IA5 String syntax is a string of zero, one or more A value of the IA5 String syntax is a string of zero, one, or more
characters from International Alphabet 5 (IA5) [T.50], the characters from International Alphabet 5 (IA5) [T.50], the
international version of the ASCII character set. The LDAP-specific international version of the ASCII character set. The LDAP-specific
encoding of a value of this syntax is the unconverted string of encoding of a value of this syntax is the unconverted string of
characters, which conforms to the <IA5String> rule in Section 3.2. characters, which conforms to the <IA5String> rule in Section 3.2.
The LDAP definition for the IA5 String syntax is: The LDAP definition for the IA5 String syntax is:
( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' ) ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )
This syntax corresponds to the IA5String ASN.1 type from [ASN.1]. This syntax corresponds to the IA5String ASN.1 type from [ASN.1].
3.3.16. Integer 3.3.16. Integer
A value of the Integer syntax is a whole number of unlimited A value of the Integer syntax is a whole number of unlimited
magnitude. The LDAP-specific encoding of a value of this syntax is magnitude. The LDAP-specific encoding of a value of this syntax is
the optionally signed decimal digit character string representation the optionally signed decimal digit character string representation
of the number (so, for example, the number 1321 is represented by the of the number (for example, the number 1321 is represented by the
character string "1321"). The encoding is defined by the following character string "1321"). The encoding is defined by the following
ABNF: ABNF:
Integer = ( HYPHEN LDIGIT *DIGIT ) / number Integer = ( HYPHEN LDIGIT *DIGIT ) / number
The <HYPHEN>, <LDIGIT>, <DIGIT> and <number> rules are defined in The <HYPHEN>, <LDIGIT>, <DIGIT>, and <number> rules are defined in
[MODELS]. [RFC4512].
The LDAP definition for the Integer syntax is: The LDAP definition for the Integer syntax is:
( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' ) ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' )
This syntax corresponds to the INTEGER ASN.1 type from [ASN.1]. This syntax corresponds to the INTEGER ASN.1 type from [ASN.1].
3.3.17. JPEG 3.3.17. JPEG
A value of the JPEG syntax is an image in the JPEG File Interchange A value of the JPEG syntax is an image in the JPEG File Interchange
skipping to change at page 17, line 17 skipping to change at page 16, line 13
The JPEG syntax corresponds to the following ASN.1 type: The JPEG syntax corresponds to the following ASN.1 type:
JPEG ::= OCTET STRING (CONSTRAINED BY JPEG ::= OCTET STRING (CONSTRAINED BY
{ -- contents octets are an image in the -- { -- contents octets are an image in the --
-- JPEG File Interchange Format -- }) -- JPEG File Interchange Format -- })
3.3.18. LDAP Syntax Description 3.3.18. LDAP Syntax Description
A value of the LDAP Syntax Description syntax is the description of A value of the LDAP Syntax Description syntax is the description of
an LDAP syntax. The LDAP-specific encoding of a value of this syntax an LDAP syntax. The LDAP-specific encoding of a value of this syntax
is defined by the <SyntaxDescription> rule in [MODELS]. is defined by the <SyntaxDescription> rule in [RFC4512].
The LDAP definition for the LDAP Syntax Description syntax is: The LDAP definition for the LDAP Syntax Description syntax is:
( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' ) ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' )
The above LDAP definition for the LDAP Syntax Description syntax is The above LDAP definition for the LDAP Syntax Description syntax is
itself a legal value of the LDAP Syntax Description syntax. itself a legal value of the LDAP Syntax Description syntax.
The ASN.1 type corresponding to the LDAP Syntax Description syntax is The ASN.1 type corresponding to the LDAP Syntax Description syntax is
defined as follows, assuming EXPLICIT TAGS: defined as follows, assuming EXPLICIT TAGS:
skipping to change at page 17, line 42 skipping to change at page 16, line 38
The DirectoryString parameterized ASN.1 type is defined in [X.520]. The DirectoryString parameterized ASN.1 type is defined in [X.520].
The value of ub-schema (an integer) is implementation defined. A The value of ub-schema (an integer) is implementation defined. A
non-normative definition appears in [X.520]. non-normative definition appears in [X.520].
3.3.19. Matching Rule Description 3.3.19. Matching Rule Description
A value of the Matching Rule Description syntax is the definition of A value of the Matching Rule Description syntax is the definition of
a matching rule. The LDAP-specific encoding of a value of this a matching rule. The LDAP-specific encoding of a value of this
syntax is defined by the <MatchingRuleDescription> rule in [MODELS]. syntax is defined by the <MatchingRuleDescription> rule in [RFC4512].
Example: Example:
( 2.5.13.2 NAME 'caseIgnoreMatch' ( 2.5.13.2 NAME 'caseIgnoreMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
Note: a line break has been added for readability - it is not part of Note: A line break has been added for readability; it is not part of
the syntax. the syntax.
The LDAP definition for the Matching Rule Description syntax is: The LDAP definition for the Matching Rule Description syntax is:
( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' ) ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' )
This syntax corresponds to the MatchingRuleDescription ASN.1 type This syntax corresponds to the MatchingRuleDescription ASN.1 type
from [X.501]. from [X.501].
3.3.20. Matching Rule Use Description 3.3.20. Matching Rule Use Description
A value of the Matching Rule Use Description syntax indicates the A value of the Matching Rule Use Description syntax indicates the
attribute types to which a matching rule may be applied in an attribute types to which a matching rule may be applied in an
extensibleMatch search filter [PROT]. The LDAP-specific encoding of extensibleMatch search filter [RFC4511]. The LDAP-specific encoding
a value of this syntax is defined by the <MatchingRuleUseDescription> of a value of this syntax is defined by the
rule in [MODELS]. <MatchingRuleUseDescription> rule in [RFC4512].
Example: Example:
( 2.5.13.16 APPLIES ( givenName $ surname ) ) ( 2.5.13.16 APPLIES ( givenName $ surname ) )
The LDAP definition for the Matching Rule Use Description syntax is: The LDAP definition for the Matching Rule Use Description syntax is:
( 1.3.6.1.4.1.1466.115.121.1.31 ( 1.3.6.1.4.1.1466.115.121.1.31
DESC 'Matching Rule Use Description' ) DESC 'Matching Rule Use Description' )
This syntax corresponds to the MatchingRuleUseDescription ASN.1 type This syntax corresponds to the MatchingRuleUseDescription ASN.1 type
from [X.501]. from [X.501].
3.3.21. Name and Optional UID 3.3.21. Name and Optional UID
A value of the Name and Optional UID syntax is the distinguished name A value of the Name and Optional UID syntax is the distinguished name
[MODELS] of an entity optionally accompanied by a unique identifier [RFC4512] of an entity optionally accompanied by a unique identifier
that serves to differentiate the entity from others with an identical that serves to differentiate the entity from others with an identical
distinguished name. distinguished name.
The LDAP-specific encoding of a value of this syntax is defined by The LDAP-specific encoding of a value of this syntax is defined by
the following ABNF: the following ABNF:
NameAndOptionalUID = distinguishedName [ SHARP BitString ] NameAndOptionalUID = distinguishedName [ SHARP BitString ]
The <BitString> rule is defined in Section 3.3.2. The The <BitString> rule is defined in Section 3.3.2. The
<distinguishedName> rule is defined in [LDAPDN]. The <SHARP> rule is <distinguishedName> rule is defined in [RFC4514]. The <SHARP> rule
defined in [MODELS]. is defined in [RFC4512].
Note that although the '#' character may occur in the string Note that although the '#' character may occur in the string
representation of a distinguished name, no additional escaping of representation of a distinguished name, no additional escaping of
this character is performed when a <distinguishedName> is encoded in this character is performed when a <distinguishedName> is encoded in
a <NameAndOptionalUID>. a <NameAndOptionalUID>.
Example: Example:
1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B
The LDAP definition for the Name and Optional UID syntax is: The LDAP definition for the Name and Optional UID syntax is:
( 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' )
This syntax corresponds to the NameAndOptionalUID ASN.1 type from This syntax corresponds to the NameAndOptionalUID ASN.1 type from
[X.520]. [X.520].
3.3.22. Name Form Description 3.3.22. Name Form Description
A value of the Name Form Description syntax is the definition of a A value of the Name Form Description syntax is the definition of a
name form, which regulates how entries may be named. The name form, which regulates how entries may be named. The LDAP-
LDAP-specific encoding of a value of this syntax is defined by the specific encoding of a value of this syntax is defined by the
<NameFormDescription> rule in [MODELS]. <NameFormDescription> rule in [RFC4512].
Example: Example:
( 2.5.15.3 NAME 'orgNameForm' OC organization MUST o ) ( 2.5.15.3 NAME 'orgNameForm' OC organization MUST o )
The LDAP definition for the Name Form Description syntax is: The LDAP definition for the Name Form Description syntax is:
( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' ) ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' )
This syntax corresponds to the NameFormDescription ASN.1 type from This syntax corresponds to the NameFormDescription ASN.1 type from
[X.501]. [X.501].
3.3.23. Numeric String 3.3.23. Numeric String
A value of the Numeric String syntax is a sequence of one or more A value of the Numeric String syntax is a sequence of one or more
numerals and spaces. The LDAP-specific encoding of a value of this numerals and spaces. The LDAP-specific encoding of a value of this
syntax is the unconverted string of characters, which conforms to the syntax is the unconverted string of characters, which conforms to the
following ABNF: following ABNF:
NumericString = 1*(DIGIT / SPACE) NumericString = 1*(DIGIT / SPACE)
The <DIGIT> and <SPACE> rules are defined in [MODELS]. The <DIGIT> and <SPACE> rules are defined in [RFC4512].
Example: Example:
15 079 672 281 15 079 672 281
The LDAP definition for the Numeric String syntax is: 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' )
This syntax corresponds to the NumericString ASN.1 type from [ASN.1]. This syntax corresponds to the NumericString ASN.1 type from [ASN.1].
3.3.24. Object Class Description 3.3.24. Object Class Description
A value of the Object Class Description syntax is the definition of A value of the Object Class Description syntax is the definition of
an object class. The LDAP-specific encoding of a value of this an object class. The LDAP-specific encoding of a value of this
syntax is defined by the <ObjectClassDescription> rule in [MODELS]. syntax is defined by the <ObjectClassDescription> rule in [RFC4512].
Example: Example:
( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c
MAY ( searchGuide $ description ) ) MAY ( searchGuide $ description ) )
Note: a line break has been added for readability - it is not part of Note: A line break has been added for readability; it is not part of
the syntax. the syntax.
The LDAP definition for the Object Class Description syntax is: 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' )
This syntax corresponds to the ObjectClassDescription ASN.1 type from This syntax corresponds to the ObjectClassDescription ASN.1 type from
[X.501]. [X.501].
3.3.25. Octet String 3.3.25. Octet String
A value of the Octet String syntax is a sequence of zero, one or more A value of the Octet String syntax is a sequence of zero, one, or
arbitrary octets. The LDAP-specific encoding of a value of this more arbitrary octets. The LDAP-specific encoding of a value of this
syntax is the unconverted sequence of octets, which conforms to the syntax is the unconverted sequence of octets, which conforms to the
following ABNF: following ABNF:
OctetString = *OCTET OctetString = *OCTET
The <OCTET> rule is defined in [MODELS]. Values of this syntax are The <OCTET> rule is defined in [RFC4512]. Values of this syntax are
not generally human-readable. not generally human-readable.
The LDAP definition for the Octet String syntax is: The LDAP definition for the Octet String syntax is:
( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' ) ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' )
This syntax corresponds to the OCTET STRING ASN.1 type from [ASN.1]. This syntax corresponds to the OCTET STRING ASN.1 type from [ASN.1].
3.3.26. OID 3.3.26. OID
A value of the OID syntax is an object identifier; a sequence of two 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 or more non-negative integers that uniquely identify some object or
item of specification. Many of the object identifiers used in LDAP item of specification. Many of the object identifiers used in LDAP
also have IANA registered names [RFC3383]. also have IANA registered names [RFC4520].
The LDAP-specific encoding of a value of this syntax is defined by The LDAP-specific encoding of a value of this syntax is defined by
the <oid> rule in [MODELS]. the <oid> rule in [RFC4512].
Examples: Examples:
1.2.3.4 1.2.3.4
cn cn
The LDAP definition for the OID syntax is: The LDAP definition for the OID syntax is:
( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' ) ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' )
This syntax corresponds to the OBJECT IDENTIFIER ASN.1 type from This syntax corresponds to the OBJECT IDENTIFIER ASN.1 type from
skipping to change at page 21, line 23 skipping to change at page 20, line 21
A value of the Other Mailbox syntax identifies an electronic mailbox, A value of the Other Mailbox syntax identifies an electronic mailbox,
in a particular named mail system. The LDAP-specific encoding of a in a particular named mail system. The LDAP-specific encoding of a
value of this syntax is defined by the following ABNF: value of this syntax is defined by the following ABNF:
OtherMailbox = mailbox-type DOLLAR mailbox OtherMailbox = mailbox-type DOLLAR mailbox
mailbox-type = PrintableString mailbox-type = PrintableString
mailbox = IA5String mailbox = IA5String
The <mailbox-type> rule represents the type of mail system in which The <mailbox-type> rule represents the type of mail system in which
the mailbox resides, for example "MCIMail", and <mailbox> is the the mailbox resides (for example, "MCIMail"), and <mailbox> is the
actual mailbox in the mail system described by <mailbox-type>. The actual mailbox in the mail system described by <mailbox-type>. The
<PrintableString> and <IA5String> rules are defined in Section 3.2. <PrintableString> and <IA5String> rules are defined in Section 3.2.
The <DOLLAR> rule is defined in [MODELS]. The <DOLLAR> rule is defined in [RFC4512].
The LDAP definition for the Other Mailbox syntax is: The LDAP definition for the Other Mailbox syntax is:
( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' ) ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' )
The ASN.1 type corresponding to the Other Mailbox syntax is defined The ASN.1 type corresponding to the Other Mailbox syntax is defined
as follows, assuming EXPLICIT TAGS: as follows, assuming EXPLICIT TAGS:
OtherMailbox ::= SEQUENCE { OtherMailbox ::= SEQUENCE {
mailboxType PrintableString, mailboxType PrintableString,
skipping to change at page 22, line 10 skipping to change at page 21, line 15
PostalAddress = line *( DOLLAR line ) PostalAddress = line *( DOLLAR line )
line = 1*line-char line = 1*line-char
line-char = %x00-23 line-char = %x00-23
/ (%x5C "24") ; escaped "$" / (%x5C "24") ; escaped "$"
/ %x25-5B / %x25-5B
/ (%x5C "5C") ; escaped "\" / (%x5C "5C") ; escaped "\"
/ %x5D-7F / %x5D-7F
/ UTFMB / UTFMB
Each character string (i.e., <line>) of a postal address value is Each character string (i.e., <line>) of a postal address value is
encoded as a UTF-8 [UTF8] string except that "\" and "$" characters, encoded as a UTF-8 [RFC3629] string, except that "\" and "$"
if they occur in the string, are escaped by a "\" character followed characters, if they occur in the string, are escaped by a "\"
by the two hexadecimal digit code for the character. The <DOLLAR> character followed by the two hexadecimal digit code for the
and <UTFMB> rules are defined in [MODELS]. character. The <DOLLAR> and <UTFMB> rules are defined in [RFC4512].
Many servers limit the postal address to no more than six lines of no Many servers limit the postal address to no more than six lines of no
more than thirty characters each. more than thirty characters each.
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
The LDAP definition for the Postal Address syntax is: The LDAP definition for the Postal Address syntax is:
( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' ) ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' )
This syntax corresponds to the PostalAddress ASN.1 type from [X.520], This syntax corresponds to the PostalAddress ASN.1 type from [X.520];
i.e., that is
PostalAddress ::= SEQUENCE SIZE(1..ub-postal-line) OF PostalAddress ::= SEQUENCE SIZE(1..ub-postal-line) OF
DirectoryString { ub-postal-string } DirectoryString { ub-postal-string }
The values of ub-postal-line and ub-postal-string (both integers) are The values of ub-postal-line and ub-postal-string (both integers) are
implementation defined. Non-normative definitions appear in [X.520]. implementation defined. Non-normative definitions appear in [X.520].
3.3.29. Printable String 3.3.29. Printable String
A value of the Printable String syntax is a string of one or more A value of the Printable String syntax is a string of one or more
skipping to change at page 23, line 10 skipping to change at page 22, line 14
The LDAP definition for the PrintableString syntax is: The LDAP definition for the PrintableString syntax is:
( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' ) ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )
This syntax corresponds to the PrintableString ASN.1 type from This syntax corresponds to the PrintableString ASN.1 type from
[ASN.1]. [ASN.1].
3.3.30. Substring Assertion 3.3.30. Substring Assertion
A value of the Substring Assertion syntax is a sequence of zero, one A value of the Substring Assertion syntax is a sequence of zero, one,
or more character substrings used as an argument for substring or more character substrings used as an argument for substring
extensible matching of character string attribute values, i.e., as extensible matching of character string attribute values; i.e., as
the matchValue of a MatchingRuleAssertion [PROT]. Each substring is the matchValue of a MatchingRuleAssertion [RFC4511]. Each substring
a string of one or more arbitrary characters from the Universal is a string of one or more arbitrary characters from the Universal
Character Set (UCS) [UCS]. A zero length substring is not permitted. Character Set (UCS) [UCS]. A zero-length substring is not permitted.
The LDAP-specific encoding of a value of this syntax is defined by The LDAP-specific encoding of a value of this syntax is defined by
the following ABNF: the following ABNF:
SubstringAssertion = [ initial ] any [ final ] SubstringAssertion = [ initial ] any [ final ]
initial = substring initial = substring
any = ASTERISK *(substring ASTERISK) any = ASTERISK *(substring ASTERISK)
final = substring final = substring
ASTERISK = %x2A ; asterisk ("*") ASTERISK = %x2A ; asterisk ("*")
substring = 1*substring-character substring = 1*substring-character
substring-character = %x00-29 substring-character = %x00-29
/ (%x5C "2A") ; escaped "*" / (%x5C "2A") ; escaped "*"
/ %x2B-5B / %x2B-5B
/ (%x5C "5C") ; escaped "\" / (%x5C "5C") ; escaped "\"
/ %x5D-7F / %x5D-7F
/ UTFMB / UTFMB
Each <substring> of a Substring Assertion value is encoded as a UTF-8 Each <substring> of a Substring Assertion value is encoded as a UTF-8
[UTF8] string, except that "\" and "*" characters, if they occur in [RFC3629] string, except that "\" and "*" characters, if they occur
the substring, are escaped by a "\" character followed by the two in the substring, are escaped by a "\" character followed by the two
hexadecimal digit code for the character. hexadecimal digit code for the character.
The Substring Assertion syntax is used only as the syntax of The Substring Assertion syntax is used only as the syntax of
assertion values in the extensible match. It is not used as an assertion values in the extensible match. It is not used as an
attribute syntax, or in the SubstringFilter [PROT]. attribute syntax, or in the SubstringFilter [RFC4511].
The LDAP definition for the Substring Assertion syntax is: The LDAP definition for the Substring Assertion syntax is:
( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' ) ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' )
This syntax corresponds to the SubstringAssertion ASN.1 type from This syntax corresponds to the SubstringAssertion ASN.1 type from
[X.520]. [X.520].
3.3.31. Telephone Number 3.3.31. Telephone Number
A value of the Telephone Number syntax is a string of printable A value of the Telephone Number syntax is a string of printable
characters that complies with the internationally agreed format for characters that complies with the internationally agreed format for
representing international telephone numbers [E.123]. representing international telephone numbers [E.123].
The LDAP-specific encoding of a value of this syntax is the The LDAP-specific encoding of a value of this syntax is the
unconverted string of characters, which conforms to the unconverted string of characters, which conforms to the
<PrintableString> rule in Section 3.2. <PrintableString> rule in Section 3.2.
Examples: Examples:
+1 512 315 0280 +1 512 315 0280
skipping to change at page 24, line 50 skipping to change at page 24, line 7
ttx-key = "graphic" / "control" / "misc" / "page" / "private" ttx-key = "graphic" / "control" / "misc" / "page" / "private"
ttx-value = *ttx-value-octet ttx-value = *ttx-value-octet
ttx-value-octet = %x00-23 ttx-value-octet = %x00-23
/ (%x5C "24") ; escaped "$" / (%x5C "24") ; escaped "$"
/ %x25-5B / %x25-5B
/ (%x5C "5C") ; escaped "\" / (%x5C "5C") ; escaped "\"
/ %x5D-FF / %x5D-FF
The <PrintableString> and <COLON> rules are defined in Section 3.2. The <PrintableString> and <COLON> rules are defined in Section 3.2.
The <DOLLAR> rule is defined in [MODELS]. The <DOLLAR> rule is defined in [RFC4512].
The LDAP definition for the Teletex Terminal Identifier syntax is: The LDAP definition for the Teletex Terminal Identifier syntax is:
( 1.3.6.1.4.1.1466.115.121.1.51 ( 1.3.6.1.4.1.1466.115.121.1.51
DESC 'Teletex Terminal Identifier' ) DESC 'Teletex Terminal Identifier' )
This syntax corresponds to the TeletexTerminalIdentifier ASN.1 type This syntax corresponds to the TeletexTerminalIdentifier ASN.1 type
from [X.520]. from [X.520].
3.3.33. Telex Number 3.3.33. Telex Number
A value of the Telex Number syntax specifies the telex number, A value of the Telex Number syntax specifies the telex number,
country code and answerback code of a telex terminal. country code, and answerback code of a telex terminal.
The LDAP-specific encoding of a value of this syntax is defined by The LDAP-specific encoding of a value of this syntax is defined by
the following ABNF: the following ABNF:
telex-number = actual-number DOLLAR country-code telex-number = actual-number DOLLAR country-code
DOLLAR answerback DOLLAR answerback
actual-number = PrintableString actual-number = PrintableString
country-code = PrintableString country-code = PrintableString
answerback = PrintableString answerback = PrintableString
The <PrintableString> rule is defined in Section 3.2. The <DOLLAR> The <PrintableString> rule is defined in Section 3.2. The <DOLLAR>
rule is defined in [MODELS]. rule is defined in [RFC4512].
The LDAP definition for the Telex Number syntax is: The LDAP definition for the Telex Number syntax is:
( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' ) ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' )
This syntax corresponds to the TelexNumber ASN.1 type from [X.520]. This syntax corresponds to the TelexNumber ASN.1 type from [X.520].
3.3.34. UTC Time 3.3.34. UTC Time
A value of the UTC Time syntax is a character string representing a A value of the UTC Time syntax is a character string representing a
skipping to change at page 25, line 48 skipping to change at page 25, line 4
A value of the UTC Time syntax is a character string representing a 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 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 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 value of this syntax follows the format defined in [ASN.1] for the
UTCTime type and is described by the following ABNF: UTCTime type and is described by the following ABNF:
UTCTime = year month day hour minute [ second ] UTCTime = year month day hour minute [ second ]
[ u-time-zone ] [ u-time-zone ]
u-time-zone = %x5A ; "Z" u-time-zone = %x5A ; "Z"
/ u-differential / u-differential
u-differential = ( MINUS / PLUS ) hour minute u-differential = ( MINUS / PLUS ) hour minute
The <year>, <month>, <day>, <hour>, <minute>, <second> and <MINUS> The <year>, <month>, <day>, <hour>, <minute>, <second>, and <MINUS>
rules are defined in Section 3.3.13. The <PLUS> rule is defined in rules are defined in Section 3.3.13. The <PLUS> rule is defined in
[MODELS]. [RFC4512].
The above ABNF allows character strings which do not represent valid The above ABNF allows character strings that do not represent valid
dates (in the Gregorian calendar) and/or valid times. Such character dates (in the Gregorian calendar) and/or valid times. Such character
strings SHOULD be considered invalid for this syntax. strings SHOULD be considered invalid for this syntax.
The time value represents coordinated universal time if the "Z" form The time value represents coordinated universal time if the "Z" form
of <u-time-zone> is used, otherwise the value represents a local of <u-time-zone> is used; otherwise, the value represents a local
time. In the latter case, if <u-differential> is provided then time. In the latter case, if <u-differential> is provided, then
coordinated universal time can be calculated by subtracting the coordinated universal time can be calculated by subtracting the
differential from the local time. The <u-time-zone> SHOULD be 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 present in time values, and the "Z" form of <u-time-zone> SHOULD be
used in preference to <u-differential>. used in preference to <u-differential>.
The LDAP definition for the UTC Time syntax is: The LDAP definition for the UTC Time syntax is:
( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' ) ( 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 Note: This syntax is deprecated in favor of the Generalized Time
syntax. syntax.
The UTC Time syntax corresponds to the UTCTime ASN.1 type from The UTC Time syntax corresponds to the UTCTime ASN.1 type from
[ASN.1]. [ASN.1].
4. Matching Rules 4. Matching Rules
Matching rules are used by directory implementations to compare Matching rules are used by directory implementations to compare
attribute values against assertion values when performing Search and attribute values against assertion values when performing Search and
Compare operations [PROT]. They are also used when comparing a Compare operations [RFC4511]. They are also used when comparing a
purported distinguished name [MODELS] with the name of an entry. purported distinguished name [RFC4512] with the name of an entry.
When modifying entries, matching rules are used to identify values to When modifying entries, matching rules are used to identify values to
be deleted and to prevent an attribute from containing two equal be deleted and to prevent an attribute from containing two equal
values. values.
Matching rules that are required for directory operation, or that are Matching rules that are required for directory operation, or that are
in common use, are specified in this section. in common use, are specified in this section.
4.1. General Considerations 4.1. General Considerations
A matching rule is applied to attribute values through an A matching rule is applied to attribute values through an
AttributeValueAssertion or MatchingRuleAssertion [PROT]. The AttributeValueAssertion or MatchingRuleAssertion [RFC4511]. The
conditions under which an AttributeValueAssertion or conditions under which an AttributeValueAssertion or
MatchingRuleAssertion evaluates to Undefined are specified elsewhere MatchingRuleAssertion evaluates to Undefined are specified elsewhere
[PROT]. If an assertion is not Undefined then the result of the [RFC4511]. If an assertion is not Undefined, then the result of the
assertion is the result of applying the selected matching rule. A assertion is the result of applying the selected matching rule. A
matching rule evaluates to TRUE, and in some cases Undefined, as matching rule evaluates to TRUE, and in some cases Undefined, as
specified in the description of the matching rule, otherwise it specified in the description of the matching rule; otherwise, it
evaluates to FALSE. evaluates to FALSE.
Each assertion contains an assertion value. The definition of each Each assertion contains an assertion value. The definition of each
matching rule specifies the syntax for the assertion value. The matching rule specifies the syntax for the assertion value. The
syntax of the assertion value is typically, but not necessarily, the syntax of the assertion value is typically, but not necessarily, the
same as the syntax of the attribute values to which the matching rule same as the syntax of the attribute values to which the matching rule
may be applied. Note that an AssertionValue in a SubstringFilter may be applied. Note that an AssertionValue in a SubstringFilter
[PROT] conforms to the assertion syntax of the equality matching rule [RFC4511] conforms to the assertion syntax of the equality matching
for the attribute type rather than the assertion syntax of the rule for the attribute type rather than to the assertion syntax of
substrings matching rule for the attribute type. Conceptually, the the substrings matching rule for the attribute type. Conceptually,
entire SubstringFilter is converted into an assertion value of the the entire SubstringFilter is converted into an assertion value of
substrings matching rule prior to applying the rule. the substrings matching rule prior to applying the rule.
The definition of each matching rule indicates the attribute syntaxes The definition of each matching rule indicates the attribute syntaxes
to which the rule may be applied, by specifying conditions the to which the rule may be applied, by specifying conditions the
corresponding ASN.1 type of a candidate attribute syntax must corresponding ASN.1 type of a candidate attribute syntax must
satisfy. These conditions are also satisfied if the corresponding satisfy. These conditions are also satisfied if the corresponding
ASN.1 type is a tagged or constrained derivative of the ASN.1 type ASN.1 type is a tagged or constrained derivative of the ASN.1 type
explicitly mentioned in the rule description (i.e., ASN.1 tags and explicitly mentioned in the rule description (i.e., ASN.1 tags and
constraints are ignored in checking applicability), or an alternative constraints are ignored in checking applicability), or is an
reference notation for the explicitly mentioned type. Each rule alternative reference notation for the explicitly mentioned type.
description lists as examples of applicable attribute syntaxes, the Each rule description lists, as examples of applicable attribute
complete list of the syntaxes defined in this document to which the syntaxes, the complete list of the syntaxes defined in this document
matching rule applies. A matching rule may be applicable to to which the matching rule applies. A matching rule may be
additional syntaxes defined in other documents if those syntaxes applicable to additional syntaxes defined in other documents if those
satisfy the conditions on the corresponding ASN.1 type. syntaxes satisfy the conditions on the corresponding ASN.1 type.
The description of each matching rule indicates whether the rule is The description of each matching rule indicates whether the rule is
suitable for use as the equality matching rule (EQUALITY), ordering suitable for use as the equality matching rule (EQUALITY), ordering
matching rule (ORDERING) or substrings matching rule (SUBSTR) in an matching rule (ORDERING), or substrings matching rule (SUBSTR) in an
attribute type definition [MODELS]. attribute type definition [RFC4512].
Each matching rule is uniquely identified with an object identifier. Each matching rule is uniquely identified with an object identifier.
The definition of a matching rule should not be subsequently changed. The definition of a matching rule should not subsequently be changed.
If a change is desirable then a new matching rule with a different If a change is desirable, then a new matching rule with a different
object identifier should be defined instead. object identifier should be defined instead.
Servers MAY implement the wordMatch and keywordMatch matching rules, Servers MAY implement the wordMatch and keywordMatch matching rules,
but SHOULD implement the other matching rules in Section 4.2. but they SHOULD implement the other matching rules in Section 4.2.
Servers MAY implement additional matching rules. Servers MAY implement additional matching rules.
Servers which implement the extensibleMatch filter SHOULD allow the Servers that implement the extensibleMatch filter SHOULD allow the
matching rules listed in Section 4.2 to be used in the matching rules listed in Section 4.2 to be used in the
extensibleMatch filter and SHOULD allow matching rules to be used extensibleMatch filter and SHOULD allow matching rules to be used
with all attribute types known to the server, where the assertion 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 syntax of the matching rule is the same as the value syntax of the
attribute. attribute.
Servers MUST publish in the matchingRules attribute, the definitions Servers MUST publish, in the matchingRules attribute, the definitions
of matching rules referenced by values of the attributeTypes and of matching rules referenced by values of the attributeTypes and
matchingRuleUse attributes in the same subschema entry. Other matchingRuleUse attributes in the same subschema entry. Other
unreferenced matching rules MAY be published in the matchingRules unreferenced matching rules MAY be published in the matchingRules
attribute. attribute.
If the server supports the extensibleMatch filter, then the server If the server supports the extensibleMatch filter, then the server
MAY use the matchingRuleUse attribute to indicate the applicability MAY use the matchingRuleUse attribute to indicate the applicability
(in an extensibleMatch filter) of selected matching rules to (in an extensibleMatch filter) of selected matching rules to
nominated attribute types. nominated attribute types.
4.2. Matching Rule Definitions 4.2. Matching Rule Definitions
Nominated character strings in assertion and attribute values are Nominated character strings in assertion and attribute values are
prepared according to the string preparation algorithms [PREP] for prepared according to the string preparation algorithms [RFC4518] for
LDAP when evaluating the following matching rules: LDAP when evaluating the following matching rules:
numericStringMatch, numericStringMatch,
numericStringSubstringsMatch, numericStringSubstringsMatch,
caseExactMatch, caseExactMatch,
caseExactOrderingMatch, caseExactOrderingMatch,
caseExactSubstringsMatch, caseExactSubstringsMatch,
caseExactIA5Match, caseExactIA5Match,
caseIgnoreIA5Match, caseIgnoreIA5Match,
caseIgnoreIA5SubstringsMatch, caseIgnoreIA5SubstringsMatch,
caseIgnoreListMatch, caseIgnoreListMatch,
caseIgnoreListSubstringsMatch, caseIgnoreListSubstringsMatch,
caseIgnoreMatch, caseIgnoreMatch,
caseIgnoreOrderingMatch, caseIgnoreOrderingMatch,
caseIgnoreSubstringsMatch, caseIgnoreSubstringsMatch,
directoryStringFirstComponentMatch, directoryStringFirstComponentMatch,
telephoneNumberMatch, telephoneNumberMatch,
telephoneNumberSubstringsMatch and telephoneNumberSubstringsMatch and
wordMatch. wordMatch.
The Transcode, Normalize, Prohibit and Check bidi steps are the same The Transcode, Normalize, Prohibit, and Check bidi steps are the same
for each of the matching rules. However, the Map and Insignificant for each of the matching rules. However, the Map and Insignificant
Character Handling steps depends on the specific rule, as detailed in Character Handling steps depend on the specific rule, as detailed in
the description of these matching rules in the sections that follow. the description of these matching rules in the sections that follow.
4.2.1. bitStringMatch 4.2.1. bitStringMatch
The bitStringMatch rule compares an assertion value of the Bit String The bitStringMatch rule compares an assertion value of the Bit String
syntax to an attribute value of a syntax (e.g., the Bit String syntax to an attribute value of a syntax (e.g., the Bit String
syntax) whose corresponding ASN.1 type is BIT STRING. syntax) whose corresponding ASN.1 type is BIT STRING.
If the corresponding ASN.1 type of the attribute syntax does not have If the corresponding ASN.1 type of the attribute syntax does not have
a named bit list [ASN.1] (which is the case for the Bit String a named bit list [ASN.1] (which is the case for the Bit String
syntax) then the rule evaluates to TRUE if and only if the attribute 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 value has the same number of bits as the assertion value and the bits
match on a bitwise basis. match on a bitwise basis.
If the corresponding ASN.1 type does have a named bit list then If the corresponding ASN.1 type does have a named bit list, then
bitStringMatch operates as above except that trailing zero bits in bitStringMatch operates as above, except that trailing zero bits in
the attribute and assertion values are treated as absent. the attribute and assertion values are treated as absent.
The LDAP definition for the bitStringMatch rule is: The LDAP definition for the bitStringMatch rule is:
( 2.5.13.16 NAME 'bitStringMatch' ( 2.5.13.16 NAME 'bitStringMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
The bitStringMatch rule is an equality matching rule. The bitStringMatch rule is an equality matching rule.
4.2.2. booleanMatch 4.2.2. booleanMatch
skipping to change at page 29, line 35 skipping to change at page 28, line 41
The LDAP definition for the booleanMatch rule is: The LDAP definition for the booleanMatch rule is:
( 2.5.13.13 NAME 'booleanMatch' ( 2.5.13.13 NAME 'booleanMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )
The booleanMatch rule is an equality matching rule. The booleanMatch rule is an equality matching rule.
4.2.3. caseExactIA5Match 4.2.3. caseExactIA5Match
The caseExactIA5Match rule compares an assertion value of the IA5 The caseExactIA5Match rule compares an assertion value of the IA5
String syntax to an attribute value of a syntax (e.g the IA5 String String syntax to an attribute value of a syntax (e.g., the IA5 String
syntax) whose corresponding ASN.1 type is IA5String. syntax) whose corresponding ASN.1 type is IA5String.
The rule evaluates to TRUE if and only if the prepared attribute The rule evaluates to TRUE if and only if the prepared attribute
value character string and the prepared assertion value character value character string and the prepared assertion value character
string have the same number of characters and corresponding string have the same number of characters and corresponding
characters have the same code point. characters have the same code point.
In preparing the attribute value and assertion value for comparison, In preparing the attribute value and assertion value for comparison,
characters are not case folded in the Map preparation step, and only characters are not case folded in the Map preparation step, and only
Insignificant Space Handling is applied in the Insignificant Insignificant Space Handling is applied in the Insignificant
skipping to change at page 30, line 11 skipping to change at page 29, line 16
( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
The caseExactIA5Match rule is an equality matching rule. The caseExactIA5Match rule is an equality matching rule.
4.2.4. caseExactMatch 4.2.4. caseExactMatch
The caseExactMatch rule compares an assertion value of the Directory The caseExactMatch rule compares an assertion value of the Directory
String syntax to an attribute value of a syntax (e.g., the Directory String syntax to an attribute value of a syntax (e.g., the Directory
String, Printable String, Country String or Telephone Number syntax) String, Printable String, Country String, or Telephone Number syntax)
whose corresponding ASN.1 type is DirectoryString or one of the whose corresponding ASN.1 type is DirectoryString or one of the
alternative string types of DirectoryString, e.g., PrintableString alternative string types of DirectoryString, such as PrintableString
(the other alternatives do not correspond to any syntax defined in (the other alternatives do not correspond to any syntax defined in
this document). this document).
The rule evaluates to TRUE if and only if the prepared attribute The rule evaluates to TRUE if and only if the prepared attribute
value character string and the prepared assertion value character value character string and the prepared assertion value character
string have the same number of characters and corresponding string have the same number of characters and corresponding
characters have the same code point. characters have the same code point.
In preparing the attribute value and assertion value for comparison, In preparing the attribute value and assertion value for comparison,
characters are not case folded in the Map preparation step, and only characters are not case folded in the Map preparation step, and only
skipping to change at page 30, line 38 skipping to change at page 29, line 43
( 2.5.13.5 NAME 'caseExactMatch' ( 2.5.13.5 NAME 'caseExactMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
The caseExactMatch rule is an equality matching rule. The caseExactMatch rule is an equality matching rule.
4.2.5. caseExactOrderingMatch 4.2.5. caseExactOrderingMatch
The caseExactOrderingMatch rule compares an assertion value of the The caseExactOrderingMatch rule compares an assertion value of the
Directory String syntax to an attribute value of a syntax (e.g., the Directory String syntax to an attribute value of a syntax (e.g., the
Directory String, Printable String, Country String or Telephone Directory String, Printable String, Country String, or Telephone
Number syntax) whose corresponding ASN.1 type is DirectoryString or Number syntax) whose corresponding ASN.1 type is DirectoryString or
one of its alternative string types. one of its alternative string types.
The rule evaluates to TRUE if, and only if, in the code point The rule evaluates to TRUE if and only if, in the code point
collation order, the prepared attribute value character string collation order, the prepared attribute value character string
appears earlier than the prepared assertion value character string, appears earlier than the prepared assertion value character string;
i.e., the attribute value is "less than" the assertion value. i.e., the attribute value is "less than" the assertion value.
In preparing the attribute value and assertion value for comparison, In preparing the attribute value and assertion value for comparison,
characters are not case folded in the Map preparation step, and only characters are not case folded in the Map preparation step, and only
Insignificant Space Handling is applied in the Insignificant Insignificant Space Handling is applied in the Insignificant
Character Handling step. Character Handling step.
The LDAP definition for the caseExactOrderingMatch rule is: The LDAP definition for the caseExactOrderingMatch rule is:
( 2.5.13.6 NAME 'caseExactOrderingMatch' ( 2.5.13.6 NAME 'caseExactOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
The caseExactOrderingMatch rule is an ordering matching rule. The caseExactOrderingMatch rule is an ordering matching rule.
4.2.6. caseExactSubstringsMatch 4.2.6. caseExactSubstringsMatch
The caseExactSubstringsMatch rule compares an assertion value of the The caseExactSubstringsMatch rule compares an assertion value of the
Substring Assertion syntax to an attribute value of a syntax (e.g., Substring Assertion syntax to an attribute value of a syntax (e.g.,
the Directory String, Printable String, Country String or Telephone the Directory String, Printable String, Country String, or Telephone
Number syntax) whose corresponding ASN.1 type is DirectoryString or Number syntax) whose corresponding ASN.1 type is DirectoryString or
one of its alternative string types. one of its alternative string types.
The rule evaluates to TRUE if and only if the prepared substrings of The rule evaluates to TRUE if and only if (1) the prepared substrings
the assertion value match disjoint portions of the prepared attribute of the assertion value match disjoint portions of the prepared
value character string in the order of the substrings in the attribute value character string in the order of the substrings in
assertion value, and an <initial> substring, if present, matches the the assertion value, (2) an <initial> substring, if present, matches
beginning of the prepared attribute value character string, and a the beginning of the prepared attribute value character string, and
<final> substring, if present, matches the end of the prepared (3) a <final> substring, if present, matches the end of the prepared
attribute value character string. A prepared substring matches a attribute value character string. A prepared substring matches a
portion of the prepared attribute value character string if portion of the prepared attribute value character string if
corresponding characters have the same code point. corresponding characters have the same code point.
In preparing the attribute value and assertion value substrings for In preparing the attribute value and assertion value substrings for
comparison, characters are not case folded in the Map preparation comparison, characters are not case folded in the Map preparation
step, and only Insignificant Space Handling is applied in the step, and only Insignificant Space Handling is applied in the
Insignificant Character Handling step. Insignificant Character Handling step.
The LDAP definition for the caseExactSubstringsMatch rule is: The LDAP definition for the caseExactSubstringsMatch rule is:
( 2.5.13.7 NAME 'caseExactSubstringsMatch' ( 2.5.13.7 NAME 'caseExactSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
The caseExactSubstringsMatch rule is a substrings matching rule. The caseExactSubstringsMatch rule is a substrings matching rule.
4.2.7. caseIgnoreIA5Match 4.2.7. caseIgnoreIA5Match
The caseIgnoreIA5Match rule compares an assertion value of the IA5 The caseIgnoreIA5Match rule compares an assertion value of the IA5
String syntax to an attribute value of a syntax (e.g the IA5 String String syntax to an attribute value of a syntax (e.g., the IA5 String
syntax) whose corresponding ASN.1 type is IA5String. syntax) whose corresponding ASN.1 type is IA5String.
The rule evaluates to TRUE if and only if the prepared attribute The rule evaluates to TRUE if and only if the prepared attribute
value character string and the prepared assertion value character value character string and the prepared assertion value character
string have the same number of characters and corresponding string have the same number of characters and corresponding
characters have the same code point. characters have the same code point.
In preparing the attribute value and assertion value for comparison, In preparing the attribute value and assertion value for comparison,
characters are case folded in the Map preparation step, and only characters are case folded in the Map preparation step, and only
Insignificant Space Handling is applied in the Insignificant Insignificant Space Handling is applied in the Insignificant
skipping to change at page 32, line 17 skipping to change at page 31, line 25
The LDAP definition for the caseIgnoreIA5Match rule is: The LDAP definition for the caseIgnoreIA5Match rule is:
( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
The caseIgnoreIA5Match rule is an equality matching rule. The caseIgnoreIA5Match rule is an equality matching rule.
4.2.8. caseIgnoreIA5SubstringsMatch 4.2.8. caseIgnoreIA5SubstringsMatch
The caseIgnoreIA5SubstringsMatch rule compares an assertion value of The caseIgnoreIA5SubstringsMatch rule compares an assertion value of
the Substring Assertion syntax to an attribute value of a syntax (e.g the Substring Assertion syntax to an attribute value of a syntax
the IA5 String syntax) whose corresponding ASN.1 type is IA5String. (e.g., the IA5 String syntax) whose corresponding ASN.1 type is
IA5String.
The rule evaluates to TRUE if and only if the prepared substrings of The rule evaluates to TRUE if and only if (1) the prepared substrings
the assertion value match disjoint portions of the prepared attribute of the assertion value match disjoint portions of the prepared
value character string in the order of the substrings in the attribute value character string in the order of the substrings in
assertion value, and an <initial> substring, if present, matches the the assertion value, (2) an <initial> substring, if present, matches
beginning of the prepared attribute value character string, and a the beginning of the prepared attribute value character string, and
<final> substring, if present, matches the end of the prepared (3) a <final> substring, if present, matches the end of the prepared
attribute value character string. A prepared substring matches a attribute value character string. A prepared substring matches a
portion of the prepared attribute value character string if portion of the prepared attribute value character string if
corresponding characters have the same code point. corresponding characters have the same code point.
In preparing the attribute value and assertion value substrings for In preparing the attribute value and assertion value substrings for
comparison, characters are case folded in the Map preparation step, comparison, characters are case folded in the Map preparation step,
and only Insignificant Space Handling is applied in the Insignificant and only Insignificant Space Handling is applied in the Insignificant
Character Handling step. Character Handling step.
( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch' ( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch'
skipping to change at page 33, line 5 skipping to change at page 32, line 12
The caseIgnoreListMatch rule compares an assertion value that is a The caseIgnoreListMatch rule compares an assertion value that is a
sequence of strings to an attribute value of a syntax (e.g., the sequence of strings to an attribute value of a syntax (e.g., the
Postal Address syntax) whose corresponding ASN.1 type is a SEQUENCE Postal Address syntax) whose corresponding ASN.1 type is a SEQUENCE
OF the DirectoryString ASN.1 type. OF the DirectoryString ASN.1 type.
The rule evaluates to TRUE if and only if the attribute value and the The rule evaluates to TRUE if and only if the attribute value and the
assertion value have the same number of strings and corresponding assertion value have the same number of strings and corresponding
strings (by position) match according to the caseIgnoreMatch matching strings (by position) match according to the caseIgnoreMatch matching
rule. rule.
In [X.520] the assertion syntax for this matching rule is defined to In [X.520], the assertion syntax for this matching rule is defined to
be: be:
SEQUENCE OF DirectoryString {ub-match} SEQUENCE OF DirectoryString {ub-match}
i.e., different from the corresponding type for the Postal Address That is, it is different from the corresponding type for the Postal
syntax. The choice of the Postal Address syntax for the assertion Address syntax. The choice of the Postal Address syntax for the
syntax of the caseIgnoreListMatch in LDAP should not be seen as assertion syntax of the caseIgnoreListMatch in LDAP should not be
limiting the matching rule to only apply to attributes with the seen as limiting the matching rule to apply only to attributes with
Postal Address syntax. the Postal Address syntax.
The LDAP definition for the caseIgnoreListMatch rule is: The LDAP definition for the caseIgnoreListMatch rule is:
( 2.5.13.11 NAME 'caseIgnoreListMatch' ( 2.5.13.11 NAME 'caseIgnoreListMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
The caseIgnoreListMatch rule is an equality matching rule. The caseIgnoreListMatch rule is an equality matching rule.
4.2.10. caseIgnoreListSubstringsMatch 4.2.10. caseIgnoreListSubstringsMatch
skipping to change at page 34, line 4 skipping to change at page 33, line 12
( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch' ( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
The caseIgnoreListSubstringsMatch rule is a substrings matching rule. The caseIgnoreListSubstringsMatch rule is a substrings matching rule.
4.2.11. caseIgnoreMatch 4.2.11. caseIgnoreMatch
The caseIgnoreMatch rule compares an assertion value of the Directory The caseIgnoreMatch rule compares an assertion value of the Directory
String syntax to an attribute value of a syntax (e.g., the Directory String syntax to an attribute value of a syntax (e.g., the Directory
String, Printable String, Country String or Telephone Number syntax) String, Printable String, Country String, or Telephone Number syntax)
whose corresponding ASN.1 type is DirectoryString or one of its whose corresponding ASN.1 type is DirectoryString or one of its
alternative string types. alternative string types.
The rule evaluates to TRUE if and only if the prepared attribute The rule evaluates to TRUE if and only if the prepared attribute
value character string and the prepared assertion value character value character string and the prepared assertion value character
string have the same number of characters and corresponding string have the same number of characters and corresponding
characters have the same code point. characters have the same code point.
In preparing the attribute value and assertion value for comparison, In preparing the attribute value and assertion value for comparison,
characters are case folded in the Map preparation step, and only characters are case folded in the Map preparation step, and only
skipping to change at page 34, line 29 skipping to change at page 33, line 37
( 2.5.13.2 NAME 'caseIgnoreMatch' ( 2.5.13.2 NAME 'caseIgnoreMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
The caseIgnoreMatch rule is an equality matching rule. The caseIgnoreMatch rule is an equality matching rule.
4.2.12. caseIgnoreOrderingMatch 4.2.12. caseIgnoreOrderingMatch
The caseIgnoreOrderingMatch rule compares an assertion value of the The caseIgnoreOrderingMatch rule compares an assertion value of the
Directory String syntax to an attribute value of a syntax (e.g., the Directory String syntax to an attribute value of a syntax (e.g., the
Directory String, Printable String, Country String or Telephone Directory String, Printable String, Country String, or Telephone
Number syntax) whose corresponding ASN.1 type is DirectoryString or Number syntax) whose corresponding ASN.1 type is DirectoryString or
one of its alternative string types. one of its alternative string types.
The rule evaluates to TRUE if, and only if, in the code point The rule evaluates to TRUE if and only if, in the code point
collation order, the prepared attribute value character string collation order, the prepared attribute value character string
appears earlier than the prepared assertion value character string, appears earlier than the prepared assertion value character string;
i.e., the attribute value is "less than" the assertion value. i.e., the attribute value is "less than" the assertion value.
In preparing the attribute value and assertion value for comparison, In preparing the attribute value and assertion value for comparison,
characters are case folded in the Map preparation step, and only characters are case folded in the Map preparation step, and only
Insignificant Space Handling is applied in the Insignificant Insignificant Space Handling is applied in the Insignificant
Character Handling step. Character Handling step.
The LDAP definition for the caseIgnoreOrderingMatch rule is: The LDAP definition for the caseIgnoreOrderingMatch rule is:
( 2.5.13.3 NAME 'caseIgnoreOrderingMatch' ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch'
skipping to change at page 35, line 4 skipping to change at page 34, line 11
Character Handling step. Character Handling step.
The LDAP definition for the caseIgnoreOrderingMatch rule is: 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 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
The caseIgnoreOrderingMatch rule is an ordering matching rule. The caseIgnoreOrderingMatch rule is an ordering matching rule.
4.2.13. caseIgnoreSubstringsMatch 4.2.13. caseIgnoreSubstringsMatch
The caseIgnoreSubstringsMatch rule compares an assertion value of the The caseIgnoreSubstringsMatch rule compares an assertion value of the
Substring Assertion syntax to an attribute value of a syntax (e.g., Substring Assertion syntax to an attribute value of a syntax (e.g.,
the Directory String, Printable String, Country String or Telephone the Directory String, Printable String, Country String, or Telephone
Number syntax) whose corresponding ASN.1 type is DirectoryString or Number syntax) whose corresponding ASN.1 type is DirectoryString or
one of its alternative string types. one of its alternative string types.
The rule evaluates to TRUE if and only if the prepared substrings of The rule evaluates to TRUE if and only if (1) the prepared substrings
the assertion value match disjoint portions of the prepared attribute of the assertion value match disjoint portions of the prepared
value character string in the order of the substrings in the attribute value character string in the order of the substrings in
assertion value, and an <initial> substring, if present, matches the the assertion value, (2) an <initial> substring, if present, matches
beginning of the prepared attribute value character string, and a the beginning of the prepared attribute value character string, and
<final> substring, if present, matches the end of the prepared (3) a <final> substring, if present, matches the end of the prepared
attribute value character string. A prepared substring matches a attribute value character string. A prepared substring matches a
portion of the prepared attribute value character string if portion of the prepared attribute value character string if
corresponding characters have the same code point. corresponding characters have the same code point.
In preparing the attribute value and assertion value substrings for In preparing the attribute value and assertion value substrings for
comparison, characters are case folded in the Map preparation step, comparison, characters are case folded in the Map preparation step,
and only Insignificant Space Handling is applied in the Insignificant and only Insignificant Space Handling is applied in the Insignificant
Character Handling step. Character Handling step.
The LDAP definition for the caseIgnoreSubstringsMatch rule is: The LDAP definition for the caseIgnoreSubstringsMatch rule is:
skipping to change at page 36, line 44 skipping to change at page 36, line 8
The LDAP definition for the distinguishedNameMatch rule is: 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 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
The distinguishedNameMatch rule is an equality matching rule. The distinguishedNameMatch rule is an equality matching rule.
4.2.16. generalizedTimeMatch 4.2.16. generalizedTimeMatch
The generalizedTimeMatch rule compares an assertion value of the 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 to an attribute value of a syntax (e.g., the
Generalized Time syntax) whose corresponding ASN.1 type is Generalized Time syntax) whose corresponding ASN.1 type is
GeneralizedTime. GeneralizedTime.
The rule evaluates to TRUE if and only if the attribute value The rule evaluates to TRUE if and only if the attribute value
represents the same universal coordinated time as the assertion represents the same universal coordinated time as the assertion
value. If a time is specified with the minutes or seconds absent value. If a time is specified with the minutes or seconds absent,
then the number of minutes or seconds (respectively) is assumed to be then the number of minutes or seconds (respectively) is assumed to be
zero. zero.
The LDAP definition for the generalizedTimeMatch rule is: 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 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
The generalizedTimeMatch rule is an equality matching rule. The generalizedTimeMatch rule is an equality matching rule.
4.2.17. generalizedTimeOrderingMatch 4.2.17. generalizedTimeOrderingMatch
The generalizedTimeOrderingMatch rule compares the time ordering of The generalizedTimeOrderingMatch rule compares the time ordering of
an assertion value of the Generalized Time syntax to an attribute an assertion value of the Generalized Time syntax to an attribute
value of a syntax (e.g the Generalized Time syntax) whose value of a syntax (e.g., the Generalized Time syntax) whose
corresponding ASN.1 type is GeneralizedTime. corresponding ASN.1 type is GeneralizedTime.
The rule evaluates to TRUE if and only if the attribute value The rule evaluates to TRUE if and only if the attribute value
represents a universal coordinated time which is earlier than the represents a universal coordinated time that is earlier than the
universal coordinated time represented by the assertion value. universal coordinated time represented by the assertion value.
The LDAP definition for the generalizedTimeOrderingMatch rule is: 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 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
The generalizedTimeOrderingMatch rule is an ordering matching rule. The generalizedTimeOrderingMatch rule is an ordering matching rule.
4.2.18. integerFirstComponentMatch 4.2.18. integerFirstComponentMatch
The integerFirstComponentMatch rule compares an assertion value of The integerFirstComponentMatch rule compares an assertion value of
the Integer syntax to an attribute value of a syntax (e.g the DIT the Integer syntax to an attribute value of a syntax (e.g., the DIT
Structure Rule Description syntax) whose corresponding ASN.1 type is Structure Rule Description syntax) whose corresponding ASN.1 type is
a SEQUENCE with a mandatory first component of the INTEGER ASN.1 a SEQUENCE with a mandatory first component of the INTEGER ASN.1
type. type.
Note that the assertion syntax of this matching rule differs from the Note that the assertion syntax of this matching rule differs from the
attribute syntax of attributes for which this is the equality attribute syntax of attributes for which this is the equality
matching rule. matching rule.
The rule evaluates to TRUE if and only if the assertion value and the 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. first component of the attribute value are the same integer value.
skipping to change at page 38, line 12 skipping to change at page 37, line 28
The integerFirstComponentMatch rule is an equality matching rule. The integerFirstComponentMatch rule is an equality matching rule.
When using integerFirstComponentMatch to compare two attribute values When using integerFirstComponentMatch to compare two attribute values
(of an applicable syntax), an assertion value must first be derived (of an applicable syntax), an assertion value must first be derived
from one of the attribute values. An assertion value can 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 from an attribute value by taking the first component of that
attribute value. attribute value.
4.2.19. integerMatch 4.2.19. integerMatch
The integerMatch rule compares an assertion value of the Integer The integerMatch rule compares an assertion value of the Integer
syntax to an attribute value of a syntax (e.g the Integer syntax) syntax to an attribute value of a syntax (e.g., the Integer syntax)
whose corresponding ASN.1 type is INTEGER. whose corresponding ASN.1 type is INTEGER.
The rule evaluates to TRUE if and only if the attribute value and the The rule evaluates to TRUE if and only if the attribute value and the
assertion value are the same integer value. assertion value are the same integer value.
The LDAP definition for the integerMatch matching rule is: 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 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
The integerMatch rule is an equality matching rule. The integerMatch rule is an equality matching rule.
4.2.20. integerOrderingMatch 4.2.20. integerOrderingMatch
The integerOrderingMatch rule compares an assertion value of the The integerOrderingMatch rule compares an assertion value of the
Integer syntax to an attribute value of a syntax (e.g the Integer Integer syntax to an attribute value of a syntax (e.g., the Integer
syntax) whose corresponding ASN.1 type is INTEGER. syntax) whose corresponding ASN.1 type is INTEGER.
The rule evaluates to TRUE if and only if the integer value of the The rule evaluates to TRUE if and only if the integer value of the
attribute value is less than the integer value the assertion value. attribute value is less than the integer value of the assertion
value.
The LDAP definition for the integerOrderingMatch matching rule is: The LDAP definition for the integerOrderingMatch matching rule is:
( 2.5.13.15 NAME 'integerOrderingMatch' ( 2.5.13.15 NAME 'integerOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
The integerOrderingMatch rule is an ordering matching rule. The integerOrderingMatch rule is an ordering matching rule.
4.2.21. keywordMatch 4.2.21. keywordMatch
skipping to change at page 39, line 13 skipping to change at page 38, line 29
of the match are both implementation specific. of the match are both implementation specific.
The LDAP definition for the keywordMatch rule is: The LDAP definition for the keywordMatch rule is:
( 2.5.13.33 NAME 'keywordMatch' ( 2.5.13.33 NAME 'keywordMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
4.2.22. numericStringMatch 4.2.22. numericStringMatch
The numericStringMatch rule compares an assertion value of the The numericStringMatch rule compares an assertion value of the
Numeric String syntax to an attribute value of a syntax (e.g the Numeric String syntax to an attribute value of a syntax (e.g., the
Numeric String syntax) whose corresponding ASN.1 type is Numeric String syntax) whose corresponding ASN.1 type is
NumericString. NumericString.
The rule evaluates to TRUE if and only if the prepared attribute The rule evaluates to TRUE if and only if the prepared attribute
value character string and the prepared assertion value character value character string and the prepared assertion value character
string have the same number of characters and corresponding string have the same number of characters and corresponding
characters have the same code point. characters have the same code point.
In preparing the attribute value and assertion value for comparison, In preparing the attribute value and assertion value for comparison,
characters are not case folded in the Map preparation step, and only characters are not case folded in the Map preparation step, and only
skipping to change at page 39, line 37 skipping to change at page 39, line 8
The LDAP definition for the numericStringMatch matching rule is: 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 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
The numericStringMatch rule is an equality matching rule. The numericStringMatch rule is an equality matching rule.
4.2.23. numericStringOrderingMatch 4.2.23. numericStringOrderingMatch
The numericStringOrderingMatch rule compares an assertion value of The numericStringOrderingMatch rule compares an assertion value of
the Numeric String syntax to an attribute value of a syntax (e.g the the Numeric String syntax to an attribute value of a syntax (e.g.,
Numeric String syntax) whose corresponding ASN.1 type is the Numeric String syntax) whose corresponding ASN.1 type is
NumericString. NumericString.
The rule evaluates to TRUE if, and only if, in the code point The rule evaluates to TRUE if and only if, in the code point
collation order, the prepared attribute value character string collation order, the prepared attribute value character string
appears earlier than the prepared assertion value character string, appears earlier than the prepared assertion value character string;
i.e., the attribute value is "less than" the assertion value. i.e., the attribute value is "less than" the assertion value.
In preparing the attribute value and assertion value for comparison, In preparing the attribute value and assertion value for comparison,
characters are not case folded in the Map preparation step, and only characters are not case folded in the Map preparation step, and only
numericString Insignificant Character Handling is applied in the numericString Insignificant Character Handling is applied in the
Insignificant Character Handling step. Insignificant Character Handling step.
The rule is identical to the caseIgnoreOrderingMatch rule except that The rule is identical to the caseIgnoreOrderingMatch rule except that
all space characters are skipped during comparison (case is all space characters are skipped during comparison (case is
irrelevant as characters are numeric). irrelevant as the characters are numeric).
The LDAP definition for the numericStringOrderingMatch matching rule The LDAP definition for the numericStringOrderingMatch matching rule
is: is:
( 2.5.13.9 NAME 'numericStringOrderingMatch' ( 2.5.13.9 NAME 'numericStringOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
The numericStringOrderingMatch rule is an ordering matching rule. The numericStringOrderingMatch rule is an ordering matching rule.
4.2.24. numericStringSubstringsMatch 4.2.24. numericStringSubstringsMatch
The numericStringSubstringsMatch rule compares an assertion value of The numericStringSubstringsMatch rule compares an assertion value of
the Substring Assertion syntax to an attribute value of a syntax (e.g the Substring Assertion syntax to an attribute value of a syntax
the Numeric String syntax) whose corresponding ASN.1 type is (e.g., the Numeric String syntax) whose corresponding ASN.1 type is
NumericString. NumericString.
The rule evaluates to TRUE if and only if the prepared substrings of The rule evaluates to TRUE if and only if (1) the prepared substrings
the assertion value match disjoint portions of the prepared attribute of the assertion value match disjoint portions of the prepared
value character string in the order of the substrings in the attribute value character string in the order of the substrings in
assertion value, and an <initial> substring, if present, matches the the assertion value, (2) an <initial> substring, if present, matches
beginning of the prepared attribute value character string, and a the beginning of the prepared attribute value character string, and
<final> substring, if present, matches the end of the prepared (3) a <final> substring, if present, matches the end of the prepared
attribute value character string. A prepared substring matches a attribute value character string. A prepared substring matches a
portion of the prepared attribute value character string if portion of the prepared attribute value character string if
corresponding characters have the same code point. corresponding characters have the same code point.
In preparing the attribute value and assertion value for comparison, In preparing the attribute value and assertion value for comparison,
characters are not case folded in the Map preparation step, and only characters are not case folded in the Map preparation step, and only
numericString Insignificant Character Handling is applied in the numericString Insignificant Character Handling is applied in the
Insignificant Character Handling step. Insignificant Character Handling step.
The LDAP definition for the numericStringSubstringsMatch matching The LDAP definition for the numericStringSubstringsMatch matching
rule is: rule is:
( 2.5.13.10 NAME 'numericStringSubstringsMatch' ( 2.5.13.10 NAME 'numericStringSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
The numericStringSubstringsMatch rule is a substrings matching rule. The numericStringSubstringsMatch rule is a substrings matching rule.
4.2.25. objectIdentifierFirstComponentMatch 4.2.25. objectIdentifierFirstComponentMatch
The objectIdentifierFirstComponentMatch rule compares an assertion The objectIdentifierFirstComponentMatch rule compares an assertion
value of the OID syntax to an attribute value of a syntax (e.g the value of the OID syntax to an attribute value of a syntax (e.g., the
Attribute Type Description, DIT Content Rule Description, LDAP Syntax Attribute Type Description, DIT Content Rule Description, LDAP Syntax
Description, Matching Rule Description, Matching Rule Use Description, Matching Rule Description, Matching Rule Use
Description, Name Form Description or Object Class Description Description, Name Form Description, or Object Class Description
syntax) whose corresponding ASN.1 type is a SEQUENCE with a mandatory syntax) whose corresponding ASN.1 type is a SEQUENCE with a mandatory
first component of the OBJECT IDENTIFIER ASN.1 type. first component of the OBJECT IDENTIFIER ASN.1 type.
Note that the assertion syntax of this matching rule differs from the Note that the assertion syntax of this matching rule differs from the
attribute syntax of attributes for which this is the equality attribute syntax of attributes for which this is the equality
matching rule. matching rule.
The rule evaluates to TRUE if and only if the assertion value matches The rule evaluates to TRUE if and only if the assertion value matches
the first component of the attribute value using the rules of the first component of the attribute value using the rules of
objectIdentifierMatch. objectIdentifierMatch.
skipping to change at page 41, line 30 skipping to change at page 40, line 49
The objectIdentifierFirstComponentMatch rule is an equality matching The objectIdentifierFirstComponentMatch rule is an equality matching
rule. When using objectIdentifierFirstComponentMatch to compare two rule. When using objectIdentifierFirstComponentMatch to compare two
attribute values (of an applicable syntax), an assertion value must attribute values (of an applicable syntax), an assertion value must
first be derived from one of the attribute values. An assertion first be derived from one of the attribute values. An assertion
value can be derived from an attribute value by taking the first value can be derived from an attribute value by taking the first
component of that attribute value. component of that attribute value.
4.2.26. objectIdentifierMatch 4.2.26. objectIdentifierMatch
The objectIdentifierMatch rule compares an assertion value of the OID The objectIdentifierMatch rule compares an assertion value of the OID
syntax to an attribute value of a syntax (e.g the OID syntax) whose syntax to an attribute value of a syntax (e.g., the OID syntax) whose
corresponding ASN.1 type is OBJECT IDENTIFIER. corresponding ASN.1 type is OBJECT IDENTIFIER.
The rule evaluates to TRUE if and only if the assertion value and the The rule evaluates to TRUE if and only if the assertion value and the
attribute value represent the same object identifier, that is, the attribute value represent the same object identifier; that is, the
same sequence of integers, whether represented explicitly in the same sequence of integers, whether represented explicitly in the
<numericoid> form of <oid> or implicitly in the <descr> form (see <numericoid> form of <oid> or implicitly in the <descr> form (see
[MODELS]). [RFC4512]).
If an LDAP client supplies an assertion value in the <descr> form, If an LDAP client supplies an assertion value in the <descr> form and
and the chosen descriptor is not recognized by the server, then the the chosen descriptor is not recognized by the server, then the
objectIdentifierMatch rule evaluates to Undefined. objectIdentifierMatch rule evaluates to Undefined.
The LDAP definition for the objectIdentifierMatch matching rule is: The LDAP definition for the objectIdentifierMatch matching rule is:
( 2.5.13.0 NAME 'objectIdentifierMatch' ( 2.5.13.0 NAME 'objectIdentifierMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
The objectIdentifierMatch rule is an equality matching rule. The objectIdentifierMatch rule is an equality matching rule.
4.2.27. octetStringMatch 4.2.27. octetStringMatch
skipping to change at page 42, line 4 skipping to change at page 41, line 23
objectIdentifierMatch rule evaluates to Undefined. objectIdentifierMatch rule evaluates to Undefined.
The LDAP definition for the objectIdentifierMatch matching rule is: The LDAP definition for the objectIdentifierMatch matching rule is:
( 2.5.13.0 NAME 'objectIdentifierMatch' ( 2.5.13.0 NAME 'objectIdentifierMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
The objectIdentifierMatch rule is an equality matching rule. The objectIdentifierMatch rule is an equality matching rule.
4.2.27. octetStringMatch 4.2.27. octetStringMatch
The octetStringMatch rule compares an assertion value of the Octet The octetStringMatch rule compares an assertion value of the Octet
String syntax to an attribute value of a syntax (e.g the Octet String String syntax to an attribute value of a syntax (e.g., the Octet
or JPEG syntax) whose corresponding ASN.1 type is the OCTET STRING String or JPEG syntax) whose corresponding ASN.1 type is the OCTET
ASN.1 type. STRING ASN.1 type.
The rule evaluates to TRUE if and only if the attribute value and the The rule evaluates to TRUE if and only if the attribute value and the
assertion value are the same length and corresponding octets (by assertion value are the same length and corresponding octets (by
position) are the same. position) are the same.
The LDAP definition for the octetStringMatch matching rule is: 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 )
The octetStringMatch rule is an equality matching rule. The octetStringMatch rule is an equality matching rule.
4.2.28. octetStringOrderingMatch 4.2.28. octetStringOrderingMatch
The octetStringOrderingMatch rule compares an assertion value of the The octetStringOrderingMatch rule compares an assertion value of the
Octet String syntax to an attribute value of a syntax (e.g the Octet Octet String syntax to an attribute value of a syntax (e.g., the
String or JPEG syntax) whose corresponding ASN.1 type is the OCTET Octet String or JPEG syntax) whose corresponding ASN.1 type is the
STRING ASN.1 type. OCTET STRING ASN.1 type.
The rule evaluates to TRUE if and only if the attribute value appears The rule evaluates to TRUE if and only if the attribute value appears
earlier in the collation order than the assertion value. The rule earlier in the collation order than the assertion value. The rule
compares octet strings from the first octet to the last octet, and compares octet strings from the first octet to the last octet, and
from the most significant bit to the least significant bit within the from the most significant bit to the least significant bit within the
octet. The first occurrence of a different bit determines the octet. The first occurrence of a different bit determines the
ordering of the strings. A zero bit precedes a one bit. If the ordering of the strings. A zero bit precedes a one bit. If the
strings contain different numbers of octets but the longer string is strings contain different numbers of octets but the longer string is
identical to the shorter string up to the length of the shorter identical to the shorter string up to the length of the shorter
string then the shorter string precedes the longer string. string, then the shorter string precedes the longer string.
The LDAP definition for the octetStringOrderingMatch matching rule The LDAP definition for the octetStringOrderingMatch matching rule
is: is:
( 2.5.13.18 NAME 'octetStringOrderingMatch' ( 2.5.13.18 NAME 'octetStringOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
The octetStringOrderingMatch rule is an ordering matching rule. The octetStringOrderingMatch rule is an ordering matching rule.
4.2.29. telephoneNumberMatch 4.2.29. telephoneNumberMatch
The telephoneNumberMatch rule compares an assertion value of the 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 to an attribute value of a syntax (e.g., the
Telephone Number syntax) whose corresponding ASN.1 type is a Telephone Number syntax) whose corresponding ASN.1 type is a
PrintableString representing a telephone number. PrintableString representing a telephone number.
The rule evaluates to TRUE if and only if the prepared attribute The rule evaluates to TRUE if and only if the prepared attribute
value character string and the prepared assertion value character value character string and the prepared assertion value character
string have the same number of characters and corresponding string have the same number of characters and corresponding
characters have the same code point. characters have the same code point.
In preparing the attribute value and assertion value for comparison, In preparing the attribute value and assertion value for comparison,
characters are case folded in the Map preparation step, and only characters are case folded in the Map preparation step, and only
skipping to change at page 43, line 26 skipping to change at page 42, line 44
( 2.5.13.20 NAME 'telephoneNumberMatch' ( 2.5.13.20 NAME 'telephoneNumberMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
The telephoneNumberMatch rule is an equality matching rule. The telephoneNumberMatch rule is an equality matching rule.
4.2.30. telephoneNumberSubstringsMatch 4.2.30. telephoneNumberSubstringsMatch
The telephoneNumberSubstringsMatch rule compares an assertion value The telephoneNumberSubstringsMatch rule compares an assertion value
of the Substring Assertion syntax to an attribute value of a 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 (e.g., the Telephone Number syntax) whose corresponding ASN.1 type is
PrintableString representing a telephone number. a PrintableString representing a telephone number.
The rule evaluates to TRUE if and only if the prepared substrings of The rule evaluates to TRUE if and only if (1) the prepared substrings
the assertion value match disjoint portions of the prepared attribute of the assertion value match disjoint portions of the prepared
value character string in the order of the substrings in the attribute value character string in the order of the substrings in
assertion value, and an <initial> substring, if present, matches the the assertion value, (2) an <initial> substring, if present, matches
beginning of the prepared attribute value character string, and a the beginning of the prepared attribute value character string, and
<final> substring, if present, matches the end of the prepared (3) a <final> substring, if present, matches the end of the prepared
attribute value character string. A prepared substring matches a attribute value character string. A prepared substring matches a
portion of the prepared attribute value character string if portion of the prepared attribute value character string if
corresponding characters have the same code point. corresponding characters have the same code point.
In preparing the attribute value and assertion value substrings for In preparing the attribute value and assertion value substrings for
comparison, characters are case folded in the Map preparation step, comparison, characters are case folded in the Map preparation step,
and only telephoneNumber Insignificant Character Handling is applied and only telephoneNumber Insignificant Character Handling is applied
in the Insignificant Character Handling step. in the Insignificant Character Handling step.
The LDAP definition for the telephoneNumberSubstringsMatch matching The LDAP definition for the telephoneNumberSubstringsMatch matching
skipping to change at page 44, line 8 skipping to change at page 43, line 26
( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch' ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
The telephoneNumberSubstringsMatch rule is a substrings matching The telephoneNumberSubstringsMatch rule is a substrings matching
rule. rule.
4.2.31. uniqueMemberMatch 4.2.31. uniqueMemberMatch
The uniqueMemberMatch rule compares an assertion value of the Name The uniqueMemberMatch rule compares an assertion value of the Name
And Optional UID syntax to an attribute value of a syntax (e.g the 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 Name And Optional UID syntax) whose corresponding ASN.1 type is
NameAndOptionalUID. NameAndOptionalUID.
The rule evaluates to TRUE if and only if the <distinguishedName> The rule evaluates to TRUE if and only if the <distinguishedName>
components of the assertion value and attribute value match according components of the assertion value and attribute value match according
to the distinguishedNameMatch rule and either, the <BitString> to the distinguishedNameMatch rule and either, (1) the <BitString>
component is absent from both the attribute value and assertion component is absent from both the attribute value and assertion
value, or the <BitString> component is present in both the attribute value, or (2) the <BitString> component is present in both the
value and the assertion value and the <BitString> component of the attribute value and the assertion value and the <BitString> component
assertion value matches the <BitString> component of the attribute of the assertion value matches the <BitString> component of the
value according to the bitStringMatch rule. attribute value according to the bitStringMatch rule.
Note that this matching rule has been altered from its description in Note that this matching rule has been altered from its description in
X.520 [X.520] in order to make the matching rule commutative. Server X.520 [X.520] in order to make the matching rule commutative. Server
implementors should consider using the original X.520 semantics implementors should consider using the original X.520 semantics
(where the matching was less exact) for approximate matching of (where the matching was less exact) for approximate matching of
attributes with uniqueMemberMatch as the equality matching rule. attributes with uniqueMemberMatch as the equality matching rule.
The LDAP definition for the uniqueMemberMatch matching rule is: The LDAP definition for the uniqueMemberMatch matching rule is:
( 2.5.13.23 NAME 'uniqueMemberMatch' ( 2.5.13.23 NAME 'uniqueMemberMatch'
skipping to change at page 45, line 7 skipping to change at page 44, line 27
( 2.5.13.32 NAME 'wordMatch' ( 2.5.13.32 NAME 'wordMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
5. Security Considerations 5. Security Considerations
In general, the LDAP-specific encodings for syntaxes defined in this In general, the LDAP-specific encodings for syntaxes defined in this
document do not define canonical encodings. That is, a document do not define canonical encodings. That is, a
transformation from an LDAP-specific encoding into some other transformation from an LDAP-specific encoding into some other
encoding (e.g., BER) and back into the LDAP-specific encoding will encoding (e.g., BER) and back into the LDAP-specific encoding will
not necessarily reproduce exactly the original octets of the not necessarily reproduce exactly the original octets of the LDAP-
LDAP-specific encoding. Therefore an LDAP-specific encoding should specific encoding. Therefore, an LDAP-specific encoding should not
not be used where a canonical encoding is required. be used where a canonical encoding is required.
Furthermore, the LDAP-specific encodings do not necessarily enable an Furthermore, the LDAP-specific encodings do not necessarily enable an
alternative encoding of values of the Directory String and DN alternative encoding of values of the Directory String and DN
syntaxes to be reconstructed, e.g., a transformation from a syntaxes to be reconstructed; e.g., a transformation from a
Distinguished Encoding Rules (DER) [BER] encoding to an LDAP-specific Distinguished Encoding Rules (DER) [BER] encoding to an LDAP-specific
encoding and back to a DER encoding may not reproduce the original encoding and back to a DER encoding may not reproduce the original
DER encoding. Therefore LDAP-specific encodings should not be used DER encoding. Therefore, LDAP-specific encodings should not be used
where reversibility to DER is needed, e.g., for the verification of where reversibility to DER is needed; e.g., for the verification of
digital signatures. Instead, DER or a DER-reversible encoding should digital signatures. Instead, DER or a DER-reversible encoding should
be used. be used.
When interpreting security-sensitive fields, and in particular fields When interpreting security-sensitive fields (in particular, fields
used to grant or deny access, implementations MUST ensure that any used to grant or deny access), implementations MUST ensure that any
matching rule comparisons are done on the underlying abstract value, matching rule comparisons are done on the underlying abstract value,
regardless of the particular encoding used. regardless of the particular encoding used.
6. Acknowledgements 6. Acknowledgements
This document is primarily a revision of RFC 2252 by M. Wahl, A. This document is primarily a revision of RFC 2252 by M. Wahl, A.
Coulbeck, T. Howes, and S. Kille. RFC 2252 was a product of the IETF Coulbeck, T. Howes, and S. Kille. RFC 2252 was a product of the IETF
ASID Working Group. ASID Working Group.
This document is based upon input of the IETF LDAPBIS working group. This document is based on input from the IETF LDAPBIS working group.
The author would like to thank Kathy Dally for editing the early The author would like to thank Kathy Dally for editing the early
drafts of this revision, and Jim Sermersheim and Kurt Zeilenga for drafts of this document, and Jim Sermersheim and Kurt Zeilenga for
their significant contributions to this revision. their significant contributions to this revision.
7. IANA Considerations 7. IANA Considerations
The Internet Assigned Numbers Authority (IANA) is requested to update The Internet Assigned Numbers Authority (IANA) has updated the LDAP
the LDAP descriptors registry [BCP64] as indicated by the following descriptors registry [BCP64] as indicated by the following templates:
templates:
Subject: Request for LDAP Descriptor Registration Update Subject: Request for LDAP Descriptor Registration Update
Descriptor (short name): see comment Descriptor (short name): see comment
Object Identifier: see comment Object Identifier: see comment
Person & email address to contact for further information: Person & email address to contact for further information:
Steven Legg <steven.legg@eb2bcom.com> Steven Legg <steven.legg@eb2bcom.com>
Usage: see comment Usage: see comment
Specification: RFC XXXX Specification: RFC 4517
Author/Change Controller: IESG Author/Change Controller: IESG
Comments:
The following descriptors (short names) should be updated to refer
to RFC XXXX.
NAME Type OID NAME Type OID
------------------------------------------------------------------ ------------------------------------------------------------------
bitStringMatch M 2.5.13.16 bitStringMatch M 2.5.13.16
booleanMatch M 2.5.13.13 booleanMatch M 2.5.13.13
caseExactIA5Match M 1.3.6.1.4.1.1466.109.114.1 caseExactIA5Match M 1.3.6.1.4.1.1466.109.114.1
caseExactMatch M 2.5.13.5 caseExactMatch M 2.5.13.5
caseExactOrderingMatch M 2.5.13.6 caseExactOrderingMatch M 2.5.13.6
caseExactSubstringsMatch M 2.5.13.7 caseExactSubstringsMatch M 2.5.13.7
caseIgnoreIA5Match M 1.3.6.1.4.1.1466.109.114.2 caseIgnoreIA5Match M 1.3.6.1.4.1.1466.109.114.2
skipping to change at page 46, line 42 skipping to change at page 46, line 9
numericStringSubstringsMatch M 2.5.13.10 numericStringSubstringsMatch M 2.5.13.10
objectIdentifierFirstComponentMatch M 2.5.13.30 objectIdentifierFirstComponentMatch M 2.5.13.30
octetStringMatch M 2.5.13.17 octetStringMatch M 2.5.13.17
octetStringOrderingMatch M 2.5.13.18 octetStringOrderingMatch M 2.5.13.18
telephoneNumberMatch M 2.5.13.20 telephoneNumberMatch M 2.5.13.20
telephoneNumberSubstringsMatch M 2.5.13.21 telephoneNumberSubstringsMatch M 2.5.13.21
uniqueMemberMatch M 2.5.13.23 uniqueMemberMatch M 2.5.13.23
wordMatch M 2.5.13.32 wordMatch M 2.5.13.32
The descriptor for the object identifier 2.5.13.0 was incorrectly The descriptor for the object identifier 2.5.13.0 was incorrectly
registered as objectIdentifiersMatch (extraneous `s') in BCP 64. registered as objectIdentifiersMatch (extraneous \`s') in BCP 64.
It should be changed to the following with a reference to It has been changed to the following, with a reference to
RFC XXXX. RFC 4517.
NAME Type OID NAME Type OID
------------------------------------------------------------------ ------------------------------------------------------------------
objectIdentifierMatch M 2.5.13.0 objectIdentifierMatch M 2.5.13.0
Subject: Request for LDAP Descriptor Registration Subject: Request for LDAP Descriptor Registration
Descriptor (short name): caseIgnoreIA5SubstringsMatch Descriptor (short name): caseIgnoreIA5SubstringsMatch
Object Identifier: 1.3.6.1.4.1.1466.109.114.3 Object Identifier: 1.3.6.1.4.1.1466.109.114.3
Person & email address to contact for further information: Person & email address to contact for further information:
Steven Legg <steven.legg@eb2bcom.com> Steven Legg <steven.legg@eb2bcom.com>
Usage: other (M) Usage: other (M)
Specification: RFC XXXX Specification: RFC 4517
Author/Change Controller: IESG Author/Change Controller: IESG
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
(LDAP): Technical Specification Road Map", RFC 4510, June
2006.
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Directory Information Models", RFC 4512, June
2006.
[RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
(LDAP): String Representation of Distinguished Names", RFC
4514, June 2006.
[RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Internationalized String Preparation", RFC 4518,
June 2006.
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
Considerations for the Lightweight Directory Access
Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
[E.123] Notation for national and international telephone numbers,
ITU-T Recommendation E.123, 1988.
[FAX] Standardization of Group 3 facsimile apparatus for
document transmission - Terminal Equipment and Protocols
for Telematic Services, ITU-T Recommendation T.4, 1993
[T.50] International Reference Alphabet (IRA) (Formerly
International Alphabet No. 5 or IA5) Information
Technology - 7-Bit Coded Character Set for Information
Interchange, ITU-T Recommendation T.50, 1992
[X.420] ITU-T Recommendation X.420 (1996) | ISO/IEC 10021-7:1997,
Information Technology - Message Handling Systems (MHS):
Interpersonal messaging system
[X.501] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994,
Information Technology - Open Systems Interconnection -
The Directory: Models
[X.520] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994,
Information Technology - Open Systems Interconnection -
The Directory: Selected attribute types
[ASN.1] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002,
Information technology - Abstract Syntax Notation One
(ASN.1): Specification of basic notation
[ISO3166] ISO 3166, "Codes for the representation of names of
countries".
[ISO8601] ISO 8601:2004, "Data elements and interchange formats --
Information interchange -- Representation of dates and
times".
[UCS] Universal Multiple-Octet Coded Character Set (UCS) -
Architecture and Basic Multilingual Plane, ISO/IEC 10646-
1: 1993 (with amendments).
[JPEG] JPEG File Interchange Format (Version 1.02). Eric
Hamilton, C-Cube Microsystems, Milpitas, CA, September 1,
1992.
8.2. Informative References
[RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol
(LDAP): Schema for User Applications", RFC 4519, June
2006.
[RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP) Schema Definitions for X.509 Certificates", RFC
4523, June 2006.
[X.500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
Information Technology - Open Systems Interconnection -
The Directory: Overview of concepts, models and services
[BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1:2002,
Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)
Appendix A. Summary of Syntax Object Identifiers Appendix A. Summary of Syntax Object Identifiers
The following list summarizes the object identifiers assigned to the The following list summarizes the object identifiers assigned to the
syntaxes defined in this document. syntaxes defined in this document.
Syntax 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
skipping to change at page 48, line 15 skipping to change at page 50, line 10
Appendix B. Changes from RFC 2252 Appendix B. Changes from RFC 2252
This annex lists the significant differences between this This annex lists the significant differences between this
specification and RFC 2252. specification and RFC 2252.
This annex is provided for informational purposes only. It is not a This annex is provided for informational purposes only. It is not a
normative part of this specification. normative part of this specification.
1. The IESG Note has been removed. 1. The IESG Note has been removed.
2. The major part of Sections 4, 5 and 7 has been moved to [MODELS] 2. The major part of Sections 4, 5 and 7 has been moved to [RFC4512]
and revised. Changes to the parts of these sections moved to and revised. Changes to the parts of these sections moved to
[MODELS] are detailed in [MODELS]. [RFC4512] are detailed in [RFC4512].
3. BNF descriptions of syntax formats have been replaced by ABNF 3. BNF descriptions of syntax formats have been replaced by ABNF
[ABNF] specifications. [RFC4234] specifications.
4. The ambiguous statement in RFC 2252, Section 4.3 regarding the 4. The ambiguous statement in RFC 2252, Section 4.3 regarding the
use of a backslash quoting mechanism to escape separator symbols use of a backslash quoting mechanism to escape separator symbols
has been removed. The escaping mechanism is now explicitly has been removed. The escaping mechanism is now explicitly
represented in the ABNF for the syntaxes where this provision represented in the ABNF for the syntaxes where this provision
applies. applies.
5. The description of each of the LDAP syntaxes has been expanded so 5. The description of each of the LDAP syntaxes has been expanded so
that they are less dependent on knowledge of X.500 for that they are less dependent on knowledge of X.500 for
interpretation. interpretation.
skipping to change at page 48, line 45 skipping to change at page 50, line 40
7. The set of characters allowed in a <PrintableString> (formerly 7. The set of characters allowed in a <PrintableString> (formerly
<printablestring>) has been corrected to align with the <printablestring>) has been corrected to align with the
PrintableString ASN.1 type in [ASN.1]. Specifically, the double PrintableString ASN.1 type in [ASN.1]. Specifically, the double
quote character has been removed and the single quote character quote character has been removed and the single quote character
and equals sign have been added. and equals sign have been added.
8. Values of the Directory String, Printable String and Telephone 8. Values of the Directory String, Printable String and Telephone
Number syntaxes are now required to have at least one character. Number syntaxes are now required to have at least one character.
9. The <DITContentRuleDescription>, <NameFormDescription> and 9. The <DITContentRuleDescription>, <NameFormDescription> and
<DITStructureRuleDescription> rules have been moved to [MODELS]. <DITStructureRuleDescription> rules have been moved to [RFC4512].
10. The corresponding ASN.1 type for the Other Mailbox syntax has 10. The corresponding ASN.1 type for the Other Mailbox syntax has
been incorporated from RFC 1274. been incorporated from RFC 1274.
11. A corresponding ASN.1 type for the LDAP Syntax Description syntax 11. A corresponding ASN.1 type for the LDAP Syntax Description syntax
has been invented. has been invented.
12. The Binary syntax has been removed because it was not adequately 12. The Binary syntax has been removed because it was not adequately
specified, implementations with different incompatible specified, implementations with different incompatible
interpretations exist, and it was confused with the ;binary interpretations exist, and it was confused with the ;binary
skipping to change at page 49, line 26 skipping to change at page 51, line 21
been incorporated. been incorporated.
15. The <criteria> rule for the Enhanced Guide and Guide syntaxes has 15. The <criteria> rule for the Enhanced Guide and Guide syntaxes has
been extended to accommodate empty "and" and "or" expressions. been extended to accommodate empty "and" and "or" expressions.
16. An encoding for the <ttx-value> rule in the Teletex Terminal 16. An encoding for the <ttx-value> rule in the Teletex Terminal
Identifier syntax has been defined. Identifier syntax has been defined.
17. The PKI-related syntaxes (Certificate, Certificate List and 17. The PKI-related syntaxes (Certificate, Certificate List and
Certificate Pair) have been removed. They are reintroduced in Certificate Pair) have been removed. They are reintroduced in
[LDAP-PKI] (as is the Supported Algorithm syntax from RFC 2256). [RFC4523] (as is the Supported Algorithm syntax from RFC 2256).
18. The MHS OR Address syntax has been removed since its 18. The MHS OR Address syntax has been removed since its
specification (in RFC 2156) is not at draft standard maturity. specification (in RFC 2156) is not at draft standard maturity.
19. The DL Submit Permission syntax has been removed as it depends on 19. The DL Submit Permission syntax has been removed as it depends on
the MHS OR Address syntax. the MHS OR Address syntax.
20. The Presentation Address syntax has been removed since its 20. The Presentation Address syntax has been removed since its
specification (in RFC 1278) is not at draft standard maturity. specification (in RFC 1278) is not at draft standard maturity.
skipping to change at page 50, line 41 skipping to change at page 52, line 36
31. String preparation algorithms have been applied to the character 31. String preparation algorithms have been applied to the character
string matching rules. string matching rules.
32. The specifications of the booleanMatch, caseExactMatch, 32. The specifications of the booleanMatch, caseExactMatch,
caseExactOrderingMatch, caseExactSubstringsMatch, caseExactOrderingMatch, caseExactSubstringsMatch,
directoryStringFirstComponentMatch, integerOrderingMatch, directoryStringFirstComponentMatch, integerOrderingMatch,
keywordMatch, numericStringOrderingMatch, keywordMatch, numericStringOrderingMatch,
octetStringOrderingMatch and wordMatch matching rules from octetStringOrderingMatch and wordMatch matching rules from
RFC 3698 & X.520 have been added. RFC 3698 & X.520 have been added.
Normative References
[KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 3629, November 2003.
[BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
Considerations for the Lightweight Directory Access
Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", draft-crocker-abnf-rfc2234bis-
xx.txt, a work in progress, March 2005.
[ROADMAP] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Technical Specification Road Map", draft-ietf-
ldapbis-roadmap-xx.txt, a work in progress, February 2005.
[MODELS] Zeilenga, K., "LDAP: Directory Information Models", draft-
ietf-ldapbis-models-xx.txt, a work in progress, February
2005.
[PROT] Sermersheim, J., "LDAP: The Protocol", draft-ietf-ldapbis-
protocol-xx.txt, a work in progress, May 2005.
[LDAPDN] Zeilenga, K., "LDAP: String Representation of
Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work
in progress, February 2005.
[PREP] Zeilenga, K., "LDAP: Internationalized String
Preparation", draft-ietf-ldapbis-strprep-xx.txt, a work in
progress, February 2005.
[E.123] Notation for national and international telephone numbers,
ITU-T Recommendation E.123, 1988.
[FAX] Standardization of Group 3 facsimile apparatus for
document transmission - Terminal Equipment and Protocols
for Telematic Services, ITU-T Recommendation T.4, 1993
[T.50] International Reference Alphabet (IRA) (Formerly
International Alphabet No. 5 or IA5) Information
Technology - 7-Bit Coded Character Set for Information
Interchange, ITU-T Recommendation T.50, 1992
[X.420] ITU-T Recommendation X.420 (1996) | ISO/IEC 10021-7:1997,
Information Technology - Message Handling Systems (MHS):
Interpersonal messaging system
[X.501] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994,
Information Technology - Open Systems Interconnection -
The Directory: Models
[X.520] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994,
Information Technology - Open Systems Interconnection -
The Directory: Selected attribute types
[ASN.1] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002,
Information technology - Abstract Syntax Notation One
(ASN.1): Specification of basic notation
[ISO3166] ISO 3166, "Codes for the representation of names of
countries".
[ISO8601] ISO 8601:2004, "Data elements and interchange formats --
Information interchange -- Representation of dates and
times".
[UCS] Universal Multiple-Octet Coded Character Set (UCS) -
Architecture and Basic Multilingual Plane, ISO/IEC
10646-1: 1993 (with amendments).
[JPEG] JPEG File Interchange Format (Version 1.02). Eric
Hamilton, C-Cube Microsystems, Milpitas, CA, September 1,
1992.
Informative References
[RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
"Lightweight Directory Access Protocol (v3): Attribute
Syntax Definitions", RFC 2252, December 1997.
[RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use
with LDAPv3", RFC 2256, December 1997.
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[RFC3698] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Additional Matching Rules", RFC 3698, February
2004.
[SCHEMA] Sciberras, A., "LDAP: Schema for User Applications",
draft-ietf-ldapbis-user-schema-xx.txt, a work in progress,
April 2005.
[LDAP-PKI] Zeilenga, K. D., "Lightweight Directory Access Protocol
(LDAP) schema definitions for X.509 Certificates", draft-
zeilenga-ldap-x509-xx.txt, a work in progress, February
2005.
[X.500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
Information Technology - Open Systems Interconnection -
The Directory: Overview of concepts, models and services
[BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1:2002,
Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)
Author's Address Author's Address
Steven Legg Steven Legg
eB2Bcom eB2Bcom
Suite3, Woodhouse Corporate Centre Suite3, Woodhouse Corporate Centre
935 Station Street 935 Station Street
Box Hill North, Victoria 3129 Box Hill North, Victoria 3129
AUSTRALIA AUSTRALIA
Phone: +61 3 9896 7830 Phone: +61 3 9896 7830
Fax: +61 3 9896 7801 Fax: +61 3 9896 7801
EMail: steven.legg@eb2bcom.com EMail: steven.legg@eb2bcom.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
skipping to change at line 2523 skipping to change at page 53, line 44
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 174 change blocks. 
523 lines changed or deleted 490 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/