1 2 3 4 5 6 7Network Working Group K. Zeilenga, Ed. 8Request for Comments: 4514 OpenLDAP Foundation 9Obsoletes: 2253 June 2006 10Category: Standards Track 11 12 13 Lightweight Directory Access Protocol (LDAP): 14 String Representation of Distinguished Names 15 16Status of This Memo 17 18 This document specifies an Internet standards track protocol for the 19 Internet community, and requests discussion and suggestions for 20 improvements. Please refer to the current edition of the "Internet 21 Official Protocol Standards" (STD 1) for the standardization state 22 and status of this protocol. Distribution of this memo is unlimited. 23 24Copyright Notice 25 26 Copyright (C) The Internet Society (2006). 27 28Abstract 29 30 The X.500 Directory uses distinguished names (DNs) as primary keys to 31 entries in the directory. This document defines the string 32 representation used in the Lightweight Directory Access Protocol 33 (LDAP) to transfer distinguished names. The string representation is 34 designed to give a clean representation of commonly used 35 distinguished names, while being able to represent any distinguished 36 name. 37 381. Background and Intended Usage 39 40 In X.500-based directory systems [X.500], including those accessed 41 using the Lightweight Directory Access Protocol (LDAP) [RFC4510], 42 distinguished names (DNs) are used to unambiguously refer to 43 directory entries [X.501][RFC4512]. 44 45 The structure of a DN [X.501] is described in terms of ASN.1 [X.680]. 46 In the X.500 Directory Access Protocol [X.511] (and other ITU-defined 47 directory protocols), DNs are encoded using the Basic Encoding Rules 48 (BER) [X.690]. In LDAP, DNs are represented in the string form 49 described in this document. 50 51 It is important to have a common format to be able to unambiguously 52 represent a distinguished name. The primary goal of this 53 specification is ease of encoding and decoding. A secondary goal is 54 to have names that are human readable. It is not expected that LDAP 55 56 57 58Zeilenga Standards Track [Page 1] 59 60RFC 4514 LDAP: Distinguished Names June 2006 61 62 63 implementations with a human user interface would display these 64 strings directly to the user, but that they would most likely be 65 performing translations (such as expressing attribute type names in 66 the local national language). 67 68 This document defines the string representation of Distinguished 69 Names used in LDAP [RFC4511][RFC4517]. Section 2 details the 70 RECOMMENDED algorithm for converting a DN from its ASN.1 structured 71 representation to a string. Section 3 details how to convert a DN 72 from a string to an ASN.1 structured representation. 73 74 While other documents may define other algorithms for converting a DN 75 from its ASN.1 structured representation to a string, all algorithms 76 MUST produce strings that adhere to the requirements of Section 3. 77 78 This document does not define a canonical string representation for 79 DNs. Comparison of DNs for equality is to be performed in accordance 80 with the distinguishedNameMatch matching rule [RFC4517]. 81 82 This document is a integral part of the LDAP technical specification 83 [RFC4510], which obsoletes the previously defined LDAP technical 84 specification, RFC 3377, in its entirety. This document obsoletes 85 RFC 2253. Changes since RFC 2253 are summarized in Appendix B. 86 87 This specification assumes familiarity with X.500 [X.500] and the 88 concept of Distinguished Name [X.501][RFC4512]. 89 901.1. Conventions 91 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in BCP 14 [RFC2119]. 95 96 Character names in this document use the notation for code points and 97 names from the Unicode Standard [Unicode]. For example, the letter 98 "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>. 99 100 Note: a glossary of terms used in Unicode can be found in [Glossary]. 101 Information on the Unicode character encoding model can be found in 102 [CharModel]. 103 104 105 106 107 108 109 110 111 112 113 114Zeilenga Standards Track [Page 2] 115 116RFC 4514 LDAP: Distinguished Names June 2006 117 118 1192. Converting DistinguishedName from ASN.1 to a String 120 121 X.501 [X.501] defines the ASN.1 [X.680] structure of distinguished 122 name. The following is a variant provided for discussion purposes. 123 124 DistinguishedName ::= RDNSequence 125 126 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 127 128 RelativeDistinguishedName ::= SET SIZE (1..MAX) OF 129 AttributeTypeAndValue 130 131 AttributeTypeAndValue ::= SEQUENCE { 132 type AttributeType, 133 value AttributeValue } 134 135 This section defines the RECOMMENDED algorithm for converting a 136 distinguished name from an ASN.1-structured representation to a UTF-8 137 [RFC3629] encoded Unicode [Unicode] character string representation. 138 Other documents may describe other algorithms for converting a 139 distinguished name to a string, but only strings that conform to the 140 grammar defined in Section 3 SHALL be produced by LDAP 141 implementations. 142 1432.1. Converting the RDNSequence 144 145 If the RDNSequence is an empty sequence, the result is the empty or 146 zero-length string. 147 148 Otherwise, the output consists of the string encodings of each 149 RelativeDistinguishedName in the RDNSequence (according to Section 150 2.2), starting with the last element of the sequence and moving 151 backwards toward the first. 152 153 The encodings of adjoining RelativeDistinguishedNames are separated 154 by a comma (',' U+002C) character. 155 1562.2. Converting RelativeDistinguishedName 157 158 When converting from an ASN.1 RelativeDistinguishedName to a string, 159 the output consists of the string encodings of each 160 AttributeTypeAndValue (according to Section 2.3), in any order. 161 162 Where there is a multi-valued RDN, the outputs from adjoining 163 AttributeTypeAndValues are separated by a plus sign ('+' U+002B) 164 character. 165 166 167 168 169 170Zeilenga Standards Track [Page 3] 171 172RFC 4514 LDAP: Distinguished Names June 2006 173 174 1752.3. Converting AttributeTypeAndValue 176 177 The AttributeTypeAndValue is encoded as the string representation of 178 the AttributeType, followed by an equals sign ('=' U+003D) character, 179 followed by the string representation of the AttributeValue. The 180 encoding of the AttributeValue is given in Section 2.4. 181 182 If the AttributeType is defined to have a short name (descriptor) 183 [RFC4512] and that short name is known to be registered [REGISTRY] 184 [RFC4520] as identifying the AttributeType, that short name, a 185 <descr>, is used. Otherwise the AttributeType is encoded as the 186 dotted-decimal encoding, a <numericoid>, of its OBJECT IDENTIFIER. 187 The <descr> and <numericoid> are defined in [RFC4512]. 188 189 Implementations are not expected to dynamically update their 190 knowledge of registered short names. However, implementations SHOULD 191 provide a mechanism to allow their knowledge of registered short 192 names to be updated. 193 1942.4. Converting an AttributeValue from ASN.1 to a String 195 196 If the AttributeType is of the dotted-decimal form, the 197 AttributeValue is represented by an number sign ('#' U+0023) 198 character followed by the hexadecimal encoding of each of the octets 199 of the BER encoding of the X.500 AttributeValue. This form is also 200 used when the syntax of the AttributeValue does not have an LDAP- 201 specific ([RFC4517], Section 3.1) string encoding defined for it, or 202 the LDAP-specific string encoding is not restricted to UTF-8-encoded 203 Unicode characters. This form may also be used in other cases, such 204 as when a reversible string representation is desired (see Section 205 5.2). 206 207 Otherwise, if the AttributeValue is of a syntax that has a LDAP- 208 specific string encoding, the value is converted first to a UTF-8- 209 encoded Unicode string according to its syntax specification (see 210 [RFC4517], Section 3.3, for examples). If that UTF-8-encoded Unicode 211 string does not have any of the following characters that need 212 escaping, then that string can be used as the string representation 213 of the value. 214 215 - a space (' ' U+0020) or number sign ('#' U+0023) occurring at 216 the beginning of the string; 217 218 - a space (' ' U+0020) character occurring at the end of the 219 string; 220 221 222 223 224 225 226Zeilenga Standards Track [Page 4] 227 228RFC 4514 LDAP: Distinguished Names June 2006 229 230 231 - one of the characters '"', '+', ',', ';', '<', '>', or '\' 232 (U+0022, U+002B, U+002C, U+003B, U+003C, U+003E, or U+005C, 233 respectively); 234 235 - the null (U+0000) character. 236 237 Other characters may be escaped. 238 239 Each octet of the character to be escaped is replaced by a backslash 240 and two hex digits, which form a single octet in the code of the 241 character. Alternatively, if and only if the character to be escaped 242 is one of 243 244 ' ', '"', '#', '+', ',', ';', '<', '=', '>', or '\' 245 (U+0020, U+0022, U+0023, U+002B, U+002C, U+003B, 246 U+003C, U+003D, U+003E, U+005C, respectively) 247 248 it can be prefixed by a backslash ('\' U+005C). 249 250 Examples of the escaping mechanism are shown in Section 4. 251 2523. Parsing a String Back to a Distinguished Name 253 254 The string representation of Distinguished Names is restricted to 255 UTF-8 [RFC3629] encoded Unicode [Unicode] characters. The structure 256 of this string representation is specified using the following 257 Augmented BNF [RFC4234] grammar: 258 259 distinguishedName = [ relativeDistinguishedName 260 *( COMMA relativeDistinguishedName ) ] 261 relativeDistinguishedName = attributeTypeAndValue 262 *( PLUS attributeTypeAndValue ) 263 attributeTypeAndValue = attributeType EQUALS attributeValue 264 attributeType = descr / numericoid 265 attributeValue = string / hexstring 266 267 ; The following characters are to be escaped when they appear 268 ; in the value to be encoded: ESC, one of <escaped>, leading 269 ; SHARP or SPACE, trailing SPACE, and NULL. 270 string = [ ( leadchar / pair ) [ *( stringchar / pair ) 271 ( trailchar / pair ) ] ] 272 273 leadchar = LUTF1 / UTFMB 274 LUTF1 = %x01-1F / %x21 / %x24-2A / %x2D-3A / 275 %x3D / %x3F-5B / %x5D-7F 276 277 trailchar = TUTF1 / UTFMB 278 TUTF1 = %x01-1F / %x21 / %x23-2A / %x2D-3A / 279 280 281 282Zeilenga Standards Track [Page 5] 283 284RFC 4514 LDAP: Distinguished Names June 2006 285 286 287 %x3D / %x3F-5B / %x5D-7F 288 289 stringchar = SUTF1 / UTFMB 290 SUTF1 = %x01-21 / %x23-2A / %x2D-3A / 291 %x3D / %x3F-5B / %x5D-7F 292 293 pair = ESC ( ESC / special / hexpair ) 294 special = escaped / SPACE / SHARP / EQUALS 295 escaped = DQUOTE / PLUS / COMMA / SEMI / LANGLE / RANGLE 296 hexstring = SHARP 1*hexpair 297 hexpair = HEX HEX 298 299 where the productions <descr>, <numericoid>, <COMMA>, <DQUOTE>, 300 <EQUALS>, <ESC>, <HEX>, <LANGLE>, <NULL>, <PLUS>, <RANGLE>, <SEMI>, 301 <SPACE>, <SHARP>, and <UTFMB> are defined in [RFC4512]. 302 303 Each <attributeType>, either a <descr> or a <numericoid>, refers to 304 an attribute type of an attribute value assertion (AVA). The 305 <attributeType> is followed by an <EQUALS> and an <attributeValue>. 306 The <attributeValue> is either in <string> or <hexstring> form. 307 308 If in <string> form, a LDAP string representation asserted value can 309 be obtained by replacing (left to right, non-recursively) each <pair> 310 appearing in the <string> as follows: 311 312 replace <ESC><ESC> with <ESC>; 313 replace <ESC><special> with <special>; 314 replace <ESC><hexpair> with the octet indicated by the <hexpair>. 315 316 If in <hexstring> form, a BER representation can be obtained from 317 converting each <hexpair> of the <hexstring> to the octet indicated 318 by the <hexpair>. 319 320 There is one or more attribute value assertions, separated by <PLUS>, 321 for a relative distinguished name. 322 323 There is zero or more relative distinguished names, separated by 324 <COMMA>, for a distinguished name. 325 326 Implementations MUST recognize AttributeType name strings 327 (descriptors) listed in the following table, but MAY recognize other 328 name strings. 329 330 331 332 333 334 335 336 337 338Zeilenga Standards Track [Page 6] 339 340RFC 4514 LDAP: Distinguished Names June 2006 341 342 343 String X.500 AttributeType 344 ------ -------------------------------------------- 345 CN commonName (2.5.4.3) 346 L localityName (2.5.4.7) 347 ST stateOrProvinceName (2.5.4.8) 348 O organizationName (2.5.4.10) 349 OU organizationalUnitName (2.5.4.11) 350 C countryName (2.5.4.6) 351 STREET streetAddress (2.5.4.9) 352 DC domainComponent (0.9.2342.19200300.100.1.25) 353 UID userId (0.9.2342.19200300.100.1.1) 354 355 These attribute types are described in [RFC4519]. 356 357 Implementations MAY recognize other DN string representations. 358 However, as there is no requirement that alternative DN string 359 representations be recognized (and, if so, how), implementations 360 SHOULD only generate DN strings in accordance with Section 2 of this 361 document. 362 3634. Examples 364 365 This notation is designed to be convenient for common forms of name. 366 This section gives a few examples of distinguished names written 367 using this notation. First is a name containing three relative 368 distinguished names (RDNs): 369 370 UID=jsmith,DC=example,DC=net 371 372 Here is an example of a name containing three RDNs, in which the 373 first RDN is multi-valued: 374 375 OU=Sales+CN=J. Smith,DC=example,DC=net 376 377 This example shows the method of escaping of a special characters 378 appearing in a common name: 379 380 CN=James \"Jim\" Smith\, III,DC=example,DC=net 381 382 The following shows the method for encoding a value that contains a 383 carriage return character: 384 385 CN=Before\0dAfter,DC=example,DC=net 386 387 In this RDN example, the type in the RDN is unrecognized, and the 388 value is the BER encoding of an OCTET STRING containing two octets, 389 0x48 and 0x69. 390 391 392 393 394Zeilenga Standards Track [Page 7] 395 396RFC 4514 LDAP: Distinguished Names June 2006 397 398 399 1.3.6.1.4.1.1466.0=#04024869 400 401 Finally, this example shows an RDN whose commonName value consists of 402 5 letters: 403 404 Unicode Character Code UTF-8 Escaped 405 ------------------------------- ------ ------ -------- 406 LATIN CAPITAL LETTER L U+004C 0x4C L 407 LATIN SMALL LETTER U U+0075 0x75 u 408 LATIN SMALL LETTER C WITH CARON U+010D 0xC48D \C4\8D 409 LATIN SMALL LETTER I U+0069 0x69 i 410 LATIN SMALL LETTER C WITH ACUTE U+0107 0xC487 \C4\87 411 412 This could be encoded in printable ASCII [ASCII] (useful for 413 debugging purposes) as: 414 415 CN=Lu\C4\8Di\C4\87 416 4175. Security Considerations 418 419 The following security considerations are specific to the handling of 420 distinguished names. LDAP security considerations are discussed in 421 [RFC4511] and other documents comprising the LDAP Technical 422 Specification [RFC4510]. 423 4245.1. Disclosure 425 426 Distinguished Names typically consist of descriptive information 427 about the entries they name, which can be people, organizations, 428 devices, or other real-world objects. This frequently includes some 429 of the following kinds of information: 430 431 - the common name of the object (i.e., a person's full name) 432 - an email or TCP/IP address 433 - its physical location (country, locality, city, street address) 434 - organizational attributes (such as department name or 435 affiliation) 436 437 In some cases, such information can be considered sensitive. In many 438 countries, privacy laws exist that prohibit disclosure of certain 439 kinds of descriptive information (e.g., email addresses). Hence, 440 server implementers are encouraged to support Directory Information 441 Tree (DIT) structural rules and name forms [RFC4512], as these 442 provide a mechanism for administrators to select appropriate naming 443 attributes for entries. Administrators are encouraged to use 444 mechanisms, access controls, and other administrative controls that 445 may be available to restrict use of attributes containing sensitive 446 information in naming of entries. Additionally, use of 447 448 449 450Zeilenga Standards Track [Page 8] 451 452RFC 4514 LDAP: Distinguished Names June 2006 453 454 455 authentication and data security services in LDAP [RFC4513][RFC4511] 456 should be considered. 457 4585.2. Use of Distinguished Names in Security Applications 459 460 The transformations of an AttributeValue value from its X.501 form to 461 an LDAP string representation are not always reversible back to the 462 same BER (Basic Encoding Rules) or DER (Distinguished Encoding Rules) 463 form. An example of a situation that requires the DER form of a 464 distinguished name is the verification of an X.509 certificate. 465 466 For example, a distinguished name consisting of one RDN with one AVA, 467 in which the type is commonName and the value is of the TeletexString 468 choice with the letters 'Sam', would be represented in LDAP as the 469 string <CN=Sam>. Another distinguished name in which the value is 470 still 'Sam', but is of the PrintableString choice, would have the 471 same representation <CN=Sam>. 472 473 Applications that require the reconstruction of the DER form of the 474 value SHOULD NOT use the string representation of attribute syntaxes 475 when converting a distinguished name to the LDAP format. Instead, 476 they SHOULD use the hexadecimal form prefixed by the number sign ('#' 477 U+0023) as described in the first paragraph of Section 2.4. 478 4796. Acknowledgements 480 481 This document is an update to RFC 2253, by Mark Wahl, Tim Howes, and 482 Steve Kille. RFC 2253 was a product of the IETF ASID Working Group. 483 484 This document is a product of the IETF LDAPBIS Working Group. 485 4867. References 487 4887.1. Normative References 489 490 [REGISTRY] IANA, Object Identifier Descriptors Registry, 491 <http://www.iana.org/assignments/ldap-parameters>. 492 493 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 494 3.2.0" is defined by "The Unicode Standard, Version 495 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201- 496 61633-5), as amended by the "Unicode Standard Annex 497 #27: Unicode 3.1" 498 (http://www.unicode.org/reports/tr27/) and by the 499 "Unicode Standard Annex #28: Unicode 3.2" 500 (http://www.unicode.org/reports/tr28/). 501 502 503 504 505 506Zeilenga Standards Track [Page 9] 507 508RFC 4514 LDAP: Distinguished Names June 2006 509 510 511 [X.501] International Telecommunication Union - 512 Telecommunication Standardization Sector, "The 513 Directory -- Models," X.501(1993) (also ISO/IEC 9594- 514 2:1994). 515 516 [X.680] International Telecommunication Union - 517 Telecommunication Standardization Sector, "Abstract 518 Syntax Notation One (ASN.1) - Specification of Basic 519 Notation", X.680(1997) (also ISO/IEC 8824-1:1998). 520 521 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 522 Requirement Levels", BCP 14, RFC 2119, March 1997. 523 524 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 525 10646", STD 63, RFC 3629, November 2003. 526 527 [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 528 Specifications: ABNF", RFC 4234, October 2005. 529 530 [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access 531 Protocol (LDAP): Technical Specification Road Map", RFC 532 4510, June 2006. 533 534 [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 535 Protocol (LDAP): The Protocol", RFC 4511, June 2006. 536 537 [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol 538 (LDAP): Directory Information Models", RFC 4512, June 539 2006. 540 541 [RFC4513] Harrison, R., Ed., "Lightweight Directory Access 542 Protocol (LDAP): Authentication Methods and Security 543 Mechanisms", RFC 4513, June 2006. 544 545 [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol 546 (LDAP): Syntaxes and Matching Rules", RFC 4517, June 547 2006. 548 549 [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access 550 Protocol (LDAP): Schema for User Applications", RFC 551 4519, June 2006. 552 553 [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority 554 (IANA) Considerations for the Lightweight Directory 555 Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006. 556 557 558 559 560 561 562Zeilenga Standards Track [Page 10] 563 564RFC 4514 LDAP: Distinguished Names June 2006 565 566 5677.2. Informative References 568 569 [ASCII] Coded Character Set--7-bit American Standard Code for 570 Information Interchange, ANSI X3.4-1986. 571 572 [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report 573 #17, Character Encoding Model", UTR17, 574 <http://www.unicode.org/unicode/reports/tr17/>, August 575 2000. 576 577 [Glossary] The Unicode Consortium, "Unicode Glossary", 578 <http://www.unicode.org/glossary/>. 579 580 [X.500] International Telecommunication Union - 581 Telecommunication Standardization Sector, "The 582 Directory -- Overview of concepts, models and 583 services," X.500(1993) (also ISO/IEC 9594-1:1994). 584 585 [X.511] International Telecommunication Union - 586 Telecommunication Standardization Sector, "The 587 Directory: Abstract Service Definition", X.511(1993) 588 (also ISO/IEC 9594-3:1993). 589 590 [X.690] International Telecommunication Union - 591 Telecommunication Standardization Sector, 592 "Specification of ASN.1 encoding rules: Basic Encoding 593 Rules (BER), Canonical Encoding Rules (CER), and 594 Distinguished Encoding Rules (DER)", X.690(1997) (also 595 ISO/IEC 8825-1:1998). 596 597 [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) - 598 Technical Specification", RFC 2849, June 2000. 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618Zeilenga Standards Track [Page 11] 619 620RFC 4514 LDAP: Distinguished Names June 2006 621 622 623Appendix A. Presentation Issues 624 625 This appendix is provided for informational purposes only; it is not 626 a normative part of this specification. 627 628 The string representation described in this document is not intended 629 to be presented to humans without translation. However, at times it 630 may be desirable to present non-translated DN strings to users. This 631 section discusses presentation issues associated with non-translated 632 DN strings. Issues with presentation of translated DN strings are 633 not discussed in this appendix. Transcoding issues are also not 634 discussed in this appendix. 635 636 This appendix provides guidance for applications presenting DN 637 strings to users. This section is not comprehensive; it does not 638 discuss all presentation issues that implementers may face. 639 640 Not all user interfaces are capable of displaying the full set of 641 Unicode characters. Some Unicode characters are not displayable. 642 643 It is recommended that human interfaces use the optional hex pair 644 escaping mechanism (Section 2.3) to produce a string representation 645 suitable for display to the user. For example, an application can 646 generate a DN string for display that escapes all non-printable 647 characters appearing in the AttributeValue's string representation 648 (as demonstrated in the final example of Section 4). 649 650 When a DN string is displayed in free-form text, it is often 651 necessary to distinguish the DN string from surrounding text. While 652 this is often done with whitespace (as demonstrated in Section 4), it 653 is noted that DN strings may end with whitespace. Careful readers of 654 Section 3 will note that the characters '<' (U+003C) and '>' (U+003E) 655 may only appear in the DN string if escaped. These characters are 656 intended to be used in free-form text to distinguish a DN string from 657 surrounding text. For example, <CN=Sam\ > distinguishes the string 658 representation of the DN composed of one RDN consisting of the AVA 659 (the commonName (CN) value 'Sam ') from the surrounding text. It 660 should be noted to the user that the wrapping '<' and '>' characters 661 are not part of the DN string. 662 663 DN strings can be quite long. It is often desirable to line-wrap 664 overly long DN strings in presentations. Line wrapping should be 665 done by inserting whitespace after the RDN separator character or, if 666 necessary, after the AVA separator character. It should be noted to 667 the user that the inserted whitespace is not part of the DN string 668 and is to be removed before use in LDAP. For example, the following 669 DN string is long: 670 671 672 673 674Zeilenga Standards Track [Page 12] 675 676RFC 4514 LDAP: Distinguished Names June 2006 677 678 679 CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores, 680 O=OpenLDAP Foundation,ST=California,C=US 681 682 So it has been line-wrapped for readability. The extra whitespace is 683 to be removed before the DN string is used in LDAP. 684 685 Inserting whitespace is not advised because it may not be obvious to 686 the user which whitespace is part of the DN string and which 687 whitespace was added for readability. 688 689 Another alternative is to use the LDAP Data Interchange Format (LDIF) 690 [RFC2849]. For example: 691 692 # This entry has a long DN... 693 dn: CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores, 694 O=OpenLDAP Foundation,ST=California,C=US 695 CN: Kurt D. Zeilenga 696 SN: Zeilenga 697 objectClass: person 698 699Appendix B. Changes Made since RFC 2253 700 701 This appendix is provided for informational purposes only, it is not 702 a normative part of this specification. 703 704 The following substantive changes were made to RFC 2253: 705 706 - Removed IESG Note. The IESG Note has been addressed. 707 - Replaced all references to ISO 10646-1 with [Unicode]. 708 - Clarified (in Section 1) that this document does not define a 709 canonical string representation. 710 - Clarified that Section 2 describes the RECOMMENDED encoding 711 algorithm and that alternative algorithms are allowed. Some 712 encoding options described in RFC 2253 are now treated as 713 alternative algorithms in this specification. 714 - Revised specification (in Section 2) to allow short names of any 715 registered attribute type to appear in string representations of 716 DNs instead of being restricted to a "published table". Removed 717 "as an example" language. Added statement (in Section 3) 718 allowing recognition of additional names but require recognition 719 of those names in the published table. The table now appears in 720 Section 3. 721 - Removed specification of additional requirements for LDAPv2 722 implementations which also support LDAPv3 (RFC 2253, Section 4) 723 as LDAPv2 is now Historic. 724 - Allowed recognition of alternative string representations. 725 - Updated Section 2.4 to allow hex pair escaping of all characters 726 and clarified escaping for when multiple octet UTF-8 encodings 727 728 729 730Zeilenga Standards Track [Page 13] 731 732RFC 4514 LDAP: Distinguished Names June 2006 733 734 735 are present. Indicated that null (U+0000) character is to be 736 escaped. Indicated that equals sign ('=' U+003D) character may 737 be escaped as '\='. 738 - Rewrote Section 3 to use ABNF as defined in RFC 4234. 739 - Updated the Section 3 ABNF. Changes include: 740 + allowed AttributeType short names of length 1 (e.g., 'L'), 741 + used more restrictive <oid> production in AttributeTypes, 742 + did not require escaping of equals sign ('=' U+003D) 743 characters, 744 + did not require escaping of non-leading number sign ('#' 745 U+0023) characters, 746 + allowed space (' ' U+0020) to be escaped as '\ ', 747 + required hex escaping of null (U+0000) characters, and 748 + removed LDAPv2-only constructs. 749 - Updated Section 3 to describe how to parse elements of the 750 grammar. 751 - Rewrote examples. 752 - Added reference to documentations containing general LDAP 753 security considerations. 754 - Added discussion of presentation issues (Appendix A). 755 - Added this appendix. 756 757 In addition, numerous editorial changes were made. 758 759Editor's Address 760 761 Kurt D. Zeilenga 762 OpenLDAP Foundation 763 764 EMail: Kurt@OpenLDAP.org 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786Zeilenga Standards Track [Page 14] 787 788RFC 4514 LDAP: Distinguished Names June 2006 789 790 791Full Copyright Statement 792 793 Copyright (C) The Internet Society (2006). 794 795 This document is subject to the rights, licenses and restrictions 796 contained in BCP 78, and except as set forth therein, the authors 797 retain all their rights. 798 799 This document and the information contained herein are provided on an 800 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 801 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 802 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 803 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 804 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 805 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 806 807Intellectual Property 808 809 The IETF takes no position regarding the validity or scope of any 810 Intellectual Property Rights or other rights that might be claimed to 811 pertain to the implementation or use of the technology described in 812 this document or the extent to which any license under such rights 813 might or might not be available; nor does it represent that it has 814 made any independent effort to identify any such rights. Information 815 on the procedures with respect to rights in RFC documents can be 816 found in BCP 78 and BCP 79. 817 818 Copies of IPR disclosures made to the IETF Secretariat and any 819 assurances of licenses to be made available, or the result of an 820 attempt made to obtain a general license or permission for the use of 821 such proprietary rights by implementers or users of this 822 specification can be obtained from the IETF on-line IPR repository at 823 http://www.ietf.org/ipr. 824 825 The IETF invites any interested party to bring to its attention any 826 copyrights, patents or patent applications, or other proprietary 827 rights that may cover technology that may be required to implement 828 this standard. Please address the information to the IETF at 829 ietf-ipr@ietf.org. 830 831Acknowledgement 832 833 Funding for the RFC Editor function is provided by the IETF 834 Administrative Support Activity (IASA). 835 836 837 838 839 840 841 842Zeilenga Standards Track [Page 15] 843 844