draft-ietf-ldapbis-syntaxes-06.txt   draft-ietf-ldapbis-syntaxes-07.txt 
INTERNET-DRAFT S. Legg, Editor INTERNET-DRAFT S. Legg, Editor
draft-ietf-ldapbis-syntaxes-06.txt Adacel Technologies draft-ietf-ldapbis-syntaxes-07.txt Adacel Technologies
Intended Category: Standard Track K. Dally Intended Category: Standards Track K. Dally
Obsoletes: RFC 2252, RFC 2256 The MITRE Corp. Obsoletes: RFC 2252, RFC 2256 The MITRE Corp.
3 June 2003 27 October 2003
LDAP: Syntaxes and Matching Rules LDAP: Syntaxes and Matching Rules
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This document is intended to be, after appropriate review and This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as a Standard Track document. revision, submitted to the RFC Editor as a Standard Track document.
Distribution of this document is unlimited. Technical discussion of Distribution of this document is unlimited. Technical discussion of
this document should take place on the IETF LDAP Revision Working this document should take place on the IETF LDAP Revision Working
Group (LDAPbis) mailing list <ietf-ldapbis@openldap.org>. Please Group (LDAPbis) mailing list <ietf-ldapbis@openldap.org>. Please
send editorial comments directly to the editor send editorial comments directly to the editor
<steven.legg@adacel.com.au>. <steven.legg@adacel.com.au>.
This Internet-Draft expires on 3 December 2003. This Internet-Draft expires on 27 April 2004.
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, and whose values may be transfered in the LDAP
protocol, has a defined syntax which constrains the structure and protocol, has a defined syntax which 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.
1. Table of Contents Table of Contents
1. Table of Contents ............................................. 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction .................................................. 4 2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Conventions ................................................... 5 3. Syntaxes . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Syntaxes ...................................................... 5 3.1. General Considerations . . . . . . . . . . . . . . . . . 6
4.1 General Considerations .................................... 5 3.2. Common Definitions . . . . . . . . . . . . . . . . . . . 6
4.2 Common Definitions ........................................ 6 3.3. Syntax Definitions . . . . . . . . . . . . . . . . . . . 7
4.3 Syntax Definitions ........................................ 7 3.3.1. Attribute Type Description . . . . . . . . . . . 7
4.3.1 Attribute Type Description ........................... 7 3.3.2. Bit String . . . . . . . . . . . . . . . . . . . 7
4.3.2 Bit String ........................................... 7 3.3.3. Boolean. . . . . . . . . . . . . . . . . . . . . 8
4.3.3 Boolean .............................................. 8 3.3.4. Country String . . . . . . . . . . . . . . . . . 8
4.3.4 Country String ....................................... 8 3.3.5. Delivery Method. . . . . . . . . . . . . . . . . 9
4.3.5 Delivery Method ...................................... 9 3.3.6. Directory String . . . . . . . . . . . . . . . . 9
4.3.6 Directory String ..................................... 9 3.3.7. DIT Content Rule Description . . . . . . . . . . 10
4.3.7 DIT Content Rule Description ......................... 10 3.3.8. DIT Structure Rule Description . . . . . . . . . 11
4.3.8 DIT Structure Rule Description ....................... 11 3.3.9. DN . . . . . . . . . . . . . . . . . . . . . . . 11
4.3.9 DN ................................................... 11 3.3.10. Enhanced Guide . . . . . . . . . . . . . . . . . 12
4.3.10 Enhanced Guide ...................................... 12 3.3.11. Facsimile Telephone Number . . . . . . . . . . . 13
4.3.11 Facsimile Telephone Number .......................... 13 3.3.12. Fax. . . . . . . . . . . . . . . . . . . . . . . 13
4.3.12 Fax ................................................. 13 3.3.13. Generalized Time . . . . . . . . . . . . . . . . 14
4.3.13 Generalized Time .................................... 14 3.3.14. Guide. . . . . . . . . . . . . . . . . . . . . . 15
4.3.14 Guide ............................................... 15 3.3.15. IA5 String . . . . . . . . . . . . . . . . . . . 15
4.3.15 IA5 String .......................................... 15 3.3.16. Integer. . . . . . . . . . . . . . . . . . . . . 15
4.3.16 Integer ............................................. 16 3.3.17. JPEG . . . . . . . . . . . . . . . . . . . . . . 16
4.3.17 JPEG ................................................ 16 3.3.18. LDAP Syntax Description. . . . . . . . . . . . . 16
4.3.18 LDAP Syntax Description ............................. 16 3.3.19. Matching Rule Description. . . . . . . . . . . . 17
4.3.19 Matching Rule Description ........................... 17 3.3.20. Matching Rule Use Description. . . . . . . . . . 17
4.3.20 Matching Rule Use Description ....................... 17 3.3.21. Name and Optional UID. . . . . . . . . . . . . . 18
4.3.21 Name and Optional UID ............................... 18 3.3.22. Name Form Description. . . . . . . . . . . . . . 18
4.3.22 Name Form Description ............................... 19 3.3.23. Numeric String . . . . . . . . . . . . . . . . . 19
4.3.23 Numeric String ...................................... 19 3.3.24. Object Class Description . . . . . . . . . . . . 19
4.3.24 Object Class Description ............................ 19 3.3.25. Octet String . . . . . . . . . . . . . . . . . . 19
4.3.25 Octet String ........................................ 20 3.3.26. OID. . . . . . . . . . . . . . . . . . . . . . . 20
4.3.26 OID ................................................. 20 3.3.27. Other Mailbox. . . . . . . . . . . . . . . . . . 20
4.3.27 Other Mailbox ....................................... 21 3.3.28. Postal Address . . . . . . . . . . . . . . . . . 21
4.3.28 Postal Address ...................................... 21 3.3.29. Printable String . . . . . . . . . . . . . . . . 22
4.3.29 Printable String .................................... 22 3.3.30. Substring Assertion. . . . . . . . . . . . . . . 22
4.3.30 Substring Assertion ................................. 23 3.3.31. Telephone Number . . . . . . . . . . . . . . . . 23
4.3.31 Telephone Number .................................... 24 3.3.32. Teletex Terminal Identifier. . . . . . . . . . . 24
4.3.32 Teletex Terminal Identifier ......................... 24 3.3.33. Telex Number . . . . . . . . . . . . . . . . . . 24
4.3.33 Telex Number ........................................ 25 3.3.34. UTC Time . . . . . . . . . . . . . . . . . . . . 25
4.3.34 UTC Time ............................................ 25 4. Matching Rules . . . . . . . . . . . . . . . . . . . . . . . . 25
5. Matching Rules ................................................ 26 4.1. General Considerations . . . . . . . . . . . . . . . . . 26
5.1 General Considerations .................................... 26 4.2. Matching Rule Definitions. . . . . . . . . . . . . . . . 27
5.2 Matching Rule Definitions ................................. 28 4.2.1. bitStringMatch . . . . . . . . . . . . . . . . . 27
5.2.1 bitStringMatch ....................................... 28 4.2.2. caseExactIA5Match. . . . . . . . . . . . . . . . 28
5.2.2 caseExactIA5Match .................................... 28 4.2.3. caseIgnoreIA5Match . . . . . . . . . . . . . . . 28
5.2.3 caseIgnoreIA5Match ................................... 29 4.2.4. caseIgnoreIA5SubstringsMatch . . . . . . . . . . 29
5.2.4 caseIgnoreIA5SubstringsMatch ......................... 29 4.2.5. caseIgnoreListMatch. . . . . . . . . . . . . . . 29
5.2.5 caseIgnoreListMatch .................................. 30 4.2.6. caseIgnoreListSubstringsMatch. . . . . . . . . . 30
5.2.6 caseIgnoreListSubstringsMatch ........................ 31 4.2.7. caseIgnoreMatch. . . . . . . . . . . . . . . . . 31
5.2.7 caseIgnoreMatch ...................................... 31 4.2.8. caseIgnoreOrderingMatch. . . . . . . . . . . . . 31
5.2.8 caseIgnoreOrderingMatch .............................. 32 4.2.9. caseIgnoreSubstringsMatch. . . . . . . . . . . . 32
5.2.9 caseIgnoreSubstringsMatch ............................ 32 4.2.10. distinguishedNameMatch . . . . . . . . . . . . . 32
5.2.10 distinguishedNameMatch .............................. 33 4.2.11. generalizedTimeMatch . . . . . . . . . . . . . . 33
5.2.11 generalizedTimeMatch ................................ 34 4.2.12. generalizedTimeOrderingMatch . . . . . . . . . . 33
5.2.12 generalizedTimeOrderingMatch ........................ 34 4.2.13. integerFirstComponentMatch . . . . . . . . . . . 34
5.2.13 integerFirstComponentMatch .......................... 34 4.2.14. integerMatch . . . . . . . . . . . . . . . . . . 34
5.2.14 integerMatch ........................................ 35 4.2.15. numericStringMatch . . . . . . . . . . . . . . . 35
5.2.15 numericStringMatch .................................. 35 4.2.16. numericStringSubstringsMatch . . . . . . . . . . 35
5.2.16 numericStringSubstringsMatch ........................ 36 4.2.17. objectIdentifierFirstComponentMatch. . . . . . . 36
5.2.17 objectIdentifierFirstComponentMatch ................. 36 4.2.18. objectIdentifierMatch. . . . . . . . . . . . . . 36
5.2.18 objectIdentifierMatch ............................... 37 4.2.19. octetStringMatch . . . . . . . . . . . . . . . . 37
5.2.19 octetStringMatch .................................... 38 4.2.20. telephoneNumberMatch . . . . . . . . . . . . . . 37
5.2.20 telephoneNumberMatch ................................ 38 4.2.21. telephoneNumberSubstringsMatch . . . . . . . . . 38
5.2.21 telephoneNumberSubstringsMatch ...................... 38 4.2.22. uniqueMemberMatch. . . . . . . . . . . . . . . . 38
5.2.22 uniqueMemberMatch ................................... 39 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 39
6. Security Considerations ....................................... 40 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39
7. Acknowledgements .............................................. 40 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 39
8. IANA Considerations ........................................... 40 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
9. Normative References .......................................... 42 8.1. Normative References . . . . . . . . . . . . . . . . . . 41
10. Informative References ....................................... 43 8.2. Informative References . . . . . . . . . . . . . . . . . 42
11. Authors' Addresses ........................................... 44 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 43
12. Intellectual Property Notice ................................. 44 10. Intellectual Property Notice . . . . . . . . . . . . . . . . . 44
13. Copyright Notice ............................................. 45 Appendix A. Summary of Syntax Object Identifiers . . . . . . . . . 44
Appendix A. Summary of Syntax Object Identifiers ................. 45 Appendix B. Changes from RFC 2252 & RFC 2256 . . . . . . . . . . . 45
Appendix B. Changes from RFC 2252 & RFC 2256 ..................... 46 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 47
2. 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 [ROADMAP], and whose values may be transfered in the
LDAP protocol [PROT], has a defined syntax (i.e. data type) which LDAP protocol [PROT], has a defined syntax (i.e., data type) which
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 [MODELS] before reading the rest of this document.
Section 4 provides definitions for the base set of LDAP syntaxes. Section 3 provides definitions for the base set of LDAP syntaxes.
Section 4 provides definitions for the base set of matching rules for
Section 5 provides definitions for the base set of matching rules for
LDAP. LDAP.
This document is a integral part of the LDAP technical specification This document is a integral part of the LDAP technical specification
[ROADMAP] which obsoletes the previously defined LDAP technical [ROADMAP] which obsoletes the previously defined LDAP technical
specification [RFC3377] in its entirety. specification [RFC3377] in its entirety.
Sections 4, 5 and 7 of RFC 2252 [RFC2252] are obsoleted by [MODELS]. Sections 4, 5 and 7 of RFC 2252 [RFC2252] are obsoleted by [MODELS].
The remainder of RFC 2252 is obsoleted by this document. Sections 6 The remainder of RFC 2252 is obsoleted by this document. Sections 6
and 8 of RFC 2256 are obsoleted by this document. The changes from and 8 of RFC 2256 [RFC2256] are obsoleted by this document. The
RFC 2252 and RFC 2256 [RFC2256] are described in Appendix B of this remainder of RFC 2256 is obsoleted by [SCHEMA] and [MODELS].
document.
3. Conventions A number of schema elements which were included in the previous
revision of the LDAP technical specification are not included in this
revision of LDAP. Public Key Infrastructure schema elements are now
specified in [LDAP-PKI]. Unless reintroduced in future technical
specifications, the remainder are to be considered Historic.
The changes from RFC 2252 and RFC 2256 are described in Appendix B of
this document.
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [KEYWORD]. document are to be interpreted as described in BCP 14, RFC 2119
[KEYWORD].
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 [ABNF] rule specified in [MODELS], and matching rule definitions
are written according to the <MatchingRuleDescription> ABNF rule are written according to the <MatchingRuleDescription> ABNF rule
specified in [MODELS], except that the syntax and matching rule specified in [MODELS], except that the syntax and matching rule
definitions provided in this document are line-wrapped for definitions provided in this document are line-wrapped for
readability. When such definitions are transfered as attribute readability. When such definitions are transfered 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 [MODELS] respectively) then those values
would not contain line breaks. would not contain line breaks.
4. 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 transfered 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.
4.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 transfered
in the LDAP protocol [PROT]. This representation is referred to as in the LDAP protocol [PROT]. This representation is referred to as
the LDAP-specific encoding to distinguish it from other methods of the LDAP-specific encoding to distinguish it from other methods of
encoding attribute values (e.g. the BER encoding [BER] used by X.500 encoding attribute values (e.g., the Basic Encoding Rules (BER)
[X.500] directories). 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-specific encoding of a value of an unrecognized syntax is a LDAP-specific encoding of a value of an unrecognized syntax is a
human-readable character string. There are a few cases (e.g. the human-readable character string. There are a few cases (e.g., the
JPEG syntax) when it is not reasonable to produce a human-readable JPEG 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
skipping to change at page 6, line 39 skipping to change at page 6, line 45
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 [MODELS]).
Such a bound is not considered part of the syntax identifier. 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 [UTF-8] is a variable-length encoding. Therefore a 64 UTF-8 [UTF8] is a variable-length encoding. Therefore a 64 character
character string may be more than 64 octets in length. string may be more than 64 octets in length.
4.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 4.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)
HEX-DIGIT = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" HEX-DIGIT = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
; N.B. allows upper and lower case ; N.B. allows upper and lower case
SLASH = %x2F ; forward slash ("/") SLASH = %x2F ; forward slash ("/")
COLON = %x3A ; colon (":") COLON = %x3A ; colon (":")
QUESTION = %x3F ; question mark ("?") QUESTION = %x3F ; question mark ("?")
The <OCTET>, <ALPHA>, <DIGIT>, <SQUOTE>, <LPAREN>, <RPAREN>, <PLUS>, The <OCTET>, <ALPHA>, <DIGIT>, <SQUOTE>, <LPAREN>, <RPAREN>, <PLUS>,
<COMMA>, <HYPHEN>, <DOT>, <EQUALS> and <SPACE> rules are defined in <COMMA>, <HYPHEN>, <DOT>, <EQUALS> and <SPACE> rules are defined in
[MODELS]. [MODELS].
4.3 Syntax Definitions 3.3. Syntax Definitions
4.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 [MODELS].
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 [MODELS] is also a value of the Attribute Type
Description syntax (note: line breaks have been added for readability Description syntax (note: line breaks have been added for readability
- they are not part of the value when transfered in protocol). - they are not part of the value when transfered in protocol).
( 2.5.18.1 NAME 'createTimestamp' ( 2.5.18.1 NAME 'createTimestamp'
skipping to change at page 7, line 41 skipping to change at page 7, line 46
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:
( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' ) ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' )
This syntax corresponds to the AttributeTypeDescription ASN.1 type This syntax corresponds to the AttributeTypeDescription ASN.1 type
from [X.501]. from [X.501].
4.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 [MODELS].
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 15 skipping to change at page 8, line 17
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].
4.3.3 Boolean 3.3.3. Boolean
A value of the Boolean syntax is one of the Boolean values, true or A value of the Boolean syntax is one of the Boolean values, true or
false. The LDAP-specific encoding of a value of this syntax is false. The LDAP-specific encoding of a value of this syntax is
defined by the following ABNF: defined by the following ABNF:
Boolean = "TRUE" / "FALSE" Boolean = "TRUE" / "FALSE"
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].
4.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-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:
CountryString = 2(PrintableCharacter) CountryString = 2(PrintableCharacter)
The <PrintableCharacter> rule is defined in Section 4.2. The <PrintableCharacter> rule is defined in Section 3.2.
Examples: Examples:
US US
AU AU
The LDAP definition for the Country String syntax is: The LDAP definition for the Country String syntax is:
( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' ) ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' )
This syntax corresponds to the following ASN.1 type from [X.520]: This syntax corresponds to the following ASN.1 type from [X.520]:
PrintableString (SIZE (2)) -- IS 3166 codes only PrintableString (SIZE (2)) -- ISO 3166 codes only
4.3.5 Delivery Method 3.3.5. Delivery Method
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"
skipping to change at page 9, line 42 skipping to change at page 9, line 42
mhs-delivery (1), mhs-delivery (1),
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) }
4.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 [UTF-8] of encoding of a value of this syntax is the UTF-8 encoding [UTF8] 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 [MODELS].
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
skipping to change at page 10, line 14 skipping to change at page 10, line 13
The <UTF8> rule is defined in [MODELS]. The <UTF8> rule is defined in [MODELS].
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 requiring not restrict the format of Directory String values, e.g., by
that the character string conforms to specific patterns described by requiring that the character string conforms to specific patterns
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
skipping to change at page 10, line 40 skipping to change at page 10, line 39
Implementations which convert Directory String values from the Implementations which convert Directory String values from the
LDAP-specific encoding to the BER encoding used by X.500 must choose LDAP-specific encoding to the BER encoding used by X.500 must choose
an alternative that permits the particular characters in the string, an alternative that permits the particular characters in the string,
and must convert the characters from the UTF-8 encoding into the and must convert the characters from the UTF-8 encoding into the
character encoding of the chosen alternative. character encoding of the chosen alternative.
When converting Directory String values from the BER encoding to the When converting Directory String values from the BER encoding to the
LDAP-specific encoding the characters must be converted from the LDAP-specific encoding the characters must be converted from the
character encoding of the chosen alternative into the UTF-8 encoding. character encoding of the chosen alternative into the UTF-8 encoding.
4.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 content rule. The LDAP-specific encoding of a value of this of a DIT (Directory Information Tree) content rule. The
syntax is defined by the <DITContentRuleDescription> rule in LDAP-specific encoding of a value of this syntax is defined by the
[MODELS]. <DITContentRuleDescription> rule in [MODELS].
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 of Note: a line break has been added for readability - it is not part of
the value. 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].
skipping to change at page 11, line 15 skipping to change at page 11, line 13
the value. 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].
4.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 [MODELS].
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].
4.3.9 DN 3.3.9. DN
A value of the DN syntax is the (purported) distinguished name of an A value of the DN syntax is the (purported) distinguished name (DN)
entry [MODELS]. The LDAP-specific encoding of a value of this syntax of an entry [MODELS]. The LDAP-specific encoding of a value of this
is defined by the <distinguishedName> rule in [LDAPDN]. syntax is defined by the <distinguishedName> rule in [LDAPDN].
Examples (from [LDAPDN]): Examples (from [LDAPDN]):
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:
skipping to change at page 12, line 4 skipping to change at page 11, line 48
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' )
The DN syntax corresponds to the DistinguishedName ASN.1 type from The DN syntax corresponds to the DistinguishedName ASN.1 type from
[X.501]. Note that a BER encoded distinguished name (as used by [X.501]. Note that a BER encoded distinguished name (as used by
X.500) re-encoded into the LDAP-specific encoding is not necessarily X.500) re-encoded into the LDAP-specific encoding is not necessarily
reversible to the original BER encoding since the chosen string type reversible to the original BER encoding since the chosen string type
in any DirectoryString components of the distinguished name is not in any DirectoryString components of the distinguished name is not
indicated in the LDAP-specific encoding of the distinguished name indicated in the LDAP-specific encoding of the distinguished name
(see Section 4.3.6). (see Section 3.3.6).
4.3.10 Enhanced Guide 3.3.10. Enhanced Guide
A value of the Enhanced Guide syntax suggests criteria, which consist A value of the Enhanced Guide syntax suggests criteria, which consist
of combinations of attribute types and filter operators, to be used of combinations of attribute types and filter operators, to be used
in constructing filters to search for entries of particular object in constructing filters to search for entries of particular object
classes. The Enhanced Guide syntax improves upon the Guide syntax by classes. The Enhanced Guide syntax improves upon the Guide syntax by
allowing the recommended depth of the search to be specified. allowing the recommended depth of the search to be specified.
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:
skipping to change at page 13, line 4 skipping to change at page 12, line 46
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 [MODELS].
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.
4.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 )
telephone-number = PrintableString telephone-number = PrintableString
fax-parameter = "twoDimensional" / fax-parameter = "twoDimensional" /
"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 4.2. The <DOLLAR> rule is defined in [MODELS]. is defined in Section 3.2. The <DOLLAR> rule is defined in [MODELS].
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].
4.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 which 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:
Fax ::= CHOICE { Fax ::= CHOICE {
g3-facsimile [3] G3FacsimileBodyPart g3-facsimile [3] G3FacsimileBodyPart
} }
The G3FacsimileBodyPart ASN.1 type is defined in [X.420]. The G3FacsimileBodyPart ASN.1 type is defined in [X.420].
4.3.13 Generalized Time 3.3.13. Generalized Time
A value of the Generalized Time syntax is a character string A value of the Generalized Time syntax is a character string
representing a date and time. The LDAP-specific encoding of a value representing a date and time. The LDAP-specific encoding of a value
of this syntax is a restriction of the format defined in [ISO8601], of this syntax is a restriction of the format defined in [ISO8601],
and is described by the following ABNF: and is described by the following ABNF:
century = 2(%x30-39) ; "00" to "99" century = 2(%x30-39) ; "00" to "99"
year = 2(%x30-39) ; "00" to "99" year = 2(%x30-39) ; "00" to "99"
month = ( %x30 %x31-39 ) ; "01" (January) to "09" month = ( %x30 %x31-39 ) ; "01" (January) to "09"
/ ( %x31 %x30-32 ) ; "10" to "12" / ( %x31 %x30-32 ) ; "10" to "12"
skipping to change at page 15, line 11 skipping to change at page 15, line 4
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>.
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:
40: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:
( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' ) ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' )
This syntax corresponds to the GeneralizedTime ASN.1 type from This syntax corresponds to the GeneralizedTime ASN.1 type from
[ASN.1], with the constraint that local time without a differential [ASN.1], with the constraint that local time without a differential
SHALL NOT be used. SHALL NOT be used.
4.3.14 Guide 3.3.14. Guide
A value of the Guide syntax suggests criteria, which consist of A value of the Guide syntax suggests criteria, which consist of
combinations of attribute types and filter operators, to be used in combinations of attribute types and filter operators, to be used in
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
4.3.10. The <SHARP> rule is defined in [MODELS]. 3.3.10. The <SHARP> rule is defined in [MODELS].
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].
4.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 4.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].
4.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 (so, 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]. [MODELS].
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].
4.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
Format (JFIF), as described in [JPEG]. The LDAP-specific encoding of Format (JFIF), as described in [JPEG]. The LDAP-specific encoding of
a value of this syntax is the sequence of octets of the JFIF encoding a value of this syntax is the sequence of octets of the JFIF encoding
of the image. of the image.
The LDAP definition for the JPEG syntax is: The LDAP definition for the JPEG syntax is:
( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' ) ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' )
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 -- })
4.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 [MODELS].
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.
skipping to change at page 17, line 27 skipping to change at page 17, line 17
LDAPSyntaxDescription ::= SEQUENCE { LDAPSyntaxDescription ::= SEQUENCE {
identifier OBJECT IDENTIFIER, identifier OBJECT IDENTIFIER,
description DirectoryString { ub-schema } OPTIONAL } description DirectoryString { ub-schema } OPTIONAL }
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].
4.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 [MODELS].
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].
4.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 [PROT]. The LDAP-specific encoding of
a value of this syntax is defined by the <MatchingRuleUseDescription> a value of this syntax is defined by the <MatchingRuleUseDescription>
rule in [MODELS]. rule in [MODELS].
Example: Example:
( 2.5.13.16 APPLIES ( givenName $ surname ) ) ( 2.5.13.16 APPLIES ( givenName $ surname ) )
skipping to change at page 18, line 16 skipping to change at page 18, line 4
a value of this syntax is defined by the <MatchingRuleUseDescription> a value of this syntax is defined by the <MatchingRuleUseDescription>
rule in [MODELS]. rule in [MODELS].
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].
4.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 [MODELS] 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 4.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 [LDAPDN]. The <SHARP> rule is
defined in [MODELS]. defined in [MODELS].
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].
4.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-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
<NameFormDescription> rule in [MODELS]. <NameFormDescription> rule in [MODELS].
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:
skipping to change at page 19, line 18 skipping to change at page 19, line 4
name form, which regulates how entries may be named. The name form, which regulates how entries may be named. 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
<NameFormDescription> rule in [MODELS]. <NameFormDescription> rule in [MODELS].
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].
4.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 [MODELS].
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].
4.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 [MODELS].
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].
skipping to change at page 20, line 14 skipping to change at page 19, line 47
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].
4.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 more
arbitrary octets. The LDAP-specific encoding of a value of this 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 [MODELS]. 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].
4.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 [RFC3383].
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 [MODELS].
Examples: Examples:
skipping to change at page 21, line 4 skipping to change at page 20, line 34
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 [MODELS].
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
[ASN.1]. [ASN.1].
4.3.27 Other Mailbox 3.3.27. Other Mailbox
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 4.2. <PrintableString> and <IA5String> rules are defined in Section 3.2.
The <DOLLAR> rule is defined in [MODELS]. The <DOLLAR> rule is defined in [MODELS].
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,
mailbox IA5String mailbox IA5String
} }
4.3.28 Postal Address 3.3.28. Postal Address
A value of the Postal Address syntax is a sequence of strings of one A value of the Postal Address syntax is a sequence of strings of one
or more arbitrary UCS characters, which form an address in a physical or more arbitrary UCS characters, which form an address in a physical
mail system. mail system.
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:
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 [UTF-8] string except that "\" and "$" characters, encoded as a UTF-8 [UTF8] string except that "\" and "$" characters,
if they occur in the string, are escaped by a "\" character followed if they occur in the string, are escaped by a "\" character followed
by the two hexadecimal digit code for the character. The <HEX-DIGIT> by the two hexadecimal digit code for the character. The <HEX-DIGIT>
rule is defined in Section 4.2. The <DOLLAR> and <UTFMB> rules are rule is defined in Section 3.2. The <DOLLAR> and <UTFMB> rules are
defined in [MODELS]. defined in [MODELS].
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. i.e.,
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].
4.3.29 Printable String 3.3.29. Printable String
A value of the Printable String syntax is a string of latin A value of the Printable String syntax is a string of one or more
alphabetic, numeric, and (limited) punctuation characters as latin alphabetic, numeric, and selected punctuation characters as
specified by the <PrintableCharacter> rule in Section 4.2. specified by the <PrintableCharacter> rule in Section 3.2.
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 4.2. <PrintableString> rule in Section 3.2.
Example: Example:
This is a PrintableString. This is a PrintableString.
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].
4.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 the extensible matching of character string attribute values, i.e., as
matchValue of a MatchingRuleAssertion [PROT]. Each substring is a the matchValue of a MatchingRuleAssertion [PROT]. Each substring is
string of one or more arbitrary characters from the Universal 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
skipping to change at page 23, line 35 skipping to change at page 23, line 15
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
[UTF-8] string, except that "\" and "*" characters, if they occur in [UTF8] string, except that "\" and "*" characters, if they occur in
the substring, are escaped by a "\" character followed by the two 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 [PROT].
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].
4.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 4.2. <PrintableString> rule in Section 3.2.
Example: +1 512 315 0280 Example: +1 512 315 0280
The LDAP definition for the Telephone Number syntax is: The LDAP definition for the Telephone Number syntax is:
( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' ) ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' )
The Telephone Number syntax corresponds to the following ASN.1 type The Telephone Number syntax corresponds to the following ASN.1 type
from [X.520]: from [X.520]:
PrintableString (SIZE(1..ub-telephone-number)) PrintableString (SIZE(1..ub-telephone-number))
The value of ub-telephone-number (an integer) is implementation The value of ub-telephone-number (an integer) is implementation
defined. A non-normative definition appears in [X.520]. defined. A non-normative definition appears in [X.520].
4.3.32 Teletex Terminal Identifier 3.3.32. Teletex Terminal Identifier
A value of this syntax specifies the identifier and (optionally) A value of this syntax specifies the identifier and (optionally)
parameters of a teletex terminal. parameters of a teletex 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:
teletex-id = ttx-term *(DOLLAR ttx-param) teletex-id = ttx-term *(DOLLAR ttx-param)
ttx-term = PrintableString ; terminal identifier ttx-term = PrintableString ; terminal identifier
ttx-param = ttx-key COLON ttx-value ; parameter ttx-param = ttx-key COLON ttx-value ; parameter
ttx-key = "graphic" / "control" / "misc" / "page" / "private" ttx-key = "graphic" / "control" / "misc" / "page" / "private"
ttx-value = *ttx-value-char ttx-value = *ttx-value-char
ttx-value-char = %x00-23 ttx-value-char = %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 4.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 [MODELS].
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].
4.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 4.2. The <DOLLAR> The <PrintableString> rule is defined in Section 3.2. The <DOLLAR>
rule is defined in [MODELS]. rule is defined in [MODELS].
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].
4.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
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 4.3.13. The <PLUS> rule is defined in rules are defined in Section 3.3.13. The <PLUS> rule is defined in
[MODELS]. [MODELS].
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].
5. 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 [PROT]. They are also used when comparing a
purported distinguished name [MODELS] with the name of an entry. purported distinguished name [MODELS] 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.
5.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 [PROT]. The
conditions under which an AttributeValueAssertion or conditions under which an AttributeValueAssertion or
MatchingRuleAssertion evaluates to Undefined are specified in [PROT]. MatchingRuleAssertion evaluates to Undefined are specified in [PROT].
If an assertion is not Undefined then the result of the assertion is If an assertion is not Undefined then the result of the assertion is
the result of applying the selected matching rule. A matching rule the result of applying the selected matching rule. A matching rule
evaluates to TRUE, and in some cases Undefined, as specified in the evaluates to TRUE, and in some cases Undefined, as specified in the
description of the matching rule, otherwise it evaluates to FALSE. description of the matching rule, otherwise it evaluates to FALSE.
skipping to change at page 27, line 18 skipping to change at page 26, line 40
rule for the attribute type rather than the assertion syntax of the rule for the attribute type rather than the assertion syntax of the
substrings matching rule for the attribute type. The entire substrings matching rule for the attribute type. The entire
SubstringFilter is converted into an assertion value of the SubstringFilter is converted into an assertion value of the
substrings matching rule prior to applying the rule. 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 an alternative
reference notation for the explicitly mentioned type. Each rule reference notation for the explicitly mentioned type. Each rule
description lists as examples of applicable attribute syntaxes, the description lists as examples of applicable attribute syntaxes, the
complete list of the syntaxes defined in this document to which the complete list of the syntaxes defined in this document to which the
matching rule applies. A matching rule may be applicable to matching rule applies. A matching rule may be applicable to
additional syntaxes defined in other documents if those syntaxes additional syntaxes defined in other documents if those syntaxes
satisfy the conditions on the corresponding ASN.1 type. 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 [MODELS].
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 be subsequently 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 SHOULD implement all the matching rules in Section 5.2. Servers SHOULD implement all the 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 which implement the extensibleMatch filter SHOULD allow the
matching rules listed in Section 5.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.
5.2 Matching Rule Definitions 4.2. Matching Rule Definitions
When evaluating the numericStringMatch, numericStringSubstringsMatch, When evaluating the numericStringMatch, numericStringSubstringsMatch,
caseExactIA5Match, caseIgnoreIA5Match, caseIgnoreIA5SubstringsMatch, caseExactIA5Match, caseIgnoreIA5Match, caseIgnoreIA5SubstringsMatch,
caseIgnoreListMatch, caseIgnoreListSubstringsMatch, caseIgnoreMatch, caseIgnoreListMatch, caseIgnoreListSubstringsMatch, caseIgnoreMatch,
caseIgnoreOrderingMatch and caseIgnoreSubstringsMatch matching rules caseIgnoreOrderingMatch, caseIgnoreSubstringsMatch,
the assertion value and attribute value are prepared according to the telephoneNumberMatch and telephoneNumberSubstringsMatch matching
string preparation algorithms [PREP] for LDAP before being compared. rules the assertion value and attribute value are prepared according
The Transcode, Normalize, Prohibit and Check bidi steps are the same to the string preparation algorithms [PREP] for LDAP before being
for each of the matching rules. However, the Map and Insignificant compared. The Transcode, Normalize, Prohibit and Check bidi steps
Character Removal steps depends on the specific rule, as detailed in are the same for each of the matching rules. However, the Map and
the description of these matching rules in the sections that follow. Insignificant Character Removal steps depends on the specific rule,
as detailed in the description of these matching rules in the
sections that follow.
5.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) syntax to an attribute value of a syntax (e.g., the Bit String
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 (which is the case for the Bit String syntax) then a named bit list (which is the case for the Bit String syntax) then
the rule evaluates to TRUE if and only if the attribute value has the the rule evaluates to TRUE if and only if the attribute value has the
same number of bits as the assertion value and the bits match on a same number of bits as the assertion value and the bits match on a
bitwise basis. 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.
5.2.2 caseExactIA5Match 4.2.2. 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.
skipping to change at page 29, line 23 skipping to change at page 28, line 45
Insignificant Space Removal is applied in the Insignificant Character Insignificant Space Removal is applied in the Insignificant Character
Removal step. Removal step.
The LDAP definition for the caseExactIA5Match rule is: The LDAP definition for the caseExactIA5Match rule is:
( 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.
5.2.3 caseIgnoreIA5Match 4.2.3. 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.
skipping to change at page 29, line 46 skipping to change at page 29, line 19
Insignificant Space Removal is applied in the Insignificant Character Insignificant Space Removal is applied in the Insignificant Character
Removal step. Removal step.
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.
5.2.4 caseIgnoreIA5SubstringsMatch 4.2.4. 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 (e.g
the IA5 String syntax) whose corresponding ASN.1 type is IA5String. 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 the prepared substrings of
the assertion value match disjoint portions of the prepared attribute the assertion value match disjoint portions of the prepared attribute
value character string in the order of the substrings in the value character string in the order of the substrings in the
assertion value, and an <initial> substring, if present, matches the assertion value, and an <initial> substring, if present, matches the
beginning of the prepared attribute value character string, and a beginning of the prepared attribute value character string, and a
skipping to change at page 30, line 26 skipping to change at page 29, line 45
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 Removal is applied in the Insignificant and only Insignificant Space Removal is applied in the Insignificant
Character Removal step. Character Removal 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'
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 caseIgnoreIA5SubstringsMatch rule is a substrings matching rule. The caseIgnoreIA5SubstringsMatch rule is a substrings matching rule.
5.2.5 caseIgnoreListMatch 4.2.5. caseIgnoreListMatch
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 i.e., different from the corresponding type for the Postal Address
syntax. The choice of the Postal Address syntax for the assertion syntax. The choice of the Postal Address syntax for the assertion
syntax of the caseIgnoreListMatch in LDAP should not be seen as syntax of the caseIgnoreListMatch in LDAP should not be seen as
limiting the matching rule to only apply to attributes with the limiting the matching rule to only apply to attributes with the
Postal Address syntax. 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.
5.2.6 caseIgnoreListSubstringsMatch 4.2.6. caseIgnoreListSubstringsMatch
The caseIgnoreListSubstringsMatch rule compares an assertion value of The caseIgnoreListSubstringsMatch rule compares an assertion value of
the Substring Assertion syntax to an attribute value of a syntax the Substring Assertion syntax to an attribute value of a syntax
(e.g. the Postal Address syntax) whose corresponding ASN.1 type is a (e.g., the Postal Address syntax) whose corresponding ASN.1 type is a
SEQUENCE OF the DirectoryString ASN.1 type. SEQUENCE OF the DirectoryString ASN.1 type.
The rule evaluates to TRUE if and only if the assertion value The rule evaluates to TRUE if and only if the assertion value
matches, per the caseIgnoreSubstringsMatch rule, the character string matches, per the caseIgnoreSubstringsMatch rule, the character string
formed by concatenating the strings of the attribute value, except formed by concatenating the strings of the attribute value, except
that none of the <initial>, <any>, or <final> substrings of the that none of the <initial>, <any>, or <final> substrings of the
assertion value are considered to match a substring of the assertion value are considered to match a substring of the
concatenated string which spans more than one of the original strings concatenated string which spans more than one of the original strings
of the attribute value. of the attribute value.
skipping to change at page 31, line 36 skipping to change at page 31, line 5
Address syntax, the concatenated string omits the <DOLLAR> line Address syntax, the concatenated string omits the <DOLLAR> line
separator and the escaping of "\" and "$" characters. separator and the escaping of "\" and "$" characters.
The LDAP definition for the caseIgnoreListSubstringsMatch rule is: The LDAP definition for the caseIgnoreListSubstringsMatch rule is:
( 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.
5.2.7 caseIgnoreMatch 4.2.7. 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 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, e.g., 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 case folded in the Map preparation step, and only characters are case folded in the Map preparation step, and only
Insignificant Space Removal is applied in the Insignificant Character Insignificant Space Removal is applied in the Insignificant Character
Removal step. Removal step.
The LDAP definition for the caseIgnoreMatch rule is: The LDAP definition for the caseIgnoreMatch rule is:
( 2.5.13.2 NAME 'caseIgnoreMatch' ( 2.5.13.2 NAME 'caseIgnoreMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 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.
5.2.8 caseIgnoreOrderingMatch 4.2.8. 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 Removal is applied in the Insignificant Character Insignificant Space Removal is applied in the Insignificant Character
Removal step. Removal 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.
5.2.9 caseIgnoreSubstringsMatch 4.2.9. 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 the prepared substrings of
the assertion value match disjoint portions of the prepared attribute the assertion value match disjoint portions of the prepared attribute
value character string in the order of the substrings in the value character string in the order of the substrings in the
assertion value, and an <initial> substring, if present, matches the assertion value, and an <initial> substring, if present, matches the
beginning of the prepared attribute value character string, and a beginning of the prepared attribute value character string, and a
<final> substring, if present, matches the end of the prepared <final> substring, if present, matches the end of the prepared
skipping to change at page 33, line 25 skipping to change at page 32, line 38
and only Insignificant Space Removal is applied in the Insignificant and only Insignificant Space Removal is applied in the Insignificant
Character Removal step. Character Removal step.
The LDAP definition for the caseIgnoreSubstringsMatch rule is: The LDAP definition for the caseIgnoreSubstringsMatch rule is:
( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
The caseIgnoreSubstringsMatch rule is a substrings matching rule. The caseIgnoreSubstringsMatch rule is a substrings matching rule.
5.2.10 distinguishedNameMatch 4.2.10. distinguishedNameMatch
The distinguishedNameMatch rule compares an assertion value of the DN The distinguishedNameMatch rule compares an assertion value of the DN
syntax to an attribute value of a syntax (e.g. the DN syntax) whose syntax to an attribute value of a syntax (e.g., the DN syntax) whose
corresponding ASN.1 type is DistinguishedName. corresponding ASN.1 type is DistinguishedName.
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 RDNs and corresponding RDNs assertion value have the same number of relative distinguished names
(by position) are the same. An RDN of the assertion value is the and corresponding relative distinguished names (by position) are the
same as an RDN of the attribute value if and only if they have the same. A relative distinguished name (RDN) of the assertion value is
same number of attribute value assertions (AVAs) and each AVA of the the same as an RDN of the attribute value if and only if they have
first RDN is the same as the AVA of the second RDN with the same the same number of attribute value assertions and each attribute
attribute type. The order of the AVAs is not significant. Also note value assertion (AVA) of the first RDN is the same as the AVA of the
that a particular attribute type may appear in at most one AVA in an second RDN with the same attribute type. The order of the AVAs is
RDN. Two AVAs with the same attribute type are the same if their not significant. Also note that a particular attribute type may
values are equal according to the equality matching rule of the appear in at most one AVA in an RDN. Two AVAs with the same
attribute type. If one or more of the AVA comparisons evaluate to attribute type are the same if their values are equal according to
Undefined and the remaining AVA comparisons return TRUE then the the equality matching rule of the attribute type. If one or more of
distinguishedNameMatch rule evaluates to Undefined. the AVA comparisons evaluate to Undefined and the remaining AVA
comparisons return TRUE then the distinguishedNameMatch rule
evaluates to Undefined.
The LDAP definition for the distinguishedNameMatch rule is: 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.
5.2.11 generalizedTimeMatch 4.2.11. 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.
5.2.12 generalizedTimeOrderingMatch 4.2.12. generalizedTimeOrderingMatch
The generalizedTimeMatch rule compares the time ordering of an The generalizedTimeOrderingMatch rule compares the time ordering of
assertion value of the Generalized Time syntax to an attribute value an assertion value of the Generalized Time syntax to an attribute
of a syntax (e.g the Generalized Time syntax) whose corresponding value of a syntax (e.g the Generalized Time syntax) whose
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 which 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.
5.2.13 integerFirstComponentMatch 4.2.13. 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.
skipping to change at page 35, line 25 skipping to change at page 34, line 38
( 2.5.13.29 NAME 'integerFirstComponentMatch' ( 2.5.13.29 NAME 'integerFirstComponentMatch'
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 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.
5.2.14 integerMatch 4.2.14. 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.
5.2.15 numericStringMatch 4.2.15. 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.
skipping to change at page 36, line 18 skipping to change at page 35, line 29
numericString Insignificant Character Removal is applied in the numericString Insignificant Character Removal is applied in the
Insignificant Character Removal step. Insignificant Character Removal step.
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.
5.2.16 numericStringSubstringsMatch 4.2.16. 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 (e.g
the 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 the prepared substrings of The rule evaluates to TRUE if and only if the prepared substrings of
the assertion value match disjoint portions of the prepared attribute the assertion value match disjoint portions of the prepared attribute
value character string in the order of the substrings in the value character string in the order of the substrings in the
assertion value, and an <initial> substring, if present, matches the assertion value, and an <initial> substring, if present, matches the
skipping to change at page 36, line 40 skipping to change at page 35, line 51
<final> substring, if present, matches the end of the prepared <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 Removal is applied in the numericString Insignificant Character Removal is applied in the
Insignificant Character Removal step. Insignificant Character Removal step.
The LDAP definition for the numericStringSubstringsMatch matching
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.
5.2.17 objectIdentifierFirstComponentMatch 4.2.17. 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
skipping to change at page 37, line 30 skipping to change at page 36, line 41
( 2.5.13.31 NAME 'objectIdentifierFirstComponentMatch' ( 2.5.13.31 NAME 'objectIdentifierFirstComponentMatch'
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 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.
5.2.18 objectIdentifierMatch 4.2.18. 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]). [MODELS]).
skipping to change at page 38, line 4 skipping to change at page 37, line 13
[MODELS]). [MODELS]).
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 the chosen descriptor is not recognized by the server, then the and 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.
5.2.19 octetStringMatch 4.2.19. 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 String
or JPEG syntax) whose corresponding ASN.1 type is the OCTET STRING or JPEG syntax) whose corresponding ASN.1 type is the OCTET STRING
ASN.1 type. 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.
5.2.20 telephoneNumberMatch 4.2.20. 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.
skipping to change at page 38, line 48 skipping to change at page 38, line 10
telephoneNumber Insignificant Character Removal is applied in the telephoneNumber Insignificant Character Removal is applied in the
Insignificant Character Removal step. Insignificant Character Removal step.
The LDAP definition for the telephoneNumberMatch matching rule is: The LDAP definition for the telephoneNumberMatch matching rule is:
( 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.
5.2.21 telephoneNumberSubstringsMatch 4.2.21. 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 a
PrintableString representing a telephone number. 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 the prepared substrings of
the assertion value match disjoint portions of the prepared attribute the assertion value match disjoint portions of the prepared attribute
value character string in the order of the substrings in the value character string in the order of the substrings in the
assertion value, and an <initial> substring, if present, matches the assertion value, and an <initial> substring, if present, matches the
beginning of the prepared attribute value character string, and a beginning of the prepared attribute value character string, and a
skipping to change at page 39, line 33 skipping to change at page 38, line 41
The LDAP definition for the telephoneNumberSubstringsMatch matching The LDAP definition for the telephoneNumberSubstringsMatch matching
rule is: rule is:
( 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.
5.2.22 uniqueMemberMatch 4.2.22. 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 the <BitString> component is to the distinguishedNameMatch rule and the <BitString> component is
absent from the attribute value or matches the <BitString> component absent from the attribute value or matches the <BitString> component
skipping to change at page 40, line 4 skipping to change at page 39, line 9
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 the <BitString> component is to the distinguishedNameMatch rule and the <BitString> component is
absent from the attribute value or matches the <BitString> component absent from the attribute value or matches the <BitString> component
of the assertion value according to the bitStringMatch rule. of the assertion value according to the bitStringMatch 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'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
The uniqueMemberMatch rule is an equality matching rule. The uniqueMemberMatch rule is an equality matching rule.
6. 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 not encoding (e.g., BER) and back into the LDAP-specific encoding will
necessarily reproduce exactly the original octets of the not necessarily reproduce exactly the original octets of the
LDAP-specific encoding. Therefore an LDAP-specific encoding should LDAP-specific encoding. Therefore an LDAP-specific encoding should
not be used where a canonical encoding is required. not 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 DER to syntaxes to be reconstructed, e.g., a transformation from a
LDAP-specific encoding and back to DER may not reproduce the original Distinguished Encoding Rules (DER) [BER] encoding to an LDAP-specific
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, and 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.
7. Acknowledgements 6. Acknowledgements
This document is an revision of RFC 2252 by M. Wahl, A. Coulbeck, T. This document is an revision of RFC 2252 by M. Wahl, A. Coulbeck, T.
Howes, and S. Kille. RFC 2252 was a product of the IETF ASID Working Howes, and S. Kille. RFC 2252 was a product of the IETF ASID Working
Group. Group.
This document is based upon input of the IETF LDAPBIS working group. This document is based upon input of the IETF LDAPBIS working group.
The authors wish to thank J. Sermersheim and K. Zeilenga for their The authors wish to thank J. Sermersheim and K. Zeilenga for their
significant contribution to this revision. significant contribution to this revision.
8. IANA Considerations 7. IANA Considerations
The Internet Assigned Numbers Authority (IANA) is requested to update The Internet Assigned Numbers Authority (IANA) is requested to update
the LDAP descriptors registry as indicated by the following the LDAP 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@adacel.com.au> Steven Legg <steven.legg@adacel.com.au>
Usage: see comment Usage: see comment
Specification: RFC XXXX Specification: RFC XXXX
Author/Change Controller: IESG Author/Change Controller: IESG
skipping to change at page 41, line 37 skipping to change at page 40, line 41
integerMatch M 2.5.13.14 integerMatch M 2.5.13.14
numericStringMatch M 2.5.13.8 numericStringMatch M 2.5.13.8
numericStringSubstringsMatch M 2.5.13.10 numericStringSubstringsMatch M 2.5.13.10
objectIdentifierFirstComponentMatch M 2.5.13.31 objectIdentifierFirstComponentMatch M 2.5.13.31
octetStringMatch M 2.5.13.17 octetStringMatch M 2.5.13.17
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
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 RFC 3383. registered as objectIdentifiersMatch (extraneous `s') in BCP 64.
It should be changed to the following with a reference to RFC It should be changed to the following with a reference to RFC
XXXX. XXXX.
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
skipping to change at page 42, line 16 skipping to change at page 41, line 19
Subject: Request for LDAP Descriptor Registration Subject: Request for LDAP Descriptor Registration
Descriptor (short name): caseIgnoreListSubstringsMatch Descriptor (short name): caseIgnoreListSubstringsMatch
Object Identifier: 2.5.13.12 Object Identifier: 2.5.13.12
Person & email address to contact for further information: Person & email address to contact for further information:
Steven Legg <steven.legg@adacel.com.au> Steven Legg <steven.legg@adacel.com.au>
Usage: other (M) Usage: other (M)
Specification: RFC XXXX Specification: RFC XXXX
Author/Change Controller: IESG Author/Change Controller: IESG
9. Normative References 8. References
8.1. Normative References
[KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998. 10646", draft-yergeau-rfc2279bis-xx.txt, a work in
progress, June 2003.
[RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64, RFC [BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
3383, September 2002. Considerations for the Lightweight Directory Access
Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
[LDAPDN] Zeilenga, K., "LDAP: String Representation of [LDAPDN] Zeilenga, K., "LDAP: String Representation of
Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work
in progress, May 2003. in progress, June 2003.
[PROT] Sermersheim, J., "LDAP: The Protocol", draft-ietf-ldapbis- [PROT] Sermersheim, J., "LDAP: The Protocol", draft-ietf-ldapbis-
protocol-xx.txt, a work in progress, March 2003. protocol-xx.txt, a work in progress, September 2003.
[E.123] Notation for national and international telephone numbers, [E.123] Notation for national and international telephone numbers,
ITU-T Recommendation E.123, 1988. ITU-T Recommendation E.123, 1988.
[FAX] Standardization of Group 3 facsimile apparatus for [FAX] Standardization of Group 3 facsimile apparatus for
document transmission - Terminal Equipment and Protocols document transmission - Terminal Equipment and Protocols
for Telematic Services, ITU-T Recommendation T.4, 1993 for Telematic Services, ITU-T Recommendation T.4, 1993
[T.50] International Reference Alphabet (IRA) (Formerly [T.50] International Reference Alphabet (IRA) (Formerly
International Alphabet No. 5 or IA5) Information International Alphabet No. 5 or IA5) Information
Technology - 7-Bit Coded Character Set for Information Technology - 7-Bit Coded Character Set for Information
Interchange, ITU-T Recommendation T.50, 1992 Interchange, ITU-T Recommendation T.50, 1992
[X.420] ITU-T Recommendation X.420 (1996) | ISO/IEC 10021-7:1997, [X.420] ITU-T Recommendation X.420 (1996) | ISO/IEC 10021-7:1997,
Information Technology - Message Handling Systems (MHS): Information Technology - Message Handling Systems (MHS):
Interpersonal messaging system Interpersonal messaging system
[X.501] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994, [X.501] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994,
skipping to change at page 43, line 15 skipping to change at page 42, line 21
Interpersonal messaging system Interpersonal messaging system
[X.501] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994, [X.501] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994,
Information Technology - Open Systems Interconnection - Information Technology - Open Systems Interconnection -
The Directory: Models The Directory: Models
[X.520] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994, [X.520] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994,
Information Technology - Open Systems Interconnection - Information Technology - Open Systems Interconnection -
The Directory: Selected attribute types The Directory: Selected attribute types
[ASN.1] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1 [ASN.1] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002,
Information technology - Abstract Syntax Notation One Information technology - Abstract Syntax Notation One
(ASN.1): Specification of basic notation (ASN.1): Specification of basic notation
[ISO3166] ISO 3166, "Codes for the representation of names of [ISO3166] ISO 3166, "Codes for the representation of names of
countries". countries".
[UCS] Universal Multiple-Octet Coded Character Set (UCS) - [UCS] Universal Multiple-Octet Coded Character Set (UCS) -
Architecture and Basic Multilingual Plane, ISO/IEC Architecture and Basic Multilingual Plane, ISO/IEC
10646-1: 1993 (with amendments). 10646-1: 1993 (with amendments).
[JPEG] JPEG File Interchange Format (Version 1.02). Eric [JPEG] JPEG File Interchange Format (Version 1.02). Eric
Hamilton, C-Cube Microsystems, Milpitas, CA, September 1, Hamilton, C-Cube Microsystems, Milpitas, CA, September 1,
1992. 1992.
[ROADMAP] Zeilenga, K., "LDAP: Technical Specification Road Map",
draft-ietf-ldapbis-roadmap-xx.txt, a work in progress,
June 2003.
[MODELS] Zeilenga, K., "LDAP: Directory Information Models", draft- [MODELS] Zeilenga, K., "LDAP: Directory Information Models", draft-
ietf-ldapbis-models-xx.txt, a work in progress, March ietf-ldapbis-models-xx.txt, a work in progress, June 2003.
2003.
[PREP] Zeilenga, K., "LDAP: Internationalized String [PREP] Zeilenga, K., "LDAP: Internationalized String
Preparation", draft-ietf-ldapbis-strprep-xx.txt, a work in Preparation", draft-ietf-ldapbis-strprep-xx.txt, a work in
progress, May 2003. progress, June 2003.
10. Informative References
[BCP11] Hovey, R. and S. Bradner, "The Organizations Involved in 8.2. Informative References
the IETF Standards Process", BCP 11, RFC 2028, October
1996.
[RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
"Lightweight Directory Access Protocol (v3): Attribute "Lightweight Directory Access Protocol (v3): Attribute
Syntax Definitions", RFC 2252, December 1997. Syntax Definitions", RFC 2252, December 1997.
[RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use
with LDAPv3", RFC 2256, December 1997. with LDAPv3", RFC 2256, December 1997.
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377, Protocol (v3): Technical Specification", RFC 3377,
September 2002. September 2002.
[SCHEMA] Dally, K., "LDAP: Schema for User Applications", draft-
ietf-ldapbis-user-schema-xx.txt, a work in progress, June
2003.
[LDAP-PKI] Chadwick, D. W. and S. Legg, "LDAP Schema and Syntaxes for
PKIs", draft-ietf-pkix-ldap-pki-schema-xx.txt, a work in
progress, July 2002.
[X.500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994, [X.500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
Information Technology - Open Systems Interconnection - Information Technology - Open Systems Interconnection -
The Directory: Overview of concepts, models and services The Directory: Overview of concepts, models and services
[BER] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998 [BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1:2002,
Information Technology - ASN.1 encoding rules: Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules Encoding Rules (CER) and Distinguished Encoding Rules
(DER) (DER)
11. Authors' Addresses 9. Authors' Addresses
Steven Legg Steven Legg
Adacel Technologies Ltd. Adacel Technologies Ltd.
250 Bay Street 250 Bay Street
Brighton, Victoria 3186 Brighton, Victoria 3186
AUSTRALIA AUSTRALIA
Phone: +61 3 8530 7710 Phone: +61 3 8530 7710
Fax: +61 3 8530 7888 Fax: +61 3 8530 7888
Email: steven.legg@adacel.com.au Email: steven.legg@adacel.com.au
skipping to change at page 44, line 41 skipping to change at page 44, line 5
Kathy Dally Kathy Dally
The MITRE Corp. The MITRE Corp.
7515 Colshire Dr., ms-W650 7515 Colshire Dr., ms-W650
McLean VA 22102 McLean VA 22102
USA USA
Phone: +1 703 883 6058 Phone: +1 703 883 6058
Fax: +1 703 883 7142 Fax: +1 703 883 7142
Email: kdally@mitre.org Email: kdally@mitre.org
12. Intellectual Property Notice 10. Intellectual Property Notice
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. [BCP11] standards-related documentation can be found in BCP-11. Copies of
Copies of claims of rights made available for publication and any claims of rights made available for publication and any assurances of
assurances of licenses to be made available, or the result of an licenses to be made available, or the result of an attempt made to
attempt made to obtain a general license or permission for the use of obtain a general license or permission for the use of such
such proprietary rights by implementors or users of this proprietary rights by implementors or users of this specification can
specification can be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
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 which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
13. Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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 45 skipping to change at page 47, line 23
Mail Preference syntax have been removed on the grounds that they Mail Preference syntax have been removed on the grounds that they
are out of scope for a core specification. are out of scope for a core specification.
23. The description of each of the matching rules has been expanded 23. The description of each of the matching rules has been expanded
so that they are less dependent on knowledge of X.500 for so that they are less dependent on knowledge of X.500 for
interpretation. interpretation.
24. The caseIgnoreIA5SubstringsMatch matching rule from RFC 2798 has 24. The caseIgnoreIA5SubstringsMatch matching rule from RFC 2798 has
been added. been added.
25. The caseIgnoreIA5SubstringsMatch, caseIgnoreListSubstringsMatch, 25. The caseIgnoreListSubstringsMatch, caseIgnoreOrderingMatch and
caseIgnoreOrderingMatch and caseIgnoreSubstringsMatch matching caseIgnoreSubstringsMatch matching rules have been added to the
rules have been added to the list of matching rules for which the list of matching rules for which the provisions for handling
provisions for handling leading, trailing and multiple adjoining leading, trailing and multiple adjoining whitespace characters
whitespace characters apply. This is consistent with the apply (now through string preparation). This is consistent with
definitions of these matching rules in X.500. The the definitions of these matching rules in X.500. The
telephoneNumberMatch rule has been removed from the list since it caseIgnoreIA5SubstringsMatch rule has also been added to the
completely ignores all space characters. list.
26. The specification of the octetStringMatch matching rule from RFC 26. The specification of the octetStringMatch matching rule from RFC
2256 has been added to this document. 2256 has been added to this document.
27. The presentationAddressMatch matching rule has been removed as it 27. The presentationAddressMatch matching rule has been removed as it
depends on an assertion syntax (Presentation Address) that is not depends on an assertion syntax (Presentation Address) that is not
at draft standard maturity. at draft standard maturity.
28. The protocolInformationMatch matching rule has been removed as it 28. The protocolInformationMatch matching rule has been removed as it
depends on an undefined assertion syntax (Protocol Information). depends on an undefined assertion syntax (Protocol Information).
29. The definitive reference for ASN.1 has been changed from X.208 to 29. The definitive reference for ASN.1 has been changed from X.208 to
X.680 since X.680 is the version of ASN.1 referred to by X.500. X.680 since X.680 is the version of ASN.1 referred to by X.500.
30. The specification of the caseIgnoreListSubstringsMatch matching 30. The specification of the caseIgnoreListSubstringsMatch matching
rule from RFC 2798 & X.520 has been added to this document. rule from RFC 2798 & X.520 has been added to this document.
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.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

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