idnits 2.17.1 draft-ietf-ldapbis-dn-08.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. == 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 572 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 (18 August 2002) is 7894 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'LDAPTS' is mentioned on line 53, but not defined ** 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' -- No information found for draft-ietf-ldapbis-xx - is the name correct? Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 14 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 18 August 2002 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 2002, 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 1. Background and Intended Usage 52 In X.500-based directory systems [X.500], including those accessed 53 using the Lightweight Directory Access Protocol (LDAP) [LDAPTS], 54 distinguished names (DNs) are used to unambiguously refer to a 55 directory entry [X.501][Models]. 57 The structure of a DN [X.501] is described in terms of ASN.1 [X.680]. 58 In the X.500 Directory Access Protocol [X.511] (and other ITU-defined 59 directory protocols), DNs are encoded using the Basic Encoding Rules 60 (BER) [X.690]. In LDAP, DNs are represented in string form. 62 It is important to have a common format to be able to unambiguously 63 represent a distinguished name. The primary goal of this 64 specification is ease of encoding and decoding. A secondary goal is 65 to have names that are human readable. It is not expected that LDAP 66 implementations with a human user interface would display these 67 strings directly to the user, but would most likely be performing 68 translations (such as expressing attribute type names in one of the 69 local national languages). 71 This document defines the string representation of Distinguished Names 72 used in LDAP [Protocol][Syntaxes]. Section 2 details how to convert a 73 DN from ASN.1 structured representation to a string. Section 3 74 details how to convert a DN from string to ASN.1 structured 75 representation. 77 This document does not define a canonical string representation for 78 DNs. Comparison of DNs for equality is to be performed in accordance 79 with the distinguishedNameMatch matching rule [Syntaxes]. 81 This document is an integral part of the LDAP Technical Specification 82 [Roadmap]. 84 This document obsoletes RFC 2253. Changes since RFC 2253 are 85 summarized in Appendix B. 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in BCP 14 [RFC2119]. 91 This specification assumes familiarity with X.500 [X.500], and the 92 concept of Distinguished Name [X.501][Models]. 94 2. Converting DistinguishedName from ASN.1 to a String 96 In X.501 [X.501] the ASN.1 [X.680] structure of distinguished name is 97 defined as: 99 DistinguishedName ::= RDNSequence 101 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 103 RelativeDistinguishedName ::= SET SIZE (1..MAX) OF 104 AttributeTypeAndValue 106 AttributeTypeAndValue ::= SEQUENCE { 107 type AttributeType, 108 value AttributeValue } 110 This section defines the RECOMMENDED algorithm for converting a 111 distinguished name from an ASN.1 structured representation to an UTF-8 112 [RFC2279] encoded Universal Character Set (UCS) [ISO10646] character 113 string representation. 115 2.1. Converting the RDNSequence 117 If the RDNSequence is an empty sequence, the result is the empty or 118 zero length string. 120 Otherwise, the output consists of the string encodings of each 121 RelativeDistinguishedName in the RDNSequence (according to Section 122 2.2), starting with the last element of the sequence and moving 123 backwards toward the first. 125 The encodings of adjoining RelativeDistinguishedNames are separated by 126 a comma character ("," U+0002C). 128 2.2. Converting RelativeDistinguishedName 130 When converting from an ASN.1 RelativeDistinguishedName to a string, 131 the output consists of the string encodings of each 132 AttributeTypeAndValue (according to Section 2.3), in any order. 134 Where there is a multi-valued RDN, the outputs from adjoining 135 AttributeTypeAndValues are separated by a plus sign ("+" U+0002B) 136 character. 138 2.3. Converting AttributeTypeAndValue 139 The AttributeTypeAndValue is encoded as the string representation of 140 the AttributeType, followed by an equals character ("=" U+0003D), 141 followed by the string representation of the AttributeValue. The 142 encoding of the AttributeValue is given in Section 2.4. 144 If the AttributeType is in the following table of attribute types 145 associated with LDAP [Schema], then the type name string, a , 146 from that table is used, otherwise it is encoded as the dotted-decimal 147 encoding, a , of the AttributeType's OBJECT IDENTIFIER. 148 The and is defined in [Models]. 150 The type name string is not case sensitive. 152 String X.500 AttributeType 153 ------ -------------------------------------------- 154 CN commonName (2.5.4.3) 155 L localityName (2.5.4.7) 156 ST stateOrProvinceName (2.5.4.8) 157 O organizationName (2.5.4.10) 158 OU organizationalUnitName (2.5.4.11) 159 C countryName (2.5.4.6) 160 STREET streetAddress (2.5.4.9) 161 DC domainComponent (0.9.2342.19200300.100.1.25) 162 UID userId (0.9.2342.19200300.100.1.1) 164 Note: This table lists the complete set of type name strings which 165 all implementations MUST recognize in DN string representation. 166 As no extension could reasonable require all existing 167 implementations be updated to recognize additional type name 168 strings, this table is not extensible. 170 2.4. Converting an AttributeValue from ASN.1 to a String 172 If the AttributeType is of the dotted-decimal form, the AttributeValue 173 is represented by an number sign character ("#" U+00023) followed by 174 the hexadecimal encoding of each of the octets of the BER encoding of 175 the X.500 AttributeValue. This form is also used when the syntax of 176 the AttributeValue does not have a native string encoding defined for 177 it or the native string encoding is not restricted to UTF-8 encoded 178 UCS (or a subset of UCS) characters. This form may also be used in 179 other cases, such as when a reversible string representation is 180 desired (see Section 5.2). 182 Otherwise, if the AttributeValue is of a syntax which has a native 183 string encoding, the value is converted first to a UTF-8 encoded UCS 184 string according to its syntax specification (see for example Section 185 6 of [Syntaxes]). If that UTF-8 encoded UCS string does not have any 186 of the following characters which need escaping, then that string can 187 be used as the string representation of the value. 189 - a space (" " U+00020) or number sign ("#" U+00023) occurring at 190 the beginning of the string; 192 - a space (" " U+00020) character occurring at the end of the 193 string; 195 - one of the characters """, "+", ",", ";", "<", ">", or "\" 196 (U+00022, U+0002B, U+0002C, U+0003B, U+0003C, U+0003E, or 197 U+0005C respectively); 199 - the null (U+00000) character. 201 Other characters may be escaped. 203 Each octet of the character to be escaped is replaced by a backslash 204 and two hex digits, which form a single octet in the code of the 205 character. Alternatively, if and only if the character to be escaped 206 is one of 208 " ", """, "#", "+", ",", ";", "<", "=", ">", or "\" 209 (U+00020, U+00022, U+00023, U+0002B, U+0002C, U+0003B, 210 U+0003C, U+0003D, U+0003E, U+0005C respectively) 212 it can be prefixed by a backslash ("\" U+00005C). 214 Examples of the escaping mechanism are shown in Section 4. 216 3. Parsing a String back to a Distinguished Name 218 The string representation of Distinguished Names is restricted to 219 UTF-8 [RFC2279] encoded characters from the Universal Character Set 220 (UCS) [ISO10646]. The structure of this string representation is 221 specified using the following Augmented BNF [RFC2234] grammar using 222 the common productions defined in [Models]. 224 distinguishedName = [ relativeDistinguishedName 225 *( COMMA relativeDistinguishedName ) ] 227 relativeDistinguishedName = attributeTypeAndValue 228 *( PLUS attributeTypeAndValue ) 230 attributeTypeAndValue = attributeType EQUALS attributeValue 231 attributeType = descr / numericoid 233 attributeValue = string / hexstring 235 ; The UTF-8 string shall not contain NULL, ESC, or 236 ; one of escaped, shall not start with SHARP or SPACE, 237 ; and shall must not end with SPACE. 238 string = [ (leadchar / pair) 239 [ *( stringchar / pair ) ( trailchar / pair ) ] ] 241 leadchar = LUTF1 / UTFMB 242 LUTF1 = %x01-1F / %x21 / %x24-2A / %x2D-3A / 243 %x3D / %x3F-5B / %x5D-7F 245 trailchar = TUTF1 / UTFMB 246 TUTF1 = %x01-1F / %x21 / %x23-2A / %x2D-3A / 247 %x3D / %x3F-5B / %x5D-7F 249 stringchar = SUTF1 / UTFMB 250 SUTF1 = %x01-21 / %x23-2A / %x2D-3A / 251 %x3D / %x3F-5B / %x5D-7F 253 pair = ESC ( ESC / special / hexpair ) 255 special = escaped / SPACE / SHARP / EQUALS 257 escaped = DQUOTE / PLUS / COMMA / SEMI / LANGLE / RANGLE 259 hexstring = SHARP 1*hexpair 261 hexpair = HEX HEX 263 where the productions , , , , 264 , , , , , , , , 265 , , are defined in [Models]. 267 Implementations MUST recognize AttributeType name strings 268 (descriptors) listed in the Section 2.3 table, but MAY recognize other 269 name strings. Implementations MAY recognize other DN string 270 representations (such as that described in RFC 1779). However, as 271 there is no requirement for other names or alternative DN string 272 representations to be recognized (and, if so, how), implementations 273 SHOULD only generate DN strings in accordance with Section 2 of this 274 document. 276 4. Examples 277 This notation is designed to be convenient for common forms of name. 278 This section gives a few examples of distinguished names written using 279 this notation. First is a name containing three relative 280 distinguished names (RDNs): 282 UID=jsmith,DC=example,DC=net 284 Here is an example name containing three RDNs, in which the first RDN 285 is multi-valued: 287 OU=Sales+CN=J. Smith,DC=example,DC=net 289 This example shows the method of escaping of a comma in a common name: 291 CN=John Smith\, III,DC=example,DC=net 293 An example name in which a value contains a carriage return character: 295 CN=Before\0dAfter,DC=example,DC=net 297 An example name in which an RDN was of an unrecognized type. The 298 value is the BER encoding of an OCTET STRING containing two octets 299 0x48 and 0x69. 301 1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com 303 Finally, an example of an RDN commonName value consisting of 5 304 letters: 306 Unicode Letter Description UCS code UTF-8 Quoted 307 ------------------------------- -------- ------ -------- 308 LATIN CAPITAL LETTER L U+0004C 0x4C L 309 LATIN SMALL LETTER U U+00075 0x75 u 310 LATIN SMALL LETTER C WITH CARON U+0010D 0xC48D \C4\8D 311 LATIN SMALL LETTER I U+00069 0x69 i 312 LATIN SMALL LETTER C WITH ACUTE U+00107 0xC487 \C4\87 314 could be written in printable ASCII (useful for debugging purposes): 316 CN=Lu\C4\8Di\C4\87 318 5. Security Considerations 320 The following security considerations are specific to the handling of 321 distinguished names. LDAP security considerations are discussed in 322 [Protocol] and other documents comprising the LDAP Technical 323 Specification [Roadmap]. 325 5.1. Disclosure 327 Distinguished Names typically consist of descriptive information about 328 the entries they name, which can be people, organizations, devices or 329 other real-world objects. This frequently includes some of the 330 following kinds of information: 332 - the common name of the object (i.e. a person's full name) 333 - an email or TCP/IP address 334 - its physical location (country, locality, city, street address) 335 - organizational attributes (such as department name or affiliation) 337 Most countries have privacy laws regarding the publication of 338 information about people. 340 5.2. Use of Distinguished Names in Security Applications 342 The transformations of an AttributeValue value from its X.501 form to 343 an LDAP string representation are not always reversible back to the 344 same BER or DER form. An example of a situation which requires the 345 DER form of a distinguished name is the verification of an X.509 346 certificate. 348 For example, a distinguished name consisting of one RDN with one AVA, 349 in which the type is commonName and the value is of the TeletexString 350 choice with the letters 'Sam' would be represented in LDAP as the 351 string CN=Sam. Another distinguished name in which the value is still 352 'Sam' but of the PrintableString choice would have the same 353 representation CN=Sam. 355 Applications which require the reconstruction of the DER form of the 356 value SHOULD NOT use the string representation of attribute syntaxes 357 when converting a distinguished name to the LDAP format. Instead, 358 they SHOULD use the hexadecimal form prefixed by the number sign ('#') 359 as described in the first paragraph of Section 2.3. 361 5.3. Use of Other Names 363 Attribute type names are not unique. A string representation 364 generated with names other than those in the Section 2.3 table is 365 ambiguous. That is, two applications may recognize the string as 366 representing two different DNs possibly associated with two different 367 entries. This may lead to a wide range of unexpected behaviors which 368 can have both direct and indirect impacts upon security. 370 For example, a distinguished name consisting of one RDN with one AVA 371 of the known locally attribute type FOO and the value "BAR" (an 372 octetString) could be represented in LDAP as the string FOO=BAR. As 373 the name FOO does not uniquely identify an attribute type, the DN 374 FOO=BAR is ambiguous. That is, FOO could be recognized as the 375 attribute type 1.1.1 by one application and 1.2.3.4 in another and not 376 recognized by another. This may lead to operations not behaving as 377 intended. 379 Applications desiring to generate an unambiguous string representation 380 of a DN SHOULD generate string representation per section 2, not use 381 names other than those in the Section 2.3 table, and while taking 382 Section 5.2 into consideration. 384 It is noted that while a registry for attribute type names 385 (descriptors) has been established [LDAPIANA], this registry does not 386 remove the ambiguity of attribute types names used in LDAP. It only 387 removes the ambiguity of attribute type names used in Standard Track 388 technical specifications. 390 6. Acknowledgment 392 This document is an update to RFC 2253, by Mark Wahl, Tim Howes, and 393 Steve Kille. RFC 2253 was a product of the IETF ASID Working Group. 395 This document is a product of the IETF LDAPbis Working Group. 397 7. Document Editor's Address 399 Kurt D. Zeilenga 400 OpenLDAP Foundation 401 403 8. Normative References 405 [X.501] "The Directory -- Models," ITU-T Rec. X.501(1993). 407 [X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) - 408 Specification of Basic Notation", X.680, 1994. 410 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 411 Requirement Levels", BCP 14 (also RFC 2119). 413 [RFC2234] Crocker, D., and P. Overell, "Augmented BNF for Syntax 414 Specifications: ABNF", RFC 2234, November 1997. 416 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 417 10646", RFC 2279, January 1998. 419 [Models] K. Zeilenga (editor), "LDAP: Directory Information 420 Models", draft-ietf-ldapbis-models-xx.txt, a work in 421 progress. 423 [Roadmap] K. Zeilenga, "LDAP: Technical Specification Road Map", 424 draft-ietf-ldapbis-roadmap-xx.txt, a work in progress. 426 [Protocol] J. Sermersheim (editor), "LDAP: The Protocol", 427 draft-ietf-ldapbis-protocol-xx.txt, a work in progress. 429 [Syntaxes] S. Legg (editor), "LDAP: Syntaxes", 430 draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress. 432 [Schema] K. Dally (editor), "LDAP: User Schema", 433 draft-ietf-ldapbis-user-schema-xx.txt, a work in 434 progress. 436 [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) - 437 Architecture and Basic Multilingual Plane, ISO/IEC 438 10646-1 : 1993. 440 9. Informative References 442 [X.500] "The Directory -- overview of concepts, models and 443 services," ITU-T Rec. X.500(1993). 445 [X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic, 446 Canonical, and Distinguished Encoding Rules", X.690, 447 1994. 449 [LDAPIANA] K. Zeilenga, "IANA Considerations for LDAP", 450 draft-ietf-ldapbis-xx.txt (a work in progress). 452 [RFC2849] G. Good, "The LDAP Data Interchange Format (LDIF) - 453 Technical Specification", RFC 2849, June 2000. 455 Appendix A. Presentation Issues 457 This appendix is provided for informational purposes only, it is not a 458 normative part of this specification. 460 The string representation described in this document is not intended 461 to be presented to humans without translation. However, at times it 462 may be desirable to present non-translated DN strings to users. This 463 section discusses presentation issues associated with non-translated 464 DN strings. Presentation of translated DN strings issues are not 465 discussed in this document. Transcoding issues are also not discussed 466 in this document. 468 This appendix provides guidance for applications presenting DN strings 469 to users. This section is not comprehensive, it does not discuss all 470 presentation issues which implementors may face. 472 Not all user interfaces are capable of displaying the full set of UCS 473 characters. Some UCS characters are not displayable. 475 It is recommended that human interfaces use the optional hex pair 476 escaping mechanism (Section 2.3) to produce a string representation 477 suitable for display to the human. For example, an application only 478 capable of displaying printable characters can generate a DN string 479 for display which escapes all non-printable characters appearing in 480 the AttributeValue's string representation (as demonstrated in the 481 final example of Section 4). 483 When a DN string is displayed in free form text, it is necessary to 484 distinguish the DN string from surrounding text. While this is often 485 done with white space (as demonstrated in Section 4), it is noted that 486 DN strings may end with white space. Careful readers of Section 3 487 will note that characters "<" and ">" may only appear in the DN string 488 if escaped. These characters are intended to be used in free form 489 text to distinguish a DN string from surrounding text. For example, 490 distinguished the string representation of the DN comprised 491 of one RDN consisting of the AVA: the commonName (CN) value "Sam " 492 from the surrounding text. It should be noted to the user that the 493 wrapping "<" and ">" characters are not part of the DN string. 495 DN strings can be quite long. It is often desirable to line-wrap 496 overly long DN strings in presentations. Line wrapping should be done 497 by inserting white space after the RDN separator character or, if 498 necessary, after the AVA separator character in such presentations. 499 It should be noted to the user that the inserted white space is not 500 part of the DN string and is to be removed before use in LDAP. For 501 example, 503 The following DN string is long: 504 CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores, 505 O=OpenLDAP Foundation,ST=California,C=US 506 so it has been line-wrapped for readability. The extra white 507 space is to be removed the DN string is used in LDAP. 509 It is not advised to insert white space otherwise as it may not be 510 obvious to the user what white space is part of the DN string and what 511 white space was added for readability. 513 Another alternative is to use the LDAP Data Interchange Format (LDIF) 514 [RFC2849]. For example, 516 The following entry has a long DN: 517 dn: CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores, 518 O=OpenLDAP Foundation,ST=California,C=US 519 CN: Kurt D. Zeilenga 520 SN: Zeilenga 521 objectClass: person 523 It is noted that that is often desirable to replace dotted-decimal 524 OIDs appearing in DN strings with attribute type names. Such 525 replacement is viewed as a translation and, hence, not discussed here. 527 Appendix B. Changes made since RFC 2253 529 This appendix is provided for informational purposes only, it is not a 530 normative part of this specification. 532 The following substantive changes were made to RFC 2253: 533 - Removed IESG Note. The IESG Note has been addressed. 534 - Clarified (in Section 1), that this document does not define a 535 canonical string representation. 536 - Replaced specification of additional requirements for LDAPv2 537 implementations which also support LDAPv3 (RFC 2253, Section 4) 538 with a statement (in Section 3) allowing recognition of 539 alternative string representations. 540 - Clarified (in Section 2.3) that the "published" table of names 541 which may be appear in DNs is the table which Section 2.3 542 provides. Remove "as an example" language. Noted this table is 543 not extensible. Added statement (in Section 3) allowing 544 recognition of additional names. Added security considerations 545 (Section 5.3) regarding the use of other names. 546 - Updated Section 2.3 to indicate attribute type name strings are 547 case insensitive. 548 - Updated Section 2.4 to allow hex pair escaping of all characters 549 and clarified escaping for when multiple octet UTF-8 characters 550 are present. 551 - Rewrote Section 3 to use ABNF as defined in RFC 2234. 552 - Rewrote Section 3 ABNF to be consistent with 2.4. 553 - Rewrote examples. 554 - Added reference to documentations containing general LDAP security 555 considerations. 556 - Added discussion of presentation issues (Appendix A). 558 - Added this appendix. 560 In addition, numerous editorial changes were made. 562 Copyright 2002, The Internet Society. All Rights Reserved. 564 This document and translations of it may be copied and furnished to 565 others, and derivative works that comment on or otherwise explain it 566 or assist in its implementation may be prepared, copied, published and 567 distributed, in whole or in part, without restriction of any kind, 568 provided that the above copyright notice and this paragraph are 569 included on all such copies and derivative works. However, this 570 document itself may not be modified in any way, such as by removing 571 the copyright notice or references to the Internet Society or other 572 Internet organizations, except as needed for the purpose of 573 developing Internet standards in which case the procedures for 574 copyrights defined in the Internet Standards process must be followed, 575 or as required to translate it into languages other than English. 577 The limited permissions granted above are perpetual and will not be 578 revoked by the Internet Society or its successors or assigns. 580 This document and the information contained herein is provided on an 581 "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET 582 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, 583 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 584 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 585 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.