1 2 3 4 5 6 7Network Working Group K. Zeilenga 8Request for Comments: 4518 OpenLDAP Foundation 9Category: Standards Track June 2006 10 11 12 Lightweight Directory Access Protocol (LDAP): 13 Internationalized String Preparation 14 15Status of This Memo 16 17 This document specifies an Internet standards track protocol for the 18 Internet community, and requests discussion and suggestions for 19 improvements. Please refer to the current edition of the "Internet 20 Official Protocol Standards" (STD 1) for the standardization state 21 and status of this protocol. Distribution of this memo is unlimited. 22 23Copyright Notice 24 25 Copyright (C) The Internet Society (2006). 26 27Abstract 28 29 The previous Lightweight Directory Access Protocol (LDAP) technical 30 specifications did not precisely define how character string matching 31 is to be performed. This led to a number of usability and 32 interoperability problems. This document defines string preparation 33 algorithms for character-based matching rules defined for use in 34 LDAP. 35 361. Introduction 37 381.1. Background 39 40 A Lightweight Directory Access Protocol (LDAP) [RFC4510] matching 41 rule [RFC4517] defines an algorithm for determining whether a 42 presented value matches an attribute value in accordance with the 43 criteria defined for the rule. The proposition may be evaluated to 44 True, False, or Undefined. 45 46 True - the attribute contains a matching value, 47 48 False - the attribute contains no matching value, 49 50 Undefined - it cannot be determined whether the attribute contains 51 a matching value. 52 53 54 55 56 57 58Zeilenga Standards Track [Page 1] 59 60RFC 4518 LDAP: Internationalized String Preparation June 2006 61 62 63 For instance, the caseIgnoreMatch matching rule may be used to 64 compare whether the commonName attribute contains a particular value 65 without regard for case and insignificant spaces. 66 671.2. X.500 String Matching Rules 68 69 "X.520: Selected attribute types" [X.520] provides (among other 70 things) value syntaxes and matching rules for comparing values 71 commonly used in the directory [X.500]. These specifications are 72 inadequate for strings composed of Unicode [Unicode] characters. 73 74 The caseIgnoreMatch matching rule [X.520], for example, is simply 75 defined as being a case-insensitive comparison where insignificant 76 spaces are ignored. For printableString, there is only one space 77 character and case mapping is bijective, hence this definition is 78 sufficient. However, for Unicode string types such as 79 universalString, this is not sufficient. For example, a case- 80 insensitive matching implementation that folded lowercase characters 81 to uppercase would yield different results than an implementation 82 that used uppercase to lowercase folding. Or one implementation may 83 view space as referring to only SPACE (U+0020), a second 84 implementation may view any character with the space separator (Zs) 85 property as a space, and another implementation may view any 86 character with the whitespace (WS) category as a space. 87 88 The lack of precise specification for character string matching has 89 led to significant interoperability problems. When used in 90 certificate chain validation, security vulnerabilities can arise. To 91 address these problems, this document defines precise algorithms for 92 preparing character strings for matching. 93 941.3. Relationship to "stringprep" 95 96 The character string preparation algorithms described in this 97 document are based upon the "stringprep" approach [RFC3454]. In 98 "stringprep", presented and stored values are first prepared for 99 comparison so that a character-by-character comparison yields the 100 "correct" result. 101 102 The approach used here is a refinement of the "stringprep" [RFC3454] 103 approach. Each algorithm involves two additional preparation steps. 104 105 a) Prior to applying the Unicode string preparation steps outlined in 106 "stringprep", the string is transcoded to Unicode. 107 108 b) After applying the Unicode string preparation steps outlined in 109 "stringprep", the string is modified to appropriately handle 110 characters insignificant to the matching rule. 111 112 113 114Zeilenga Standards Track [Page 2] 115 116RFC 4518 LDAP: Internationalized String Preparation June 2006 117 118 119 Hence, preparation of character strings for X.500 [X.500] matching 120 [X.501] involves the following steps: 121 122 1) Transcode 123 2) Map 124 3) Normalize 125 4) Prohibit 126 5) Check Bidi (Bidirectional) 127 6) Insignificant Character Handling 128 129 These steps are described in Section 2. 130 131 It is noted that while various tables of Unicode characters included 132 or referenced by this specification are derived from Unicode 133 [Unicode] data, these tables are to be considered definitive for the 134 purpose of implementing this specification. 135 1361.4. Relationship to the LDAP Technical Specification 137 138 This document is an integral part of the LDAP technical specification 139 [RFC4510], which obsoletes the previously defined LDAP technical 140 specification [RFC3377] in its entirety. 141 142 This document details new LDAP internationalized character string 143 preparation algorithms used by [RFC4517] and possible other technical 144 specifications defining LDAP syntaxes and/or matching rules. 145 1461.5. Relationship to X.500 147 148 LDAP is defined [RFC4510] in X.500 terms as an X.500 access 149 mechanism. As such, there is a strong desire for alignment between 150 LDAP and X.500 syntax and semantics. The character string 151 preparation algorithms described in this document are based upon 152 "Internationalized String Matching Rules for X.500" [XMATCH] proposal 153 to ITU/ISO Joint Study Group 2. 154 1551.6. Conventions and Terms 156 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in BCP 14 [RFC2119]. 160 161 Character names in this document use the notation for code points and 162 names from the Unicode Standard [Unicode]. For example, the letter 163 "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>. 164 In the lists of mappings and the prohibited characters, the "U+" is 165 166 167 168 169 170Zeilenga Standards Track [Page 3] 171 172RFC 4518 LDAP: Internationalized String Preparation June 2006 173 174 175 left off to make the lists easier to read. The comments for 176 character ranges are shown in square brackets (such as "[CONTROL 177 CHARACTERS]") and do not come from the standard. 178 179 Note: a glossary of terms used in Unicode can be found in [Glossary]. 180 Information on the Unicode character encoding model can be found in 181 [CharModel]. 182 183 The term "combining mark", as used in this specification, refers to 184 any Unicode [Unicode] code point that has a mark property (Mn, Mc, 185 Me). Appendix A provides a definitive list of combining marks. 186 1872. String Preparation 188 189 The following six-step process SHALL be applied to each presented and 190 attribute value in preparation for character string matching rule 191 evaluation. 192 193 1) Transcode 194 2) Map 195 3) Normalize 196 4) Prohibit 197 5) Check bidi 198 6) Insignificant Character Handling 199 200 Failure in any step causes the assertion to evaluate to Undefined. 201 202 The character repertoire of this process is Unicode 3.2 [Unicode]. 203 204 Note that this six-step process specification is intended to describe 205 expected matching behavior. Implementations are free to use 206 alternative processes so long as the matching rule evaluation 207 behavior provided is consistent with the behavior described by this 208 specification. 209 2102.1. Transcode 211 212 Each non-Unicode string value is transcoded to Unicode. 213 214 PrintableString [X.680] values are transcoded directly to Unicode. 215 216 UniversalString, UTF8String, and bmpString [X.680] values need not be 217 transcoded as they are Unicode-based strings (in the case of 218 bmpString, a subset of Unicode). 219 220 TeletexString [X.680] values are transcoded to Unicode. As there is 221 no standard for mapping TeletexString values to Unicode, the mapping 222 is left a local matter. 223 224 225 226Zeilenga Standards Track [Page 4] 227 228RFC 4518 LDAP: Internationalized String Preparation June 2006 229 230 231 For these and other reasons, use of TeletexString is NOT RECOMMENDED. 232 233 The output is the transcoded string. 234 2352.2. Map 236 237 SOFT HYPHEN (U+00AD) and MONGOLIAN TODO SOFT HYPHEN (U+1806) code 238 points are mapped to nothing. COMBINING GRAPHEME JOINER (U+034F) and 239 VARIATION SELECTORs (U+180B-180D, FF00-FE0F) code points are also 240 mapped to nothing. The OBJECT REPLACEMENT CHARACTER (U+FFFC) is 241 mapped to nothing. 242 243 CHARACTER TABULATION (U+0009), LINE FEED (LF) (U+000A), LINE 244 TABULATION (U+000B), FORM FEED (FF) (U+000C), CARRIAGE RETURN (CR) 245 (U+000D), and NEXT LINE (NEL) (U+0085) are mapped to SPACE (U+0020). 246 247 All other control code (e.g., Cc) points or code points with a 248 control function (e.g., Cf) are mapped to nothing. The following is 249 a complete list of these code points: U+0000-0008, 000E-001F, 007F- 250 0084, 0086-009F, 06DD, 070F, 180E, 200C-200F, 202A-202E, 2060-2063, 251 206A-206F, FEFF, FFF9-FFFB, 1D173-1D17A, E0001, E0020-E007F. 252 253 ZERO WIDTH SPACE (U+200B) is mapped to nothing. All other code 254 points with Separator (space, line, or paragraph) property (e.g., Zs, 255 Zl, or Zp) are mapped to SPACE (U+0020). The following is a complete 256 list of these code points: U+0020, 00A0, 1680, 2000-200A, 2028-2029, 257 202F, 205F, 3000. 258 259 For case ignore, numeric, and stored prefix string matching rules, 260 characters are case folded per B.2 of [RFC3454]. 261 262 The output is the mapped string. 263 2642.3. Normalize 265 266 The input string is to be normalized to Unicode Form KC 267 (compatibility composed) as described in [UAX15]. The output is the 268 normalized string. 269 2702.4. Prohibit 271 272 All Unassigned code points are prohibited. Unassigned code points 273 are listed in Table A.1 of [RFC3454]. 274 275 Characters that, per Section 5.8 of [RFC3454], change display 276 properties or are deprecated are prohibited. These characters are 277 listed in Table C.8 of [RFC3454]. 278 279 280 281 282Zeilenga Standards Track [Page 5] 283 284RFC 4518 LDAP: Internationalized String Preparation June 2006 285 286 287 Private Use code points are prohibited. These characters are listed 288 in Table C.3 of [RFC3454]. 289 290 All non-character code points are prohibited. These code points are 291 listed in Table C.4 of [RFC3454]. 292 293 Surrogate codes are prohibited. These characters are listed in Table 294 C.5 of [RFC3454]. 295 296 The REPLACEMENT CHARACTER (U+FFFD) code point is prohibited. 297 298 The step fails if the input string contains any prohibited code 299 point. Otherwise, the output is the input string. 300 3012.5. Check bidi 302 303 Bidirectional characters are ignored. 304 3052.6. Insignificant Character Handling 306 307 In this step, the string is modified to ensure proper handling of 308 characters insignificant to the matching rule. This modification 309 differs from matching rule to matching rule. 310 311 Section 2.6.1 applies to case ignore and exact string matching. 312 Section 2.6.2 applies to numericString matching. 313 Section 2.6.3 applies to telephoneNumber matching. 314 3152.6.1. Insignificant Space Handling 316 317 For the purposes of this section, a space is defined to be the SPACE 318 (U+0020) code point followed by no combining marks. 319 320 NOTE - The previous steps ensure that the string cannot contain 321 any code points in the separator class, other than SPACE 322 (U+0020). 323 324 For input strings that are attribute values or non-substring 325 assertion values: If the input string contains no non-space 326 character, then the output is exactly two SPACEs. Otherwise (the 327 input string contains at least one non-space character), the string 328 is modified such that the string starts with exactly one space 329 character, ends with exactly one SPACE character, and any inner 330 (non-empty) sequence of space characters is replaced with exactly two 331 SPACE characters. For instance, the input strings 332 "foo<SPACE>bar<SPACE><SPACE>", result in the output 333 "<SPACE>foo<SPACE><SPACE>bar<SPACE>". 334 335 336 337 338Zeilenga Standards Track [Page 6] 339 340RFC 4518 LDAP: Internationalized String Preparation June 2006 341 342 343 For input strings that are substring assertion values: If the string 344 being prepared contains no non-space characters, then the output 345 string is exactly one SPACE. Otherwise, the following steps are 346 taken: 347 348 - If the input string is an initial substring, it is modified to 349 start with exactly one SPACE character; 350 351 - If the input string is an initial or an any substring that ends in 352 one or more space characters, it is modified to end with exactly 353 one SPACE character; 354 355 - If the input string is an any or a final substring that starts in 356 one or more space characters, it is modified to start with exactly 357 one SPACE character; and 358 359 - If the input string is a final substring, it is modified to end 360 with exactly one SPACE character. 361 362 For instance, for the input string "foo<SPACE>bar<SPACE><SPACE>" as 363 an initial substring, the output would be 364 "<SPACE>foo<SPACE><SPACE>bar<SPACE>". As an any or final substring, 365 the same input would result in "foo<SPACE>bar<SPACE>". 366 367 Appendix B discusses the rationale for the behavior. 368 3692.6.2. numericString Insignificant Character Handling 370 371 For the purposes of this section, a space is defined to be the SPACE 372 (U+0020) code point followed by no combining marks. 373 374 All spaces are regarded as insignificant and are to be removed. 375 376 For example, removal of spaces from the Form KC string: 377 "<SPACE><SPACE>123<SPACE><SPACE>456<SPACE><SPACE>" 378 would result in the output string: 379 "123456" 380 and the Form KC string: 381 "<SPACE><SPACE><SPACE>" 382 would result in the output string: 383 "" (an empty string). 384 3852.6.3. telephoneNumber Insignificant Character Handling 386 387 For the purposes of this section, a hyphen is defined to be a 388 HYPHEN-MINUS (U+002D), ARMENIAN HYPHEN (U+058A), HYPHEN (U+2010), 389 NON-BREAKING HYPHEN (U+2011), MINUS SIGN (U+2212), SMALL HYPHEN-MINUS 390 (U+FE63), or FULLWIDTH HYPHEN-MINUS (U+FF0D) code point followed by 391 392 393 394Zeilenga Standards Track [Page 7] 395 396RFC 4518 LDAP: Internationalized String Preparation June 2006 397 398 399 no combining marks and a space is defined to be the SPACE (U+0020) 400 code point followed by no combining marks. 401 402 All hyphens and spaces are considered insignificant and are to be 403 removed. 404 405 For example, removal of hyphens and spaces from the Form KC string: 406 "<SPACE><HYPHEN>123<SPACE><SPACE>456<SPACE><HYPHEN>" 407 would result in the output string: 408 "123456" 409 and the Form KC string: 410 "<HYPHEN><HYPHEN><HYPHEN>" 411 would result in the (empty) output string: 412 "". 413 4143. Security Considerations 415 416 "Preparation of Internationalized Strings ("stringprep")" [RFC3454] 417 security considerations generally apply to the algorithms described 418 here. 419 4204. Acknowledgements 421 422 The approach used in this document is based upon design principles 423 and algorithms described in "Preparation of Internationalized Strings 424 ('stringprep')" [RFC3454] by Paul Hoffman and Marc Blanchet. Some 425 additional guidance was drawn from Unicode Technical Standards, 426 Technical Reports, and Notes. 427 428 This document is a product of the IETF LDAP Revision (LDAPBIS) 429 Working Group. 430 4315. References 432 4335.1. Normative References 434 435 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 436 Requirement Levels", BCP 14, RFC 2119, March 1997. 437 438 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 439 Internationalized Strings ("stringprep")", RFC 3454, 440 December 2002. 441 442 [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol 443 (LDAP): Technical Specification Road Map", RFC 4510, 444 June 2006. 445 446 447 448 449 450Zeilenga Standards Track [Page 8] 451 452RFC 4518 LDAP: Internationalized String Preparation June 2006 453 454 455 [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol 456 (LDAP): Syntaxes and Matching Rules", RFC 4517, June 457 2006. 458 459 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 460 3.2.0" is defined by "The Unicode Standard, Version 461 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201- 462 61633-5), as amended by the "Unicode Standard Annex 463 #27: Unicode 3.1" 464 (http://www.unicode.org/reports/tr27/) and by the 465 "Unicode Standard Annex #28: Unicode 3.2" 466 (http://www.unicode.org/reports/tr28/). 467 468 [UAX15] Davis, M. and M. Duerst, "Unicode Standard Annex #15: 469 Unicode Normalization Forms, Version 3.2.0". 470 <http://www.unicode.org/unicode/reports/tr15/tr15- 471 22.html>, March 2002. 472 473 [X.680] International Telecommunication Union - 474 Telecommunication Standardization Sector, "Abstract 475 Syntax Notation One (ASN.1) - Specification of Basic 476 Notation", X.680(2002) (also ISO/IEC 8824-1:2002). 477 4785.2. Informative References 479 480 [X.500] International Telecommunication Union - 481 Telecommunication Standardization Sector, "The 482 Directory -- Overview of concepts, models and 483 services," X.500(1993) (also ISO/IEC 9594-1:1994). 484 485 [X.501] International Telecommunication Union - 486 Telecommunication Standardization Sector, "The 487 Directory -- Models," X.501(1993) (also ISO/IEC 9594- 488 2:1994). 489 490 [X.520] International Telecommunication Union - 491 Telecommunication Standardization Sector, "The 492 Directory: Selected Attribute Types", X.520(1993) (also 493 ISO/IEC 9594-6:1994). 494 495 [Glossary] The Unicode Consortium, "Unicode Glossary", 496 <http://www.unicode.org/glossary/>. 497 498 [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report 499 #17, Character Encoding Model", UTR17, 500 <http://www.unicode.org/unicode/reports/tr17/>, August 501 2000. 502 503 504 505 506Zeilenga Standards Track [Page 9] 507 508RFC 4518 LDAP: Internationalized String Preparation June 2006 509 510 511 [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access 512 Protocol (v3): Technical Specification", RFC 3377, 513 September 2002. 514 515 [RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory 516 Access Protocol (LDAP): String Representation of Search 517 Filters", RFC 4515, June 2006. 518 519 [XMATCH] Zeilenga, K., "Internationalized String Matching Rules 520 for X.500", Work in Progress. 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562Zeilenga Standards Track [Page 10] 563 564RFC 4518 LDAP: Internationalized String Preparation June 2006 565 566 567Appendix A. Combining Marks 568 569 This appendix is normative. 570 571 This table was derived from Unicode [Unicode] data files; it lists 572 all code points with the Mn, Mc, or Me properties. This table is to 573 be considered definitive for the purposes of implementation of this 574 specification. 575 576 0300-034F 0360-036F 0483-0486 0488-0489 0591-05A1 577 05A3-05B9 05BB-05BC 05BF 05C1-05C2 05C4 064B-0655 0670 578 06D6-06DC 06DE-06E4 06E7-06E8 06EA-06ED 0711 0730-074A 579 07A6-07B0 0901-0903 093C 093E-094F 0951-0954 0962-0963 580 0981-0983 09BC 09BE-09C4 09C7-09C8 09CB-09CD 09D7 581 09E2-09E3 0A02 0A3C 0A3E-0A42 0A47-0A48 0A4B-0A4D 582 0A70-0A71 0A81-0A83 0ABC 0ABE-0AC5 0AC7-0AC9 0ACB-0ACD 583 0B01-0B03 0B3C 0B3E-0B43 0B47-0B48 0B4B-0B4D 0B56-0B57 584 0B82 0BBE-0BC2 0BC6-0BC8 0BCA-0BCD 0BD7 0C01-0C03 585 0C3E-0C44 0C46-0C48 0C4A-0C4D 0C55-0C56 0C82-0C83 586 0CBE-0CC4 0CC6-0CC8 0CCA-0CCD 0CD5-0CD6 0D02-0D03 587 0D3E-0D43 0D46-0D48 0D4A-0D4D 0D57 0D82-0D83 0DCA 588 0DCF-0DD4 0DD6 0DD8-0DDF 0DF2-0DF3 0E31 0E34-0E3A 589 0E47-0E4E 0EB1 0EB4-0EB9 0EBB-0EBC 0EC8-0ECD 0F18-0F19 590 0F35 0F37 0F39 0F3E-0F3F 0F71-0F84 0F86-0F87 0F90-0F97 591 0F99-0FBC 0FC6 102C-1032 1036-1039 1056-1059 1712-1714 592 1732-1734 1752-1753 1772-1773 17B4-17D3 180B-180D 18A9 593 20D0-20EA 302A-302F 3099-309A FB1E FE00-FE0F FE20-FE23 594 1D165-1D169 1D16D-1D172 1D17B-1D182 1D185-1D18B 595 1D1AA-1D1AD 596 597Appendix B. Substrings Matching 598 599 This appendix is non-normative. 600 601 In the absence of substrings matching, the insignificant space 602 handling for case ignore/exact matching could be simplified. 603 Specifically, the handling could be to require that all sequences of 604 one or more spaces be replaced with one space and, if the string 605 contains non-space characters, removal of all leading spaces and 606 trailing spaces. 607 608 In the presence of substrings matching, this simplified space 609 handling would lead to unexpected and undesirable matching behavior. 610 For instance: 611 612 1) (CN=foo\20*\20bar) would match the CN value "foobar"; 613 614 615 616 617 618Zeilenga Standards Track [Page 11] 619 620RFC 4518 LDAP: Internationalized String Preparation June 2006 621 622 623 2) (CN=*\20foobar\20*) would match "foobar", but 624 (CN=*\20*foobar*\20*) would not. 625 626 Note to readers not familiar with LDAP substrings matching: the LDAP 627 filter [RFC4515] assertion (CN=A*B*C) says to "match any value (of 628 the attribute CN) that begins with A, contains B after A, ends with C 629 where C is also after B." 630 631 The first case illustrates that this simplified space handling would 632 cause leading and trailing spaces in substrings of the string to be 633 regarded as insignificant. However, only leading and trailing (as 634 well as multiple consecutive spaces) of the string (as a whole) are 635 insignificant. 636 637 The second case illustrates that this simplified space handling would 638 cause sub-partitioning failures. That is, if a prepared any 639 substring matches a partition of the attribute value, then an 640 assertion constructed by subdividing that substring into multiple 641 substrings should also match. 642 643 In designing an appropriate approach for space handling for 644 substrings matching, one must study key aspects of X.500 case 645 exact/ignore matching. X.520 [X.520] says: 646 647 The [substrings] rule returns TRUE if there is a partitioning of 648 the attribute value (into portions) such that: 649 650 - the specified substrings (initial, any, final) match 651 different portions of the value in the order of the strings 652 sequence; 653 654 - initial, if present, matches the first portion of the value; 655 656 - final, if present, matches the last portion of the value; 657 658 - any, if present, matches some arbitrary portion of the 659 value. 660 661 That is, the substrings assertion (CN=foo\20*\20bar) matches the 662 attribute value "foo<SPACE><SPACE>bar" as the value can be 663 partitioned into the portions "foo<SPACE>" and "<SPACE>bar" meeting 664 the above requirements. 665 666 667 668 669 670 671 672 673 674Zeilenga Standards Track [Page 12] 675 676RFC 4518 LDAP: Internationalized String Preparation June 2006 677 678 679 X.520 also says: 680 681 [T]he following spaces are regarded as not significant: 682 683 - leading spaces (i.e., those preceding the first character 684 that is not a space); 685 686 - trailing spaces (i.e., those following the last character 687 that is not a space); 688 689 - multiple consecutive spaces (these are taken as equivalent 690 to a single space character). 691 692 This statement applies to the assertion values and attribute values 693 as whole strings, and not individually to substrings of an assertion 694 value. In particular, the statements should be taken to mean that if 695 an assertion value and attribute value match without any 696 consideration to insignificant characters, then that assertion value 697 should also match any attribute value that differs only by inclusion 698 nor removal of insignificant characters. 699 700 Hence the assertion (CN=foo\20*\20bar) matches 701 "foo<SPACE><SPACE><SPACE>bar" and "foo<SPACE>bar" as these values 702 only differ from "foo<SPACE><SPACE>bar" by the inclusion or removal 703 of insignificant spaces. 704 705 Astute readers of this text will also note that there are special 706 cases where the specified space handling does not ignore spaces that 707 could be considered insignificant. For instance, the assertion 708 (CN=\20*\20*\20) does not match "<SPACE><SPACE><SPACE>" 709 (insignificant spaces present in value) or " " (insignificant spaces 710 not present in value). However, as these cases have no practical 711 application that cannot be met by simple assertions, e.g., (cn=\20), 712 and this minor anomaly can only be fully addressed by a preparation 713 algorithm to be used in conjunction with character-by-character 714 partitioning and matching, the anomaly is considered acceptable. 715 716Author's Address 717 718 Kurt D. Zeilenga 719 OpenLDAP Foundation 720 721 EMail: Kurt@OpenLDAP.org 722 723 724 725 726 727 728 729 730Zeilenga Standards Track [Page 13] 731 732RFC 4518 LDAP: Internationalized String Preparation June 2006 733 734 735Full Copyright Statement 736 737 Copyright (C) The Internet Society (2006). 738 739 This document is subject to the rights, licenses and restrictions 740 contained in BCP 78, and except as set forth therein, the authors 741 retain all their rights. 742 743 This document and the information contained herein are provided on an 744 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 745 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 746 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 747 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 748 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 749 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 750 751Intellectual Property 752 753 The IETF takes no position regarding the validity or scope of any 754 Intellectual Property Rights or other rights that might be claimed to 755 pertain to the implementation or use of the technology described in 756 this document or the extent to which any license under such rights 757 might or might not be available; nor does it represent that it has 758 made any independent effort to identify any such rights. Information 759 on the procedures with respect to rights in RFC documents can be 760 found in BCP 78 and BCP 79. 761 762 Copies of IPR disclosures made to the IETF Secretariat and any 763 assurances of licenses to be made available, or the result of an 764 attempt made to obtain a general license or permission for the use of 765 such proprietary rights by implementers or users of this 766 specification can be obtained from the IETF on-line IPR repository at 767 http://www.ietf.org/ipr. 768 769 The IETF invites any interested party to bring to its attention any 770 copyrights, patents or patent applications, or other proprietary 771 rights that may cover technology that may be required to implement 772 this standard. Please address the information to the IETF at 773 ietf-ipr@ietf.org. 774 775Acknowledgement 776 777 Funding for the RFC Editor function is provided by the IETF 778 Administrative Support Activity (IASA). 779 780 781 782 783 784 785 786Zeilenga Standards Track [Page 14] 787 788