idnits 2.17.1 draft-ietf-ldapbis-syntaxes-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 47 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC2252, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC2256, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (3 June 2003) is 7623 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ROADMAP' is mentioned on line 155, but not defined -- Looks like a reference, but probably isn't: '3' on line 576 == Missing Reference: 'ISO8601' is mentioned on line 585, but not defined == Unused Reference: 'BCP11' is defined on line 1951, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2279 (ref. 'UTF-8') (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 3383 (Obsoleted by RFC 4520) -- No information found for draft-ietf-ldapbis-dn-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'LDAPDN' -- No information found for draft-ietf-ldapbis-protocol-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PROT' -- Possible downref: Non-RFC (?) normative reference: ref. 'FAX' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO3166' -- Possible downref: Non-RFC (?) normative reference: ref. 'UCS' -- Possible downref: Non-RFC (?) normative reference: ref. 'JPEG' -- No information found for draft-ietf-ldapbis-models-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'MODELS' -- No information found for draft-ietf-ldapbis-strprep-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PREP' -- Obsolete informational reference (is this intentional?): RFC 2028 (ref. 'BCP11') (Obsoleted by RFC 9281) -- Obsolete informational reference (is this intentional?): RFC 2252 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) -- Obsolete informational reference (is this intentional?): RFC 2256 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4519, RFC 4523) -- Obsolete informational reference (is this intentional?): RFC 3377 (Obsoleted by RFC 4510) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT S. Legg, Editor 3 draft-ietf-ldapbis-syntaxes-06.txt Adacel Technologies 4 Intended Category: Standard Track K. Dally 5 Obsoletes: RFC 2252, RFC 2256 The MITRE Corp. 6 3 June 2003 8 LDAP: Syntaxes and Matching Rules 10 Copyright (C) The Internet Society (2003). All Rights Reserved. 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This document is intended to be, after appropriate review and 34 revision, submitted to the RFC Editor as a Standard Track document. 35 Distribution of this document is unlimited. Technical discussion of 36 this document should take place on the IETF LDAP Revision Working 37 Group (LDAPbis) mailing list . Please 38 send editorial comments directly to the editor 39 . 41 This Internet-Draft expires on 3 December 2003. 43 Abstract 45 Each attribute stored in a Lightweight Directory Access Protocol 46 (LDAP) directory, and whose values may be transfered in the LDAP 47 protocol, has a defined syntax which constrains the structure and 48 format of its values. The comparison semantics for values of a 49 syntax are not part of the syntax definition but are instead provided 50 through separately defined matching rules. Matching rules specify an 51 argument, an assertion value, which also has a defined syntax. This 52 document defines a base set of syntaxes and matching rules for use in 53 defining attributes for LDAP directories. 55 1. Table of Contents 57 1. Table of Contents ............................................. 3 58 2. Introduction .................................................. 4 59 3. Conventions ................................................... 5 60 4. Syntaxes ...................................................... 5 61 4.1 General Considerations .................................... 5 62 4.2 Common Definitions ........................................ 6 63 4.3 Syntax Definitions ........................................ 7 64 4.3.1 Attribute Type Description ........................... 7 65 4.3.2 Bit String ........................................... 7 66 4.3.3 Boolean .............................................. 8 67 4.3.4 Country String ....................................... 8 68 4.3.5 Delivery Method ...................................... 9 69 4.3.6 Directory String ..................................... 9 70 4.3.7 DIT Content Rule Description ......................... 10 71 4.3.8 DIT Structure Rule Description ....................... 11 72 4.3.9 DN ................................................... 11 73 4.3.10 Enhanced Guide ...................................... 12 74 4.3.11 Facsimile Telephone Number .......................... 13 75 4.3.12 Fax ................................................. 13 76 4.3.13 Generalized Time .................................... 14 77 4.3.14 Guide ............................................... 15 78 4.3.15 IA5 String .......................................... 15 79 4.3.16 Integer ............................................. 16 80 4.3.17 JPEG ................................................ 16 81 4.3.18 LDAP Syntax Description ............................. 16 82 4.3.19 Matching Rule Description ........................... 17 83 4.3.20 Matching Rule Use Description ....................... 17 84 4.3.21 Name and Optional UID ............................... 18 85 4.3.22 Name Form Description ............................... 19 86 4.3.23 Numeric String ...................................... 19 87 4.3.24 Object Class Description ............................ 19 88 4.3.25 Octet String ........................................ 20 89 4.3.26 OID ................................................. 20 90 4.3.27 Other Mailbox ....................................... 21 91 4.3.28 Postal Address ...................................... 21 92 4.3.29 Printable String .................................... 22 93 4.3.30 Substring Assertion ................................. 23 94 4.3.31 Telephone Number .................................... 24 95 4.3.32 Teletex Terminal Identifier ......................... 24 96 4.3.33 Telex Number ........................................ 25 97 4.3.34 UTC Time ............................................ 25 98 5. Matching Rules ................................................ 26 99 5.1 General Considerations .................................... 26 100 5.2 Matching Rule Definitions ................................. 28 101 5.2.1 bitStringMatch ....................................... 28 102 5.2.2 caseExactIA5Match .................................... 28 103 5.2.3 caseIgnoreIA5Match ................................... 29 104 5.2.4 caseIgnoreIA5SubstringsMatch ......................... 29 105 5.2.5 caseIgnoreListMatch .................................. 30 106 5.2.6 caseIgnoreListSubstringsMatch ........................ 31 107 5.2.7 caseIgnoreMatch ...................................... 31 108 5.2.8 caseIgnoreOrderingMatch .............................. 32 109 5.2.9 caseIgnoreSubstringsMatch ............................ 32 110 5.2.10 distinguishedNameMatch .............................. 33 111 5.2.11 generalizedTimeMatch ................................ 34 112 5.2.12 generalizedTimeOrderingMatch ........................ 34 113 5.2.13 integerFirstComponentMatch .......................... 34 114 5.2.14 integerMatch ........................................ 35 115 5.2.15 numericStringMatch .................................. 35 116 5.2.16 numericStringSubstringsMatch ........................ 36 117 5.2.17 objectIdentifierFirstComponentMatch ................. 36 118 5.2.18 objectIdentifierMatch ............................... 37 119 5.2.19 octetStringMatch .................................... 38 120 5.2.20 telephoneNumberMatch ................................ 38 121 5.2.21 telephoneNumberSubstringsMatch ...................... 38 122 5.2.22 uniqueMemberMatch ................................... 39 123 6. Security Considerations ....................................... 40 124 7. Acknowledgements .............................................. 40 125 8. IANA Considerations ........................................... 40 126 9. Normative References .......................................... 42 127 10. Informative References ....................................... 43 128 11. Authors' Addresses ........................................... 44 129 12. Intellectual Property Notice ................................. 44 130 13. Copyright Notice ............................................. 45 131 Appendix A. Summary of Syntax Object Identifiers ................. 45 132 Appendix B. Changes from RFC 2252 & RFC 2256 ..................... 46 134 2. Introduction 136 Each attribute stored in a Lightweight Directory Access Protocol 137 (LDAP) directory [ROADMAP], and whose values may be transfered in the 138 LDAP protocol [PROT], has a defined syntax (i.e. data type) which 139 constrains the structure and format of its values. The comparison 140 semantics for values of a syntax are not part of the syntax 141 definition but are instead provided through separately defined 142 matching rules. Matching rules specify an argument, an assertion 143 value, which also has a defined syntax. This document defines a base 144 set of syntaxes and matching rules for use in defining attributes for 145 LDAP directories. 147 Readers are advised to familiarize themselves with the Directory 148 Information Models [MODELS] before reading the rest of this document. 149 Section 4 provides definitions for the base set of LDAP syntaxes. 151 Section 5 provides definitions for the base set of matching rules for 152 LDAP. 154 This document is a integral part of the LDAP technical specification 155 [ROADMAP] which obsoletes the previously defined LDAP technical 156 specification [RFC3377] in its entirety. 158 Sections 4, 5 and 7 of RFC 2252 [RFC2252] are obsoleted by [MODELS]. 159 The remainder of RFC 2252 is obsoleted by this document. Sections 6 160 and 8 of RFC 2256 are obsoleted by this document. The changes from 161 RFC 2252 and RFC 2256 [RFC2256] are described in Appendix B of this 162 document. 164 3. Conventions 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in RFC 2119 [KEYWORD]. 170 Syntax definitions are written according to the 171 ABNF [ABNF] rule specified in [MODELS], and matching rule definitions 172 are written according to the ABNF rule 173 specified in [MODELS], except that the syntax and matching rule 174 definitions provided in this document are line-wrapped for 175 readability. When such definitions are transfered as attribute 176 values in the LDAP protocol (e.g. as values of the ldapSyntaxes and 177 matchingRules attributes [MODELS] respectively) then those values 178 would not contain line breaks. 180 4. Syntaxes 182 Syntax definitions constrain the structure of attribute values stored 183 in an LDAP directory, and determine the representation of attribute 184 and assertion values transfered in the LDAP protocol. 186 Syntaxes that are required for directory operation, or that are in 187 common use, are specified in this section. Servers SHOULD recognize 188 all the syntaxes listed in this document, but are NOT REQUIRED to 189 otherwise support them, and MAY recognise or support other syntaxes. 190 However, the definition of additional arbitrary syntaxes is 191 discouraged since it will hinder interoperability. Client and server 192 implementations typically do not have the ability to dynamically 193 recognize new syntaxes. 195 4.1 General Considerations 196 The description of each syntax specifies how attribute or assertion 197 values conforming to the syntax are to be represented when transfered 198 in the LDAP protocol [PROT]. This representation is referred to as 199 the LDAP-specific encoding to distinguish it from other methods of 200 encoding attribute values (e.g. the BER encoding [BER] used by X.500 201 [X.500] directories). 203 The LDAP-specific encoding of a given attribute syntax always 204 produces octet-aligned values. To the greatest extent possible, 205 encoding rules for LDAP syntaxes should produce character strings 206 that can be displayed with little or no translation by clients 207 implementing LDAP. However, clients MUST NOT assume that the 208 LDAP-specific encoding of a value of an unrecognized syntax is a 209 human-readable character string. There are a few cases (e.g. the 210 JPEG syntax) when it is not reasonable to produce a human-readable 211 representation. 213 Each LDAP syntax is uniquely identified with an object identifier 214 [ASN.1] represented in the dotted-decimal format (short descriptive 215 names are not defined for syntaxes). These object identifiers are 216 not intended to be displayed to users. The object identifiers for 217 the syntaxes defined in this document are summarized in Appendix A. 219 A suggested minimum upper bound on the number of characters in an 220 attribute value with a string-based syntax, or the number of octets 221 in a value for all other syntaxes, MAY be indicated by appending the 222 bound inside of curly braces following the syntax's OBJECT IDENTIFIER 223 in an attribute type definition (see the rule in [MODELS]). 224 Such a bound is not considered part of the syntax identifier. 226 For example, "1.3.6.1.4.1.1466.115.121.1.15{64}" in an attribute 227 definition suggests that the directory server will allow a value of 228 the attribute to be up to 64 characters long, although it may allow 229 longer character strings. Note that a single character of the 230 Directory String syntax can be encoded in more than one octet since 231 UTF-8 [UTF-8] is a variable-length encoding. Therefore a 64 232 character string may be more than 64 octets in length. 234 4.2 Common Definitions 236 The following ABNF rules are used in a number of the syntax 237 definitions in Section 4.3. 239 PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN / 240 PLUS / COMMA / HYPHEN / DOT / EQUALS / 241 SLASH / COLON / QUESTION / SPACE 242 PrintableString = 1*PrintableCharacter 243 IA5String = *(%x00-7F) 244 HEX-DIGIT = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" 245 ; N.B. allows upper and lower case 246 SLASH = %x2F ; forward slash ("/") 247 COLON = %x3A ; colon (":") 248 QUESTION = %x3F ; question mark ("?") 250 The , , , , , , , 251 , , , and rules are defined in 252 [MODELS]. 254 4.3 Syntax Definitions 256 4.3.1 Attribute Type Description 258 A value of the Attribute Type Description syntax is the definition of 259 an attribute type. The LDAP-specific encoding of a value of this 260 syntax is defined by the rule in [MODELS]. 261 For example, the following definition of the createTimestamp 262 attribute type from [MODELS] is also a value of the Attribute Type 263 Description syntax (note: line breaks have been added for readability 264 - they are not part of the value when transfered in protocol). 266 ( 2.5.18.1 NAME 'createTimestamp' 267 EQUALITY generalizedTimeMatch 268 ORDERING generalizedTimeOrderingMatch 269 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 270 SINGLE-VALUE NO-USER-MODIFICATION 271 USAGE directoryOperation ) 273 The LDAP definition for the Attribute Type Description syntax is: 275 ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' ) 277 This syntax corresponds to the AttributeTypeDescription ASN.1 type 278 from [X.501]. 280 4.3.2 Bit String 282 A value of the Bit String syntax is a sequence of binary digits. The 283 LDAP-specific encoding of a value of this syntax is defined by the 284 following ABNF: 286 BitString = SQUOTE *binary-digit SQUOTE "B" 287 binary-digit = "0" / "1" 289 The rule is defined in [MODELS]. 291 Example: 292 '0101111101'B 294 The LDAP definition for the Bit String syntax is: 296 ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' ) 298 This syntax corresponds to the BIT STRING ASN.1 type from [ASN.1]. 300 4.3.3 Boolean 302 A value of the Boolean syntax is one of the Boolean values, true or 303 false. The LDAP-specific encoding of a value of this syntax is 304 defined by the following ABNF: 306 Boolean = "TRUE" / "FALSE" 308 The LDAP definition for the Boolean syntax is: 310 ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' ) 312 This syntax corresponds to the BOOLEAN ASN.1 type from [ASN.1]. 314 4.3.4 Country String 316 A value of the Country String syntax is one of the two-character 317 codes from ISO 3166 [ISO3166] for representing a country. The 318 LDAP-specific encoding of a value of this syntax is defined by the 319 following ABNF: 321 CountryString = 2(PrintableCharacter) 323 The rule is defined in Section 4.2. 325 Examples: 326 US 327 AU 329 The LDAP definition for the Country String syntax is: 331 ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' ) 333 This syntax corresponds to the following ASN.1 type from [X.520]: 335 PrintableString (SIZE (2)) -- IS 3166 codes only 337 4.3.5 Delivery Method 339 A value of the Delivery Method syntax is a sequence of items that 340 indicate, in preference order, the service(s) by which an entity is 341 willing and/or capable of receiving messages. The LDAP-specific 342 encoding of a value of this syntax is defined by the following ABNF: 344 DeliveryMethod = pdm *( WSP DOLLAR WSP pdm ) 346 pdm = "any" / "mhs" / "physical" / "telex" / "teletex" / 347 "g3fax" / "g4fax" / "ia5" / "videotex" / "telephone" 349 The and rules are defined in [MODELS]. 351 Example: 352 telephone $ videotex 354 The LDAP definition for the Delivery Method syntax is: 356 ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' ) 358 This syntax corresponds to the following ASN.1 type from [X.520]: 360 SEQUENCE OF INTEGER { 361 any-delivery-method (0), 362 mhs-delivery (1), 363 physical-delivery (2), 364 telex-delivery (3), 365 teletex-delivery (4), 366 g3-facsimile-delivery (5), 367 g4-facsimile-delivery (6), 368 ia5-terminal-delivery (7), 369 videotex-delivery (8), 370 telephone-delivery (9) } 372 4.3.6 Directory String 374 A value of the Directory String syntax is a string of one or more 375 arbitrary characters from the Universal Character Set (UCS) [UCS]. A 376 zero length character string is not permitted. The LDAP-specific 377 encoding of a value of this syntax is the UTF-8 encoding [UTF-8] of 378 the character string. Such encodings conform to the following ABNF: 380 DirectoryString = 1*UTF8 382 The rule is defined in [MODELS]. 384 Example: 385 This is a value of Directory String containing #!%#@. 387 Servers and clients MUST be prepared to receive arbitrary UCS code 388 points, including code points outside the range of printable ASCII 389 and code points not presently assigned to any character. 391 Attribute type definitions using the Directory String syntax should 392 not restrict the format of Directory String values, e.g. by requiring 393 that the character string conforms to specific patterns described by 394 ABNF. A new syntax should be defined in such cases. 396 The LDAP definition for the Directory String syntax is: 398 ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' ) 400 This syntax corresponds to the DirectoryString parameterized ASN.1 401 type from [X.520]. 403 The DirectoryString ASN.1 type allows a choice between the 404 TeletexString, PrintableString or UniversalString ASN.1 types from 405 [ASN.1]. However, note that the chosen alternative is not indicated 406 in the LDAP-specific encoding of a Directory String value. 408 Implementations which convert Directory String values from the 409 LDAP-specific encoding to the BER encoding used by X.500 must choose 410 an alternative that permits the particular characters in the string, 411 and must convert the characters from the UTF-8 encoding into the 412 character encoding of the chosen alternative. 414 When converting Directory String values from the BER encoding to the 415 LDAP-specific encoding the characters must be converted from the 416 character encoding of the chosen alternative into the UTF-8 encoding. 418 4.3.7 DIT Content Rule Description 420 A value of the DIT Content Rule Description syntax is the definition 421 of a DIT content rule. The LDAP-specific encoding of a value of this 422 syntax is defined by the rule in 423 [MODELS]. 425 Example: 426 ( 2.5.6.4 DESC 'content rule for organization' 427 NOT ( x121Address $ telexNumber ) ) 429 Note: a line break has been added for readability - it is not part of 430 the value. 432 The LDAP definition for the DIT Content Rule Description syntax is: 434 ( 1.3.6.1.4.1.1466.115.121.1.16 435 DESC 'DIT Content Rule Description' ) 437 This syntax corresponds to the DITContentRuleDescription ASN.1 type 438 from [X.501]. 440 4.3.8 DIT Structure Rule Description 442 A value of the DIT Structure Rule Description syntax is the 443 definition of a DIT structure rule. The LDAP-specific encoding of a 444 value of this syntax is defined by the 445 rule in [MODELS]. 447 Example: 448 ( 2 DESC 'organization structure rule' FORM 2.5.15.3 ) 450 The LDAP definition for the DIT Structure Rule Description syntax is: 452 ( 1.3.6.1.4.1.1466.115.121.1.17 453 DESC 'DIT Structure Rule Description' ) 455 This syntax corresponds to the DITStructureRuleDescription ASN.1 type 456 from [X.501]. 458 4.3.9 DN 460 A value of the DN syntax is the (purported) distinguished name of an 461 entry [MODELS]. The LDAP-specific encoding of a value of this syntax 462 is defined by the rule in [LDAPDN]. 464 Examples (from [LDAPDN]): 465 UID=jsmith,DC=example,DC=net 466 OU=Sales+CN=J. Smith,DC=example,DC=net 467 CN=John Smith\, III,DC=example,DC=net 468 CN=Before\0dAfter,DC=example,DC=net 469 1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com 470 CN=Lu\C4\8Di\C4\87 472 The LDAP definition for the DN syntax is: 474 ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' ) 476 The DN syntax corresponds to the DistinguishedName ASN.1 type from 477 [X.501]. Note that a BER encoded distinguished name (as used by 478 X.500) re-encoded into the LDAP-specific encoding is not necessarily 479 reversible to the original BER encoding since the chosen string type 480 in any DirectoryString components of the distinguished name is not 481 indicated in the LDAP-specific encoding of the distinguished name 482 (see Section 4.3.6). 484 4.3.10 Enhanced Guide 486 A value of the Enhanced Guide syntax suggests criteria, which consist 487 of combinations of attribute types and filter operators, to be used 488 in constructing filters to search for entries of particular object 489 classes. The Enhanced Guide syntax improves upon the Guide syntax by 490 allowing the recommended depth of the search to be specified. 492 The LDAP-specific encoding of a value of this syntax is defined by 493 the following ABNF: 495 EnhancedGuide = object-class SHARP WSP criteria WSP 496 SHARP WSP subset 497 object-class = WSP oid WSP 498 subset = "baseobject" / "oneLevel" / "wholeSubtree" 500 criteria = and-term *( BAR and-term ) 501 and-term = term *( AMPERSAND term ) 502 term = EXCLAIM term / 503 attributetype DOLLAR match-type / 504 LPAREN criteria RPAREN / 505 true / 506 false 507 match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX" 508 true = "?true" 509 false = "?false" 510 BAR = %x7C ; vertical bar ("|") 511 AMPERSAND = %x26 ; ampersand ("&") 512 EXCLAIM = %x21 ; exclamation mark ("!") 514 The , , , , , and 515 rules are defined in [MODELS]. 517 The LDAP definition for the Enhanced Guide syntax is: 519 ( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' ) 521 Example: 523 person#(sn$EQ)#oneLevel 525 The Enhanced Guide syntax corresponds to the EnhancedGuide ASN.1 type 526 from [X.520]. The EnhancedGuide type references the Criteria ASN.1 527 type, also from [X.520]. The rule above represents an empty 528 "and" expression in a value of the Criteria type. The rule 529 above represents an empty "or" expression in a value of the Criteria 530 type. 532 4.3.11 Facsimile Telephone Number 534 A value of the Facsimile Telephone Number syntax is a subscriber 535 number of a facsimile device on the public switched telephone 536 network. The LDAP-specific encoding of a value of this syntax is 537 defined by the following ABNF: 539 fax-number = telephone-number *( DOLLAR fax-parameter ) 540 telephone-number = PrintableString 541 fax-parameter = "twoDimensional" / 542 "fineResolution" / 543 "unlimitedLength" / 544 "b4Length" / 545 "a3Width" / 546 "b4Width" / 547 "uncompressed" 549 The is a string of printable characters that 550 complies with the internationally agreed format for representing 551 international telephone numbers [E.123]. The rule 552 is defined in Section 4.2. The rule is defined in [MODELS]. 554 The LDAP definition for the Facsimile Telephone Number syntax is: 556 ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number') 558 The Facsimile Telephone Number syntax corresponds to the 559 FacsimileTelephoneNumber ASN.1 type from [X.520]. 561 4.3.12 Fax 563 A value of the Fax syntax is an image which is produced using the 564 Group 3 facsimile process [FAX] to duplicate an object, such as a 565 memo. The LDAP-specific encoding of a value of this syntax is the 566 string of octets for a Group 3 Fax image as defined in [FAX]. 568 The LDAP definition for the Fax syntax is: 570 ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' ) 572 The ASN.1 type corresponding to the Fax syntax is defined as follows, 573 assuming EXPLICIT TAGS: 575 Fax ::= CHOICE { 576 g3-facsimile [3] G3FacsimileBodyPart 577 } 579 The G3FacsimileBodyPart ASN.1 type is defined in [X.420]. 581 4.3.13 Generalized Time 583 A value of the Generalized Time syntax is a character string 584 representing a date and time. The LDAP-specific encoding of a value 585 of this syntax is a restriction of the format defined in [ISO8601], 586 and is described by the following ABNF: 588 century = 2(%x30-39) ; "00" to "99" 589 year = 2(%x30-39) ; "00" to "99" 590 month = ( %x30 %x31-39 ) ; "01" (January) to "09" 591 / ( %x31 %x30-32 ) ; "10" to "12" 592 day = ( %x30 %x31-39 ) ; "01" to "09" 593 / ( %x31-32 %x30-39 ) ; "10" to "29" 594 / ( %x33 %x30-31 ) ; "30" to "31" 595 hour = ( %x30-31 %x30-39 ) / ( %x32 %x30-33 ) ; "00" to "23" 596 minute = %x30-35 %x30-39 ; "00" to "59" 597 second = ( %x30-35 %x30-39 ) ; "00" to "59" 598 / ( %x36 %x30 ) ; "60" (a leap second) 600 GeneralizedTime = century year month day hour 601 [ minute [ second ] ] [ fraction ] 602 g-time-zone 603 fraction = ( DOT / COMMA ) 1*(%x30-39) 604 g-time-zone = %x5A ; "Z" 605 / g-differential 606 g-differential = ( MINUS / PLUS ) hour [ minute ] 607 MINUS = %x2D ; minus sign ("-") 609 The , and rules are defined in [MODELS]. 611 The time value represents coordinated universal time (equivalent to 612 Greenwich Mean Time) if the "Z" form of is used, 613 otherwise the value represents a local time in the time zone 614 indicated by . In the latter case, coordinated 615 universal time can be calculated by subtracting the differential from 616 the local time. The "Z" form of SHOULD be used in 617 preference to . 619 Examples: 620 199412161032Z 621 199412160532-0500 623 Both example values represent the same coordinated universal time: 624 40:32 am, December 16, 1994. 626 The LDAP definition for the Generalized Time syntax is: 628 ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' ) 630 This syntax corresponds to the GeneralizedTime ASN.1 type from 631 [ASN.1], with the constraint that local time without a differential 632 SHALL NOT be used. 634 4.3.14 Guide 636 A value of the Guide syntax suggests criteria, which consist of 637 combinations of attribute types and filter operators, to be used in 638 constructing filters to search for entries of particular object 639 classes. The Guide syntax is obsolete and should not be used for 640 defining new attribute types. 642 The LDAP-specific encoding of a value of this syntax is defined by 643 the following ABNF: 645 Guide = [ object-class SHARP ] criteria 647 The and rules are defined in Section 648 4.3.10. The rule is defined in [MODELS]. 650 The LDAP definition for the Guide syntax is: 652 ( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' ) 654 The Guide syntax corresponds to the Guide ASN.1 type from [X.520]. 656 4.3.15 IA5 String 658 A value of the IA5 String syntax is a string of zero, one or more 659 characters from International Alphabet 5 (IA5) [T.50], the 660 international version of the ASCII character set. The LDAP-specific 661 encoding of a value of this syntax is the unconverted string of 662 characters, which conforms to the rule in Section 4.2. 664 The LDAP definition for the IA5 String syntax is: 666 ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' ) 668 This syntax corresponds to the IA5String ASN.1 type from [ASN.1]. 670 4.3.16 Integer 672 A value of the Integer syntax is a whole number of unlimited 673 magnitude. The LDAP-specific encoding of a value of this syntax is 674 the optionally signed decimal digit character string representation 675 of the number (so, for example, the number 1321 is represented by the 676 character string "1321"). The encoding is defined by the following 677 ABNF: 679 Integer = ( HYPHEN LDIGIT *DIGIT ) / number 681 The , , and rules are defined in 682 [MODELS]. 684 The LDAP definition for the Integer syntax is: 686 ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' ) 688 This syntax corresponds to the INTEGER ASN.1 type from [ASN.1]. 690 4.3.17 JPEG 692 A value of the JPEG syntax is an image in the JPEG File Interchange 693 Format (JFIF), as described in [JPEG]. The LDAP-specific encoding of 694 a value of this syntax is the sequence of octets of the JFIF encoding 695 of the image. 697 The LDAP definition for the JPEG syntax is: 699 ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' ) 701 The JPEG syntax corresponds to the following ASN.1 type: 703 JPEG ::= OCTET STRING (CONSTRAINED BY 704 { -- contents octets are an image in the -- 705 -- JPEG File Interchange Format -- }) 707 4.3.18 LDAP Syntax Description 708 A value of the LDAP Syntax Description syntax is the description of 709 an LDAP syntax. The LDAP-specific encoding of a value of this syntax 710 is defined by the rule in [MODELS]. 712 The LDAP definition for the LDAP Syntax Description syntax is: 714 ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' ) 716 The above LDAP definition for the LDAP Syntax Description syntax is 717 itself a legal value of the LDAP Syntax Description syntax. 719 The ASN.1 type corresponding to the LDAP Syntax Description syntax is 720 defined as follows, assuming EXPLICIT TAGS: 722 LDAPSyntaxDescription ::= SEQUENCE { 723 identifier OBJECT IDENTIFIER, 724 description DirectoryString { ub-schema } OPTIONAL } 726 The DirectoryString parameterized ASN.1 type is defined in [X.520]. 728 The value of ub-schema (an integer) is implementation defined. A 729 non-normative definition appears in [X.520]. 731 4.3.19 Matching Rule Description 733 A value of the Matching Rule Description syntax is the definition of 734 a matching rule. The LDAP-specific encoding of a value of this 735 syntax is defined by the rule in [MODELS]. 737 Example: 738 ( 2.5.13.2 NAME 'caseIgnoreMatch' 739 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 741 Note: a line break has been added for readability - it is not part of 742 the syntax. 744 The LDAP definition for the Matching Rule Description syntax is: 746 ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' ) 748 This syntax corresponds to the MatchingRuleDescription ASN.1 type 749 from [X.501]. 751 4.3.20 Matching Rule Use Description 753 A value of the Matching Rule Use Description syntax indicates the 754 attribute types to which a matching rule may be applied in an 755 extensibleMatch search filter [PROT]. The LDAP-specific encoding of 756 a value of this syntax is defined by the 757 rule in [MODELS]. 759 Example: 760 ( 2.5.13.16 APPLIES ( givenName $ surname ) ) 762 The LDAP definition for the Matching Rule Use Description syntax is: 764 ( 1.3.6.1.4.1.1466.115.121.1.31 765 DESC 'Matching Rule Use Description' ) 767 This syntax corresponds to the MatchingRuleUseDescription ASN.1 type 768 from [X.501]. 770 4.3.21 Name and Optional UID 772 A value of the Name and Optional UID syntax is the distinguished name 773 [MODELS] of an entity optionally accompanied by a unique identifier 774 that serves to differentiate the entity from others with an identical 775 distinguished name. 777 The LDAP-specific encoding of a value of this syntax is defined by 778 the following ABNF: 780 NameAndOptionalUID = distinguishedName [ SHARP BitString ] 782 The rule is defined in Section 4.3.2. The 783 rule is defined in [LDAPDN]. The rule is 784 defined in [MODELS]. 786 Note that although the '#' character may occur in the string 787 representation of a distinguished name, no additional escaping of 788 this character is performed when a is encoded in 789 a . 791 Example: 792 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B 794 The LDAP definition for the Name and Optional UID syntax is: 796 ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' ) 798 This syntax corresponds to the NameAndOptionalUID ASN.1 type from 799 [X.520]. 801 4.3.22 Name Form Description 803 A value of the Name Form Description syntax is the definition of a 804 name form, which regulates how entries may be named. The 805 LDAP-specific encoding of a value of this syntax is defined by the 806 rule in [MODELS]. 808 Example: 809 ( 2.5.15.3 NAME 'orgNameForm' OC organization MUST o ) 811 The LDAP definition for the Name Form Description syntax is: 813 ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' ) 815 This syntax corresponds to the NameFormDescription ASN.1 type from 816 [X.501]. 818 4.3.23 Numeric String 820 A value of the Numeric String syntax is a sequence of one or more 821 numerals and spaces. The LDAP-specific encoding of a value of this 822 syntax is the unconverted string of characters, which conforms to the 823 following ABNF: 825 NumericString = 1*(DIGIT / SPACE) 827 The and rules are defined in [MODELS]. 829 Example: 830 15 079 672 281 832 The LDAP definition for the Numeric String syntax is: 834 ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' ) 836 This syntax corresponds to the NumericString ASN.1 type from [ASN.1]. 838 4.3.24 Object Class Description 840 A value of the Object Class Description syntax is the definition of 841 an object class. The LDAP-specific encoding of a value of this 842 syntax is defined by the rule in [MODELS]. 844 Example: 845 ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c 846 MAY ( searchGuide $ description ) ) 848 Note: a line break has been added for readability - it is not part of 849 the syntax. 851 The LDAP definition for the Object Class Description syntax is: 853 ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' ) 855 This syntax corresponds to the ObjectClassDescription ASN.1 type from 856 [X.501]. 858 4.3.25 Octet String 860 A value of the Octet String syntax is a sequence of zero, one or more 861 arbitrary octets. The LDAP-specific encoding of a value of this 862 syntax is the unconverted sequence of octets, which conforms to the 863 following ABNF: 865 OctetString = *OCTET 867 The rule is defined in [MODELS]. Values of this syntax are 868 not generally human-readable. 870 The LDAP definition for the Octet String syntax is: 872 ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' ) 874 This syntax corresponds to the OCTET STRING ASN.1 type from [ASN.1]. 876 4.3.26 OID 878 A value of the OID syntax is an object identifier; a sequence of two 879 or more non-negative integers that uniquely identify some object or 880 item of specification. Many of the object identifiers used in LDAP 881 also have IANA registered names [RFC3383]. 883 The LDAP-specific encoding of a value of this syntax is defined by 884 the rule in [MODELS]. 886 Examples: 887 1.2.3.4 888 cn 890 The LDAP definition for the OID syntax is: 892 ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' ) 894 This syntax corresponds to the OBJECT IDENTIFIER ASN.1 type from 895 [ASN.1]. 897 4.3.27 Other Mailbox 899 A value of the Other Mailbox syntax identifies an electronic mailbox, 900 in a particular named mail system. The LDAP-specific encoding of a 901 value of this syntax is defined by the following ABNF: 903 OtherMailbox = mailbox-type DOLLAR mailbox 904 mailbox-type = PrintableString 905 mailbox = IA5String 907 The rule represents the type of mail system in which 908 the mailbox resides, for example "MCIMail", and is the 909 actual mailbox in the mail system described by . The 910 and rules are defined in Section 4.2. 911 The rule is defined in [MODELS]. 913 The LDAP definition for the Other Mailbox syntax is: 915 ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' ) 917 The ASN.1 type corresponding to the Other Mailbox syntax is defined 918 as follows, assuming EXPLICIT TAGS: 920 OtherMailbox ::= SEQUENCE { 921 mailboxType PrintableString, 922 mailbox IA5String 923 } 925 4.3.28 Postal Address 927 A value of the Postal Address syntax is a sequence of strings of one 928 or more arbitrary UCS characters, which form an address in a physical 929 mail system. 931 The LDAP-specific encoding of a value of this syntax is defined by 932 the following ABNF: 934 PostalAddress = line *( DOLLAR line ) 935 line = 1*line-char 936 line-char = %x00-23 937 / (%x5C "24") ; escaped "$" 938 / %x25-5B 939 / (%x5C "5C") ; escaped "\" 940 / %x5D-7F 941 / UTFMB 943 Each character string (i.e. ) of a postal address value is 944 encoded as a UTF-8 [UTF-8] string except that "\" and "$" characters, 945 if they occur in the string, are escaped by a "\" character followed 946 by the two hexadecimal digit code for the character. The 947 rule is defined in Section 4.2. The and rules are 948 defined in [MODELS]. 950 Many servers limit the postal address to no more than six lines of no 951 more than thirty characters each. 953 Example: 954 1234 Main St.$Anytown, CA 12345$USA 955 \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA 957 The LDAP definition for the Postal Address syntax is: 959 ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' ) 961 This syntax corresponds to the PostalAddress ASN.1 type from [X.520], 962 i.e. 964 PostalAddress ::= SEQUENCE SIZE(1..ub-postal-line) OF 965 DirectoryString { ub-postal-string } 967 The values of ub-postal-line and ub-postal-string (both integers) are 968 implementation defined. Non-normative definitions appear in [X.520]. 970 4.3.29 Printable String 972 A value of the Printable String syntax is a string of latin 973 alphabetic, numeric, and (limited) punctuation characters as 974 specified by the rule in Section 4.2. 976 The LDAP-specific encoding of a value of this syntax is the 977 unconverted string of characters, which conforms to the 978 rule in Section 4.2. 980 Example: 981 This is a PrintableString. 983 The LDAP definition for the PrintableString syntax is: 985 ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' ) 987 This syntax corresponds to the PrintableString ASN.1 type from 988 [ASN.1]. 990 4.3.30 Substring Assertion 992 A value of the Substring Assertion syntax is a sequence of zero, one 993 or more character substrings used as an argument for substring 994 extensible matching of character string attribute values, i.e. as the 995 matchValue of a MatchingRuleAssertion [PROT]. Each substring is a 996 string of one or more arbitrary characters from the Universal 997 Character Set (UCS) [UCS]. A zero length substring is not permitted. 999 The LDAP-specific encoding of a value of this syntax is defined by 1000 the following ABNF: 1002 SubstringAssertion = [ initial ] any [ final ] 1004 initial = substring 1005 any = ASTERISK *(substring ASTERISK) 1006 final = substring 1007 ASTERISK = %x2A ; asterisk ("*") 1009 substring = 1*substring-character 1010 substring-character = %x00-29 1011 / (%x5C "2A") ; escaped "*" 1012 / %x2B-5B 1013 / (%x5C "5C") ; escaped "\" 1014 / %x5D-7F 1015 / UTFMB 1017 Each of a Substring Assertion value is encoded as a UTF-8 1018 [UTF-8] string, except that "\" and "*" characters, if they occur in 1019 the substring, are escaped by a "\" character followed by the two 1020 hexadecimal digit code for the character. 1022 The Substring Assertion syntax is used only as the syntax of 1023 assertion values in the extensible match. It is not used as an 1024 attribute syntax, or in the SubstringFilter [PROT]. 1026 The LDAP definition for the Substring Assertion syntax is: 1028 ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' ) 1030 This syntax corresponds to the SubstringAssertion ASN.1 type from 1031 [X.520]. 1033 4.3.31 Telephone Number 1035 A value of the Telephone Number syntax is a string of printable 1036 characters that complies with the internationally agreed format for 1037 representing international telephone numbers [E.123]. 1039 The LDAP-specific encoding of a value of this syntax is the 1040 unconverted string of characters, which conforms to the 1041 rule in Section 4.2. 1043 Example: +1 512 315 0280 1045 The LDAP definition for the Telephone Number syntax is: 1047 ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' ) 1049 The Telephone Number syntax corresponds to the following ASN.1 type 1050 from [X.520]: 1052 PrintableString (SIZE(1..ub-telephone-number)) 1054 The value of ub-telephone-number (an integer) is implementation 1055 defined. A non-normative definition appears in [X.520]. 1057 4.3.32 Teletex Terminal Identifier 1059 A value of this syntax specifies the identifier and (optionally) 1060 parameters of a teletex terminal. 1062 The LDAP-specific encoding of a value of this syntax is defined by 1063 the following ABNF: 1065 teletex-id = ttx-term *(DOLLAR ttx-param) 1066 ttx-term = PrintableString ; terminal identifier 1067 ttx-param = ttx-key COLON ttx-value ; parameter 1068 ttx-key = "graphic" / "control" / "misc" / "page" / "private" 1069 ttx-value = *ttx-value-char 1071 ttx-value-char = %x00-23 1072 / (%x5C "24") ; escaped "$" 1073 / %x25-5B 1074 / (%x5C "5C") ; escaped "\" 1075 / %x5D-FF 1077 The and rules are defined in Section 4.2. 1078 The rule is defined in [MODELS]. 1080 The LDAP definition for the Teletex Terminal Identifier syntax is: 1082 ( 1.3.6.1.4.1.1466.115.121.1.51 1083 DESC 'Teletex Terminal Identifier' ) 1085 This syntax corresponds to the TeletexTerminalIdentifier ASN.1 type 1086 from [X.520]. 1088 4.3.33 Telex Number 1090 A value of the Telex Number syntax specifies the telex number, 1091 country code and answerback code of a telex terminal. 1093 The LDAP-specific encoding of a value of this syntax is defined by 1094 the following ABNF: 1096 telex-number = actual-number DOLLAR country-code 1097 DOLLAR answerback 1098 actual-number = PrintableString 1099 country-code = PrintableString 1100 answerback = PrintableString 1102 The rule is defined in Section 4.2. The 1103 rule is defined in [MODELS]. 1105 The LDAP definition for the Telex Number syntax is: 1107 ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' ) 1109 This syntax corresponds to the TelexNumber ASN.1 type from [X.520]. 1111 4.3.34 UTC Time 1113 A value of the UTC Time syntax is a character string representing a 1114 date and time to a precision of one minute or one second. The year 1115 is given as a two-digit number. The LDAP-specific encoding of a 1116 value of this syntax follows the format defined in [ASN.1] for the 1117 UTCTime type and is described by the following ABNF: 1119 UTCTime = year month day hour minute [ second ] 1120 [ u-time-zone ] 1121 u-time-zone = %x5A ; "Z" 1122 / u-differential 1123 u-differential = ( MINUS / PLUS ) hour minute 1125 The , , , , , and 1126 rules are defined in Section 4.3.13. The rule is defined in 1127 [MODELS]. 1129 The time value represents coordinated universal time if the "Z" form 1130 of is used, otherwise the value represents a local 1131 time. In the latter case, if is provided then 1132 coordinated universal time can be calculated by subtracting the 1133 differential from the local time. The SHOULD be 1134 present in time values and the "Z" form of SHOULD be 1135 used in preference to . 1137 The LDAP definition for the UTC Time syntax is: 1139 ( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' ) 1141 Note: This syntax is deprecated in favor of the Generalized Time 1142 syntax. 1144 The UTC Time syntax corresponds to the UTCTime ASN.1 type from 1145 [ASN.1]. 1147 5. Matching Rules 1149 Matching rules are used by directory implementations to compare 1150 attribute values against assertion values when performing Search and 1151 Compare operations [PROT]. They are also used when comparing a 1152 purported distinguished name [MODELS] with the name of an entry. 1153 When modifying entries, matching rules are used to identify values to 1154 be deleted and to prevent an attribute from containing two equal 1155 values. 1157 Matching rules that are required for directory operation, or that are 1158 in common use, are specified in this section. 1160 5.1 General Considerations 1162 A matching rule is applied to attribute values through an 1163 AttributeValueAssertion or MatchingRuleAssertion [PROT]. The 1164 conditions under which an AttributeValueAssertion or 1165 MatchingRuleAssertion evaluates to Undefined are specified in [PROT]. 1166 If an assertion is not Undefined then the result of the assertion is 1167 the result of applying the selected matching rule. A matching rule 1168 evaluates to TRUE, and in some cases Undefined, as specified in the 1169 description of the matching rule, otherwise it evaluates to FALSE. 1171 Each assertion contains an assertion value. The definition of each 1172 matching rule specifies the syntax for the assertion value. The 1173 syntax of the assertion value is typically, but not necessarily, the 1174 same as the syntax of the attribute values to which the matching rule 1175 may be applied. Note that the AssertionValue in a SubstringFilter 1176 [PROT] MUST conform to the assertion syntax of the equality matching 1177 rule for the attribute type rather than the assertion syntax of the 1178 substrings matching rule for the attribute type. The entire 1179 SubstringFilter is converted into an assertion value of the 1180 substrings matching rule prior to applying the rule. 1182 The definition of each matching rule indicates the attribute syntaxes 1183 to which the rule may be applied, by specifying conditions the 1184 corresponding ASN.1 type of a candidate attribute syntax must 1185 satisfy. These conditions are also satisfied if the corresponding 1186 ASN.1 type is a tagged or constrained derivative of the ASN.1 type 1187 explicitly mentioned in the rule description (i.e. ASN.1 tags and 1188 constraints are ignored in checking applicability), or an alternative 1189 reference notation for the explicitly mentioned type. Each rule 1190 description lists as examples of applicable attribute syntaxes, the 1191 complete list of the syntaxes defined in this document to which the 1192 matching rule applies. A matching rule may be applicable to 1193 additional syntaxes defined in other documents if those syntaxes 1194 satisfy the conditions on the corresponding ASN.1 type. 1196 The description of each matching rule indicates whether the rule is 1197 suitable for use as the equality matching rule (EQUALITY), ordering 1198 matching rule (ORDERING) or substrings matching rule (SUBSTR) in an 1199 attribute type definition [MODELS]. 1201 Each matching rule is uniquely identified with an object identifier. 1202 The definition of a matching rule should not be subsequently changed. 1203 If a change is desirable then a new matching rule with a different 1204 object identifier should be defined instead. 1206 Servers SHOULD implement all the matching rules in Section 5.2. 1207 Servers MAY implement additional matching rules. 1209 Servers which implement the extensibleMatch filter SHOULD allow the 1210 matching rules listed in Section 5.2 to be used in the 1211 extensibleMatch filter and SHOULD allow matching rules to be used 1212 with all attribute types known to the server, where the assertion 1213 syntax of the matching rule is the same as the value syntax of the 1214 attribute. 1216 Servers MUST publish in the matchingRules attribute, the definitions 1217 of matching rules referenced by values of the attributeTypes and 1218 matchingRuleUse attributes in the same subschema entry. Other 1219 unreferenced matching rules MAY be published in the matchingRules 1220 attribute. 1222 If the server supports the extensibleMatch filter, then the server 1223 MAY use the matchingRuleUse attribute to indicate the applicability 1224 (in an extensibleMatch filter) of selected matching rules to 1225 nominated attribute types. 1227 5.2 Matching Rule Definitions 1229 When evaluating the numericStringMatch, numericStringSubstringsMatch, 1230 caseExactIA5Match, caseIgnoreIA5Match, caseIgnoreIA5SubstringsMatch, 1231 caseIgnoreListMatch, caseIgnoreListSubstringsMatch, caseIgnoreMatch, 1232 caseIgnoreOrderingMatch and caseIgnoreSubstringsMatch matching rules 1233 the assertion value and attribute value are prepared according to the 1234 string preparation algorithms [PREP] for LDAP before being compared. 1235 The Transcode, Normalize, Prohibit and Check bidi steps are the same 1236 for each of the matching rules. However, the Map and Insignificant 1237 Character Removal steps depends on the specific rule, as detailed in 1238 the description of these matching rules in the sections that follow. 1240 5.2.1 bitStringMatch 1242 The bitStringMatch rule compares an assertion value of the Bit String 1243 syntax to an attribute value of a syntax (e.g. the Bit String syntax) 1244 whose corresponding ASN.1 type is BIT STRING. 1246 If the corresponding ASN.1 type of the attribute syntax does not have 1247 a named bit list (which is the case for the Bit String syntax) then 1248 the rule evaluates to TRUE if and only if the attribute value has the 1249 same number of bits as the assertion value and the bits match on a 1250 bitwise basis. 1252 If the corresponding ASN.1 type does have a named bit list then 1253 bitStringMatch operates as above except that trailing zero bits in 1254 the attribute and assertion values are treated as absent. 1256 The LDAP definition for the bitStringMatch rule is: 1258 ( 2.5.13.16 NAME 'bitStringMatch' 1259 SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 ) 1261 The bitStringMatch rule is an equality matching rule. 1263 5.2.2 caseExactIA5Match 1265 The caseExactIA5Match rule compares an assertion value of the IA5 1266 String syntax to an attribute value of a syntax (e.g the IA5 String 1267 syntax) whose corresponding ASN.1 type is IA5String. 1269 The rule evaluates to TRUE if and only if the prepared attribute 1270 value character string and the prepared assertion value character 1271 string have the same number of characters and corresponding 1272 characters have the same code point. 1274 In preparing the attribute value and assertion value for comparison, 1275 characters are not case folded in the Map preparation step, and only 1276 Insignificant Space Removal is applied in the Insignificant Character 1277 Removal step. 1279 The LDAP definition for the caseExactIA5Match rule is: 1281 ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' 1282 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 1284 The caseExactIA5Match rule is an equality matching rule. 1286 5.2.3 caseIgnoreIA5Match 1288 The caseIgnoreIA5Match rule compares an assertion value of the IA5 1289 String syntax to an attribute value of a syntax (e.g the IA5 String 1290 syntax) whose corresponding ASN.1 type is IA5String. 1292 The rule evaluates to TRUE if and only if the prepared attribute 1293 value character string and the prepared assertion value character 1294 string have the same number of characters and corresponding 1295 characters have the same code point. 1297 In preparing the attribute value and assertion value for comparison, 1298 characters are case folded in the Map preparation step, and only 1299 Insignificant Space Removal is applied in the Insignificant Character 1300 Removal step. 1302 The LDAP definition for the caseIgnoreIA5Match rule is: 1304 ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' 1305 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 1307 The caseIgnoreIA5Match rule is an equality matching rule. 1309 5.2.4 caseIgnoreIA5SubstringsMatch 1311 The caseIgnoreIA5SubstringsMatch rule compares an assertion value of 1312 the Substring Assertion syntax to an attribute value of a syntax (e.g 1313 the IA5 String syntax) whose corresponding ASN.1 type is IA5String. 1315 The rule evaluates to TRUE if and only if the prepared substrings of 1316 the assertion value match disjoint portions of the prepared attribute 1317 value character string in the order of the substrings in the 1318 assertion value, and an substring, if present, matches the 1319 beginning of the prepared attribute value character string, and a 1320 substring, if present, matches the end of the prepared 1321 attribute value character string. A prepared substring matches a 1322 portion of the prepared attribute value character string if 1323 corresponding characters have the same code point. 1325 In preparing the attribute value and assertion value substrings for 1326 comparison, characters are case folded in the Map preparation step, 1327 and only Insignificant Space Removal is applied in the Insignificant 1328 Character Removal step. 1330 ( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch' 1331 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 1333 The caseIgnoreIA5SubstringsMatch rule is a substrings matching rule. 1335 5.2.5 caseIgnoreListMatch 1337 The caseIgnoreListMatch rule compares an assertion value that is a 1338 sequence of strings to an attribute value of a syntax (e.g. the 1339 Postal Address syntax) whose corresponding ASN.1 type is a SEQUENCE 1340 OF the DirectoryString ASN.1 type. 1342 The rule evaluates to TRUE if and only if the attribute value and the 1343 assertion value have the same number of strings and corresponding 1344 strings (by position) match according to the caseIgnoreMatch matching 1345 rule. 1347 In [X.520] the assertion syntax for this matching rule is defined to 1348 be: 1350 SEQUENCE OF DirectoryString {ub-match} 1352 i.e. different from the corresponding type for the Postal Address 1353 syntax. The choice of the Postal Address syntax for the assertion 1354 syntax of the caseIgnoreListMatch in LDAP should not be seen as 1355 limiting the matching rule to only apply to attributes with the 1356 Postal Address syntax. 1358 The LDAP definition for the caseIgnoreListMatch rule is: 1360 ( 2.5.13.11 NAME 'caseIgnoreListMatch' 1361 SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) 1363 The caseIgnoreListMatch rule is an equality matching rule. 1365 5.2.6 caseIgnoreListSubstringsMatch 1367 The caseIgnoreListSubstringsMatch rule compares an assertion value of 1368 the Substring Assertion syntax to an attribute value of a syntax 1369 (e.g. the Postal Address syntax) whose corresponding ASN.1 type is a 1370 SEQUENCE OF the DirectoryString ASN.1 type. 1372 The rule evaluates to TRUE if and only if the assertion value 1373 matches, per the caseIgnoreSubstringsMatch rule, the character string 1374 formed by concatenating the strings of the attribute value, except 1375 that none of the , , or substrings of the 1376 assertion value are considered to match a substring of the 1377 concatenated string which spans more than one of the original strings 1378 of the attribute value. 1380 Note that, in terms of the LDAP-specific encoding of the Postal 1381 Address syntax, the concatenated string omits the line 1382 separator and the escaping of "\" and "$" characters. 1384 The LDAP definition for the caseIgnoreListSubstringsMatch rule is: 1386 ( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch' 1387 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 1389 The caseIgnoreListSubstringsMatch rule is a substrings matching rule. 1391 5.2.7 caseIgnoreMatch 1393 The caseIgnoreMatch rule compares an assertion value of the Directory 1394 String syntax to an attribute value of a syntax (e.g. the Directory 1395 String, Printable String, Country String or Telephone Number syntax) 1396 whose corresponding ASN.1 type is DirectoryString or one of the 1397 alternative string types of DirectoryString, e.g. PrintableString 1398 (the other alternatives do not correspond to any syntax defined in 1399 this document). 1401 The rule evaluates to TRUE if and only if the prepared attribute 1402 value character string and the prepared assertion value character 1403 string have the same number of characters and corresponding 1404 characters have the same code point. 1406 In preparing the attribute value and assertion value for comparison, 1407 characters are case folded in the Map preparation step, and only 1408 Insignificant Space Removal is applied in the Insignificant Character 1409 Removal step. 1411 The LDAP definition for the caseIgnoreMatch rule is: 1413 ( 2.5.13.2 NAME 'caseIgnoreMatch' 1414 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 1416 The caseIgnoreMatch rule is an equality matching rule. 1418 5.2.8 caseIgnoreOrderingMatch 1420 The caseIgnoreOrderingMatch rule compares an assertion value of the 1421 Directory String syntax to an attribute value of a syntax (e.g. the 1422 Directory String, Printable String, Country String or Telephone 1423 Number syntax) whose corresponding ASN.1 type is DirectoryString or 1424 one of its alternative string types. 1426 The rule evaluates to TRUE if, and only if, in the code point 1427 collation order, the prepared attribute value character string 1428 appears earlier than the prepared assertion value character string, 1429 i.e. the attribute value is "less than" the assertion value. 1431 In preparing the attribute value and assertion value for comparison, 1432 characters are case folded in the Map preparation step, and only 1433 Insignificant Space Removal is applied in the Insignificant Character 1434 Removal step. 1436 The LDAP definition for the caseIgnoreOrderingMatch rule is: 1438 ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch' 1439 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 1441 The caseIgnoreOrderingMatch rule is an ordering matching rule. 1443 5.2.9 caseIgnoreSubstringsMatch 1445 The caseIgnoreSubstringsMatch rule compares an assertion value of the 1446 Substring Assertion syntax to an attribute value of a syntax (e.g. 1447 the Directory String, Printable String, Country String or Telephone 1448 Number syntax) whose corresponding ASN.1 type is DirectoryString or 1449 one of its alternative string types. 1451 The rule evaluates to TRUE if and only if the prepared substrings of 1452 the assertion value match disjoint portions of the prepared attribute 1453 value character string in the order of the substrings in the 1454 assertion value, and an substring, if present, matches the 1455 beginning of the prepared attribute value character string, and a 1456 substring, if present, matches the end of the prepared 1457 attribute value character string. A prepared substring matches a 1458 portion of the prepared attribute value character string if 1459 corresponding characters have the same code point. 1461 In preparing the attribute value and assertion value substrings for 1462 comparison, characters are case folded in the Map preparation step, 1463 and only Insignificant Space Removal is applied in the Insignificant 1464 Character Removal step. 1466 The LDAP definition for the caseIgnoreSubstringsMatch rule is: 1468 ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' 1469 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 1471 The caseIgnoreSubstringsMatch rule is a substrings matching rule. 1473 5.2.10 distinguishedNameMatch 1475 The distinguishedNameMatch rule compares an assertion value of the DN 1476 syntax to an attribute value of a syntax (e.g. the DN syntax) whose 1477 corresponding ASN.1 type is DistinguishedName. 1479 The rule evaluates to TRUE if and only if the attribute value and the 1480 assertion value have the same number of RDNs and corresponding RDNs 1481 (by position) are the same. An RDN of the assertion value is the 1482 same as an RDN of the attribute value if and only if they have the 1483 same number of attribute value assertions (AVAs) and each AVA of the 1484 first RDN is the same as the AVA of the second RDN with the same 1485 attribute type. The order of the AVAs is not significant. Also note 1486 that a particular attribute type may appear in at most one AVA in an 1487 RDN. Two AVAs with the same attribute type are the same if their 1488 values are equal according to the equality matching rule of the 1489 attribute type. If one or more of the AVA comparisons evaluate to 1490 Undefined and the remaining AVA comparisons return TRUE then the 1491 distinguishedNameMatch rule evaluates to Undefined. 1493 The LDAP definition for the distinguishedNameMatch rule is: 1495 ( 2.5.13.1 NAME 'distinguishedNameMatch' 1496 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) 1498 The distinguishedNameMatch rule is an equality matching rule. 1500 5.2.11 generalizedTimeMatch 1502 The generalizedTimeMatch rule compares an assertion value of the 1503 Generalized Time syntax to an attribute value of a syntax (e.g the 1504 Generalized Time syntax) whose corresponding ASN.1 type is 1505 GeneralizedTime. 1507 The rule evaluates to TRUE if and only if the attribute value 1508 represents the same universal coordinated time as the assertion 1509 value. If a time is specified with the minutes or seconds absent 1510 then the number of minutes or seconds (respectively) is assumed to be 1511 zero. 1513 The LDAP definition for the generalizedTimeMatch rule is: 1515 ( 2.5.13.27 NAME 'generalizedTimeMatch' 1516 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) 1518 The generalizedTimeMatch rule is an equality matching rule. 1520 5.2.12 generalizedTimeOrderingMatch 1522 The generalizedTimeMatch rule compares the time ordering of an 1523 assertion value of the Generalized Time syntax to an attribute value 1524 of a syntax (e.g the Generalized Time syntax) whose corresponding 1525 ASN.1 type is GeneralizedTime. 1527 The rule evaluates to TRUE if and only if the attribute value 1528 represents a universal coordinated time which is earlier than the 1529 universal coordinated time represented by the assertion value. 1531 The LDAP definition for the generalizedTimeOrderingMatch rule is: 1533 ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch' 1534 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) 1536 The generalizedTimeOrderingMatch rule is an ordering matching rule. 1538 5.2.13 integerFirstComponentMatch 1540 The integerFirstComponentMatch rule compares an assertion value of 1541 the Integer syntax to an attribute value of a syntax (e.g the DIT 1542 Structure Rule Description syntax) whose corresponding ASN.1 type is 1543 a SEQUENCE with a mandatory first component of the INTEGER ASN.1 1544 type. 1546 Note that the assertion syntax of this matching rule differs from the 1547 attribute syntax of attributes for which this is the equality 1548 matching rule. 1550 The rule evaluates to TRUE if and only if the assertion value and the 1551 first component of the attribute value are the same integer value. 1553 The LDAP definition for the integerFirstComponentMatch matching rule 1554 is: 1556 ( 2.5.13.29 NAME 'integerFirstComponentMatch' 1557 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) 1559 The integerFirstComponentMatch rule is an equality matching rule. 1560 When using integerFirstComponentMatch to compare two attribute values 1561 (of an applicable syntax), an assertion value must first be derived 1562 from one of the attribute values. An assertion value can be derived 1563 from an attribute value by taking the first component of that 1564 attribute value. 1566 5.2.14 integerMatch 1568 The integerMatch rule compares an assertion value of the Integer 1569 syntax to an attribute value of a syntax (e.g the Integer syntax) 1570 whose corresponding ASN.1 type is INTEGER. 1572 The rule evaluates to TRUE if and only if the attribute value and the 1573 assertion value are the same integer value. 1575 The LDAP definition for the integerMatch matching rule is: 1577 ( 2.5.13.14 NAME 'integerMatch' 1578 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) 1580 The integerMatch rule is an equality matching rule. 1582 5.2.15 numericStringMatch 1584 The numericStringMatch rule compares an assertion value of the 1585 Numeric String syntax to an attribute value of a syntax (e.g the 1586 Numeric String syntax) whose corresponding ASN.1 type is 1587 NumericString. 1589 The rule evaluates to TRUE if and only if the prepared attribute 1590 value character string and the prepared assertion value character 1591 string have the same number of characters and corresponding 1592 characters have the same code point. 1594 In preparing the attribute value and assertion value for comparison, 1595 characters are not case folded in the Map preparation step, and only 1596 numericString Insignificant Character Removal is applied in the 1597 Insignificant Character Removal step. 1599 The LDAP definition for the numericStringMatch matching rule is: 1601 ( 2.5.13.8 NAME 'numericStringMatch' 1602 SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) 1604 The numericStringMatch rule is an equality matching rule. 1606 5.2.16 numericStringSubstringsMatch 1608 The numericStringSubstringsMatch rule compares an assertion value of 1609 the Substring Assertion syntax to an attribute value of a syntax (e.g 1610 the Numeric String syntax) whose corresponding ASN.1 type is 1611 NumericString. 1613 The rule evaluates to TRUE if and only if the prepared substrings of 1614 the assertion value match disjoint portions of the prepared attribute 1615 value character string in the order of the substrings in the 1616 assertion value, and an substring, if present, matches the 1617 beginning of the prepared attribute value character string, and a 1618 substring, if present, matches the end of the prepared 1619 attribute value character string. A prepared substring matches a 1620 portion of the prepared attribute value character string if 1621 corresponding characters have the same code point. 1623 In preparing the attribute value and assertion value for comparison, 1624 characters are not case folded in the Map preparation step, and only 1625 numericString Insignificant Character Removal is applied in the 1626 Insignificant Character Removal step. 1628 ( 2.5.13.10 NAME 'numericStringSubstringsMatch' 1629 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 1631 The numericStringSubstringsMatch rule is a substrings matching rule. 1633 5.2.17 objectIdentifierFirstComponentMatch 1635 The objectIdentifierFirstComponentMatch rule compares an assertion 1636 value of the OID syntax to an attribute value of a syntax (e.g the 1637 Attribute Type Description, DIT Content Rule Description, LDAP Syntax 1638 Description, Matching Rule Description, Matching Rule Use 1639 Description, Name Form Description or Object Class Description 1640 syntax) whose corresponding ASN.1 type is a SEQUENCE with a mandatory 1641 first component of the OBJECT IDENTIFIER ASN.1 type. 1643 Note that the assertion syntax of this matching rule differs from the 1644 attribute syntax of attributes for which this is the equality 1645 matching rule. 1647 The rule evaluates to TRUE if and only if the assertion value matches 1648 the first component of the attribute value using the rules of 1649 objectIdentifierMatch. 1651 The LDAP definition for the objectIdentifierFirstComponentMatch 1652 matching rule is: 1654 ( 2.5.13.31 NAME 'objectIdentifierFirstComponentMatch' 1655 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) 1657 The objectIdentifierFirstComponentMatch rule is an equality matching 1658 rule. When using objectIdentifierFirstComponentMatch to compare two 1659 attribute values (of an applicable syntax), an assertion value must 1660 first be derived from one of the attribute values. An assertion 1661 value can be derived from an attribute value by taking the first 1662 component of that attribute value. 1664 5.2.18 objectIdentifierMatch 1666 The objectIdentifierMatch rule compares an assertion value of the OID 1667 syntax to an attribute value of a syntax (e.g the OID syntax) whose 1668 corresponding ASN.1 type is OBJECT IDENTIFIER. 1670 The rule evaluates to TRUE if and only if the assertion value and the 1671 attribute value represent the same object identifier, that is, the 1672 same sequence of integers, whether represented explicitly in the 1673 form of or implicitly in the form (see 1674 [MODELS]). 1676 If an LDAP client supplies an assertion value in the form, 1677 and the chosen descriptor is not recognized by the server, then the 1678 objectIdentifierMatch rule evaluates to Undefined. 1680 The LDAP definition for the objectIdentifierMatch matching rule is: 1682 ( 2.5.13.0 NAME 'objectIdentifierMatch' 1683 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) 1685 The objectIdentifierMatch rule is an equality matching rule. 1687 5.2.19 octetStringMatch 1689 The octetStringMatch rule compares an assertion value of the Octet 1690 String syntax to an attribute value of a syntax (e.g the Octet String 1691 or JPEG syntax) whose corresponding ASN.1 type is the OCTET STRING 1692 ASN.1 type. 1694 The rule evaluates to TRUE if and only if the attribute value and the 1695 assertion value are the same length and corresponding octets (by 1696 position) are the same. 1698 The LDAP definition for the octetStringMatch matching rule is: 1700 ( 2.5.13.17 NAME 'octetStringMatch' 1701 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) 1703 The octetStringMatch rule is an equality matching rule. 1705 5.2.20 telephoneNumberMatch 1707 The telephoneNumberMatch rule compares an assertion value of the 1708 Telephone Number syntax to an attribute value of a syntax (e.g the 1709 Telephone Number syntax) whose corresponding ASN.1 type is a 1710 PrintableString representing a telephone number. 1712 The rule evaluates to TRUE if and only if the prepared attribute 1713 value character string and the prepared assertion value character 1714 string have the same number of characters and corresponding 1715 characters have the same code point. 1717 In preparing the attribute value and assertion value for comparison, 1718 characters are case folded in the Map preparation step, and only 1719 telephoneNumber Insignificant Character Removal is applied in the 1720 Insignificant Character Removal step. 1722 The LDAP definition for the telephoneNumberMatch matching rule is: 1724 ( 2.5.13.20 NAME 'telephoneNumberMatch' 1725 SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) 1727 The telephoneNumberMatch rule is an equality matching rule. 1729 5.2.21 telephoneNumberSubstringsMatch 1730 The telephoneNumberSubstringsMatch rule compares an assertion value 1731 of the Substring Assertion syntax to an attribute value of a syntax 1732 (e.g the Telephone Number syntax) whose corresponding ASN.1 type is a 1733 PrintableString representing a telephone number. 1735 The rule evaluates to TRUE if and only if the prepared substrings of 1736 the assertion value match disjoint portions of the prepared attribute 1737 value character string in the order of the substrings in the 1738 assertion value, and an substring, if present, matches the 1739 beginning of the prepared attribute value character string, and a 1740 substring, if present, matches the end of the prepared 1741 attribute value character string. A prepared substring matches a 1742 portion of the prepared attribute value character string if 1743 corresponding characters have the same code point. 1745 In preparing the attribute value and assertion value substrings for 1746 comparison, characters are case folded in the Map preparation step, 1747 and only telephoneNumber Insignificant Character Removal is applied 1748 in the Insignificant Character Removal step. 1750 The LDAP definition for the telephoneNumberSubstringsMatch matching 1751 rule is: 1753 ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch' 1754 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 1756 The telephoneNumberSubstringsMatch rule is a substrings matching 1757 rule. 1759 5.2.22 uniqueMemberMatch 1761 The uniqueMemberMatch rule compares an assertion value of the Name 1762 And Optional UID syntax to an attribute value of a syntax (e.g the 1763 Name And Optional UID syntax) whose corresponding ASN.1 type is 1764 NameAndOptionalUID. 1766 The rule evaluates to TRUE if and only if the 1767 components of the assertion value and attribute value match according 1768 to the distinguishedNameMatch rule and the component is 1769 absent from the attribute value or matches the component 1770 of the assertion value according to the bitStringMatch rule. 1772 The LDAP definition for the uniqueMemberMatch matching rule is: 1774 ( 2.5.13.23 NAME 'uniqueMemberMatch' 1775 SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 ) 1777 The uniqueMemberMatch rule is an equality matching rule. 1779 6. Security Considerations 1781 In general, the LDAP-specific encodings for syntaxes defined in this 1782 document do not define canonical encodings. That is, a 1783 transformation from an LDAP-specific encoding into some other 1784 encoding (e.g. BER) and back into the LDAP-specific encoding will not 1785 necessarily reproduce exactly the original octets of the 1786 LDAP-specific encoding. Therefore an LDAP-specific encoding should 1787 not be used where a canonical encoding is required. 1789 Furthermore, the LDAP-specific encodings do not necessarily enable an 1790 alternative encoding of values of the Directory String and DN 1791 syntaxes to be reconstructed, e.g. a transformation from DER to 1792 LDAP-specific encoding and back to DER may not reproduce the original 1793 DER encoding. Therefore LDAP-specific encodings should not be used 1794 where reversibility to DER is needed, e.g. for the verification of 1795 digital signatures. Instead, DER or a DER-reversible encoding should 1796 be used. 1798 When interpreting security-sensitive fields, and in particular fields 1799 used to grant or deny access, implementations MUST ensure that any 1800 matching rule comparisons are done on the underlying abstract value, 1801 regardless of the particular encoding used. 1803 7. Acknowledgements 1805 This document is an revision of RFC 2252 by M. Wahl, A. Coulbeck, T. 1806 Howes, and S. Kille. RFC 2252 was a product of the IETF ASID Working 1807 Group. 1809 This document is based upon input of the IETF LDAPBIS working group. 1810 The authors wish to thank J. Sermersheim and K. Zeilenga for their 1811 significant contribution to this revision. 1813 8. IANA Considerations 1815 The Internet Assigned Numbers Authority (IANA) is requested to update 1816 the LDAP descriptors registry as indicated by the following 1817 templates: 1819 Subject: Request for LDAP Descriptor Registration Update 1820 Descriptor (short name): see comment 1821 Object Identifier: see comment 1822 Person & email address to contact for further information: 1823 Steven Legg 1824 Usage: see comment 1825 Specification: RFC XXXX 1826 Author/Change Controller: IESG 1827 Comments: 1829 The following descriptors (short names) should be updated to refer 1830 to RFC XXXX. 1832 NAME Type OID 1833 ------------------------------------------------------------------ 1834 bitStringMatch M 2.5.13.16 1835 caseExactIA5Match M 1.3.6.1.4.1.1466.109.114.1 1836 caseIgnoreIA5Match M 1.3.6.1.4.1.1466.109.114.2 1837 caseIgnoreListMatch M 2.5.13.11 1838 caseIgnoreMatch M 2.5.13.2 1839 caseIgnoreOrderingMatch M 2.5.13.3 1840 caseIgnoreSubstringsMatch M 2.5.13.4 1841 distinguishedNameMatch M 2.5.13.1 1842 generalizedTimeMatch M 2.5.13.27 1843 generalizedTimeOrderingMatch M 2.5.13.28 1844 integerFirstComponentMatch M 2.5.13.29 1845 integerMatch M 2.5.13.14 1846 numericStringMatch M 2.5.13.8 1847 numericStringSubstringsMatch M 2.5.13.10 1848 objectIdentifierFirstComponentMatch M 2.5.13.31 1849 octetStringMatch M 2.5.13.17 1850 telephoneNumberMatch M 2.5.13.20 1851 telephoneNumberSubstringsMatch M 2.5.13.21 1852 uniqueMemberMatch M 2.5.13.23 1854 The descriptor for the object identifier 2.5.13.0 was incorrectly 1855 registered as objectIdentifiersMatch (extraneous `s') in RFC 3383. 1856 It should be changed to the following with a reference to RFC 1857 XXXX. 1859 NAME Type OID 1860 ------------------------------------------------------------------ 1861 objectIdentifierMatch M 2.5.13.0 1863 Subject: Request for LDAP Descriptor Registration 1864 Descriptor (short name): caseIgnoreIA5SubstringsMatch 1865 Object Identifier: 1.3.6.1.4.1.1466.109.114.3 1866 Person & email address to contact for further information: 1867 Steven Legg 1868 Usage: other (M) 1869 Specification: RFC XXXX 1870 Author/Change Controller: IESG 1872 Subject: Request for LDAP Descriptor Registration 1873 Descriptor (short name): caseIgnoreListSubstringsMatch 1874 Object Identifier: 2.5.13.12 1875 Person & email address to contact for further information: 1876 Steven Legg 1877 Usage: other (M) 1878 Specification: RFC XXXX 1879 Author/Change Controller: IESG 1881 9. Normative References 1883 [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate 1884 Requirement Levels", BCP 14, RFC 2119, March 1997. 1886 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1887 Specifications: ABNF", RFC 2234, November 1997. 1889 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 1890 10646", RFC 2279, January 1998. 1892 [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64, RFC 1893 3383, September 2002. 1895 [LDAPDN] Zeilenga, K., "LDAP: String Representation of 1896 Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work 1897 in progress, May 2003. 1899 [PROT] Sermersheim, J., "LDAP: The Protocol", draft-ietf-ldapbis- 1900 protocol-xx.txt, a work in progress, March 2003. 1902 [E.123] Notation for national and international telephone numbers, 1903 ITU-T Recommendation E.123, 1988. 1905 [FAX] Standardization of Group 3 facsimile apparatus for 1906 document transmission - Terminal Equipment and Protocols 1907 for Telematic Services, ITU-T Recommendation T.4, 1993 1909 [T.50] International Reference Alphabet (IRA) (Formerly 1910 International Alphabet No. 5 or IA5) Information 1911 Technology - 7-Bit Coded Character Set for Information 1912 Interchange, ITU-T Recommendation T.50, 1992 1914 [X.420] ITU-T Recommendation X.420 (1996) | ISO/IEC 10021-7:1997, 1915 Information Technology - Message Handling Systems (MHS): 1916 Interpersonal messaging system 1918 [X.501] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994, 1919 Information Technology - Open Systems Interconnection - 1920 The Directory: Models 1922 [X.520] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994, 1923 Information Technology - Open Systems Interconnection - 1924 The Directory: Selected attribute types 1926 [ASN.1] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1 1927 Information technology - Abstract Syntax Notation One 1928 (ASN.1): Specification of basic notation 1930 [ISO3166] ISO 3166, "Codes for the representation of names of 1931 countries". 1933 [UCS] Universal Multiple-Octet Coded Character Set (UCS) - 1934 Architecture and Basic Multilingual Plane, ISO/IEC 1935 10646-1: 1993 (with amendments). 1937 [JPEG] JPEG File Interchange Format (Version 1.02). Eric 1938 Hamilton, C-Cube Microsystems, Milpitas, CA, September 1, 1939 1992. 1941 [MODELS] Zeilenga, K., "LDAP: Directory Information Models", draft- 1942 ietf-ldapbis-models-xx.txt, a work in progress, March 1943 2003. 1945 [PREP] Zeilenga, K., "LDAP: Internationalized String 1946 Preparation", draft-ietf-ldapbis-strprep-xx.txt, a work in 1947 progress, May 2003. 1949 10. Informative References 1951 [BCP11] Hovey, R. and S. Bradner, "The Organizations Involved in 1952 the IETF Standards Process", BCP 11, RFC 2028, October 1953 1996. 1955 [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, 1956 "Lightweight Directory Access Protocol (v3): Attribute 1957 Syntax Definitions", RFC 2252, December 1997. 1959 [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use 1960 with LDAPv3", RFC 2256, December 1997. 1962 [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access 1963 Protocol (v3): Technical Specification", RFC 3377, 1964 September 2002. 1966 [X.500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994, 1967 Information Technology - Open Systems Interconnection - 1968 The Directory: Overview of concepts, models and services 1970 [BER] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998 1971 Information Technology - ASN.1 encoding rules: 1972 Specification of Basic Encoding Rules (BER), Canonical 1973 Encoding Rules (CER) and Distinguished Encoding Rules 1974 (DER) 1976 11. Authors' Addresses 1978 Steven Legg 1979 Adacel Technologies Ltd. 1980 250 Bay Street 1981 Brighton, Victoria 3186 1982 AUSTRALIA 1984 Phone: +61 3 8530 7710 1985 Fax: +61 3 8530 7888 1986 Email: steven.legg@adacel.com.au 1988 Kathy Dally 1989 The MITRE Corp. 1990 7515 Colshire Dr., ms-W650 1991 McLean VA 22102 1992 USA 1994 Phone: +1 703 883 6058 1995 Fax: +1 703 883 7142 1996 Email: kdally@mitre.org 1998 12. Intellectual Property Notice 2000 The IETF takes no position regarding the validity or scope of any 2001 intellectual property or other rights that might be claimed to 2002 pertain to the implementation or use of the technology described in 2003 this document or the extent to which any license under such rights 2004 might or might not be available; neither does it represent that it 2005 has made any effort to identify any such rights. Information on the 2006 IETF's procedures with respect to rights in standards-track and 2007 standards-related documentation can be found in BCP-11. [BCP11] 2008 Copies of claims of rights made available for publication and any 2009 assurances of licenses to be made available, or the result of an 2010 attempt made to obtain a general license or permission for the use of 2011 such proprietary rights by implementors or users of this 2012 specification can be obtained from the IETF Secretariat. 2014 The IETF invites any interested party to bring to its attention any 2015 copyrights, patents or patent applications, or other proprietary 2016 rights which may cover technology that may be required to practice 2017 this standard. Please address the information to the IETF Executive 2018 Director. 2020 13. Copyright Notice 2022 Copyright (C) The Internet Society (2003). All Rights Reserved. 2024 This document and translations of it may be copied and furnished to 2025 others, and derivative works that comment on or otherwise explain it 2026 or assist in its implementation may be prepared, copied, published 2027 and distributed, in whole or in part, without restriction of any 2028 kind, provided that the above copyright notice and this paragraph are 2029 included on all such copies and derivative works. However, this 2030 document itself may not be modified in any way, such as by removing 2031 the copyright notice or references to the Internet Society or other 2032 Internet organizations, except as needed for the purpose of 2033 developing Internet standards in which case the procedures for 2034 copyrights defined in the Internet Standards process must be 2035 followed, or as required to translate it into languages other than 2036 English. 2038 The limited permissions granted above are perpetual and will not be 2039 revoked by the Internet Society or its successors or assigns. 2041 This document and the information contained herein is provided on an 2042 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2043 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2044 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2045 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2046 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2048 Appendix A. Summary of Syntax Object Identifiers 2050 The following list summarizes the object identifiers assigned to the 2051 syntaxes defined in this document. 2053 Syntax OBJECT IDENTIFIER 2054 ============================================================== 2055 Attribute Type Description 1.3.6.1.4.1.1466.115.121.1.3 2056 Bit String 1.3.6.1.4.1.1466.115.121.1.6 2057 Boolean 1.3.6.1.4.1.1466.115.121.1.7 2058 Country String 1.3.6.1.4.1.1466.115.121.1.11 2059 Delivery Method 1.3.6.1.4.1.1466.115.121.1.14 2060 Directory String 1.3.6.1.4.1.1466.115.121.1.15 2061 DIT Content Rule Description 1.3.6.1.4.1.1466.115.121.1.16 2062 DIT Structure Rule Description 1.3.6.1.4.1.1466.115.121.1.17 2063 DN 1.3.6.1.4.1.1466.115.121.1.12 2064 Enhanced Guide 1.3.6.1.4.1.1466.115.121.1.21 2065 Facsimile Telephone Number 1.3.6.1.4.1.1466.115.121.1.22 2066 Fax 1.3.6.1.4.1.1466.115.121.1.23 2067 Generalized Time 1.3.6.1.4.1.1466.115.121.1.24 2068 Guide 1.3.6.1.4.1.1466.115.121.1.25 2069 IA5 String 1.3.6.1.4.1.1466.115.121.1.26 2070 Integer 1.3.6.1.4.1.1466.115.121.1.27 2071 JPEG 1.3.6.1.4.1.1466.115.121.1.28 2072 LDAP Syntax Description 1.3.6.1.4.1.1466.115.121.1.54 2073 Matching Rule Description 1.3.6.1.4.1.1466.115.121.1.30 2074 Matching Rule Use Description 1.3.6.1.4.1.1466.115.121.1.31 2075 Name And Optional UID 1.3.6.1.4.1.1466.115.121.1.34 2076 Name Form Description 1.3.6.1.4.1.1466.115.121.1.35 2077 Numeric String 1.3.6.1.4.1.1466.115.121.1.36 2078 Object Class Description 1.3.6.1.4.1.1466.115.121.1.37 2079 Octet String 1.3.6.1.4.1.1466.115.121.1.40 2080 OID 1.3.6.1.4.1.1466.115.121.1.38 2081 Other Mailbox 1.3.6.1.4.1.1466.115.121.1.39 2082 Postal Address 1.3.6.1.4.1.1466.115.121.1.41 2083 Printable String 1.3.6.1.4.1.1466.115.121.1.44 2084 Substring Assertion 1.3.6.1.4.1.1466.115.121.1.58 2085 Telephone Number 1.3.6.1.4.1.1466.115.121.1.50 2086 Teletex Terminal Identifier 1.3.6.1.4.1.1466.115.121.1.51 2087 Telex Number 1.3.6.1.4.1.1466.115.121.1.52 2088 UTC Time 1.3.6.1.4.1.1466.115.121.1.53 2090 Appendix B. Changes from RFC 2252 & RFC 2256 2092 This annex lists the significant differences between this 2093 specification and RFC 2252 and Sections 6 and 8 of RFC 2256. 2095 This annex is provided for informational purposes only. It is not a 2096 normative part of this specification. 2098 1. The IESG Note has been removed. 2100 2. The major part of Sections 4, 5 and 7 has been moved to [MODELS] 2101 and revised. Changes to the parts of these sections moved to 2102 [MODELS] are detailed in [MODELS]. 2104 3. BNF descriptions of syntax formats have been replaced by ABNF 2105 [ABNF] specifications. 2107 4. The ambiguous statement in RFC 2252, Section 4.3 regarding the 2108 use of a backslash quoting mechanism to escape separator symbols 2109 has been removed. The escaping mechanism is now explicitly 2110 represented in the ABNF for the syntaxes where this provision 2111 applies. 2113 5. The description of each of the LDAP syntaxes has been expanded so 2114 that they are less dependent on knowledge of X.500 for 2115 interpretation. 2117 6. The relationship of LDAP syntaxes to corresponding ASN.1 type 2118 definitions has been made explicit. 2120 7. The set of characters allowed in a (formerly 2121 ) has been corrected to align with the 2122 PrintableString ASN.1 type in [ASN.1]. Specifically, the double 2123 quote character has been removed and the single quote character 2124 and equals sign have been added. 2126 8. Values of the Directory String, Printable String and Telephone 2127 Number syntaxes are now required to have at least one character. 2129 9. The , and 2130 rules have been moved to [MODELS]. 2132 10. The corresponding ASN.1 type for the Other Mailbox syntax has 2133 been incorporated from RFC 1274. 2135 11. A corresponding ASN.1 type for the LDAP Syntax Description syntax 2136 has been invented. 2138 12. The Binary syntax has been removed because it was not adequately 2139 specified, implementations with different incompatible 2140 interpretations exist, and it was confused with the ;binary 2141 transfer encoding. 2143 13. All discussion of transfer options, including the ";binary" 2144 option, has been removed. All imperatives regarding binary 2145 transfer of values have been removed. 2147 14. The Delivery Method, Enhanced Guide, Guide, Octet String, Teletex 2148 Terminal Identifier and Telex Number syntaxes from RFC 2256 have 2149 been incorporated. 2151 15. The rule for the Enhanced Guide and Guide syntaxes has 2152 been extended to accommodate empty "and" and "or" expressions. 2154 16. An encoding for the rule in the Teletex Terminal 2155 Identifier syntax has been defined. 2157 17. The PKI-related syntaxes (Certificate, Certificate List and 2158 Certificate Pair from RFC 2252, and Supported Algorithm syntax 2159 from RFC 2256) have been removed. They are to be reintroduced in 2160 PKIX documents. 2162 18. The MHS OR Address syntax has been removed since its 2163 specification (in RFC 2156) is not at draft standard maturity. 2165 19. The DL Submit Permission syntax has been removed as it depends on 2166 the MHS OR Address syntax. 2168 20. The Presentation Address syntax has been removed since its 2169 specification (in RFC 1278) is not at draft standard maturity. 2171 21. The ACI Item, Access Point, Audio, Data Quality, DSA Quality, DSE 2172 Type, LDAP Schema Description, Master And Shadow Access Points, 2173 Modify Rights, Protocol Information, Subtree Specification, 2174 Supplier Information, Supplier Or Consumer and Supplier And 2175 Consumer syntaxes have been removed. These syntaxes are 2176 referenced in RFC 2252, but not defined. 2178 22. The LDAP Schema Definition syntax (defined in RFC 2927) and the 2179 Mail Preference syntax have been removed on the grounds that they 2180 are out of scope for a core specification. 2182 23. The description of each of the matching rules has been expanded 2183 so that they are less dependent on knowledge of X.500 for 2184 interpretation. 2186 24. The caseIgnoreIA5SubstringsMatch matching rule from RFC 2798 has 2187 been added. 2189 25. The caseIgnoreIA5SubstringsMatch, caseIgnoreListSubstringsMatch, 2190 caseIgnoreOrderingMatch and caseIgnoreSubstringsMatch matching 2191 rules have been added to the list of matching rules for which the 2192 provisions for handling leading, trailing and multiple adjoining 2193 whitespace characters apply. This is consistent with the 2194 definitions of these matching rules in X.500. The 2195 telephoneNumberMatch rule has been removed from the list since it 2196 completely ignores all space characters. 2198 26. The specification of the octetStringMatch matching rule from RFC 2199 2256 has been added to this document. 2201 27. The presentationAddressMatch matching rule has been removed as it 2202 depends on an assertion syntax (Presentation Address) that is not 2203 at draft standard maturity. 2205 28. The protocolInformationMatch matching rule has been removed as it 2206 depends on an undefined assertion syntax (Protocol Information). 2208 29. The definitive reference for ASN.1 has been changed from X.208 to 2209 X.680 since X.680 is the version of ASN.1 referred to by X.500. 2211 30. The specification of the caseIgnoreListSubstringsMatch matching 2212 rule from RFC 2798 & X.520 has been added to this document. 2214 31. String preparation algorithms have been applied to the character 2215 string matching rules.