draft-ietf-ldapbis-syntaxes-04.txt   draft-ietf-ldapbis-syntaxes-05.txt 
INTERNET-DRAFT S. Legg, Editor INTERNET-DRAFT S. Legg, Editor
draft-ietf-ldapbis-syntaxes-04.txt Adacel Technologies draft-ietf-ldapbis-syntaxes-05.txt Adacel Technologies
Intended Category: Standard Track K. Dally Intended Category: Standard Track K. Dally
Obsoletes: RFC 2252, RFC 2256 The MITRE Corp. Obsoletes: RFC 2252, RFC 2256 The MITRE Corp.
20 December 2002 27 February 2003
LDAP: Syntaxes and Matching Rules LDAP: Syntaxes and Matching Rules
Copyright (C) The Internet Society (2002). 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.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
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 20 June 2003. This Internet-Draft expires on 27 August 2003.
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 1. Table of Contents
Abstract ...................................................... 1
1. Table of Contents ............................................. 3 1. Table of Contents ............................................. 3
2. Introduction .................................................. 4 2. Introduction .................................................. 4
3. Conventions ................................................... 5 3. Conventions ................................................... 5
4. Syntaxes ...................................................... 5 4. Syntaxes ...................................................... 5
4.1 General Considerations .................................... 5 4.1 General Considerations .................................... 5
4.2 Common Definitions ........................................ 6 4.2 Common Definitions ........................................ 6
4.3 Syntax Definitions ........................................ 7 4.3 Syntax Definitions ........................................ 7
4.3.1 Attribute Type Description ........................... 7 4.3.1 Attribute Type Description ........................... 7
4.3.2 Bit String ........................................... 7 4.3.2 Bit String ........................................... 7
4.3.3 Boolean .............................................. 8 4.3.3 Boolean .............................................. 8
skipping to change at page 3, line 41 skipping to change at page 3, line 40
4.3.17 JPEG ................................................ 16 4.3.17 JPEG ................................................ 16
4.3.18 LDAP Syntax Description ............................. 16 4.3.18 LDAP Syntax Description ............................. 16
4.3.19 Matching Rule Description ........................... 17 4.3.19 Matching Rule Description ........................... 17
4.3.20 Matching Rule Use Description ....................... 17 4.3.20 Matching Rule Use Description ....................... 17
4.3.21 Name and Optional UID ............................... 18 4.3.21 Name and Optional UID ............................... 18
4.3.22 Name Form Description ............................... 18 4.3.22 Name Form Description ............................... 18
4.3.23 Numeric String ...................................... 19 4.3.23 Numeric String ...................................... 19
4.3.24 Object Class Description ............................ 19 4.3.24 Object Class Description ............................ 19
4.3.25 Octet String ........................................ 20 4.3.25 Octet String ........................................ 20
4.3.26 OID ................................................. 20 4.3.26 OID ................................................. 20
4.3.27 Other Mailbox ....................................... 20 4.3.27 Other Mailbox ....................................... 21
4.3.28 Postal Address ...................................... 21 4.3.28 Postal Address ...................................... 21
4.3.29 Printable String .................................... 22 4.3.29 Printable String .................................... 22
4.3.30 Substring Assertion ................................. 22 4.3.30 Substring Assertion ................................. 23
4.3.31 Telephone Number .................................... 23 4.3.31 Telephone Number .................................... 23
4.3.32 Teletex Terminal Identifier ......................... 24 4.3.32 Teletex Terminal Identifier ......................... 24
4.3.33 Telex Number ........................................ 24 4.3.33 Telex Number ........................................ 25
4.3.34 UTC Time ............................................ 25 4.3.34 UTC Time ............................................ 25
5. Matching Rules ................................................ 26 5. Matching Rules ................................................ 26
5.1 General Considerations .................................... 26 5.1 General Considerations .................................... 26
5.2 Matching Rule Definitions ................................. 27 5.2 Matching Rule Definitions ................................. 28
5.2.1 bitStringMatch ....................................... 27 5.2.1 bitStringMatch ....................................... 28
5.2.2 caseExactIA5Match .................................... 28 5.2.2 caseExactIA5Match .................................... 28
5.2.3 caseIgnoreIA5Match ................................... 28 5.2.3 caseIgnoreIA5Match ................................... 29
5.2.4 caseIgnoreIA5SubstringsMatch ......................... 29 5.2.4 caseIgnoreIA5SubstringsMatch ......................... 29
5.2.5 caseIgnoreListMatch .................................. 29 5.2.5 caseIgnoreListMatch .................................. 29
5.2.6 caseIgnoreMatch ...................................... 30 5.2.6 caseIgnoreListSubstringsMatch ........................ 30
5.2.7 caseIgnoreOrderingMatch .............................. 30 5.2.7 caseIgnoreMatch ...................................... 31
5.2.8 caseIgnoreSubstringsMatch ............................ 31 5.2.8 caseIgnoreOrderingMatch .............................. 31
5.2.9 distinguishedNameMatch ............................... 31 5.2.9 caseIgnoreSubstringsMatch ............................ 32
5.2.10 generalizedTimeMatch ................................ 32 5.2.10 distinguishedNameMatch .............................. 32
5.2.11 generalizedTimeOrderingMatch ........................ 32 5.2.11 generalizedTimeMatch ................................ 33
5.2.12 integerFirstComponentMatch .......................... 32 5.2.12 generalizedTimeOrderingMatch ........................ 33
5.2.13 integerMatch ........................................ 33 5.2.13 integerFirstComponentMatch .......................... 34
5.2.14 numericStringMatch .................................. 33 5.2.14 integerMatch ........................................ 34
5.2.15 numericStringSubstringsMatch ........................ 34 5.2.15 numericStringMatch .................................. 34
5.2.16 objectIdentifierFirstComponentMatch ................. 34 5.2.16 numericStringSubstringsMatch ........................ 35
5.2.17 objectIdentifierMatch ............................... 35 5.2.17 objectIdentifierFirstComponentMatch ................. 35
5.2.18 octetStringMatch .................................... 35 5.2.18 objectIdentifierMatch ............................... 36
5.2.19 telephoneNumberMatch ................................ 36 5.2.19 octetStringMatch .................................... 36
5.2.20 telephoneNumberSubstringsMatch ...................... 36 5.2.20 telephoneNumberMatch ................................ 37
5.2.21 uniqueMemberMatch ................................... 37 5.2.21 telephoneNumberSubstringsMatch ...................... 37
6. Security Considerations ....................................... 37 5.2.22 uniqueMemberMatch ................................... 38
7. Acknowledgements .............................................. 38 6. Security Considerations ....................................... 38
8. IANA Considerations ........................................... 38 7. Acknowledgements .............................................. 39
9. Normative References .......................................... 39 8. IANA Considerations ........................................... 39
10. Informative References ....................................... 40 9. Normative References .......................................... 40
11. Authors' Addresses ........................................... 41 10. Informative References ....................................... 42
12. Copyright Notice ............................................. 41 11. Authors' Addresses ........................................... 42
Appendix A. Summary of Syntax Object Identifiers ................. 42 12. Copyright Notice ............................................. 43
Appendix B. Changes from RFC 2252 & RFC 2256 ..................... 43 Appendix A. Summary of Syntax Object Identifiers ................. 43
Appendix B. Changes from RFC 2252 & RFC 2256 ..................... 44
2. Introduction 2. 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
skipping to change at page 14, line 29 skipping to change at page 14, line 29
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"
day = ( %x30 %x31-39 ) ; "01" to "09" day = ( %x30 %x31-39 ) ; "01" to "09"
/ ( %x31-32 %x30-39 ) ; "10" to "29" / ( %x31-32 %x30-39 ) ; "10" to "29"
/ ( %x32 %x30-31 ) ; "30" to "31" / ( %x33 %x30-31 ) ; "30" to "31"
hour = ( %x30-31 %x30-39 ) / ( %x32 %x30-33 ) ; "00" to "23" hour = ( %x30-31 %x30-39 ) / ( %x32 %x30-33 ) ; "00" to "23"
minute = %x30-36 %x30-39 ; "00" to "59" minute = %x30-35 %x30-39 ; "00" to "59"
second = %x30-36 %x30-39 ; "00" to "59" second = %x30-35 %x30-39 ; "00" to "59"
GeneralizedTime = century year month day hour GeneralizedTime = century year month day hour
[ minute [ second ] ] [ fraction ] [ minute [ second ] ] [ fraction ]
g-time-zone g-time-zone
fraction = ( DOT / COMMA ) 1*(%x30-39) fraction = ( DOT / COMMA ) 1*(%x30-39)
g-time-zone = %x5A ; "Z" g-time-zone = %x5A ; "Z"
/ g-differential / g-differential
g-differential = ( MINUS / PLUS ) hour [ minute ] g-differential = ( MINUS / PLUS ) hour [ minute ]
MINUS = %x2D ; minus sign ("-") MINUS = %x2D ; minus sign ("-")
skipping to change at page 17, line 20 skipping to change at page 17, line 20
itself a legal value of the LDAP Syntax Description syntax. itself a legal value of the LDAP Syntax Description syntax.
The ASN.1 type corresponding to the LDAP Syntax Description syntax is The ASN.1 type corresponding to the LDAP Syntax Description syntax is
defined as follows, assuming EXPLICIT TAGS: defined as follows, assuming EXPLICIT TAGS:
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 is implementation defined.
The value of ub-schema (an integer) is implementation defined. A
non-normative definition appears in [X.520].
4.3.19 Matching Rule Description 4.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 )
skipping to change at page 21, line 32 skipping to change at page 21, line 35
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 4.3.28 Postal Address
A value of the Postal Address syntax is a series of strings which A value of the Postal Address syntax is a sequence of strings of one
form an address in a physical mail system. or more arbitrary UCS characters, which form an address in a physical
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 <line> of a postal address value is encoded as a UTF-8 [UTF-8] Each character string (i.e. <line>) of a postal address value is
string except that "\" and "$" characters, if they occur in the line, encoded as a UTF-8 [UTF-8] string except that "\" and "$" characters,
are escaped by a "\" character followed by the two hexadecimal digit if they occur in the string, are escaped by a "\" character followed
code for the character. The <HEX-DIGIT> rule is defined in Section by the two hexadecimal digit code for the character. The <HEX-DIGIT>
4.2. The <DOLLAR> and <UTFMB> rules are defined in [MODELS]. rule is defined in Section 4.2. The <DOLLAR> and <UTFMB> rules are
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
implementation defined. Non-normative definitions appear in [X.520].
4.3.29 Printable String 4.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 latin
alphabetic, numeric, and (limited) punctuation characters as alphabetic, numeric, and (limited) punctuation characters as
specified by the <PrintableCharacter> rule in Section 4.2. specified by the <PrintableCharacter> rule in Section 4.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 4.2.
skipping to change at page 24, line 4 skipping to change at page 24, line 11
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 4.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 is implementation defined. The value of ub-telephone-number (an integer) is implementation
defined. A non-normative definition appears in [X.520].
4.3.32 Teletex Terminal Identifier 4.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)
skipping to change at page 25, line 38 skipping to change at page 25, line 45
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 <DOLLAR> rule is defined in rules are defined in Section 4.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>.
skipping to change at page 26, line 45 skipping to change at page 27, line 8
matching rule specifies the syntax for the assertion value. The matching rule specifies the syntax for the assertion value. The
syntax of the assertion value is typically, but not necessarily, the syntax of the assertion value is typically, but not necessarily, the
same as the syntax of the attribute values to which the matching rule same as the syntax of the attribute values to which the matching rule
may be applied. Note that the AssertionValue in a SubstringFilter may be applied. Note that the AssertionValue in a SubstringFilter
[PROT] MUST conform to the assertion syntax of the equality matching [PROT] MUST conform to the assertion syntax of the equality matching
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
to which the rule may be applied, by specifying conditions the
corresponding ASN.1 type of a candidate attribute syntax must
satisfy. These conditions are also satisfied if the corresponding
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
constraints are ignored in checking applicability), or an alternative
reference notation for the explicitly mentioned type. Each rule
description lists as examples of applicable attribute syntaxes, the
complete list of the syntaxes defined in this document to which the
matching rule applies. A matching rule may be applicable to
additional syntaxes defined in other documents if those syntaxes
satisfy the conditions on the corresponding ASN.1 type.
The description of each matching rule indicates whether the rule is The description of each matching rule indicates whether the rule is
suitable for use as the equality matching rule (EQUALITY), ordering suitable for use as the equality matching rule (EQUALITY), ordering
matching rule (ORDERING) or substrings matching rule (SUBSTR) in an matching rule (ORDERING) or substrings matching rule (SUBSTR) in an
attribute type definition [MODELS]. attribute type definition [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 5.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 5.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
skipping to change at page 27, line 33 skipping to change at page 28, line 8
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 5.2 Matching Rule Definitions
When evaluating the caseExactIA5Match, caseIgnoreIA5Match, When evaluating the caseExactIA5Match, caseIgnoreIA5Match,
caseIgnoreIA5SubstringsMatch, caseIgnoreListMatch, caseIgnoreMatch, caseIgnoreIA5SubstringsMatch, caseIgnoreListMatch,
caseIgnoreListSubstringsMatch, caseIgnoreMatch,
caseIgnoreOrderingMatch and caseIgnoreSubstringsMatch matching rules caseIgnoreOrderingMatch and caseIgnoreSubstringsMatch matching rules
multiple adjoining whitespace characters are treated the same as an multiple adjoining whitespace characters are treated the same as an
individual space, and leading and trailing whitespace is ignored. individual space, and leading and trailing whitespace is ignored.
5.2.1 bitStringMatch 5.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 syntax)
whose corresponding ASN.1 type is BIT STRING. whose corresponding ASN.1 type is BIT STRING.
skipping to change at page 29, line 28 skipping to change at page 29, line 48
( 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 5.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}
skipping to change at page 30, line 4 skipping to change at page 30, line 26
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 caseIgnoreMatch 5.2.6 caseIgnoreListSubstringsMatch
The caseIgnoreListSubstringsMatch rule compares an assertion value of
the Substring Assertion syntax to an attribute value of a syntax
(e.g. the Postal Address syntax) whose corresponding ASN.1 type is a
SEQUENCE OF the DirectoryString ASN.1 type.
The rule evaluates to TRUE if and only if the assertion value
matches, per the caseIgnoreSubstringsMatch rule, the character string
formed by concatenating the strings of the attribute value, except
that none of the <initial>, <any>, or <final> substrings of the
assertion value are considered to match a substring of the
concatenated string which spans more than one of the original strings
of the attribute value.
Note that, in terms of the LDAP-specific encoding of the Postal
Address syntax, the concatenated string omits the <DOLLAR> line
separator and the escaping of "\" and "$" characters.
The LDAP definition for the caseIgnoreListSubstringsMatch rule is:
( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
The caseIgnoreListSubstringsMatch rule is a substrings matching rule.
5.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 its whose corresponding ASN.1 type is DirectoryString or one of the
alternative string types, e.g. PrintableString. alternative string types of DirectoryString, e.g. PrintableString
(the other alternatives do not correspond to any syntax defined in
this document).
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 characters and corresponding assertion value have the same number of characters and corresponding
characters are the same, ignoring the case of letters. characters are the same, ignoring the case of letters.
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.7 caseIgnoreOrderingMatch 5.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 normal collation The rule evaluates to TRUE if, and only if, in the normal collation
order for the attribute syntax after lower-case letters in both the order for the attribute syntax after lower-case letters in both the
attribute and assertion values have been replaced by their upper-case attribute and assertion values have been replaced by their upper-case
skipping to change at page 31, line 5 skipping to change at page 32, line 8
implementation-defined. [Editor's note: this will be specified by a implementation-defined. [Editor's note: this will be specified by a
stringprep profile before final publication.] stringprep profile before final publication.]
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.8 caseIgnoreSubstringsMatch 5.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 substrings of the The rule evaluates to TRUE if and only if the substrings of the
assertion value match disjoint portions of the attribute value in the assertion value match disjoint portions of the attribute value in the
order of the substrings in the assertion value, and an <initial> order of the substrings in the assertion value, and an <initial>
skipping to change at page 31, line 28 skipping to change at page 32, line 31
value. A substring matches a portion of the attribute value if value. A substring matches a portion of the attribute value if
corresponding characters are the same, ignoring the case of letters. corresponding characters are the same, ignoring the case of letters.
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.9 distinguishedNameMatch 5.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 RDNs and corresponding RDNs
(by position) are the same. An RDN of the assertion value is the (by position) are the same. An RDN of the assertion value is the
same as an RDN of the attribute value if and only if they have the same as an RDN of the attribute value if and only if they have the
same number of attribute value assertions (AVAs) and each AVA of the same number of attribute value assertions (AVAs) and each AVA of the
skipping to change at page 32, line 4 skipping to change at page 33, line 9
RDN. Two AVAs with the same attribute type are the same if their RDN. Two AVAs with the same attribute type are the same if their
values are equal according to the equality matching rule of the values are equal according to the equality matching rule of the
attribute type. If one or more of the AVA comparisons evaluate to attribute type. If one or more of the AVA comparisons evaluate to
Undefined and the remaining AVA comparisons return TRUE then the Undefined and the remaining AVA comparisons return TRUE then the
distinguishedNameMatch rule evaluates to Undefined. 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.10 generalizedTimeMatch 5.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.11 generalizedTimeOrderingMatch 5.2.12 generalizedTimeOrderingMatch
The generalizedTimeMatch rule compares the time ordering of an The generalizedTimeMatch rule compares the time ordering of an
assertion value of the Generalized Time syntax to an attribute value assertion value of the Generalized Time syntax to an attribute value
of a syntax (e.g the Generalized Time syntax) whose corresponding of a syntax (e.g the Generalized Time syntax) whose corresponding
ASN.1 type is GeneralizedTime. 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.12 integerFirstComponentMatch 5.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 33, line 27 skipping to change at page 34, line 33
( 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.13 integerMatch 5.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.14 numericStringMatch 5.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 attribute value and the The rule evaluates to TRUE if and only if the attribute value and the
assertion value are the same string of numerals, ignoring any space assertion value are the same string of numerals, ignoring any space
characters. characters.
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.15 numericStringSubstringsMatch 5.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 substrings of the The rule evaluates to TRUE if and only if the substrings of the
assertion value match disjoint portions of the attribute value in the assertion value match disjoint portions of the attribute value in the
order of the substrings in the assertion value, and an <initial> order of the substrings in the assertion value, and an <initial>
substring, if present, matches the beginning of the attribute value, substring, if present, matches the beginning of the attribute value,
and a <final> substring, if present, matches the end of the attribute and a <final> substring, if present, matches the end of the attribute
value. A substring matches a portion of the attribute value if value. A substring matches a portion of the attribute value if
corresponding characters are the same, ignoring any space characters. corresponding characters are the same, ignoring any space characters.
( 2.5.13.10 NAME 'numericStringSubstringsMatch' ( 2.5.13.10 NAME 'numericStringSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 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.16 objectIdentifierFirstComponentMatch 5.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 35, line 20 skipping to change at page 36, line 26
( 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.17 objectIdentifierMatch 5.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 35, line 43 skipping to change at page 36, line 49
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.18 octetStringMatch 5.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.19 telephoneNumberMatch 5.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 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 characters and corresponding assertion value have the same number of characters and corresponding
characters are the same, ignoring the case of letters, and ignoring characters are the same, ignoring the case of letters, and ignoring
space and `-' characters. space and `-' characters.
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.20 telephoneNumberSubstringsMatch 5.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 substrings of the The rule evaluates to TRUE if and only if the substrings of the
assertion value match disjoint portions of the attribute value in the assertion value match disjoint portions of the attribute value in the
order of the substrings in the assertion value, and an <initial> order of the substrings in the assertion value, and an <initial>
substring, if present, matches the beginning of the attribute value, substring, if present, matches the beginning of the attribute value,
skipping to change at page 37, line 14 skipping to change at page 38, line 18
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.21 uniqueMemberMatch 5.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 38, line 23 skipping to change at page 39, line 28
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 8. IANA Considerations
It is requested that the Internet Assigned Numbers Authority (IANA) The Internet Assigned Numbers Authority (IANA) is requested to update
update the LDAP descriptors registry as indicated by the following the LDAP descriptors registry as indicated by the following
two 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
Comments: Comments:
skipping to change at page 39, line 34 skipping to change at page 40, line 39
Subject: Request for LDAP Descriptor Registration Subject: Request for LDAP Descriptor Registration
Descriptor (short name): caseIgnoreIA5SubstringsMatch Descriptor (short name): caseIgnoreIA5SubstringsMatch
Object Identifier: 1.3.6.1.4.1.1466.109.114.3 Object Identifier: 1.3.6.1.4.1.1466.109.114.3
Person & email address to contact for further information: Person & email address to contact for further information:
Steven Legg <steven.legg@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 Subject: Request for LDAP Descriptor Registration
Descriptor (short name): caseIgnoreListSubstringsMatch
Object Identifier: 2.5.13.12
Person & email address to contact for further information:
Steven Legg <steven.legg@adacel.com.au>
Usage: other (M)
Specification: RFC XXXX
Author/Change Controller: IESG
9. 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 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998. 10646", RFC 2279, January 1998.
[RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64, RFC [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64, RFC
skipping to change at page 41, line 48 skipping to change at page 43, line 16
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. Copyright Notice 12. Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
skipping to change at page 45, line 27 skipping to change at page 46, line 41
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, caseIgnoreOrderingMatch and 25. The caseIgnoreIA5SubstringsMatch, caseIgnoreListSubstringsMatch,
caseIgnoreSubstringsMatch matching rules have been added to the caseIgnoreOrderingMatch and caseIgnoreSubstringsMatch matching
list of matching rules for which the provisions for handling rules have been added to the list of matching rules for which the
leading, trailing and multiple adjoining whitespace characters provisions for handling leading, trailing and multiple adjoining
apply. This is consistent with the definitions of these matching whitespace characters apply. This is consistent with the
rules in X.500. The telephoneNumberMatch rule has been removed definitions of these matching rules in X.500. The
from the list since it completely ignores all space characters. telephoneNumberMatch rule has been removed from the list since it
completely ignores all space characters.
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
rule from RFC 2798 & X.520 has been added to this document.
 End of changes. 

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