1 2 3 4 5 6 7Network Working Group S. Legg, Ed. 8Request for Comments: 4517 eB2Bcom 9Obsoletes: 2252, 2256 June 2006 10Updates: 3698 11Category: Standards Track 12 13 14 Lightweight Directory Access Protocol (LDAP): 15 Syntaxes and Matching Rules 16 17 18Status of This Memo 19 20 This document specifies an Internet standards track protocol for the 21 Internet community, and requests discussion and suggestions for 22 improvements. Please refer to the current edition of the "Internet 23 Official Protocol Standards" (STD 1) for the standardization state 24 and status of this protocol. Distribution of this memo is unlimited. 25 26Copyright Notice 27 28 Copyright (C) The Internet Society (2006). 29 30Abstract 31 32 Each attribute stored in a Lightweight Directory Access Protocol 33 (LDAP) directory, whose values may be transferred in the LDAP 34 protocol, has a defined syntax that constrains the structure and 35 format of its values. The comparison semantics for values of a 36 syntax are not part of the syntax definition but are instead provided 37 through separately defined matching rules. Matching rules specify an 38 argument, an assertion value, which also has a defined syntax. This 39 document defines a base set of syntaxes and matching rules for use in 40 defining attributes for LDAP directories. 41 42Table of Contents 43 44 1. Introduction ....................................................3 45 2. Conventions .....................................................4 46 3. Syntaxes ........................................................4 47 3.1. General Considerations .....................................5 48 3.2. Common Definitions .........................................5 49 3.3. Syntax Definitions .........................................6 50 3.3.1. Attribute Type Description ..........................6 51 3.3.2. Bit String ..........................................6 52 3.3.3. Boolean .............................................7 53 3.3.4. Country String ......................................7 54 3.3.5. Delivery Method .....................................8 55 56 57 58Legg Standards Track [Page 1] 59 60RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 61 62 63 3.3.6. Directory String ....................................8 64 3.3.7. DIT Content Rule Description ........................9 65 3.3.8. DIT Structure Rule Description .....................10 66 3.3.9. DN .................................................10 67 3.3.10. Enhanced Guide ....................................11 68 3.3.11. Facsimile Telephone Number ........................12 69 3.3.12. Fax ...............................................12 70 3.3.13. Generalized Time ..................................13 71 3.3.14. Guide .............................................14 72 3.3.15. IA5 String ........................................15 73 3.3.16. Integer ...........................................15 74 3.3.17. JPEG ..............................................15 75 3.3.18. LDAP Syntax Description ...........................16 76 3.3.19. Matching Rule Description .........................16 77 3.3.20. Matching Rule Use Description .....................17 78 3.3.21. Name and Optional UID .............................17 79 3.3.22. Name Form Description .............................18 80 3.3.23. Numeric String ....................................18 81 3.3.24. Object Class Description ..........................18 82 3.3.25. Octet String ......................................19 83 3.3.26. OID ...............................................19 84 3.3.27. Other Mailbox .....................................20 85 3.3.28. Postal Address ....................................20 86 3.3.29. Printable String ..................................21 87 3.3.30. Substring Assertion ...............................22 88 3.3.31. Telephone Number ..................................23 89 3.3.32. Teletex Terminal Identifier .......................23 90 3.3.33. Telex Number ......................................24 91 3.3.34. UTC Time ..........................................24 92 4. Matching Rules .................................................25 93 4.1. General Considerations ....................................25 94 4.2. Matching Rule Definitions .................................27 95 4.2.1. bitStringMatch .....................................27 96 4.2.2. booleanMatch .......................................28 97 4.2.3. caseExactIA5Match ..................................28 98 4.2.4. caseExactMatch .....................................29 99 4.2.5. caseExactOrderingMatch .............................29 100 4.2.6. caseExactSubstringsMatch ...........................30 101 4.2.7. caseIgnoreIA5Match .................................30 102 4.2.8. caseIgnoreIA5SubstringsMatch .......................31 103 4.2.9. caseIgnoreListMatch ................................31 104 4.2.10. caseIgnoreListSubstringsMatch .....................32 105 4.2.11. caseIgnoreMatch ...................................33 106 4.2.12. caseIgnoreOrderingMatch ...........................33 107 4.2.13. caseIgnoreSubstringsMatch .........................34 108 4.2.14. directoryStringFirstComponentMatch ................34 109 4.2.15. distinguishedNameMatch ............................35 110 4.2.16. generalizedTimeMatch ..............................36 111 112 113 114Legg Standards Track [Page 2] 115 116RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 117 118 119 4.2.17. generalizedTimeOrderingMatch ......................36 120 4.2.18. integerFirstComponentMatch ........................36 121 4.2.19. integerMatch ......................................37 122 4.2.20. integerOrderingMatch ..............................37 123 4.2.21. keywordMatch ......................................38 124 4.2.22. numericStringMatch ................................38 125 4.2.23. numericStringOrderingMatch ........................39 126 4.2.24. numericStringSubstringsMatch ......................39 127 4.2.25. objectIdentifierFirstComponentMatch ...............40 128 4.2.26. objectIdentifierMatch .............................40 129 4.2.27. octetStringMatch ..................................41 130 4.2.28. octetStringOrderingMatch ..........................41 131 4.2.29. telephoneNumberMatch ..............................42 132 4.2.30. telephoneNumberSubstringsMatch ....................42 133 4.2.31. uniqueMemberMatch .................................43 134 4.2.32. wordMatch .........................................44 135 5. Security Considerations ........................................44 136 6. Acknowledgements ...............................................44 137 7. IANA Considerations ............................................45 138 8. References .....................................................46 139 8.1. Normative References ......................................46 140 8.2. Informative References ....................................48 141 Appendix A. Summary of Syntax Object Identifiers ..................49 142 Appendix B. Changes from RFC 2252 .................................49 143 1441. Introduction 145 146 Each attribute stored in a Lightweight Directory Access Protocol 147 (LDAP) directory [RFC4510], whose values may be transferred in the 148 LDAP protocol [RFC4511], has a defined syntax (i.e., data type) that 149 constrains the structure and format of its values. The comparison 150 semantics for values of a syntax are not part of the syntax 151 definition but are instead provided through separately defined 152 matching rules. Matching rules specify an argument, an assertion 153 value, which also has a defined syntax. This document defines a base 154 set of syntaxes and matching rules for use in defining attributes for 155 LDAP directories. 156 157 Readers are advised to familiarize themselves with the Directory 158 Information Models [RFC4512] before reading the rest of this 159 document. Section 3 provides definitions for the base set of LDAP 160 syntaxes. Section 4 provides definitions for the base set of 161 matching rules for LDAP. 162 163 This document is an integral part of the LDAP technical specification 164 [RFC4510], which obsoletes the previously defined LDAP technical 165 specification, RFC 3377, in its entirety. 166 167 168 169 170Legg Standards Track [Page 3] 171 172RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 173 174 175 Sections 4, 5, and 7 of RFC 2252 are obsoleted by [RFC4512]. The 176 remainder of RFC 2252 is obsoleted by this document. Sections 6 and 177 8 of RFC 2256 are obsoleted by this document. The remainder of RFC 178 2256 is obsoleted by [RFC4519] and [RFC4512]. All but Section 2.11 179 of RFC 3698 is obsoleted by this document. 180 181 A number of schema elements that were included in the previous 182 revision of the LDAP technical specification are not included in this 183 revision of LDAP. Public Key Infrastructure schema elements are now 184 specified in [RFC4523]. Unless reintroduced in future technical 185 specifications, the remainder are to be considered Historic. 186 187 The changes with respect to RFC 2252 are described in Appendix B of 188 this document. 189 1902. Conventions 191 192 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 193 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 194 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 195 [RFC2119]. 196 197 Syntax definitions are written according to the <SyntaxDescription> 198 ABNF [RFC4234] rule specified in [RFC4512], and matching rule 199 definitions are written according to the <MatchingRuleDescription> 200 ABNF rule specified in [RFC4512], except that the syntax and matching 201 rule definitions provided in this document are line-wrapped for 202 readability. When such definitions are transferred as attribute 203 values in the LDAP protocol (e.g., as values of the ldapSyntaxes and 204 matchingRules attributes [RFC4512], respectively), then those values 205 would not contain line breaks. 206 2073. Syntaxes 208 209 Syntax definitions constrain the structure of attribute values stored 210 in an LDAP directory, and determine the representation of attribute 211 and assertion values transferred in the LDAP protocol. 212 213 Syntaxes that are required for directory operation, or that are in 214 common use, are specified in this section. Servers SHOULD recognize 215 all the syntaxes listed in this document, but are not required to 216 otherwise support them, and MAY recognise or support other syntaxes. 217 However, the definition of additional arbitrary syntaxes is 218 discouraged since it will hinder interoperability. Client and server 219 implementations typically do not have the ability to dynamically 220 recognize new syntaxes. 221 222 223 224 225 226Legg Standards Track [Page 4] 227 228RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 229 230 2313.1. General Considerations 232 233 The description of each syntax specifies how attribute or assertion 234 values conforming to the syntax are to be represented when 235 transferred in the LDAP protocol [RFC4511]. This representation is 236 referred to as the LDAP-specific encoding to distinguish it from 237 other methods of encoding attribute values (e.g., the Basic Encoding 238 Rules (BER) encoding [BER] used by X.500 [X.500] directories). 239 240 The LDAP-specific encoding of a given attribute syntax always 241 produces octet-aligned values. To the greatest extent possible, 242 encoding rules for LDAP syntaxes should produce character strings 243 that can be displayed with little or no translation by clients 244 implementing LDAP. However, clients MUST NOT assume that the LDAP- 245 specific encoding of a value of an unrecognized syntax is a human- 246 readable character string. There are a few cases (e.g., the JPEG 247 syntax) when it is not reasonable to produce a human-readable 248 representation. 249 250 Each LDAP syntax is uniquely identified with an object identifier 251 [ASN.1] represented in the dotted-decimal format (short descriptive 252 names are not defined for syntaxes). These object identifiers are 253 not intended to be displayed to users. The object identifiers for 254 the syntaxes defined in this document are summarized in Appendix A. 255 256 A suggested minimum upper bound on the number of characters in an 257 attribute value with a string-based syntax, or the number of octets 258 in a value for all other syntaxes, MAY be indicated by appending the 259 bound inside of curly braces following the syntax's OBJECT IDENTIFIER 260 in an attribute type definition (see the <noidlen> rule in 261 [RFC4512]). Such a bound is not considered part of the syntax 262 identifier. 263 264 For example, "1.3.6.1.4.1.1466.115.121.1.15{64}" in an attribute 265 definition suggests that the directory server will allow a value of 266 the attribute to be up to 64 characters long, although it may allow 267 longer character strings. Note that a single character of the 268 Directory String syntax can be encoded in more than one octet, since 269 UTF-8 [RFC3629] is a variable-length encoding. Therefore, a 64- 270 character string may be more than 64 octets in length. 271 2723.2. Common Definitions 273 274 The following ABNF rules are used in a number of the syntax 275 definitions in Section 3.3. 276 277 PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN / 278 PLUS / COMMA / HYPHEN / DOT / EQUALS / 279 280 281 282Legg Standards Track [Page 5] 283 284RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 285 286 287 SLASH / COLON / QUESTION / SPACE 288 PrintableString = 1*PrintableCharacter 289 IA5String = *(%x00-7F) 290 SLASH = %x2F ; forward slash ("/") 291 COLON = %x3A ; colon (":") 292 QUESTION = %x3F ; question mark ("?") 293 294 The <ALPHA>, <DIGIT>, <SQUOTE>, <LPAREN>, <RPAREN>, <PLUS>, <COMMA>, 295 <HYPHEN>, <DOT>, <EQUALS>, and <SPACE> rules are defined in 296 [RFC4512]. 297 2983.3. Syntax Definitions 299 3003.3.1. Attribute Type Description 301 302 A value of the Attribute Type Description syntax is the definition of 303 an attribute type. The LDAP-specific encoding of a value of this 304 syntax is defined by the <AttributeTypeDescription> rule in 305 [RFC4512]. 306 307 For example, the following definition of the createTimestamp 308 attribute type from [RFC4512] is also a value of the Attribute 309 Type Description syntax. (Note: Line breaks have been added for 310 readability; they are not part of the value when transferred in 311 protocol.) 312 313 ( 2.5.18.1 NAME 'createTimestamp' 314 EQUALITY generalizedTimeMatch 315 ORDERING generalizedTimeOrderingMatch 316 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 317 SINGLE-VALUE NO-USER-MODIFICATION 318 USAGE directoryOperation ) 319 320 The LDAP definition for the Attribute Type Description syntax is: 321 322 ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' ) 323 324 This syntax corresponds to the AttributeTypeDescription ASN.1 type 325 from [X.501]. 326 3273.3.2. Bit String 328 329 A value of the Bit String syntax is a sequence of binary digits. The 330 LDAP-specific encoding of a value of this syntax is defined by the 331 following ABNF: 332 333 BitString = SQUOTE *binary-digit SQUOTE "B" 334 binary-digit = "0" / "1" 335 336 337 338Legg Standards Track [Page 6] 339 340RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 341 342 343 The <SQUOTE> rule is defined in [RFC4512]. 344 345 Example: 346 '0101111101'B 347 348 The LDAP definition for the Bit String syntax is: 349 350 ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' ) 351 352 This syntax corresponds to the BIT STRING ASN.1 type from [ASN.1]. 353 3543.3.3. Boolean 355 356 A value of the Boolean syntax is one of the Boolean values, true or 357 false. The LDAP-specific encoding of a value of this syntax is 358 defined by the following ABNF: 359 360 Boolean = "TRUE" / "FALSE" 361 362 The LDAP definition for the Boolean syntax is: 363 364 ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' ) 365 366 This syntax corresponds to the BOOLEAN ASN.1 type from [ASN.1]. 367 3683.3.4. Country String 369 370 A value of the Country String syntax is one of the two-character 371 codes from ISO 3166 [ISO3166] for representing a country. The LDAP- 372 specific encoding of a value of this syntax is defined by the 373 following ABNF: 374 375 CountryString = 2(PrintableCharacter) 376 377 The <PrintableCharacter> rule is defined in Section 3.2. 378 379 Examples: 380 381 US 382 AU 383 384 The LDAP definition for the Country String syntax is: 385 386 ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' ) 387 388 This syntax corresponds to the following ASN.1 type from [X.520]: 389 390 PrintableString (SIZE (2)) -- ISO 3166 codes only 391 392 393 394Legg Standards Track [Page 7] 395 396RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 397 398 3993.3.5. Delivery Method 400 401 A value of the Delivery Method syntax is a sequence of items that 402 indicate, in preference order, the service(s) by which an entity is 403 willing and/or capable of receiving messages. The LDAP-specific 404 encoding of a value of this syntax is defined by the following ABNF: 405 406 DeliveryMethod = pdm *( WSP DOLLAR WSP pdm ) 407 408 pdm = "any" / "mhs" / "physical" / "telex" / "teletex" / 409 "g3fax" / "g4fax" / "ia5" / "videotex" / "telephone" 410 411 The <WSP> and <DOLLAR> rules are defined in [RFC4512]. 412 413 Example: 414 telephone $ videotex 415 416 The LDAP definition for the Delivery Method syntax is: 417 418 ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' ) 419 420 This syntax corresponds to the following ASN.1 type from [X.520]: 421 422 SEQUENCE OF INTEGER { 423 any-delivery-method (0), 424 mhs-delivery (1), 425 physical-delivery (2), 426 telex-delivery (3), 427 teletex-delivery (4), 428 g3-facsimile-delivery (5), 429 g4-facsimile-delivery (6), 430 ia5-terminal-delivery (7), 431 videotex-delivery (8), 432 telephone-delivery (9) } 433 4343.3.6. Directory String 435 436 A value of the Directory String syntax is a string of one or more 437 arbitrary characters from the Universal Character Set (UCS) [UCS]. A 438 zero-length character string is not permitted. The LDAP-specific 439 encoding of a value of this syntax is the UTF-8 encoding [RFC3629] of 440 the character string. Such encodings conform to the following ABNF: 441 442 DirectoryString = 1*UTF8 443 444 The <UTF8> rule is defined in [RFC4512]. 445 446 447 448 449 450Legg Standards Track [Page 8] 451 452RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 453 454 455 Example: 456 This is a value of Directory String containing #!%#@. 457 458 Servers and clients MUST be prepared to receive arbitrary UCS code 459 points, including code points outside the range of printable ASCII 460 and code points not presently assigned to any character. 461 462 Attribute type definitions using the Directory String syntax should 463 not restrict the format of Directory String values, e.g., by 464 requiring that the character string conforms to specific patterns 465 described by ABNF. A new syntax should be defined in such cases. 466 467 The LDAP definition for the Directory String syntax is: 468 469 ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' ) 470 471 This syntax corresponds to the DirectoryString parameterized ASN.1 472 type from [X.520]. 473 474 The DirectoryString ASN.1 type allows a choice between the 475 TeletexString, PrintableString, or UniversalString ASN.1 types from 476 [ASN.1]. However, note that the chosen alternative is not indicated 477 in the LDAP-specific encoding of a Directory String value. 478 479 Implementations that convert Directory String values from the LDAP- 480 specific encoding to the BER encoding used by X.500 must choose an 481 alternative that permits the particular characters in the string and 482 must convert the characters from the UTF-8 encoding into the 483 character encoding of the chosen alternative. When converting 484 Directory String values from the BER encoding to the LDAP-specific 485 encoding, the characters must be converted from the character 486 encoding of the chosen alternative into the UTF-8 encoding. These 487 conversions SHOULD be done in a manner consistent with the Transcode 488 step of the string preparation algorithms [RFC4518] for LDAP. 489 4903.3.7. DIT Content Rule Description 491 492 A value of the DIT Content Rule Description syntax is the definition 493 of a DIT (Directory Information Tree) content rule. The LDAP- 494 specific encoding of a value of this syntax is defined by the 495 <DITContentRuleDescription> rule in [RFC4512]. 496 497 Example: 498 ( 2.5.6.4 DESC 'content rule for organization' 499 NOT ( x121Address $ telexNumber ) ) 500 501 Note: A line break has been added for readability; it is not part 502 of the value. 503 504 505 506Legg Standards Track [Page 9] 507 508RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 509 510 511 The LDAP definition for the DIT Content Rule Description syntax is: 512 513 ( 1.3.6.1.4.1.1466.115.121.1.16 514 DESC 'DIT Content Rule Description' ) 515 516 This syntax corresponds to the DITContentRuleDescription ASN.1 type 517 from [X.501]. 518 5193.3.8. DIT Structure Rule Description 520 521 A value of the DIT Structure Rule Description syntax is the 522 definition of a DIT structure rule. The LDAP-specific encoding of a 523 value of this syntax is defined by the <DITStructureRuleDescription> 524 rule in [RFC4512]. 525 526 Example: 527 ( 2 DESC 'organization structure rule' FORM 2.5.15.3 ) 528 529 The LDAP definition for the DIT Structure Rule Description syntax is: 530 531 ( 1.3.6.1.4.1.1466.115.121.1.17 532 DESC 'DIT Structure Rule Description' ) 533 534 This syntax corresponds to the DITStructureRuleDescription ASN.1 type 535 from [X.501]. 536 5373.3.9. DN 538 539 A value of the DN syntax is the (purported) distinguished name (DN) 540 of an entry [RFC4512]. The LDAP-specific encoding of a value of this 541 syntax is defined by the <distinguishedName> rule from the string 542 representation of distinguished names [RFC4514]. 543 544 Examples (from [RFC4514]): 545 UID=jsmith,DC=example,DC=net 546 OU=Sales+CN=J. Smith,DC=example,DC=net 547 CN=John Smith\, III,DC=example,DC=net 548 CN=Before\0dAfter,DC=example,DC=net 549 1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com 550 CN=Lu\C4\8Di\C4\87 551 552 The LDAP definition for the DN syntax is: 553 554 ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' ) 555 556 The DN syntax corresponds to the DistinguishedName ASN.1 type from 557 [X.501]. Note that a BER encoded distinguished name (as used by 558 X.500) re-encoded into the LDAP-specific encoding is not necessarily 559 560 561 562Legg Standards Track [Page 10] 563 564RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 565 566 567 reversible to the original BER encoding since the chosen string type 568 in any DirectoryString components of the distinguished name is not 569 indicated in the LDAP-specific encoding of the distinguished name 570 (see Section 3.3.6). 571 5723.3.10. Enhanced Guide 573 574 A value of the Enhanced Guide syntax suggests criteria, which consist 575 of combinations of attribute types and filter operators, to be used 576 in constructing filters to search for entries of particular object 577 classes. The Enhanced Guide syntax improves upon the Guide syntax by 578 allowing the recommended depth of the search to be specified. 579 580 The LDAP-specific encoding of a value of this syntax is defined by 581 the following ABNF: 582 583 EnhancedGuide = object-class SHARP WSP criteria WSP 584 SHARP WSP subset 585 object-class = WSP oid WSP 586 subset = "baseobject" / "oneLevel" / "wholeSubtree" 587 588 criteria = and-term *( BAR and-term ) 589 and-term = term *( AMPERSAND term ) 590 term = EXCLAIM term / 591 attributetype DOLLAR match-type / 592 LPAREN criteria RPAREN / 593 true / 594 false 595 match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX" 596 true = "?true" 597 false = "?false" 598 BAR = %x7C ; vertical bar ("|") 599 AMPERSAND = %x26 ; ampersand ("&") 600 EXCLAIM = %x21 ; exclamation mark ("!") 601 602 The <SHARP>, <WSP>, <oid>, <LPAREN>, <RPAREN>, <attributetype>, and 603 <DOLLAR> rules are defined in [RFC4512]. 604 605 The LDAP definition for the Enhanced Guide syntax is: 606 607 ( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' ) 608 609 Example: 610 person#(sn$EQ)#oneLevel 611 612 The Enhanced Guide syntax corresponds to the EnhancedGuide ASN.1 type 613 from [X.520]. The EnhancedGuide type references the Criteria ASN.1 614 type, also from [X.520]. The <true> rule, above, represents an empty 615 616 617 618Legg Standards Track [Page 11] 619 620RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 621 622 623 "and" expression in a value of the Criteria type. The <false> rule, 624 above, represents an empty "or" expression in a value of the Criteria 625 type. 626 6273.3.11. Facsimile Telephone Number 628 629 A value of the Facsimile Telephone Number syntax is a subscriber 630 number of a facsimile device on the public switched telephone 631 network. The LDAP-specific encoding of a value of this syntax is 632 defined by the following ABNF: 633 634 fax-number = telephone-number *( DOLLAR fax-parameter ) 635 telephone-number = PrintableString 636 fax-parameter = "twoDimensional" / 637 "fineResolution" / 638 "unlimitedLength" / 639 "b4Length" / 640 "a3Width" / 641 "b4Width" / 642 "uncompressed" 643 644 The <telephone-number> is a string of printable characters that 645 complies with the internationally agreed format for representing 646 international telephone numbers [E.123]. The <PrintableString> rule 647 is defined in Section 3.2. The <DOLLAR> rule is defined in 648 [RFC4512]. 649 650 The LDAP definition for the Facsimile Telephone Number syntax is: 651 652 ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number') 653 654 The Facsimile Telephone Number syntax corresponds to the 655 FacsimileTelephoneNumber ASN.1 type from [X.520]. 656 6573.3.12. Fax 658 659 A value of the Fax syntax is an image that is produced using the 660 Group 3 facsimile process [FAX] to duplicate an object, such as a 661 memo. The LDAP-specific encoding of a value of this syntax is the 662 string of octets for a Group 3 Fax image as defined in [FAX]. 663 664 The LDAP definition for the Fax syntax is: 665 666 ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' ) 667 668 The ASN.1 type corresponding to the Fax syntax is defined as follows, 669 assuming EXPLICIT TAGS: 670 671 672 673 674Legg Standards Track [Page 12] 675 676RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 677 678 679 Fax ::= CHOICE { 680 g3-facsimile [3] G3FacsimileBodyPart 681 } 682 683 The G3FacsimileBodyPart ASN.1 type is defined in [X.420]. 684 6853.3.13. Generalized Time 686 687 A value of the Generalized Time syntax is a character string 688 representing a date and time. The LDAP-specific encoding of a value 689 of this syntax is a restriction of the format defined in [ISO8601], 690 and is described by the following ABNF: 691 692 GeneralizedTime = century year month day hour 693 [ minute [ second / leap-second ] ] 694 [ fraction ] 695 g-time-zone 696 697 century = 2(%x30-39) ; "00" to "99" 698 year = 2(%x30-39) ; "00" to "99" 699 month = ( %x30 %x31-39 ) ; "01" (January) to "09" 700 / ( %x31 %x30-32 ) ; "10" to "12" 701 day = ( %x30 %x31-39 ) ; "01" to "09" 702 / ( %x31-32 %x30-39 ) ; "10" to "29" 703 / ( %x33 %x30-31 ) ; "30" to "31" 704 hour = ( %x30-31 %x30-39 ) / ( %x32 %x30-33 ) ; "00" to "23" 705 minute = %x30-35 %x30-39 ; "00" to "59" 706 707 second = ( %x30-35 %x30-39 ) ; "00" to "59" 708 leap-second = ( %x36 %x30 ) ; "60" 709 710 fraction = ( DOT / COMMA ) 1*(%x30-39) 711 g-time-zone = %x5A ; "Z" 712 / g-differential 713 g-differential = ( MINUS / PLUS ) hour [ minute ] 714 MINUS = %x2D ; minus sign ("-") 715 716 The <DOT>, <COMMA>, and <PLUS> rules are defined in [RFC4512]. 717 718 The above ABNF allows character strings that do not represent valid 719 dates (in the Gregorian calendar) and/or valid times (e.g., February 720 31, 1994). Such character strings SHOULD be considered invalid for 721 this syntax. 722 723 The time value represents coordinated universal time (equivalent to 724 Greenwich Mean Time) if the "Z" form of <g-time-zone> is used; 725 otherwise, the value represents a local time in the time zone 726 indicated by <g-differential>. In the latter case, coordinated 727 728 729 730Legg Standards Track [Page 13] 731 732RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 733 734 735 universal time can be calculated by subtracting the differential from 736 the local time. The "Z" form of <g-time-zone> SHOULD be used in 737 preference to <g-differential>. 738 739 If <minute> is omitted, then <fraction> represents a fraction of an 740 hour; otherwise, if <second> and <leap-second> are omitted, then 741 <fraction> represents a fraction of a minute; otherwise, <fraction> 742 represents a fraction of a second. 743 744 Examples: 745 199412161032Z 746 199412160532-0500 747 748 Both example values represent the same coordinated universal time: 749 10:32 AM, December 16, 1994. 750 751 The LDAP definition for the Generalized Time syntax is: 752 753 ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' ) 754 755 This syntax corresponds to the GeneralizedTime ASN.1 type from 756 [ASN.1], with the constraint that local time without a differential 757 SHALL NOT be used. 758 7593.3.14. Guide 760 761 A value of the Guide syntax suggests criteria, which consist of 762 combinations of attribute types and filter operators, to be used in 763 constructing filters to search for entries of particular object 764 classes. The Guide syntax is obsolete and should not be used for 765 defining new attribute types. 766 767 The LDAP-specific encoding of a value of this syntax is defined by 768 the following ABNF: 769 770 Guide = [ object-class SHARP ] criteria 771 772 The <object-class> and <criteria> rules are defined in Section 773 3.3.10. The <SHARP> rule is defined in [RFC4512]. 774 775 The LDAP definition for the Guide syntax is: 776 777 ( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' ) 778 779 The Guide syntax corresponds to the Guide ASN.1 type from [X.520]. 780 781 782 783 784 785 786Legg Standards Track [Page 14] 787 788RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 789 790 7913.3.15. IA5 String 792 793 A value of the IA5 String syntax is a string of zero, one, or more 794 characters from International Alphabet 5 (IA5) [T.50], the 795 international version of the ASCII character set. The LDAP-specific 796 encoding of a value of this syntax is the unconverted string of 797 characters, which conforms to the <IA5String> rule in Section 3.2. 798 799 The LDAP definition for the IA5 String syntax is: 800 801 ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' ) 802 803 This syntax corresponds to the IA5String ASN.1 type from [ASN.1]. 804 8053.3.16. Integer 806 807 A value of the Integer syntax is a whole number of unlimited 808 magnitude. The LDAP-specific encoding of a value of this syntax is 809 the optionally signed decimal digit character string representation 810 of the number (for example, the number 1321 is represented by the 811 character string "1321"). The encoding is defined by the following 812 ABNF: 813 814 Integer = ( HYPHEN LDIGIT *DIGIT ) / number 815 816 The <HYPHEN>, <LDIGIT>, <DIGIT>, and <number> rules are defined in 817 [RFC4512]. 818 819 The LDAP definition for the Integer syntax is: 820 821 ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' ) 822 823 This syntax corresponds to the INTEGER ASN.1 type from [ASN.1]. 824 8253.3.17. JPEG 826 827 A value of the JPEG syntax is an image in the JPEG File Interchange 828 Format (JFIF), as described in [JPEG]. The LDAP-specific encoding of 829 a value of this syntax is the sequence of octets of the JFIF encoding 830 of the image. 831 832 The LDAP definition for the JPEG syntax is: 833 834 ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' ) 835 836 The JPEG syntax corresponds to the following ASN.1 type: 837 838 839 840 841 842Legg Standards Track [Page 15] 843 844RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 845 846 847 JPEG ::= OCTET STRING (CONSTRAINED BY 848 { -- contents octets are an image in the -- 849 -- JPEG File Interchange Format -- }) 850 8513.3.18. LDAP Syntax Description 852 853 A value of the LDAP Syntax Description syntax is the description of 854 an LDAP syntax. The LDAP-specific encoding of a value of this syntax 855 is defined by the <SyntaxDescription> rule in [RFC4512]. 856 857 The LDAP definition for the LDAP Syntax Description syntax is: 858 859 ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' ) 860 861 The above LDAP definition for the LDAP Syntax Description syntax is 862 itself a legal value of the LDAP Syntax Description syntax. 863 864 The ASN.1 type corresponding to the LDAP Syntax Description syntax is 865 defined as follows, assuming EXPLICIT TAGS: 866 867 LDAPSyntaxDescription ::= SEQUENCE { 868 identifier OBJECT IDENTIFIER, 869 description DirectoryString { ub-schema } OPTIONAL } 870 871 The DirectoryString parameterized ASN.1 type is defined in [X.520]. 872 873 The value of ub-schema (an integer) is implementation defined. A 874 non-normative definition appears in [X.520]. 875 8763.3.19. Matching Rule Description 877 878 A value of the Matching Rule Description syntax is the definition of 879 a matching rule. The LDAP-specific encoding of a value of this 880 syntax is defined by the <MatchingRuleDescription> rule in [RFC4512]. 881 882 Example: 883 ( 2.5.13.2 NAME 'caseIgnoreMatch' 884 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 885 886 Note: A line break has been added for readability; it is not part of 887 the syntax. 888 889 The LDAP definition for the Matching Rule Description syntax is: 890 891 ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' ) 892 893 This syntax corresponds to the MatchingRuleDescription ASN.1 type 894 from [X.501]. 895 896 897 898Legg Standards Track [Page 16] 899 900RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 901 902 9033.3.20. Matching Rule Use Description 904 905 A value of the Matching Rule Use Description syntax indicates the 906 attribute types to which a matching rule may be applied in an 907 extensibleMatch search filter [RFC4511]. The LDAP-specific encoding 908 of a value of this syntax is defined by the 909 <MatchingRuleUseDescription> rule in [RFC4512]. 910 911 Example: 912 ( 2.5.13.16 APPLIES ( givenName $ surname ) ) 913 914 The LDAP definition for the Matching Rule Use Description syntax is: 915 916 ( 1.3.6.1.4.1.1466.115.121.1.31 917 DESC 'Matching Rule Use Description' ) 918 919 This syntax corresponds to the MatchingRuleUseDescription ASN.1 type 920 from [X.501]. 921 9223.3.21. Name and Optional UID 923 924 A value of the Name and Optional UID syntax is the distinguished name 925 [RFC4512] of an entity optionally accompanied by a unique identifier 926 that serves to differentiate the entity from others with an identical 927 distinguished name. 928 929 The LDAP-specific encoding of a value of this syntax is defined by 930 the following ABNF: 931 932 NameAndOptionalUID = distinguishedName [ SHARP BitString ] 933 934 The <BitString> rule is defined in Section 3.3.2. The 935 <distinguishedName> rule is defined in [RFC4514]. The <SHARP> rule 936 is defined in [RFC4512]. 937 938 Note that although the '#' character may occur in the string 939 representation of a distinguished name, no additional escaping of 940 this character is performed when a <distinguishedName> is encoded in 941 a <NameAndOptionalUID>. 942 943 Example: 944 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B 945 946 The LDAP definition for the Name and Optional UID syntax is: 947 948 ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' ) 949 950 951 952 953 954Legg Standards Track [Page 17] 955 956RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 957 958 959 This syntax corresponds to the NameAndOptionalUID ASN.1 type from 960 [X.520]. 961 9623.3.22. Name Form Description 963 964 A value of the Name Form Description syntax is the definition of a 965 name form, which regulates how entries may be named. The LDAP- 966 specific encoding of a value of this syntax is defined by the 967 <NameFormDescription> rule in [RFC4512]. 968 969 Example: 970 ( 2.5.15.3 NAME 'orgNameForm' OC organization MUST o ) 971 972 The LDAP definition for the Name Form Description syntax is: 973 974 ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' ) 975 976 This syntax corresponds to the NameFormDescription ASN.1 type from 977 [X.501]. 978 9793.3.23. Numeric String 980 981 A value of the Numeric String syntax is a sequence of one or more 982 numerals and spaces. The LDAP-specific encoding of a value of this 983 syntax is the unconverted string of characters, which conforms to the 984 following ABNF: 985 986 NumericString = 1*(DIGIT / SPACE) 987 988 The <DIGIT> and <SPACE> rules are defined in [RFC4512]. 989 990 Example: 991 15 079 672 281 992 993 The LDAP definition for the Numeric String syntax is: 994 995 ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' ) 996 997 This syntax corresponds to the NumericString ASN.1 type from [ASN.1]. 998 9993.3.24. Object Class Description 1000 1001 A value of the Object Class Description syntax is the definition of 1002 an object class. The LDAP-specific encoding of a value of this 1003 syntax is defined by the <ObjectClassDescription> rule in [RFC4512]. 1004 1005 1006 1007 1008 1009 1010Legg Standards Track [Page 18] 1011 1012RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 1013 1014 1015 Example: 1016 ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c 1017 MAY ( searchGuide $ description ) ) 1018 1019 Note: A line break has been added for readability; it is not part of 1020 the syntax. 1021 1022 The LDAP definition for the Object Class Description syntax is: 1023 1024 ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' ) 1025 1026 This syntax corresponds to the ObjectClassDescription ASN.1 type from 1027 [X.501]. 1028 10293.3.25. Octet String 1030 1031 A value of the Octet String syntax is a sequence of zero, one, or 1032 more arbitrary octets. The LDAP-specific encoding of a value of this 1033 syntax is the unconverted sequence of octets, which conforms to the 1034 following ABNF: 1035 1036 OctetString = *OCTET 1037 1038 The <OCTET> rule is defined in [RFC4512]. Values of this syntax are 1039 not generally human-readable. 1040 1041 The LDAP definition for the Octet String syntax is: 1042 1043 ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' ) 1044 1045 This syntax corresponds to the OCTET STRING ASN.1 type from [ASN.1]. 1046 10473.3.26. OID 1048 1049 A value of the OID syntax is an object identifier: a sequence of two 1050 or more non-negative integers that uniquely identify some object or 1051 item of specification. Many of the object identifiers used in LDAP 1052 also have IANA registered names [RFC4520]. 1053 1054 The LDAP-specific encoding of a value of this syntax is defined by 1055 the <oid> rule in [RFC4512]. 1056 1057 Examples: 1058 1.2.3.4 1059 cn 1060 1061 The LDAP definition for the OID syntax is: 1062 1063 1064 1065 1066Legg Standards Track [Page 19] 1067 1068RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 1069 1070 1071 ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' ) 1072 1073 This syntax corresponds to the OBJECT IDENTIFIER ASN.1 type from 1074 [ASN.1]. 1075 10763.3.27. Other Mailbox 1077 1078 A value of the Other Mailbox syntax identifies an electronic mailbox, 1079 in a particular named mail system. The LDAP-specific encoding of a 1080 value of this syntax is defined by the following ABNF: 1081 1082 OtherMailbox = mailbox-type DOLLAR mailbox 1083 mailbox-type = PrintableString 1084 mailbox = IA5String 1085 1086 The <mailbox-type> rule represents the type of mail system in which 1087 the mailbox resides (for example, "MCIMail"), and <mailbox> is the 1088 actual mailbox in the mail system described by <mailbox-type>. The 1089 <PrintableString> and <IA5String> rules are defined in Section 3.2. 1090 The <DOLLAR> rule is defined in [RFC4512]. 1091 1092 The LDAP definition for the Other Mailbox syntax is: 1093 1094 ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' ) 1095 1096 The ASN.1 type corresponding to the Other Mailbox syntax is defined 1097 as follows, assuming EXPLICIT TAGS: 1098 1099 OtherMailbox ::= SEQUENCE { 1100 mailboxType PrintableString, 1101 mailbox IA5String 1102 } 1103 11043.3.28. Postal Address 1105 1106 A value of the Postal Address syntax is a sequence of strings of one 1107 or more arbitrary UCS characters, which form an address in a physical 1108 mail system. 1109 1110 The LDAP-specific encoding of a value of this syntax is defined by 1111 the following ABNF: 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122Legg Standards Track [Page 20] 1123 1124RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 1125 1126 1127 PostalAddress = line *( DOLLAR line ) 1128 line = 1*line-char 1129 line-char = %x00-23 1130 / (%x5C "24") ; escaped "$" 1131 / %x25-5B 1132 / (%x5C "5C") ; escaped "\" 1133 / %x5D-7F 1134 / UTFMB 1135 1136 Each character string (i.e., <line>) of a postal address value is 1137 encoded as a UTF-8 [RFC3629] string, except that "\" and "$" 1138 characters, if they occur in the string, are escaped by a "\" 1139 character followed by the two hexadecimal digit code for the 1140 character. The <DOLLAR> and <UTFMB> rules are defined in [RFC4512]. 1141 1142 Many servers limit the postal address to no more than six lines of no 1143 more than thirty characters each. 1144 1145 Example: 1146 1234 Main St.$Anytown, CA 12345$USA 1147 \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA 1148 1149 The LDAP definition for the Postal Address syntax is: 1150 1151 ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' ) 1152 1153 This syntax corresponds to the PostalAddress ASN.1 type from [X.520]; 1154 that is 1155 1156 PostalAddress ::= SEQUENCE SIZE(1..ub-postal-line) OF 1157 DirectoryString { ub-postal-string } 1158 1159 The values of ub-postal-line and ub-postal-string (both integers) are 1160 implementation defined. Non-normative definitions appear in [X.520]. 1161 11623.3.29. Printable String 1163 1164 A value of the Printable String syntax is a string of one or more 1165 latin alphabetic, numeric, and selected punctuation characters as 1166 specified by the <PrintableCharacter> rule in Section 3.2. 1167 1168 The LDAP-specific encoding of a value of this syntax is the 1169 unconverted string of characters, which conforms to the 1170 <PrintableString> rule in Section 3.2. 1171 1172 Example: 1173 This is a PrintableString. 1174 1175 1176 1177 1178Legg Standards Track [Page 21] 1179 1180RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 1181 1182 1183 The LDAP definition for the PrintableString syntax is: 1184 1185 ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' ) 1186 1187 This syntax corresponds to the PrintableString ASN.1 type from 1188 [ASN.1]. 1189 11903.3.30. Substring Assertion 1191 1192 A value of the Substring Assertion syntax is a sequence of zero, one, 1193 or more character substrings used as an argument for substring 1194 extensible matching of character string attribute values; i.e., as 1195 the matchValue of a MatchingRuleAssertion [RFC4511]. Each substring 1196 is a string of one or more arbitrary characters from the Universal 1197 Character Set (UCS) [UCS]. A zero-length substring is not permitted. 1198 1199 The LDAP-specific encoding of a value of this syntax is defined by 1200 the following ABNF: 1201 1202 SubstringAssertion = [ initial ] any [ final ] 1203 1204 initial = substring 1205 any = ASTERISK *(substring ASTERISK) 1206 final = substring 1207 ASTERISK = %x2A ; asterisk ("*") 1208 1209 substring = 1*substring-character 1210 substring-character = %x00-29 1211 / (%x5C "2A") ; escaped "*" 1212 / %x2B-5B 1213 / (%x5C "5C") ; escaped "\" 1214 / %x5D-7F 1215 / UTFMB 1216 1217 Each <substring> of a Substring Assertion value is encoded as a UTF-8 1218 [RFC3629] string, except that "\" and "*" characters, if they occur 1219 in the substring, are escaped by a "\" character followed by the two 1220 hexadecimal digit code for the character. 1221 1222 The Substring Assertion syntax is used only as the syntax of 1223 assertion values in the extensible match. It is not used as an 1224 attribute syntax, or in the SubstringFilter [RFC4511]. 1225 1226 The LDAP definition for the Substring Assertion syntax is: 1227 1228 ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' ) 1229 1230 1231 1232 1233 1234Legg Standards Track [Page 22] 1235 1236RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 1237 1238 1239 This syntax corresponds to the SubstringAssertion ASN.1 type from 1240 [X.520]. 1241 12423.3.31. Telephone Number 1243 1244 A value of the Telephone Number syntax is a string of printable 1245 characters that complies with the internationally agreed format for 1246 representing international telephone numbers [E.123]. 1247 1248 The LDAP-specific encoding of a value of this syntax is the 1249 unconverted string of characters, which conforms to the 1250 <PrintableString> rule in Section 3.2. 1251 1252 Examples: 1253 +1 512 315 0280 1254 +1-512-315-0280 1255 +61 3 9896 7830 1256 1257 The LDAP definition for the Telephone Number syntax is: 1258 1259 ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' ) 1260 1261 The Telephone Number syntax corresponds to the following ASN.1 type 1262 from [X.520]: 1263 1264 PrintableString (SIZE(1..ub-telephone-number)) 1265 1266 The value of ub-telephone-number (an integer) is implementation 1267 defined. A non-normative definition appears in [X.520]. 1268 12693.3.32. Teletex Terminal Identifier 1270 1271 A value of this syntax specifies the identifier and (optionally) 1272 parameters of a teletex terminal. 1273 1274 The LDAP-specific encoding of a value of this syntax is defined by 1275 the following ABNF: 1276 1277 teletex-id = ttx-term *(DOLLAR ttx-param) 1278 ttx-term = PrintableString ; terminal identifier 1279 ttx-param = ttx-key COLON ttx-value ; parameter 1280 ttx-key = "graphic" / "control" / "misc" / "page" / "private" 1281 ttx-value = *ttx-value-octet 1282 1283 ttx-value-octet = %x00-23 1284 / (%x5C "24") ; escaped "$" 1285 / %x25-5B 1286 / (%x5C "5C") ; escaped "\" 1287 1288 1289 1290Legg Standards Track [Page 23] 1291 1292RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 1293 1294 1295 / %x5D-FF 1296 1297 The <PrintableString> and <COLON> rules are defined in Section 3.2. 1298 The <DOLLAR> rule is defined in [RFC4512]. 1299 1300 The LDAP definition for the Teletex Terminal Identifier syntax is: 1301 1302 ( 1.3.6.1.4.1.1466.115.121.1.51 1303 DESC 'Teletex Terminal Identifier' ) 1304 1305 This syntax corresponds to the TeletexTerminalIdentifier ASN.1 type 1306 from [X.520]. 1307 13083.3.33. Telex Number 1309 1310 A value of the Telex Number syntax specifies the telex number, 1311 country code, and answerback code of a telex terminal. 1312 1313 The LDAP-specific encoding of a value of this syntax is defined by 1314 the following ABNF: 1315 1316 telex-number = actual-number DOLLAR country-code 1317 DOLLAR answerback 1318 actual-number = PrintableString 1319 country-code = PrintableString 1320 answerback = PrintableString 1321 1322 The <PrintableString> rule is defined in Section 3.2. The <DOLLAR> 1323 rule is defined in [RFC4512]. 1324 1325 The LDAP definition for the Telex Number syntax is: 1326 1327 ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' ) 1328 1329 This syntax corresponds to the TelexNumber ASN.1 type from [X.520]. 1330 13313.3.34. UTC Time 1332 1333 A value of the UTC Time syntax is a character string representing a 1334 date and time to a precision of one minute or one second. The year 1335 is given as a two-digit number. The LDAP-specific encoding of a 1336 value of this syntax follows the format defined in [ASN.1] for the 1337 UTCTime type and is described by the following ABNF: 1338 1339 UTCTime = year month day hour minute [ second ] 1340 [ u-time-zone ] 1341 u-time-zone = %x5A ; "Z" 1342 / u-differential 1343 1344 1345 1346Legg Standards Track [Page 24] 1347 1348RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 1349 1350 1351 u-differential = ( MINUS / PLUS ) hour minute 1352 1353 The <year>, <month>, <day>, <hour>, <minute>, <second>, and <MINUS> 1354 rules are defined in Section 3.3.13. The <PLUS> rule is defined in 1355 [RFC4512]. 1356 1357 The above ABNF allows character strings that do not represent valid 1358 dates (in the Gregorian calendar) and/or valid times. Such character 1359 strings SHOULD be considered invalid for this syntax. 1360 1361 The time value represents coordinated universal time if the "Z" form 1362 of <u-time-zone> is used; otherwise, the value represents a local 1363 time. In the latter case, if <u-differential> is provided, then 1364 coordinated universal time can be calculated by subtracting the 1365 differential from the local time. The <u-time-zone> SHOULD be 1366 present in time values, and the "Z" form of <u-time-zone> SHOULD be 1367 used in preference to <u-differential>. 1368 1369 The LDAP definition for the UTC Time syntax is: 1370 1371 ( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' ) 1372 1373 Note: This syntax is deprecated in favor of the Generalized Time 1374 syntax. 1375 1376 The UTC Time syntax corresponds to the UTCTime ASN.1 type from 1377 [ASN.1]. 1378 13794. Matching Rules 1380 1381 Matching rules are used by directory implementations to compare 1382 attribute values against assertion values when performing Search and 1383 Compare operations [RFC4511]. They are also used when comparing a 1384 purported distinguished name [RFC4512] with the name of an entry. 1385 When modifying entries, matching rules are used to identify values to 1386 be deleted and to prevent an attribute from containing two equal 1387 values. 1388 1389 Matching rules that are required for directory operation, or that are 1390 in common use, are specified in this section. 1391 13924.1. General Considerations 1393 1394 A matching rule is applied to attribute values through an 1395 AttributeValueAssertion or MatchingRuleAssertion [RFC4511]. The 1396 conditions under which an AttributeValueAssertion or 1397 MatchingRuleAssertion evaluates to Undefined are specified elsewhere 1398 [RFC4511]. If an assertion is not Undefined, then the result of the 1399 1400 1401 1402Legg Standards Track [Page 25] 1403 1404RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 1405 1406 1407 assertion is the result of applying the selected matching rule. A 1408 matching rule evaluates to TRUE, and in some cases Undefined, as 1409 specified in the description of the matching rule; otherwise, it 1410 evaluates to FALSE. 1411 1412 Each assertion contains an assertion value. The definition of each 1413 matching rule specifies the syntax for the assertion value. The 1414 syntax of the assertion value is typically, but not necessarily, the 1415 same as the syntax of the attribute values to which the matching rule 1416 may be applied. Note that an AssertionValue in a SubstringFilter 1417 [RFC4511] conforms to the assertion syntax of the equality matching 1418 rule for the attribute type rather than to the assertion syntax of 1419 the substrings matching rule for the attribute type. Conceptually, 1420 the entire SubstringFilter is converted into an assertion value of 1421 the substrings matching rule prior to applying the rule. 1422 1423 The definition of each matching rule indicates the attribute syntaxes 1424 to which the rule may be applied, by specifying conditions the 1425 corresponding ASN.1 type of a candidate attribute syntax must 1426 satisfy. These conditions are also satisfied if the corresponding 1427 ASN.1 type is a tagged or constrained derivative of the ASN.1 type 1428 explicitly mentioned in the rule description (i.e., ASN.1 tags and 1429 constraints are ignored in checking applicability), or is an 1430 alternative reference notation for the explicitly mentioned type. 1431 Each rule description lists, as examples of applicable attribute 1432 syntaxes, the complete list of the syntaxes defined in this document 1433 to which the matching rule applies. A matching rule may be 1434 applicable to additional syntaxes defined in other documents if those 1435 syntaxes satisfy the conditions on the corresponding ASN.1 type. 1436 1437 The description of each matching rule indicates whether the rule is 1438 suitable for use as the equality matching rule (EQUALITY), ordering 1439 matching rule (ORDERING), or substrings matching rule (SUBSTR) in an 1440 attribute type definition [RFC4512]. 1441 1442 Each matching rule is uniquely identified with an object identifier. 1443 The definition of a matching rule should not subsequently be changed. 1444 If a change is desirable, then a new matching rule with a different 1445 object identifier should be defined instead. 1446 1447 Servers MAY implement the wordMatch and keywordMatch matching rules, 1448 but they SHOULD implement the other matching rules in Section 4.2. 1449 Servers MAY implement additional matching rules. 1450 1451 Servers that implement the extensibleMatch filter SHOULD allow the 1452 matching rules listed in Section 4.2 to be used in the 1453 extensibleMatch filter and SHOULD allow matching rules to be used 1454 with all attribute types known to the server, where the assertion 1455 1456 1457 1458Legg Standards Track [Page 26] 1459 1460RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 1461 1462 1463 syntax of the matching rule is the same as the value syntax of the 1464 attribute. 1465 1466 Servers MUST publish, in the matchingRules attribute, the definitions 1467 of matching rules referenced by values of the attributeTypes and 1468 matchingRuleUse attributes in the same subschema entry. Other 1469 unreferenced matching rules MAY be published in the matchingRules 1470 attribute. 1471 1472 If the server supports the extensibleMatch filter, then the server 1473 MAY use the matchingRuleUse attribute to indicate the applicability 1474 (in an extensibleMatch filter) of selected matching rules to 1475 nominated attribute types. 1476 14774.2. Matching Rule Definitions 1478 1479 Nominated character strings in assertion and attribute values are 1480 prepared according to the string preparation algorithms [RFC4518] for 1481 LDAP when evaluating the following matching rules: 1482 1483 numericStringMatch, 1484 numericStringSubstringsMatch, 1485 caseExactMatch, 1486 caseExactOrderingMatch, 1487 caseExactSubstringsMatch, 1488 caseExactIA5Match, 1489 caseIgnoreIA5Match, 1490 caseIgnoreIA5SubstringsMatch, 1491 caseIgnoreListMatch, 1492 caseIgnoreListSubstringsMatch, 1493 caseIgnoreMatch, 1494 caseIgnoreOrderingMatch, 1495 caseIgnoreSubstringsMatch, 1496 directoryStringFirstComponentMatch, 1497 telephoneNumberMatch, 1498 telephoneNumberSubstringsMatch and 1499 wordMatch. 1500 1501 The Transcode, Normalize, Prohibit, and Check bidi steps are the same 1502 for each of the matching rules. However, the Map and Insignificant 1503 Character Handling steps depend on the specific rule, as detailed in 1504 the description of these matching rules in the sections that follow. 1505 15064.2.1. bitStringMatch 1507 1508 The bitStringMatch rule compares an assertion value of the Bit String 1509 syntax to an attribute value of a syntax (e.g., the Bit String 1510 syntax) whose corresponding ASN.1 type is BIT STRING. 1511 1512 1513 1514Legg Standards Track [Page 27] 1515 1516RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 1517 1518 1519 If the corresponding ASN.1 type of the attribute syntax does not have 1520 a named bit list [ASN.1] (which is the case for the Bit String 1521 syntax), then the rule evaluates to TRUE if and only if the attribute 1522 value has the same number of bits as the assertion value and the bits 1523 match on a bitwise basis. 1524 1525 If the corresponding ASN.1 type does have a named bit list, then 1526 bitStringMatch operates as above, except that trailing zero bits in 1527 the attribute and assertion values are treated as absent. 1528 1529 The LDAP definition for the bitStringMatch rule is: 1530 1531 ( 2.5.13.16 NAME 'bitStringMatch' 1532 SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 ) 1533 1534 The bitStringMatch rule is an equality matching rule. 1535 15364.2.2. booleanMatch 1537 1538 The booleanMatch rule compares an assertion value of the Boolean 1539 syntax to an attribute value of a syntax (e.g., the Boolean syntax) 1540 whose corresponding ASN.1 type is BOOLEAN. 1541 1542 The rule evaluates to TRUE if and only if the attribute value and the 1543 assertion value are both TRUE or both FALSE. 1544 1545 The LDAP definition for the booleanMatch rule is: 1546 1547 ( 2.5.13.13 NAME 'booleanMatch' 1548 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 ) 1549 1550 The booleanMatch rule is an equality matching rule. 1551 15524.2.3. caseExactIA5Match 1553 1554 The caseExactIA5Match rule compares an assertion value of the IA5 1555 String syntax to an attribute value of a syntax (e.g., the IA5 String 1556 syntax) whose corresponding ASN.1 type is IA5String. 1557 1558 The rule evaluates to TRUE if and only if the prepared attribute 1559 value character string and the prepared assertion value character 1560 string have the same number of characters and corresponding 1561 characters have the same code point. 1562 1563 In preparing the attribute value and assertion value for comparison, 1564 characters are not case folded in the Map preparation step, and only 1565 Insignificant Space Handling is applied in the Insignificant 1566 Character Handling step. 1567 1568 1569 1570Legg Standards Track [Page 28] 1571 1572RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 1573 1574 1575 The LDAP definition for the caseExactIA5Match rule is: 1576 1577 ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' 1578 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 1579 1580 The caseExactIA5Match rule is an equality matching rule. 1581 15824.2.4. caseExactMatch 1583 1584 The caseExactMatch rule compares an assertion value of the Directory 1585 String syntax to an attribute value of a syntax (e.g., the Directory 1586 String, Printable String, Country String, or Telephone Number syntax) 1587 whose corresponding ASN.1 type is DirectoryString or one of the 1588 alternative string types of DirectoryString, such as PrintableString 1589 (the other alternatives do not correspond to any syntax defined in 1590 this document). 1591 1592 The rule evaluates to TRUE if and only if the prepared attribute 1593 value character string and the prepared assertion value character 1594 string have the same number of characters and corresponding 1595 characters have the same code point. 1596 1597 In preparing the attribute value and assertion value for comparison, 1598 characters are not case folded in the Map preparation step, and only 1599 Insignificant Space Handling is applied in the Insignificant 1600 Character Handling step. 1601 1602 The LDAP definition for the caseExactMatch rule is: 1603 1604 ( 2.5.13.5 NAME 'caseExactMatch' 1605 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 1606 1607 The caseExactMatch rule is an equality matching rule. 1608 16094.2.5. caseExactOrderingMatch 1610 1611 The caseExactOrderingMatch rule compares an assertion value of the 1612 Directory String syntax to an attribute value of a syntax (e.g., the 1613 Directory String, Printable String, Country String, or Telephone 1614 Number syntax) whose corresponding ASN.1 type is DirectoryString or 1615 one of its alternative string types. 1616 1617 The rule evaluates to TRUE if and only if, in the code point 1618 collation order, the prepared attribute value character string 1619 appears earlier than the prepared assertion value character string; 1620 i.e., the attribute value is "less than" the assertion value. 1621 1622 1623 1624 1625 1626Legg Standards Track [Page 29] 1627 1628RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 1629 1630 1631 In preparing the attribute value and assertion value for comparison, 1632 characters are not case folded in the Map preparation step, and only 1633 Insignificant Space Handling is applied in the Insignificant 1634 Character Handling step. 1635 1636 The LDAP definition for the caseExactOrderingMatch rule is: 1637 1638 ( 2.5.13.6 NAME 'caseExactOrderingMatch' 1639 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 1640 1641 The caseExactOrderingMatch rule is an ordering matching rule. 1642 16434.2.6. caseExactSubstringsMatch 1644 1645 The caseExactSubstringsMatch rule compares an assertion value of the 1646 Substring Assertion syntax to an attribute value of a syntax (e.g., 1647 the Directory String, Printable String, Country String, or Telephone 1648 Number syntax) whose corresponding ASN.1 type is DirectoryString or 1649 one of its alternative string types. 1650 1651 The rule evaluates to TRUE if and only if (1) the prepared substrings 1652 of the assertion value match disjoint portions of the prepared 1653 attribute value character string in the order of the substrings in 1654 the assertion value, (2) an <initial> substring, if present, matches 1655 the beginning of the prepared attribute value character string, and 1656 (3) a <final> substring, if present, matches the end of the prepared 1657 attribute value character string. A prepared substring matches a 1658 portion of the prepared attribute value character string if 1659 corresponding characters have the same code point. 1660 1661 In preparing the attribute value and assertion value substrings for 1662 comparison, characters are not case folded in the Map preparation 1663 step, and only Insignificant Space Handling is applied in the 1664 Insignificant Character Handling step. 1665 1666 The LDAP definition for the caseExactSubstringsMatch rule is: 1667 1668 ( 2.5.13.7 NAME 'caseExactSubstringsMatch' 1669 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 1670 1671 The caseExactSubstringsMatch rule is a substrings matching rule. 1672 16734.2.7. caseIgnoreIA5Match 1674 1675 The caseIgnoreIA5Match rule compares an assertion value of the IA5 1676 String syntax to an attribute value of a syntax (e.g., the IA5 String 1677 syntax) whose corresponding ASN.1 type is IA5String. 1678 1679 1680 1681 1682Legg Standards Track [Page 30] 1683 1684RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 1685 1686 1687 The rule evaluates to TRUE if and only if the prepared attribute 1688 value character string and the prepared assertion value character 1689 string have the same number of characters and corresponding 1690 characters have the same code point. 1691 1692 In preparing the attribute value and assertion value for comparison, 1693 characters are case folded in the Map preparation step, and only 1694 Insignificant Space Handling is applied in the Insignificant 1695 Character Handling step. 1696 1697 The LDAP definition for the caseIgnoreIA5Match rule is: 1698 1699 ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' 1700 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 1701 1702 The caseIgnoreIA5Match rule is an equality matching rule. 1703 17044.2.8. caseIgnoreIA5SubstringsMatch 1705 1706 The caseIgnoreIA5SubstringsMatch rule compares an assertion value of 1707 the Substring Assertion syntax to an attribute value of a syntax 1708 (e.g., the IA5 String syntax) whose corresponding ASN.1 type is 1709 IA5String. 1710 1711 The rule evaluates to TRUE if and only if (1) the prepared substrings 1712 of the assertion value match disjoint portions of the prepared 1713 attribute value character string in the order of the substrings in 1714 the assertion value, (2) an <initial> substring, if present, matches 1715 the beginning of the prepared attribute value character string, and 1716 (3) a <final> substring, if present, matches the end of the prepared 1717 attribute value character string. A prepared substring matches a 1718 portion of the prepared attribute value character string if 1719 corresponding characters have the same code point. 1720 1721 In preparing the attribute value and assertion value substrings for 1722 comparison, characters are case folded in the Map preparation step, 1723 and only Insignificant Space Handling is applied in the Insignificant 1724 Character Handling step. 1725 1726 ( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch' 1727 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 1728 1729 The caseIgnoreIA5SubstringsMatch rule is a substrings matching rule. 1730 17314.2.9. caseIgnoreListMatch 1732 1733 The caseIgnoreListMatch rule compares an assertion value that is a 1734 sequence of strings to an attribute value of a syntax (e.g., the 1735 1736 1737 1738Legg Standards Track [Page 31] 1739 1740RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 1741 1742 1743 Postal Address syntax) whose corresponding ASN.1 type is a SEQUENCE 1744 OF the DirectoryString ASN.1 type. 1745 1746 The rule evaluates to TRUE if and only if the attribute value and the 1747 assertion value have the same number of strings and corresponding 1748 strings (by position) match according to the caseIgnoreMatch matching 1749 rule. 1750 1751 In [X.520], the assertion syntax for this matching rule is defined to 1752 be: 1753 1754 SEQUENCE OF DirectoryString {ub-match} 1755 1756 That is, it is different from the corresponding type for the Postal 1757 Address syntax. The choice of the Postal Address syntax for the 1758 assertion syntax of the caseIgnoreListMatch in LDAP should not be 1759 seen as limiting the matching rule to apply only to attributes with 1760 the Postal Address syntax. 1761 1762 The LDAP definition for the caseIgnoreListMatch rule is: 1763 1764 ( 2.5.13.11 NAME 'caseIgnoreListMatch' 1765 SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) 1766 1767 The caseIgnoreListMatch rule is an equality matching rule. 1768 17694.2.10. caseIgnoreListSubstringsMatch 1770 1771 The caseIgnoreListSubstringsMatch rule compares an assertion value of 1772 the Substring Assertion syntax to an attribute value of a syntax 1773 (e.g., the Postal Address syntax) whose corresponding ASN.1 type is a 1774 SEQUENCE OF the DirectoryString ASN.1 type. 1775 1776 The rule evaluates to TRUE if and only if the assertion value 1777 matches, per the caseIgnoreSubstringsMatch rule, the character string 1778 formed by concatenating the strings of the attribute value, except 1779 that none of the <initial>, <any>, or <final> substrings of the 1780 assertion value are considered to match a substring of the 1781 concatenated string which spans more than one of the original strings 1782 of the attribute value. 1783 1784 Note that, in terms of the LDAP-specific encoding of the Postal 1785 Address syntax, the concatenated string omits the <DOLLAR> line 1786 separator and the escaping of "\" and "$" characters. 1787 1788 The LDAP definition for the caseIgnoreListSubstringsMatch rule is: 1789 1790 ( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch' 1791 1792 1793 1794Legg Standards Track [Page 32] 1795 1796RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 1797 1798 1799 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 1800 1801 The caseIgnoreListSubstringsMatch rule is a substrings matching rule. 1802 18034.2.11. caseIgnoreMatch 1804 1805 The caseIgnoreMatch rule compares an assertion value of the Directory 1806 String syntax to an attribute value of a syntax (e.g., the Directory 1807 String, Printable String, Country String, or Telephone Number syntax) 1808 whose corresponding ASN.1 type is DirectoryString or one of its 1809 alternative string types. 1810 1811 The rule evaluates to TRUE if and only if the prepared attribute 1812 value character string and the prepared assertion value character 1813 string have the same number of characters and corresponding 1814 characters have the same code point. 1815 1816 In preparing the attribute value and assertion value for comparison, 1817 characters are case folded in the Map preparation step, and only 1818 Insignificant Space Handling is applied in the Insignificant 1819 Character Handling step. 1820 1821 The LDAP definition for the caseIgnoreMatch rule is: 1822 1823 ( 2.5.13.2 NAME 'caseIgnoreMatch' 1824 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 1825 1826 The caseIgnoreMatch rule is an equality matching rule. 1827 18284.2.12. caseIgnoreOrderingMatch 1829 1830 The caseIgnoreOrderingMatch rule compares an assertion value of the 1831 Directory String syntax to an attribute value of a syntax (e.g., the 1832 Directory String, Printable String, Country String, or Telephone 1833 Number syntax) whose corresponding ASN.1 type is DirectoryString or 1834 one of its alternative string types. 1835 1836 The rule evaluates to TRUE if and only if, in the code point 1837 collation order, the prepared attribute value character string 1838 appears earlier than the prepared assertion value character string; 1839 i.e., the attribute value is "less than" the assertion value. 1840 1841 In preparing the attribute value and assertion value for comparison, 1842 characters are case folded in the Map preparation step, and only 1843 Insignificant Space Handling is applied in the Insignificant 1844 Character Handling step. 1845 1846 The LDAP definition for the caseIgnoreOrderingMatch rule is: 1847 1848 1849 1850Legg Standards Track [Page 33] 1851 1852RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 1853 1854 1855 ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch' 1856 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 1857 1858 The caseIgnoreOrderingMatch rule is an ordering matching rule. 1859 18604.2.13. caseIgnoreSubstringsMatch 1861 1862 The caseIgnoreSubstringsMatch rule compares an assertion value of the 1863 Substring Assertion syntax to an attribute value of a syntax (e.g., 1864 the Directory String, Printable String, Country String, or Telephone 1865 Number syntax) whose corresponding ASN.1 type is DirectoryString or 1866 one of its alternative string types. 1867 1868 The rule evaluates to TRUE if and only if (1) the prepared substrings 1869 of the assertion value match disjoint portions of the prepared 1870 attribute value character string in the order of the substrings in 1871 the assertion value, (2) an <initial> substring, if present, matches 1872 the beginning of the prepared attribute value character string, and 1873 (3) a <final> substring, if present, matches the end of the prepared 1874 attribute value character string. A prepared substring matches a 1875 portion of the prepared attribute value character string if 1876 corresponding characters have the same code point. 1877 1878 In preparing the attribute value and assertion value substrings for 1879 comparison, characters are case folded in the Map preparation step, 1880 and only Insignificant Space Handling is applied in the Insignificant 1881 Character Handling step. 1882 1883 The LDAP definition for the caseIgnoreSubstringsMatch rule is: 1884 1885 ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' 1886 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 1887 1888 The caseIgnoreSubstringsMatch rule is a substrings matching rule. 1889 18904.2.14. directoryStringFirstComponentMatch 1891 1892 The directoryStringFirstComponentMatch rule compares an assertion 1893 value of the Directory String syntax to an attribute value of a 1894 syntax whose corresponding ASN.1 type is a SEQUENCE with a mandatory 1895 first component of the DirectoryString ASN.1 type. 1896 1897 Note that the assertion syntax of this matching rule differs from the 1898 attribute syntax of attributes for which this is the equality 1899 matching rule. 1900 1901 1902 1903 1904 1905 1906Legg Standards Track [Page 34] 1907 1908RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 1909 1910 1911 The rule evaluates to TRUE if and only if the assertion value matches 1912 the first component of the attribute value using the rules of 1913 caseIgnoreMatch. 1914 1915 The LDAP definition for the directoryStringFirstComponentMatch 1916 matching rule is: 1917 1918 ( 2.5.13.31 NAME 'directoryStringFirstComponentMatch' 1919 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 1920 1921 The directoryStringFirstComponentMatch rule is an equality matching 1922 rule. When using directoryStringFirstComponentMatch to compare two 1923 attribute values (of an applicable syntax), an assertion value must 1924 first be derived from one of the attribute values. An assertion 1925 value can be derived from an attribute value by taking the first 1926 component of that attribute value. 1927 19284.2.15. distinguishedNameMatch 1929 1930 The distinguishedNameMatch rule compares an assertion value of the DN 1931 syntax to an attribute value of a syntax (e.g., the DN syntax) whose 1932 corresponding ASN.1 type is DistinguishedName. 1933 1934 The rule evaluates to TRUE if and only if the attribute value and the 1935 assertion value have the same number of relative distinguished names 1936 and corresponding relative distinguished names (by position) are the 1937 same. A relative distinguished name (RDN) of the assertion value is 1938 the same as an RDN of the attribute value if and only if they have 1939 the same number of attribute value assertions and each attribute 1940 value assertion (AVA) of the first RDN is the same as the AVA of the 1941 second RDN with the same attribute type. The order of the AVAs is 1942 not significant. Also note that a particular attribute type may 1943 appear in at most one AVA in an RDN. Two AVAs with the same 1944 attribute type are the same if their values are equal according to 1945 the equality matching rule of the attribute type. If one or more of 1946 the AVA comparisons evaluate to Undefined and the remaining AVA 1947 comparisons return TRUE then the distinguishedNameMatch rule 1948 evaluates to Undefined. 1949 1950 The LDAP definition for the distinguishedNameMatch rule is: 1951 1952 ( 2.5.13.1 NAME 'distinguishedNameMatch' 1953 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) 1954 1955 The distinguishedNameMatch rule is an equality matching rule. 1956 1957 1958 1959 1960 1961 1962Legg Standards Track [Page 35] 1963 1964RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 1965 1966 19674.2.16. generalizedTimeMatch 1968 1969 The generalizedTimeMatch rule compares an assertion value of the 1970 Generalized Time syntax to an attribute value of a syntax (e.g., the 1971 Generalized Time syntax) whose corresponding ASN.1 type is 1972 GeneralizedTime. 1973 1974 The rule evaluates to TRUE if and only if the attribute value 1975 represents the same universal coordinated time as the assertion 1976 value. If a time is specified with the minutes or seconds absent, 1977 then the number of minutes or seconds (respectively) is assumed to be 1978 zero. 1979 1980 The LDAP definition for the generalizedTimeMatch rule is: 1981 1982 ( 2.5.13.27 NAME 'generalizedTimeMatch' 1983 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) 1984 1985 The generalizedTimeMatch rule is an equality matching rule. 1986 19874.2.17. generalizedTimeOrderingMatch 1988 1989 The generalizedTimeOrderingMatch rule compares the time ordering of 1990 an assertion value of the Generalized Time syntax to an attribute 1991 value of a syntax (e.g., the Generalized Time syntax) whose 1992 corresponding ASN.1 type is GeneralizedTime. 1993 1994 The rule evaluates to TRUE if and only if the attribute value 1995 represents a universal coordinated time that is earlier than the 1996 universal coordinated time represented by the assertion value. 1997 1998 The LDAP definition for the generalizedTimeOrderingMatch rule is: 1999 2000 ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch' 2001 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) 2002 2003 The generalizedTimeOrderingMatch rule is an ordering matching rule. 2004 20054.2.18. integerFirstComponentMatch 2006 2007 The integerFirstComponentMatch rule compares an assertion value of 2008 the Integer syntax to an attribute value of a syntax (e.g., the DIT 2009 Structure Rule Description syntax) whose corresponding ASN.1 type is 2010 a SEQUENCE with a mandatory first component of the INTEGER ASN.1 2011 type. 2012 2013 2014 2015 2016 2017 2018Legg Standards Track [Page 36] 2019 2020RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 2021 2022 2023 Note that the assertion syntax of this matching rule differs from the 2024 attribute syntax of attributes for which this is the equality 2025 matching rule. 2026 2027 The rule evaluates to TRUE if and only if the assertion value and the 2028 first component of the attribute value are the same integer value. 2029 2030 The LDAP definition for the integerFirstComponentMatch matching rule 2031 is: 2032 2033 ( 2.5.13.29 NAME 'integerFirstComponentMatch' 2034 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) 2035 2036 The integerFirstComponentMatch rule is an equality matching rule. 2037 When using integerFirstComponentMatch to compare two attribute values 2038 (of an applicable syntax), an assertion value must first be derived 2039 from one of the attribute values. An assertion value can be derived 2040 from an attribute value by taking the first component of that 2041 attribute value. 2042 20434.2.19. integerMatch 2044 2045 The integerMatch rule compares an assertion value of the Integer 2046 syntax to an attribute value of a syntax (e.g., the Integer syntax) 2047 whose corresponding ASN.1 type is INTEGER. 2048 2049 The rule evaluates to TRUE if and only if the attribute value and the 2050 assertion value are the same integer value. 2051 2052 The LDAP definition for the integerMatch matching rule is: 2053 2054 ( 2.5.13.14 NAME 'integerMatch' 2055 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) 2056 2057 The integerMatch rule is an equality matching rule. 2058 20594.2.20. integerOrderingMatch 2060 2061 The integerOrderingMatch rule compares an assertion value of the 2062 Integer syntax to an attribute value of a syntax (e.g., the Integer 2063 syntax) whose corresponding ASN.1 type is INTEGER. 2064 2065 The rule evaluates to TRUE if and only if the integer value of the 2066 attribute value is less than the integer value of the assertion 2067 value. 2068 2069 The LDAP definition for the integerOrderingMatch matching rule is: 2070 2071 2072 2073 2074Legg Standards Track [Page 37] 2075 2076RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 2077 2078 2079 ( 2.5.13.15 NAME 'integerOrderingMatch' 2080 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) 2081 2082 The integerOrderingMatch rule is an ordering matching rule. 2083 20844.2.21. keywordMatch 2085 2086 The keywordMatch rule compares an assertion value of the Directory 2087 String syntax to an attribute value of a syntax (e.g., the Directory 2088 String syntax) whose corresponding ASN.1 type is DirectoryString. 2089 2090 The rule evaluates to TRUE if and only if the assertion value 2091 character string matches any keyword in the attribute value. The 2092 identification of keywords in the attribute value and the exactness 2093 of the match are both implementation specific. 2094 2095 The LDAP definition for the keywordMatch rule is: 2096 2097 ( 2.5.13.33 NAME 'keywordMatch' 2098 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 2099 21004.2.22. numericStringMatch 2101 2102 The numericStringMatch rule compares an assertion value of the 2103 Numeric String syntax to an attribute value of a syntax (e.g., the 2104 Numeric String syntax) whose corresponding ASN.1 type is 2105 NumericString. 2106 2107 The rule evaluates to TRUE if and only if the prepared attribute 2108 value character string and the prepared assertion value character 2109 string have the same number of characters and corresponding 2110 characters have the same code point. 2111 2112 In preparing the attribute value and assertion value for comparison, 2113 characters are not case folded in the Map preparation step, and only 2114 numericString Insignificant Character Handling is applied in the 2115 Insignificant Character Handling step. 2116 2117 The LDAP definition for the numericStringMatch matching rule is: 2118 2119 ( 2.5.13.8 NAME 'numericStringMatch' 2120 SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) 2121 2122 The numericStringMatch rule is an equality matching rule. 2123 2124 2125 2126 2127 2128 2129 2130Legg Standards Track [Page 38] 2131 2132RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 2133 2134 21354.2.23. numericStringOrderingMatch 2136 2137 The numericStringOrderingMatch rule compares an assertion value of 2138 the Numeric String syntax to an attribute value of a syntax (e.g., 2139 the Numeric String syntax) whose corresponding ASN.1 type is 2140 NumericString. 2141 2142 The rule evaluates to TRUE if and only if, in the code point 2143 collation order, the prepared attribute value character string 2144 appears earlier than the prepared assertion value character string; 2145 i.e., the attribute value is "less than" the assertion value. 2146 2147 In preparing the attribute value and assertion value for comparison, 2148 characters are not case folded in the Map preparation step, and only 2149 numericString Insignificant Character Handling is applied in the 2150 Insignificant Character Handling step. 2151 2152 The rule is identical to the caseIgnoreOrderingMatch rule except that 2153 all space characters are skipped during comparison (case is 2154 irrelevant as the characters are numeric). 2155 2156 The LDAP definition for the numericStringOrderingMatch matching rule 2157 is: 2158 2159 ( 2.5.13.9 NAME 'numericStringOrderingMatch' 2160 SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) 2161 2162 The numericStringOrderingMatch rule is an ordering matching rule. 2163 21644.2.24. numericStringSubstringsMatch 2165 2166 The numericStringSubstringsMatch rule compares an assertion value of 2167 the Substring Assertion syntax to an attribute value of a syntax 2168 (e.g., the Numeric String syntax) whose corresponding ASN.1 type is 2169 NumericString. 2170 2171 The rule evaluates to TRUE if and only if (1) the prepared substrings 2172 of the assertion value match disjoint portions of the prepared 2173 attribute value character string in the order of the substrings in 2174 the assertion value, (2) an <initial> substring, if present, matches 2175 the beginning of the prepared attribute value character string, and 2176 (3) a <final> substring, if present, matches the end of the prepared 2177 attribute value character string. A prepared substring matches a 2178 portion of the prepared attribute value character string if 2179 corresponding characters have the same code point. 2180 2181 In preparing the attribute value and assertion value for comparison, 2182 characters are not case folded in the Map preparation step, and only 2183 2184 2185 2186Legg Standards Track [Page 39] 2187 2188RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 2189 2190 2191 numericString Insignificant Character Handling is applied in the 2192 Insignificant Character Handling step. 2193 2194 The LDAP definition for the numericStringSubstringsMatch matching 2195 rule is: 2196 2197 ( 2.5.13.10 NAME 'numericStringSubstringsMatch' 2198 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 2199 2200 The numericStringSubstringsMatch rule is a substrings matching rule. 2201 22024.2.25. objectIdentifierFirstComponentMatch 2203 2204 The objectIdentifierFirstComponentMatch rule compares an assertion 2205 value of the OID syntax to an attribute value of a syntax (e.g., the 2206 Attribute Type Description, DIT Content Rule Description, LDAP Syntax 2207 Description, Matching Rule Description, Matching Rule Use 2208 Description, Name Form Description, or Object Class Description 2209 syntax) whose corresponding ASN.1 type is a SEQUENCE with a mandatory 2210 first component of the OBJECT IDENTIFIER ASN.1 type. 2211 2212 Note that the assertion syntax of this matching rule differs from the 2213 attribute syntax of attributes for which this is the equality 2214 matching rule. 2215 2216 The rule evaluates to TRUE if and only if the assertion value matches 2217 the first component of the attribute value using the rules of 2218 objectIdentifierMatch. 2219 2220 The LDAP definition for the objectIdentifierFirstComponentMatch 2221 matching rule is: 2222 2223 ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch' 2224 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) 2225 2226 The objectIdentifierFirstComponentMatch rule is an equality matching 2227 rule. When using objectIdentifierFirstComponentMatch to compare two 2228 attribute values (of an applicable syntax), an assertion value must 2229 first be derived from one of the attribute values. An assertion 2230 value can be derived from an attribute value by taking the first 2231 component of that attribute value. 2232 22334.2.26. objectIdentifierMatch 2234 2235 The objectIdentifierMatch rule compares an assertion value of the OID 2236 syntax to an attribute value of a syntax (e.g., the OID syntax) whose 2237 corresponding ASN.1 type is OBJECT IDENTIFIER. 2238 2239 2240 2241 2242Legg Standards Track [Page 40] 2243 2244RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 2245 2246 2247 The rule evaluates to TRUE if and only if the assertion value and the 2248 attribute value represent the same object identifier; that is, the 2249 same sequence of integers, whether represented explicitly in the 2250 <numericoid> form of <oid> or implicitly in the <descr> form (see 2251 [RFC4512]). 2252 2253 If an LDAP client supplies an assertion value in the <descr> form and 2254 the chosen descriptor is not recognized by the server, then the 2255 objectIdentifierMatch rule evaluates to Undefined. 2256 2257 The LDAP definition for the objectIdentifierMatch matching rule is: 2258 2259 ( 2.5.13.0 NAME 'objectIdentifierMatch' 2260 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) 2261 2262 The objectIdentifierMatch rule is an equality matching rule. 2263 22644.2.27. octetStringMatch 2265 2266 The octetStringMatch rule compares an assertion value of the Octet 2267 String syntax to an attribute value of a syntax (e.g., the Octet 2268 String or JPEG syntax) whose corresponding ASN.1 type is the OCTET 2269 STRING ASN.1 type. 2270 2271 The rule evaluates to TRUE if and only if the attribute value and the 2272 assertion value are the same length and corresponding octets (by 2273 position) are the same. 2274 2275 The LDAP definition for the octetStringMatch matching rule is: 2276 2277 ( 2.5.13.17 NAME 'octetStringMatch' 2278 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) 2279 2280 The octetStringMatch rule is an equality matching rule. 2281 22824.2.28. octetStringOrderingMatch 2283 2284 The octetStringOrderingMatch rule compares an assertion value of the 2285 Octet String syntax to an attribute value of a syntax (e.g., the 2286 Octet String or JPEG syntax) whose corresponding ASN.1 type is the 2287 OCTET STRING ASN.1 type. 2288 2289 The rule evaluates to TRUE if and only if the attribute value appears 2290 earlier in the collation order than the assertion value. The rule 2291 compares octet strings from the first octet to the last octet, and 2292 from the most significant bit to the least significant bit within the 2293 octet. The first occurrence of a different bit determines the 2294 ordering of the strings. A zero bit precedes a one bit. If the 2295 2296 2297 2298Legg Standards Track [Page 41] 2299 2300RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 2301 2302 2303 strings contain different numbers of octets but the longer string is 2304 identical to the shorter string up to the length of the shorter 2305 string, then the shorter string precedes the longer string. 2306 2307 The LDAP definition for the octetStringOrderingMatch matching rule 2308 is: 2309 2310 ( 2.5.13.18 NAME 'octetStringOrderingMatch' 2311 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) 2312 2313 The octetStringOrderingMatch rule is an ordering matching rule. 2314 23154.2.29. telephoneNumberMatch 2316 2317 The telephoneNumberMatch rule compares an assertion value of the 2318 Telephone Number syntax to an attribute value of a syntax (e.g., the 2319 Telephone Number syntax) whose corresponding ASN.1 type is a 2320 PrintableString representing a telephone number. 2321 2322 The rule evaluates to TRUE if and only if the prepared attribute 2323 value character string and the prepared assertion value character 2324 string have the same number of characters and corresponding 2325 characters have the same code point. 2326 2327 In preparing the attribute value and assertion value for comparison, 2328 characters are case folded in the Map preparation step, and only 2329 telephoneNumber Insignificant Character Handling is applied in the 2330 Insignificant Character Handling step. 2331 2332 The LDAP definition for the telephoneNumberMatch matching rule is: 2333 2334 ( 2.5.13.20 NAME 'telephoneNumberMatch' 2335 SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) 2336 2337 The telephoneNumberMatch rule is an equality matching rule. 2338 23394.2.30. telephoneNumberSubstringsMatch 2340 2341 The telephoneNumberSubstringsMatch rule compares an assertion value 2342 of the Substring Assertion syntax to an attribute value of a syntax 2343 (e.g., the Telephone Number syntax) whose corresponding ASN.1 type is 2344 a PrintableString representing a telephone number. 2345 2346 The rule evaluates to TRUE if and only if (1) the prepared substrings 2347 of the assertion value match disjoint portions of the prepared 2348 attribute value character string in the order of the substrings in 2349 the assertion value, (2) an <initial> substring, if present, matches 2350 the beginning of the prepared attribute value character string, and 2351 2352 2353 2354Legg Standards Track [Page 42] 2355 2356RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 2357 2358 2359 (3) a <final> substring, if present, matches the end of the prepared 2360 attribute value character string. A prepared substring matches a 2361 portion of the prepared attribute value character string if 2362 corresponding characters have the same code point. 2363 2364 In preparing the attribute value and assertion value substrings for 2365 comparison, characters are case folded in the Map preparation step, 2366 and only telephoneNumber Insignificant Character Handling is applied 2367 in the Insignificant Character Handling step. 2368 2369 The LDAP definition for the telephoneNumberSubstringsMatch matching 2370 rule is: 2371 2372 ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch' 2373 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 2374 2375 The telephoneNumberSubstringsMatch rule is a substrings matching 2376 rule. 2377 23784.2.31. uniqueMemberMatch 2379 2380 The uniqueMemberMatch rule compares an assertion value of the Name 2381 And Optional UID syntax to an attribute value of a syntax (e.g., the 2382 Name And Optional UID syntax) whose corresponding ASN.1 type is 2383 NameAndOptionalUID. 2384 2385 The rule evaluates to TRUE if and only if the <distinguishedName> 2386 components of the assertion value and attribute value match according 2387 to the distinguishedNameMatch rule and either, (1) the <BitString> 2388 component is absent from both the attribute value and assertion 2389 value, or (2) the <BitString> component is present in both the 2390 attribute value and the assertion value and the <BitString> component 2391 of the assertion value matches the <BitString> component of the 2392 attribute value according to the bitStringMatch rule. 2393 2394 Note that this matching rule has been altered from its description in 2395 X.520 [X.520] in order to make the matching rule commutative. Server 2396 implementors should consider using the original X.520 semantics 2397 (where the matching was less exact) for approximate matching of 2398 attributes with uniqueMemberMatch as the equality matching rule. 2399 2400 The LDAP definition for the uniqueMemberMatch matching rule is: 2401 2402 ( 2.5.13.23 NAME 'uniqueMemberMatch' 2403 SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 ) 2404 2405 The uniqueMemberMatch rule is an equality matching rule. 2406 2407 2408 2409 2410Legg Standards Track [Page 43] 2411 2412RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 2413 2414 24154.2.32. wordMatch 2416 2417 The wordMatch rule compares an assertion value of the Directory 2418 String syntax to an attribute value of a syntax (e.g., the Directory 2419 String syntax) whose corresponding ASN.1 type is DirectoryString. 2420 2421 The rule evaluates to TRUE if and only if the assertion value word 2422 matches, according to the semantics of caseIgnoreMatch, any word in 2423 the attribute value. The precise definition of a word is 2424 implementation specific. 2425 2426 The LDAP definition for the wordMatch rule is: 2427 2428 ( 2.5.13.32 NAME 'wordMatch' 2429 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 2430 24315. Security Considerations 2432 2433 In general, the LDAP-specific encodings for syntaxes defined in this 2434 document do not define canonical encodings. That is, a 2435 transformation from an LDAP-specific encoding into some other 2436 encoding (e.g., BER) and back into the LDAP-specific encoding will 2437 not necessarily reproduce exactly the original octets of the LDAP- 2438 specific encoding. Therefore, an LDAP-specific encoding should not 2439 be used where a canonical encoding is required. 2440 2441 Furthermore, the LDAP-specific encodings do not necessarily enable an 2442 alternative encoding of values of the Directory String and DN 2443 syntaxes to be reconstructed; e.g., a transformation from a 2444 Distinguished Encoding Rules (DER) [BER] encoding to an LDAP-specific 2445 encoding and back to a DER encoding may not reproduce the original 2446 DER encoding. Therefore, LDAP-specific encodings should not be used 2447 where reversibility to DER is needed; e.g., for the verification of 2448 digital signatures. Instead, DER or a DER-reversible encoding should 2449 be used. 2450 2451 When interpreting security-sensitive fields (in particular, fields 2452 used to grant or deny access), implementations MUST ensure that any 2453 matching rule comparisons are done on the underlying abstract value, 2454 regardless of the particular encoding used. 2455 24566. Acknowledgements 2457 2458 This document is primarily a revision of RFC 2252 by M. Wahl, A. 2459 Coulbeck, T. Howes, and S. Kille. RFC 2252 was a product of the IETF 2460 ASID Working Group. 2461 2462 2463 2464 2465 2466Legg Standards Track [Page 44] 2467 2468RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 2469 2470 2471 This document is based on input from the IETF LDAPBIS working group. 2472 The author would like to thank Kathy Dally for editing the early 2473 drafts of this document, and Jim Sermersheim and Kurt Zeilenga for 2474 their significant contributions to this revision. 2475 24767. IANA Considerations 2477 2478 The Internet Assigned Numbers Authority (IANA) has updated the LDAP 2479 descriptors registry [BCP64] as indicated by the following templates: 2480 2481 Subject: Request for LDAP Descriptor Registration Update 2482 Descriptor (short name): see comment 2483 Object Identifier: see comment 2484 Person & email address to contact for further information: 2485 Steven Legg <steven.legg@eb2bcom.com> 2486 Usage: see comment 2487 Specification: RFC 4517 2488 Author/Change Controller: IESG 2489 2490 NAME Type OID 2491 ------------------------------------------------------------------ 2492 bitStringMatch M 2.5.13.16 2493 booleanMatch M 2.5.13.13 2494 caseExactIA5Match M 1.3.6.1.4.1.1466.109.114.1 2495 caseExactMatch M 2.5.13.5 2496 caseExactOrderingMatch M 2.5.13.6 2497 caseExactSubstringsMatch M 2.5.13.7 2498 caseIgnoreIA5Match M 1.3.6.1.4.1.1466.109.114.2 2499 caseIgnoreListMatch M 2.5.13.11 2500 caseIgnoreListSubstringsMatch M 2.5.13.12 2501 caseIgnoreMatch M 2.5.13.2 2502 caseIgnoreOrderingMatch M 2.5.13.3 2503 caseIgnoreSubstringsMatch M 2.5.13.4 2504 directoryStringFirstComponentMatch M 2.5.13.31 2505 distinguishedNameMatch M 2.5.13.1 2506 generalizedTimeMatch M 2.5.13.27 2507 generalizedTimeOrderingMatch M 2.5.13.28 2508 integerFirstComponentMatch M 2.5.13.29 2509 integerMatch M 2.5.13.14 2510 integerOrderingMatch M 2.5.13.15 2511 keywordMatch M 2.5.13.33 2512 numericStringMatch M 2.5.13.8 2513 numericStringOrderingMatch M 2.5.13.9 2514 numericStringSubstringsMatch M 2.5.13.10 2515 objectIdentifierFirstComponentMatch M 2.5.13.30 2516 octetStringMatch M 2.5.13.17 2517 octetStringOrderingMatch M 2.5.13.18 2518 telephoneNumberMatch M 2.5.13.20 2519 2520 2521 2522Legg Standards Track [Page 45] 2523 2524RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 2525 2526 2527 telephoneNumberSubstringsMatch M 2.5.13.21 2528 uniqueMemberMatch M 2.5.13.23 2529 wordMatch M 2.5.13.32 2530 2531 The descriptor for the object identifier 2.5.13.0 was incorrectly 2532 registered as objectIdentifiersMatch (extraneous \`s') in BCP 64. 2533 It has been changed to the following, with a reference to 2534 RFC 4517. 2535 2536 NAME Type OID 2537 ------------------------------------------------------------------ 2538 objectIdentifierMatch M 2.5.13.0 2539 2540 Subject: Request for LDAP Descriptor Registration 2541 Descriptor (short name): caseIgnoreIA5SubstringsMatch 2542 Object Identifier: 1.3.6.1.4.1.1466.109.114.3 2543 Person & email address to contact for further information: 2544 Steven Legg <steven.legg@eb2bcom.com> 2545 Usage: other (M) 2546 Specification: RFC 4517 2547 Author/Change Controller: IESG 2548 25498. References 2550 25518.1. Normative References 2552 2553 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2554 Requirement Levels", BCP 14, RFC 2119, March 1997. 2555 2556 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2557 10646", STD 63, RFC 3629, November 2003. 2558 2559 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2560 Specifications: ABNF", RFC 4234, October 2005. 2561 2562 [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol 2563 (LDAP): Technical Specification Road Map", RFC 4510, June 2564 2006. 2565 2566 [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 2567 Protocol (LDAP): The Protocol", RFC 4511, June 2006. 2568 2569 [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol 2570 (LDAP): Directory Information Models", RFC 4512, June 2571 2006. 2572 2573 2574 2575 2576 2577 2578Legg Standards Track [Page 46] 2579 2580RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 2581 2582 2583 [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol 2584 (LDAP): String Representation of Distinguished Names", RFC 2585 4514, June 2006. 2586 2587 [RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol 2588 (LDAP): Internationalized String Preparation", RFC 4518, 2589 June 2006. 2590 2591 [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) 2592 Considerations for the Lightweight Directory Access 2593 Protocol (LDAP)", BCP 64, RFC 4520, June 2006. 2594 2595 [E.123] Notation for national and international telephone numbers, 2596 ITU-T Recommendation E.123, 1988. 2597 2598 [FAX] Standardization of Group 3 facsimile apparatus for 2599 document transmission - Terminal Equipment and Protocols 2600 for Telematic Services, ITU-T Recommendation T.4, 1993 2601 2602 [T.50] International Reference Alphabet (IRA) (Formerly 2603 International Alphabet No. 5 or IA5) Information 2604 Technology - 7-Bit Coded Character Set for Information 2605 Interchange, ITU-T Recommendation T.50, 1992 2606 2607 [X.420] ITU-T Recommendation X.420 (1996) | ISO/IEC 10021-7:1997, 2608 Information Technology - Message Handling Systems (MHS): 2609 Interpersonal messaging system 2610 2611 [X.501] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994, 2612 Information Technology - Open Systems Interconnection - 2613 The Directory: Models 2614 2615 [X.520] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994, 2616 Information Technology - Open Systems Interconnection - 2617 The Directory: Selected attribute types 2618 2619 [ASN.1] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002, 2620 Information technology - Abstract Syntax Notation One 2621 (ASN.1): Specification of basic notation 2622 2623 [ISO3166] ISO 3166, "Codes for the representation of names of 2624 countries". 2625 2626 [ISO8601] ISO 8601:2004, "Data elements and interchange formats -- 2627 Information interchange -- Representation of dates and 2628 times". 2629 2630 2631 2632 2633 2634Legg Standards Track [Page 47] 2635 2636RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 2637 2638 2639 [UCS] Universal Multiple-Octet Coded Character Set (UCS) - 2640 Architecture and Basic Multilingual Plane, ISO/IEC 10646- 2641 1: 1993 (with amendments). 2642 2643 [JPEG] JPEG File Interchange Format (Version 1.02). Eric 2644 Hamilton, C-Cube Microsystems, Milpitas, CA, September 1, 2645 1992. 2646 26478.2. Informative References 2648 2649 [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol 2650 (LDAP): Schema for User Applications", RFC 4519, June 2651 2006. 2652 2653 [RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol 2654 (LDAP) Schema Definitions for X.509 Certificates", RFC 2655 4523, June 2006. 2656 2657 [X.500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994, 2658 Information Technology - Open Systems Interconnection - 2659 The Directory: Overview of concepts, models and services 2660 2661 [BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1:2002, 2662 Information technology - ASN.1 encoding rules: 2663 Specification of Basic Encoding Rules (BER), Canonical 2664 Encoding Rules (CER) and Distinguished Encoding Rules 2665 (DER) 2666 2667 2668 2669 2670 2671 2672 2673 2674 2675 2676 2677 2678 2679 2680 2681 2682 2683 2684 2685 2686 2687 2688 2689 2690Legg Standards Track [Page 48] 2691 2692RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 2693 2694 2695Appendix A. Summary of Syntax Object Identifiers 2696 2697 The following list summarizes the object identifiers assigned to the 2698 syntaxes defined in this document. 2699 2700 Syntax OBJECT IDENTIFIER 2701 ============================================================== 2702 Attribute Type Description 1.3.6.1.4.1.1466.115.121.1.3 2703 Bit String 1.3.6.1.4.1.1466.115.121.1.6 2704 Boolean 1.3.6.1.4.1.1466.115.121.1.7 2705 Country String 1.3.6.1.4.1.1466.115.121.1.11 2706 Delivery Method 1.3.6.1.4.1.1466.115.121.1.14 2707 Directory String 1.3.6.1.4.1.1466.115.121.1.15 2708 DIT Content Rule Description 1.3.6.1.4.1.1466.115.121.1.16 2709 DIT Structure Rule Description 1.3.6.1.4.1.1466.115.121.1.17 2710 DN 1.3.6.1.4.1.1466.115.121.1.12 2711 Enhanced Guide 1.3.6.1.4.1.1466.115.121.1.21 2712 Facsimile Telephone Number 1.3.6.1.4.1.1466.115.121.1.22 2713 Fax 1.3.6.1.4.1.1466.115.121.1.23 2714 Generalized Time 1.3.6.1.4.1.1466.115.121.1.24 2715 Guide 1.3.6.1.4.1.1466.115.121.1.25 2716 IA5 String 1.3.6.1.4.1.1466.115.121.1.26 2717 Integer 1.3.6.1.4.1.1466.115.121.1.27 2718 JPEG 1.3.6.1.4.1.1466.115.121.1.28 2719 LDAP Syntax Description 1.3.6.1.4.1.1466.115.121.1.54 2720 Matching Rule Description 1.3.6.1.4.1.1466.115.121.1.30 2721 Matching Rule Use Description 1.3.6.1.4.1.1466.115.121.1.31 2722 Name And Optional UID 1.3.6.1.4.1.1466.115.121.1.34 2723 Name Form Description 1.3.6.1.4.1.1466.115.121.1.35 2724 Numeric String 1.3.6.1.4.1.1466.115.121.1.36 2725 Object Class Description 1.3.6.1.4.1.1466.115.121.1.37 2726 Octet String 1.3.6.1.4.1.1466.115.121.1.40 2727 OID 1.3.6.1.4.1.1466.115.121.1.38 2728 Other Mailbox 1.3.6.1.4.1.1466.115.121.1.39 2729 Postal Address 1.3.6.1.4.1.1466.115.121.1.41 2730 Printable String 1.3.6.1.4.1.1466.115.121.1.44 2731 Substring Assertion 1.3.6.1.4.1.1466.115.121.1.58 2732 Telephone Number 1.3.6.1.4.1.1466.115.121.1.50 2733 Teletex Terminal Identifier 1.3.6.1.4.1.1466.115.121.1.51 2734 Telex Number 1.3.6.1.4.1.1466.115.121.1.52 2735 UTC Time 1.3.6.1.4.1.1466.115.121.1.53 2736 2737Appendix B. Changes from RFC 2252 2738 2739 This annex lists the significant differences between this 2740 specification and RFC 2252. 2741 2742 2743 2744 2745 2746Legg Standards Track [Page 49] 2747 2748RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 2749 2750 2751 This annex is provided for informational purposes only. It is not a 2752 normative part of this specification. 2753 2754 1. The IESG Note has been removed. 2755 2756 2. The major part of Sections 4, 5 and 7 has been moved to [RFC4512] 2757 and revised. Changes to the parts of these sections moved to 2758 [RFC4512] are detailed in [RFC4512]. 2759 2760 3. BNF descriptions of syntax formats have been replaced by ABNF 2761 [RFC4234] specifications. 2762 2763 4. The ambiguous statement in RFC 2252, Section 4.3 regarding the 2764 use of a backslash quoting mechanism to escape separator symbols 2765 has been removed. The escaping mechanism is now explicitly 2766 represented in the ABNF for the syntaxes where this provision 2767 applies. 2768 2769 5. The description of each of the LDAP syntaxes has been expanded so 2770 that they are less dependent on knowledge of X.500 for 2771 interpretation. 2772 2773 6. The relationship of LDAP syntaxes to corresponding ASN.1 type 2774 definitions has been made explicit. 2775 2776 7. The set of characters allowed in a <PrintableString> (formerly 2777 <printablestring>) has been corrected to align with the 2778 PrintableString ASN.1 type in [ASN.1]. Specifically, the double 2779 quote character has been removed and the single quote character 2780 and equals sign have been added. 2781 2782 8. Values of the Directory String, Printable String and Telephone 2783 Number syntaxes are now required to have at least one character. 2784 2785 9. The <DITContentRuleDescription>, <NameFormDescription> and 2786 <DITStructureRuleDescription> rules have been moved to [RFC4512]. 2787 2788 10. The corresponding ASN.1 type for the Other Mailbox syntax has 2789 been incorporated from RFC 1274. 2790 2791 11. A corresponding ASN.1 type for the LDAP Syntax Description syntax 2792 has been invented. 2793 2794 12. The Binary syntax has been removed because it was not adequately 2795 specified, implementations with different incompatible 2796 interpretations exist, and it was confused with the ;binary 2797 transfer encoding. 2798 2799 2800 2801 2802Legg Standards Track [Page 50] 2803 2804RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 2805 2806 2807 13. All discussion of transfer options, including the ";binary" 2808 option, has been removed. All imperatives regarding binary 2809 transfer of values have been removed. 2810 2811 14. The Delivery Method, Enhanced Guide, Guide, Octet String, Teletex 2812 Terminal Identifier and Telex Number syntaxes from RFC 2256 have 2813 been incorporated. 2814 2815 15. The <criteria> rule for the Enhanced Guide and Guide syntaxes has 2816 been extended to accommodate empty "and" and "or" expressions. 2817 2818 16. An encoding for the <ttx-value> rule in the Teletex Terminal 2819 Identifier syntax has been defined. 2820 2821 17. The PKI-related syntaxes (Certificate, Certificate List and 2822 Certificate Pair) have been removed. They are reintroduced in 2823 [RFC4523] (as is the Supported Algorithm syntax from RFC 2256). 2824 2825 18. The MHS OR Address syntax has been removed since its 2826 specification (in RFC 2156) is not at draft standard maturity. 2827 2828 19. The DL Submit Permission syntax has been removed as it depends on 2829 the MHS OR Address syntax. 2830 2831 20. The Presentation Address syntax has been removed since its 2832 specification (in RFC 1278) is not at draft standard maturity. 2833 2834 21. The ACI Item, Access Point, Audio, Data Quality, DSA Quality, DSE 2835 Type, LDAP Schema Description, Master And Shadow Access Points, 2836 Modify Rights, Protocol Information, Subtree Specification, 2837 Supplier Information, Supplier Or Consumer and Supplier And 2838 Consumer syntaxes have been removed. These syntaxes are 2839 referenced in RFC 2252, but not defined. 2840 2841 22. The LDAP Schema Definition syntax (defined in RFC 2927) and the 2842 Mail Preference syntax have been removed on the grounds that they 2843 are out of scope for the core specification. 2844 2845 23. The description of each of the matching rules has been expanded 2846 so that they are less dependent on knowledge of X.500 for 2847 interpretation. 2848 2849 24. The caseIgnoreIA5SubstringsMatch matching rule from RFC 2798 has 2850 been added. 2851 2852 25. The caseIgnoreListSubstringsMatch, caseIgnoreOrderingMatch and 2853 caseIgnoreSubstringsMatch matching rules have been added to the 2854 list of matching rules for which the provisions for handling 2855 2856 2857 2858Legg Standards Track [Page 51] 2859 2860RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 2861 2862 2863 leading, trailing and multiple adjoining whitespace characters 2864 apply (now through string preparation). This is consistent with 2865 the definitions of these matching rules in X.500. The 2866 caseIgnoreIA5SubstringsMatch rule has also been added to the 2867 list. 2868 2869 26. The specification of the octetStringMatch matching rule from 2870 RFC 2256 has been added to this document. 2871 2872 27. The presentationAddressMatch matching rule has been removed as it 2873 depends on an assertion syntax (Presentation Address) that is not 2874 at draft standard maturity. 2875 2876 28. The protocolInformationMatch matching rule has been removed as it 2877 depends on an undefined assertion syntax (Protocol Information). 2878 2879 29. The definitive reference for ASN.1 has been changed from X.208 to 2880 X.680 since X.680 is the version of ASN.1 referred to by X.500. 2881 2882 30. The specification of the caseIgnoreListSubstringsMatch matching 2883 rule from RFC 2798 & X.520 has been added. 2884 2885 31. String preparation algorithms have been applied to the character 2886 string matching rules. 2887 2888 32. The specifications of the booleanMatch, caseExactMatch, 2889 caseExactOrderingMatch, caseExactSubstringsMatch, 2890 directoryStringFirstComponentMatch, integerOrderingMatch, 2891 keywordMatch, numericStringOrderingMatch, 2892 octetStringOrderingMatch and wordMatch matching rules from 2893 RFC 3698 & X.520 have been added. 2894 2895Author's Address 2896 2897 Steven Legg 2898 eB2Bcom 2899 Suite3, Woodhouse Corporate Centre 2900 935 Station Street 2901 Box Hill North, Victoria 3129 2902 AUSTRALIA 2903 2904 Phone: +61 3 9896 7830 2905 Fax: +61 3 9896 7801 2906 EMail: steven.legg@eb2bcom.com 2907 2908 2909 2910 2911 2912 2913 2914Legg Standards Track [Page 52] 2915 2916RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 2917 2918 2919Full Copyright Statement 2920 2921 Copyright (C) The Internet Society (2006). 2922 2923 This document is subject to the rights, licenses and restrictions 2924 contained in BCP 78, and except as set forth therein, the authors 2925 retain all their rights. 2926 2927 This document and the information contained herein are provided on an 2928 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2929 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2930 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2931 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2932 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2933 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2934 2935Intellectual Property 2936 2937 The IETF takes no position regarding the validity or scope of any 2938 Intellectual Property Rights or other rights that might be claimed to 2939 pertain to the implementation or use of the technology described in 2940 this document or the extent to which any license under such rights 2941 might or might not be available; nor does it represent that it has 2942 made any independent effort to identify any such rights. Information 2943 on the procedures with respect to rights in RFC documents can be 2944 found in BCP 78 and BCP 79. 2945 2946 Copies of IPR disclosures made to the IETF Secretariat and any 2947 assurances of licenses to be made available, or the result of an 2948 attempt made to obtain a general license or permission for the use of 2949 such proprietary rights by implementers or users of this 2950 specification can be obtained from the IETF on-line IPR repository at 2951 http://www.ietf.org/ipr. 2952 2953 The IETF invites any interested party to bring to its attention any 2954 copyrights, patents or patent applications, or other proprietary 2955 rights that may cover technology that may be required to implement 2956 this standard. Please address the information to the IETF at 2957 ietf-ipr@ietf.org. 2958 2959Acknowledgement 2960 2961 Funding for the RFC Editor function is provided by the IETF 2962 Administrative Support Activity (IASA). 2963 2964 2965 2966 2967 2968 2969 2970Legg Standards Track [Page 53] 2971 2972