idnits 2.17.1 draft-ietf-ldapbis-dn-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 605 has weird spacing: '...for the purpo...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (3 March 2003) is 7725 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) -- No information found for draft-ietf-ldapbis-models-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Models' -- No information found for draft-ietf-ldapbis-roadmap-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Roadmap' -- No information found for draft-ietf-ldapbis-protocol-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Protocol' -- No information found for draft-ietf-ldapbis-syntaxes-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Syntaxes' -- No information found for draft-ietf-ldapbis-user-schema-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Schema' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10646' -- Obsolete informational reference (is this intentional?): RFC 3383 (Obsoleted by RFC 4520) Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Editor: Kurt D. Zeilenga 3 Intended Category: Standard Track OpenLDAP Foundation 4 Expires in six months 3 March 2003 5 Obsoletes: 2253 7 LDAP: String Representation of Distinguished Names 8 10 Status of Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 This document is intended to be, after appropriate review and 16 revision, submitted to the RFC Editor as a Standard Track document 17 replacing RFC 2253. Distribution of this memo is unlimited. 18 Technical discussion of this document will take place on the IETF LDAP 19 Revision (LDAPbis) Working Group mailing list 20 . Please send editorial comments directly 21 to the document editor . 23 Internet-Drafts are working documents of the Internet Engineering Task 24 Force (IETF), its areas, and its working groups. Note that other 25 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as ``work in progress.'' 31 The list of current Internet-Drafts can be accessed at 32 . The list of 33 Internet-Draft Shadow Directories can be accessed at 34 . 36 Copyright 2003, The Internet Society. All Rights Reserved. 38 Please see the Copyright section near the end of this document for 39 more information. 41 Abstract 43 The X.500 Directory uses distinguished names (DNs) as primary keys to 44 entries in the directory. This document defines the string 45 representation used in the Lightweight Directory Access Protocol 46 (LDAP) to transfer distinguished names. The string representation is 47 designed to give a clean representation of commonly used distinguished 48 names, while being able to represent any distinguished name. 50 Conventions 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in BCP 14 [RFC2119]. 56 1. Background and Intended Usage 58 In X.500-based directory systems [X.500], including those accessed 59 using the Lightweight Directory Access Protocol (LDAP) [Roadmap], 60 distinguished names (DNs) are used to unambiguously refer to a 61 directory entry [X.501][Models]. 63 The structure of a DN [X.501] is described in terms of ASN.1 [X.680]. 64 In the X.500 Directory Access Protocol [X.511] (and other ITU-defined 65 directory protocols), DNs are encoded using the Basic Encoding Rules 66 (BER) [X.690]. In LDAP, DNs are represented in string form. 68 It is important to have a common format to be able to unambiguously 69 represent a distinguished name. The primary goal of this 70 specification is ease of encoding and decoding. A secondary goal is 71 to have names that are human readable. It is not expected that LDAP 72 implementations with a human user interface would display these 73 strings directly to the user, but would most likely be performing 74 translations (such as expressing attribute type names in one of the 75 local national languages). 77 This document defines the string representation of Distinguished Names 78 used in LDAP [Protocol][Syntaxes]. Section 2 details the RECOMMENDED 79 algorithm for converting a DN from its ASN.1 structured representation 80 to a string. Section 3 details how to convert a DN from a string to a 81 ASN.1 structured representation. 83 While other documents may define other algorithms for converting a DN 84 from its ASN.1 structured representation to a string, all algorithms 85 MUST produce strings which adhere to the requirements of Section 3. 87 This document does not define a canonical string representation for 88 DNs. Comparison of DNs for equality is to be performed in accordance 89 with the distinguishedNameMatch matching rule [Syntaxes]. 91 This document is an integral part of the LDAP Technical Specification 92 [Roadmap]. 94 This document obsoletes RFC 2253. Changes since RFC 2253 are 95 summarized in Appendix B. 97 This specification assumes familiarity with X.500 [X.500], and the 98 concept of Distinguished Name [X.501][Models]. 100 2. Converting DistinguishedName from ASN.1 to a String 102 X.501 [X.501] defines the ASN.1 [X.680] structure of distinguished 103 name. The following is a varient provided for discussion purposes. 105 DistinguishedName ::= RDNSequence 107 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 109 RelativeDistinguishedName ::= SET SIZE (1..MAX) OF 110 AttributeTypeAndValue 112 AttributeTypeAndValue ::= SEQUENCE { 113 type AttributeType, 114 value AttributeValue } 116 This section defines the RECOMMENDED algorithm for converting a 117 distinguished name from an ASN.1 structured representation to an UTF-8 118 [RFC2279] encoded Universal Character Set (UCS) [ISO10646] character 119 string representation. Other documents may describe other algorithms 120 for converting a distinguished name to a string, but only strings 121 which conform to the grammar defined in Section 3 MUST be produced by 122 LDAP implementations. 124 2.1. Converting the RDNSequence 126 If the RDNSequence is an empty sequence, the result is the empty or 127 zero length string. 129 Otherwise, the output consists of the string encodings of each 130 RelativeDistinguishedName in the RDNSequence (according to Section 131 2.2), starting with the last element of the sequence and moving 132 backwards toward the first. 134 The encodings of adjoining RelativeDistinguishedNames are separated by 135 a comma ("," U+002C) character. 137 2.2. Converting RelativeDistinguishedName 138 When converting from an ASN.1 RelativeDistinguishedName to a string, 139 the output consists of the string encodings of each 140 AttributeTypeAndValue (according to Section 2.3), in any order. 142 Where there is a multi-valued RDN, the outputs from adjoining 143 AttributeTypeAndValues are separated by a plus sign ("+" U+002B) 144 character. 146 2.3. Converting AttributeTypeAndValue 148 The AttributeTypeAndValue is encoded as the string representation of 149 the AttributeType, followed by an equals ("=" U+003D) character, 150 followed by the string representation of the AttributeValue. The 151 encoding of the AttributeValue is given in Section 2.4. 153 If the AttributeType is in the following table of attribute types 154 associated with LDAP [Schema], then the type name string, a , 155 from that table is used, otherwise it is encoded as the dotted-decimal 156 encoding, a , of the AttributeType's OBJECT IDENTIFIER. 157 The and is defined in [Models]. 159 The type name string is not case sensitive. 161 String X.500 AttributeType 162 ------ -------------------------------------------- 163 CN commonName (2.5.4.3) 164 L localityName (2.5.4.7) 165 ST stateOrProvinceName (2.5.4.8) 166 O organizationName (2.5.4.10) 167 OU organizationalUnitName (2.5.4.11) 168 C countryName (2.5.4.6) 169 STREET streetAddress (2.5.4.9) 170 DC domainComponent (0.9.2342.19200300.100.1.25) 171 UID userId (0.9.2342.19200300.100.1.1) 173 Note: This table lists the complete set of type name strings which all 174 implementations MUST recognize in DN string representation (per 175 Section 3). As no extension could reasonably require all 176 existing implementations be updated to recognize additional type 177 name strings, this table is not extensible. 179 2.4. Converting an AttributeValue from ASN.1 to a String 181 If the AttributeType is of the dotted-decimal form, the AttributeValue 182 is represented by an number sign ("#" U+0023) character followed by 183 the hexadecimal encoding of each of the octets of the BER encoding of 184 the X.500 AttributeValue. This form is also used when the syntax of 185 the AttributeValue does not have a native string encoding defined for 186 it or the native string encoding is not restricted to UTF-8 encoded 187 UCS (or a subset of UCS) characters. This form may also be used in 188 other cases, such as when a reversible string representation is 189 desired (see Section 5.2). 191 Otherwise, if the AttributeValue is of a syntax which has a native 192 string encoding, the value is converted first to a UTF-8 encoded UCS 193 string according to its syntax specification (see for example Section 194 6 of [Syntaxes]). If that UTF-8 encoded UCS string does not have any 195 of the following characters which need escaping, then that string can 196 be used as the string representation of the value. 198 - a space (" " U+0020) or number sign ("#" U+0023) occurring at 199 the beginning of the string; 201 - a space (" " U+0020) character occurring at the end of the 202 string; 204 - one of the characters """, "+", ",", ";", "<", ">", or "\" 205 (U+0022, U+002B, U+002C, U+003B, U+003C, U+003E, or U+005C 206 respectively); 208 - the null (U+0000) character. 210 Other characters may be escaped. 212 Each octet of the character to be escaped is replaced by a backslash 213 and two hex digits, which form a single octet in the code of the 214 character. Alternatively, if and only if the character to be escaped 215 is one of 217 " ", """, "#", "+", ",", ";", "<", "=", ">", or "\" 218 (U+0020, U+0022, U+0023, U+002B, U+002C, U+003B, 219 U+003C, U+003D, U+003E, U+005C respectively) 221 it can be prefixed by a backslash ("\" U+005C). 223 Examples of the escaping mechanism are shown in Section 4. 225 3. Parsing a String back to a Distinguished Name 227 The string representation of Distinguished Names is restricted to 228 UTF-8 [RFC2279] encoded characters from the Universal Character Set 229 (UCS) [ISO10646]. The structure of this string representation is 230 specified using the following Augmented BNF [RFC2234] grammar: 232 distinguishedName = [ relativeDistinguishedName 233 *( COMMA relativeDistinguishedName ) ] 235 relativeDistinguishedName = attributeTypeAndValue 236 *( PLUS attributeTypeAndValue ) 238 attributeTypeAndValue = attributeType EQUALS attributeValue 240 attributeType = descr / numericoid 242 attributeValue = string / hexstring 244 ; The UTF-8 string shall not contain NULL, ESC, or 245 ; one of escaped, shall not start with SHARP or SPACE, 246 ; and shall must not end with SPACE. 247 string = [ (leadchar / pair) 248 [ *( stringchar / pair ) ( trailchar / pair ) ] ] 250 leadchar = LUTF1 / UTFMB 251 LUTF1 = %x01-1F / %x21 / %x24-2A / %x2D-3A / 252 %x3D / %x3F-5B / %x5D-7F 254 trailchar = TUTF1 / UTFMB 255 TUTF1 = %x01-1F / %x21 / %x23-2A / %x2D-3A / 256 %x3D / %x3F-5B / %x5D-7F 258 stringchar = SUTF1 / UTFMB 259 SUTF1 = %x01-21 / %x23-2A / %x2D-3A / 260 %x3D / %x3F-5B / %x5D-7F 262 pair = ESC ( ESC / special / hexpair ) 264 special = escaped / SPACE / SHARP / EQUALS 266 escaped = DQUOTE / PLUS / COMMA / SEMI / LANGLE / RANGLE 268 hexstring = SHARP 1*hexpair 270 hexpair = HEX HEX 272 where the productions , , , , 273 , , , , , , , , 274 , , are defined in [Models]. 276 Each , either a or a , refers to an 277 attribute type of an attribute value assertion (AVA). The 278 is followed by a and an . 279 The is either in or form. 281 If in form, a LDAP string represention asserted value can be 282 obtained by replacing (left-to-right, non-recursively) each 283 appearing in the as follows: 284 replace with ; 285 replace with ; 286 replace with the octet indicated by the . 288 If in form, a BER representation can be obtained from 289 converting each of the to the octet indicated by 290 the . 292 One or more attribute values assertions, separated by , for a 293 relative distinguished name. 295 Zero or more relative distinguished names, separated by , for a 296 distinguished name. 298 Implementations MUST recognize AttributeType name strings 299 (descriptors) listed in the Section 2.3 table, but MAY recognize other 300 name strings. Implementations MAY recognize other DN string 301 representations (such as that described in RFC 1779). However, as 302 there is no requirement for other names or alternative DN string 303 representations to be recognized (and, if so, how), implementations 304 SHOULD only generate DN strings in accordance with Section 2 of this 305 document. 307 4. Examples 309 This notation is designed to be convenient for common forms of name. 310 This section gives a few examples of distinguished names written using 311 this notation. First is a name containing three relative 312 distinguished names (RDNs): 314 UID=jsmith,DC=example,DC=net 316 Here is an example name containing three RDNs, in which the first RDN 317 is multi-valued: 319 OU=Sales+CN=J. Smith,DC=example,DC=net 321 This example shows the method of escaping of a comma in a common name: 323 CN=John Smith\, III,DC=example,DC=net 325 An example name in which a value contains a carriage return character: 327 CN=Before\0dAfter,DC=example,DC=net 329 An example name in which an RDN was of an unrecognized type. The 330 value is the BER encoding of an OCTET STRING containing two octets 331 0x48 and 0x69. 333 1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com 335 Finally, an example of an RDN commonName value consisting of 5 336 letters: 338 Unicode Letter Description UCS code UTF-8 Escaped 339 ------------------------------- -------- ------ -------- 340 LATIN CAPITAL LETTER L U+004C 0x4C L 341 LATIN SMALL LETTER U U+0075 0x75 u 342 LATIN SMALL LETTER C WITH CARON U+010D 0xC48D \C4\8D 343 LATIN SMALL LETTER I U+0069 0x69 i 344 LATIN SMALL LETTER C WITH ACUTE U+0107 0xC487 \C4\87 346 could be written in printable ASCII (useful for debugging purposes): 348 CN=Lu\C4\8Di\C4\87 350 5. Security Considerations 352 The following security considerations are specific to the handling of 353 distinguished names. LDAP security considerations are discussed in 354 [Protocol] and other documents comprising the LDAP Technical 355 Specification [Roadmap]. 357 5.1. Disclosure 359 Distinguished Names typically consist of descriptive information about 360 the entries they name, which can be people, organizations, devices or 361 other real-world objects. This frequently includes some of the 362 following kinds of information: 364 - the common name of the object (i.e. a person's full name) 365 - an email or TCP/IP address 366 - its physical location (country, locality, city, street address) 367 - organizational attributes (such as department name or affiliation) 369 Most countries have privacy laws regarding the publication of 370 information about people. 372 5.2. Use of Distinguished Names in Security Applications 374 The transformations of an AttributeValue value from its X.501 form to 375 an LDAP string representation are not always reversible back to the 376 same BER (Base Encoding Rules) or DER (Distinguished Encoding Rules) 377 form. An example of a situation which requires the DER form of a 378 distinguished name is the verification of an X.509 certificate. 380 For example, a distinguished name consisting of one RDN with one AVA, 381 in which the type is commonName and the value is of the TeletexString 382 choice with the letters 'Sam' would be represented in LDAP as the 383 string CN=Sam. Another distinguished name in which the value is still 384 'Sam' but of the PrintableString choice would have the same 385 representation CN=Sam. 387 Applications which require the reconstruction of the DER form of the 388 value SHOULD NOT use the string representation of attribute syntaxes 389 when converting a distinguished name to the LDAP format. Instead, 390 they SHOULD use the hexadecimal form prefixed by the number sign ('#') 391 as described in the first paragraph of Section 2.3. 393 5.3. Use of Other Names 395 Attribute type names are not unique. A string representation 396 generated with names other than those in the Section 2.3 table is 397 ambiguous. That is, two applications may recognize the string as 398 representing two different DNs possibly associated with two different 399 entries. This may lead to a wide range of unexpected behaviors which 400 can have both direct and indirect impacts upon security. 402 For example, a distinguished name consisting of one RDN with one AVA 403 of the known locally attribute type FOO and the value "BAR" (an 404 octetString) could be represented in LDAP as the string FOO=BAR. As 405 the name FOO does not uniquely identify an attribute type, the DN 406 string representation FOO=BAR is ambiguous. That is, FOO could be 407 recognized as the attribute type 1.1.1 by one application and 1.2.3.4 408 in another and not recognized by another. This may lead to operations 409 not behaving as intended. 411 Applications desiring to generate an unambiguous string representation 412 of a DN SHOULD generate string representation per section 2, not use 413 names other than those in the Section 2.3 table, and while taking 414 Section 5.2 into consideration. 416 It is noted that while a registry for attribute type names 417 (descriptors) has been established [RFC3383], however this registry 418 does not remove the ambiguity of attribute types names used in LDAP. 420 It only removes the ambiguity of attribute type names used in Standard 421 Track technical specifications. 423 6. Acknowledgment 425 This document is an update to RFC 2253, by Mark Wahl, Tim Howes, and 426 Steve Kille. RFC 2253 was a product of the IETF ASID Working Group. 428 This document is a product of the IETF LDAPBIS Working Group. 430 7. Document Editor's Address 432 Kurt D. Zeilenga 433 OpenLDAP Foundation 434 436 8. Normative References 438 [X.501] "The Directory -- Models," ITU-T Rec. X.501(1993). 440 [X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) - 441 Specification of Basic Notation", X.680, 1994. 443 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 444 Requirement Levels", BCP 14 (also RFC 2119). 446 [RFC2234] Crocker, D., and P. Overell, "Augmented BNF for Syntax 447 Specifications: ABNF", RFC 2234, November 1997. 449 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 450 10646", RFC 2279, January 1998. 452 [Models] K. Zeilenga (editor), "LDAP: Directory Information 453 Models", draft-ietf-ldapbis-models-xx.txt, a work in 454 progress. 456 [Roadmap] K. Zeilenga, "LDAP: Technical Specification Road Map", 457 draft-ietf-ldapbis-roadmap-xx.txt, a work in progress. 459 [Protocol] J. Sermersheim (editor), "LDAP: The Protocol", 460 draft-ietf-ldapbis-protocol-xx.txt, a work in progress. 462 [Syntaxes] S. Legg (editor), "LDAP: Syntaxes", 463 draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress. 465 [Schema] K. Dally (editor), "LDAP: User Schema", 466 draft-ietf-ldapbis-user-schema-xx.txt, a work in 467 progress. 469 [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) - 470 Architecture and Basic Multilingual Plane, ISO/IEC 471 10646-1 : 1993. 473 9. Informative References 475 [X.500] "The Directory -- overview of concepts, models and 476 services," ITU-T Rec. X.500(1993). 478 [X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic, 479 Canonical, and Distinguished Encoding Rules", X.690, 480 1994. 482 [RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also 483 RFC 3383), September 2002. 485 [RFC2849] G. Good, "The LDAP Data Interchange Format (LDIF) - 486 Technical Specification", RFC 2849, June 2000. 488 Appendix A. Presentation Issues 490 This appendix is provided for informational purposes only, it is not a 491 normative part of this specification. 493 The string representation described in this document is not intended 494 to be presented to humans without translation. However, at times it 495 may be desirable to present non-translated DN strings to users. This 496 section discusses presentation issues associated with non-translated 497 DN strings. Presentation of translated DN strings issues are not 498 discussed in this appendix. Transcoding issues are also not discussed 499 in this appendix. 501 This appendix provides guidance for applications presenting DN strings 502 to users. This section is not comprehensive, it does not discuss all 503 presentation issues which implementors may face. 505 Not all user interfaces are capable of displaying the full set of UCS 506 characters. Some UCS characters are not displayable. 508 It is recommended that human interfaces use the optional hex pair 509 escaping mechanism (Section 2.3) to produce a string representation 510 suitable for display to the user. For example, an application can 511 generate a DN string for display which escapes all non-printable 512 characters appearing in the AttributeValue's string representation (as 513 demonstrated in the final example of Section 4). 515 When a DN string is displayed in free form text, it is often necessary 516 to distinguish the DN string from surrounding text. While this is 517 often done with white space (as demonstrated in Section 4), it is 518 noted that DN strings may end with white space. Careful readers of 519 Section 3 will note that characters "<" (U+003C) and ">" (U+003E) may 520 only appear in the DN string if escaped. These characters are 521 intended to be used in free form text to distinguish a DN string from 522 surrounding text. For example, distinguished the string 523 representation of the DN comprised of one RDN consisting of the AVA: 524 the commonName (CN) value "Sam " from the surrounding text. It should 525 be noted to the user that the wrapping "<" and ">" characters are not 526 part of the DN string. 528 DN strings can be quite long. It is often desirable to line-wrap 529 overly long DN strings in presentations. Line wrapping should be done 530 by inserting white space after the RDN separator character or, if 531 necessary, after the AVA separator character. It should be noted to 532 the user that the inserted white space is not part of the DN string 533 and is to be removed before use in LDAP. For example, 535 The following DN string is long: 536 CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores, 537 O=OpenLDAP Foundation,ST=California,C=US 538 so it has been line-wrapped for readability. The extra white 539 space is to be removed before the DN string is used in LDAP. 541 It is not advised to insert white space otherwise as it may not be 542 obvious to the user which white space is part of the DN string and 543 which white space was added for readability. 545 Another alternative is to use the LDAP Data Interchange Format (LDIF) 546 [RFC2849]. For example, 548 # This entry has a long DN... 549 dn: CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores, 550 O=OpenLDAP Foundation,ST=California,C=US 551 CN: Kurt D. Zeilenga 552 SN: Zeilenga 553 objectClass: person 555 It is noted that it may be desirable to replace dotted-decimal OIDs 556 appearing in DN strings with attribute type names. Such replacement 557 is viewed as a translation and, hence, not discussed here. 559 Appendix B. Changes made since RFC 2253 561 This appendix is provided for informational purposes only, it is not a 562 normative part of this specification. 564 The following substantive changes were made to RFC 2253: 565 - Removed IESG Note. The IESG Note has been addressed. 566 - Clarified (in Section 1), that this document does not define a 567 canonical string representation. 568 - Replaced specification of additional requirements for LDAPv2 569 implementations which also support LDAPv3 (RFC 2253, Section 4) 570 with a statement (in Section 3) allowing recognition of 571 alternative string representations. 572 - Clarified (in Section 2.3) that the "published" table of names 573 which may be appear in DNs is the table which Section 2.3 574 provides. Remove "as an example" language. Noted this table is 575 not extensible. Added statement (in Section 3) allowing 576 recognition of additional names. Added security considerations 577 (Section 5.3) regarding the use of other names. 578 - Updated Section 2.3 to indicate attribute type name strings are 579 case insensitive. 580 - Updated Section 2.4 to allow hex pair escaping of all characters 581 and clarified escaping for when multiple octet UTF-8 characters 582 are present. 583 - Rewrote Section 3 to use ABNF as defined in RFC 2234. 584 - Rewrote Section 3 ABNF to be consistent with 2.4. 585 - Updated Section 3 to describe how to parse elements of the 586 grammar. 587 - Rewrote examples. 588 - Added reference to documentations containing general LDAP security 589 considerations. 590 - Added discussion of presentation issues (Appendix A). 591 - Added this appendix. 593 In addition, numerous editorial changes were made. 595 Copyright 2003, The Internet Society. All Rights Reserved. 597 This document and translations of it may be copied and furnished to 598 others, and derivative works that comment on or otherwise explain it 599 or assist in its implementation may be prepared, copied, published and 600 distributed, in whole or in part, without restriction of any kind, 601 provided that the above copyright notice and this paragraph are 602 included on all such copies and derivative works. However, this 603 document itself may not be modified in any way, such as by removing 604 the copyright notice or references to the Internet Society or other 605 Internet organizations, except as needed for the purpose of 606 developing Internet standards in which case the procedures for 607 copyrights defined in the Internet Standards process must be followed, 608 or as required to translate it into languages other than English. 610 The limited permissions granted above are perpetual and will not be 611 revoked by the Internet Society or its successors or assigns. 613 This document and the information contained herein is provided on an 614 "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET 615 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, 616 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 617 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 618 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.