idnits 2.17.1 draft-ietf-ldapbis-dn-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 24. -- Found old boilerplate from RFC 3978, Section 5.5 on line 636. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 609. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 616. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 622. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 628), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 (4 June 2004) is 7266 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) == Missing Reference: 'RFC3629' is mentioned on line 226, but not defined == Unused Reference: 'RFC3329' is defined on line 431, but no explicit reference was found in the text == Unused Reference: 'Schema' is defined on line 456, but no explicit reference was found in the text == Unused Reference: 'ASCII' is defined on line 465, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode' -- 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. 'REGISTRY' -- No information found for draft-ietf-ldapbis-bcp64-xx - is the name correct? Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 21 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 4 June 2004 5 Obsoletes: 2253 7 LDAP: String Representation of Distinguished Names 8 10 Status of Memo 12 This document is intended to be, after appropriate review and 13 revision, submitted to the RFC Editor as a Standard Track document 14 replacing RFC 2253. Distribution of this memo is unlimited. 15 Technical discussion of this document will take place on the IETF LDAP 16 Revision (LDAPBIS) Working Group mailing list 17 . Please send editorial comments directly 18 to the document editor . 20 By submitting this Internet-Draft, I accept the provisions of Section 21 4 of RFC 3667. By submitting this Internet-Draft, I certify that any 22 applicable patent or other IPR claims of which I am aware have been 23 disclosed, and any of which I become aware will be disclosed, in 24 accordance with RFC 3668. 26 Internet-Drafts are working documents of the Internet Engineering Task 27 Force (IETF), its areas, and its working groups. Note that other 28 groups may also distribute working documents as Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference material 33 or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. The list of 37 Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Please see the Full Copyright section near the end of this document 43 for more information. 45 Abstract 47 The X.500 Directory uses distinguished names (DNs) as primary keys to 48 entries in the directory. This document defines the string 49 representation used in the Lightweight Directory Access Protocol 50 (LDAP) to transfer distinguished names. The string representation is 51 designed to give a clean representation of commonly used distinguished 52 names, while being able to represent any distinguished name. 54 1. Background and Intended Usage 56 In X.500-based directory systems [X.500], including those accessed 57 using the Lightweight Directory Access Protocol (LDAP) [Roadmap], 58 distinguished names (DNs) are used to unambiguously refer to directory 59 entries [X.501][Models]. 61 The structure of a DN [X.501] is described in terms of ASN.1 [X.680]. 62 In the X.500 Directory Access Protocol [X.511] (and other ITU-defined 63 directory protocols), DNs are encoded using the Basic Encoding Rules 64 (BER) [X.690]. In LDAP, DNs are represented in the string form 65 described in this document. 67 It is important to have a common format to be able to unambiguously 68 represent a distinguished name. The primary goal of this 69 specification is ease of encoding and decoding. A secondary goal is 70 to have names that are human readable. It is not expected that LDAP 71 implementations with a human user interface would display these 72 strings directly to the user, but would most likely be performing 73 translations (such as expressing attribute type names in the local 74 national language). 76 This document defines the string representation of Distinguished Names 77 used in LDAP [Protocol][Syntaxes]. Section 2 details the RECOMMENDED 78 algorithm for converting a DN from its ASN.1 structured representation 79 to a string. Section 3 details how to convert a DN from a string to a 80 ASN.1 structured representation. 82 While other documents may define other algorithms for converting a DN 83 from its ASN.1 structured representation to a string, all algorithms 84 MUST produce strings which adhere to the requirements of Section 3. 86 This document does not define a canonical string representation for 87 DNs. Comparison of DNs for equality is to be performed in accordance 88 with the distinguishedNameMatch matching rule [Syntaxes]. 90 This document is an integral part of the LDAP Technical Specification 91 [Roadmap]. This document obsoletes RFC 2253. Changes since RFC 2253 92 are summarized in Appendix B. 94 This specification assumes familiarity with X.500 [X.500] and the 95 concept of Distinguished Name [X.501][Models]. 97 1.1. Conventions 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in BCP 14 [RFC2119]. 103 Character names in this document use the notation for code points and 104 names from the Unicode Standard [Unicode]. For example, the letter 105 "a" may be represented as either or . 107 Note: a glossary of terms used in Unicode can be found in [Glossary]. 108 Information on the Unicode character encoding model can be found in 109 [CharModel]. 111 2. Converting DistinguishedName from ASN.1 to a String 113 X.501 [X.501] defines the ASN.1 [X.680] structure of distinguished 114 name. The following is a variant provided for discussion purposes. 116 DistinguishedName ::= RDNSequence 118 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 120 RelativeDistinguishedName ::= SET SIZE (1..MAX) OF 121 AttributeTypeAndValue 123 AttributeTypeAndValue ::= SEQUENCE { 124 type AttributeType, 125 value AttributeValue } 127 This section defines the RECOMMENDED algorithm for converting a 128 distinguished name from an ASN.1 structured representation to an UTF-8 129 [RFC3629] encoded Unicode [Unicode] character string representation. 130 Other documents may describe other algorithms for converting a 131 distinguished name to a string, but only strings which conform to the 132 grammar defined in Section 3 SHALL be produced by LDAP 133 implementations. 135 2.1. Converting the RDNSequence 136 If the RDNSequence is an empty sequence, the result is the empty or 137 zero length string. 139 Otherwise, the output consists of the string encodings of each 140 RelativeDistinguishedName in the RDNSequence (according to Section 141 2.2), starting with the last element of the sequence and moving 142 backwards toward the first. 144 The encodings of adjoining RelativeDistinguishedNames are separated by 145 a comma (',' U+002C) character. 147 2.2. Converting RelativeDistinguishedName 149 When converting from an ASN.1 RelativeDistinguishedName to a string, 150 the output consists of the string encodings of each 151 AttributeTypeAndValue (according to Section 2.3), in any order. 153 Where there is a multi-valued RDN, the outputs from adjoining 154 AttributeTypeAndValues are separated by a plus sign ('+' U+002B) 155 character. 157 2.3. Converting AttributeTypeAndValue 159 The AttributeTypeAndValue is encoded as the string representation of 160 the AttributeType, followed by an equals ('=' U+003D) character, 161 followed by the string representation of the AttributeValue. The 162 encoding of the AttributeValue is given in Section 2.4. 164 If the AttributeType is defined to have a short name and that short 165 name is known to be registered [REGISTRY][BCP64bis] as identifying the 166 AttributeType, that short name, a , is used. Otherwise the 167 AttributeType is encoded as the dotted-decimal encoding, a 168 , of its OBJECT IDENTIFIER. The and 169 is defined in [Models]. 171 Implementations are not expected to dynamically update their knowledge 172 of registered short names. However, implementations SHOULD provide a 173 mechanism to allow its knowledge of registered short names to be 174 updated. 176 2.4. Converting an AttributeValue from ASN.1 to a String 178 If the AttributeType is of the dotted-decimal form, the AttributeValue 179 is represented by an number sign ('#' U+0023) character followed by 180 the hexadecimal encoding of each of the octets of the BER encoding of 181 the X.500 AttributeValue. This form is also used when the syntax of 182 the AttributeValue does not have a LDAP-specific [Syntaxes, Section 183 3.1] string encoding defined for it or the LDAP-specific string 184 encoding is not restricted to UTF-8 encoded Unicode characters. This 185 form may also be used in other cases, such as when a reversible string 186 representation is desired (see Section 5.2). 188 Otherwise, if the AttributeValue is of a syntax which has a 189 LDAP-specific string encoding, the value is converted first to a UTF-8 190 encoded Unicode string according to its syntax specification (see 191 [Syntaxes, Section 3.3] for examples). If that UTF-8 encoded Unicode 192 string does not have any of the following characters which need 193 escaping, then that string can be used as the string representation of 194 the value. 196 - a space (' ' U+0020) or number sign ('#' U+0023) occurring at 197 the beginning of the string; 199 - a space (' ' U+0020) character occurring at the end of the 200 string; 202 - one of the characters '"', '+', ',', ';', '<', '>', or '\' 203 (U+0022, U+002B, U+002C, U+003B, U+003C, U+003E, or U+005C 204 respectively); 206 - the null (U+0000) character. 208 Other characters may be escaped. 210 Each octet of the character to be escaped is replaced by a backslash 211 and two hex digits, which form a single octet in the code of the 212 character. Alternatively, if and only if the character to be escaped 213 is one of 215 ' ', '"', '#', '+', ',', ';', '<', '=', '>', or '\' 216 (U+0020, U+0022, U+0023, U+002B, U+002C, U+003B, 217 U+003C, U+003D, U+003E, U+005C respectively) 219 it can be prefixed by a backslash ('\' U+0005C). 221 Examples of the escaping mechanism are shown in Section 4. 223 3. Parsing a String back to a Distinguished Name 225 The string representation of Distinguished Names is restricted to 226 UTF-8 [RFC3629] encoded Unicode [Unicode] characters. The structure 227 of this string representation is specified using the following 228 Augmented BNF [RFC2234] grammar: 230 distinguishedName = [ relativeDistinguishedName 231 *( COMMA relativeDistinguishedName ) ] 232 relativeDistinguishedName = attributeTypeAndValue 233 *( PLUS attributeTypeAndValue ) 234 attributeTypeAndValue = attributeType EQUALS attributeValue 235 attributeType = descr / numericoid 236 attributeValue = string / hexstring 238 ; The following characters are to be escaped when they appear 239 ; in the value to be encoded: ESC, one of , leading 240 ; SHARP or SPACE, trailing SPACE, and NULL. 241 string = [ (leadchar / pair) 242 [ *( stringchar / pair ) ( trailchar / pair ) ] ] 244 leadchar = LUTF1 / UTFMB 245 LUTF1 = %x01-1F / %x21 / %x24-2A / %x2D-3A / 246 %x3D / %x3F-5B / %x5D-7F 248 trailchar = TUTF1 / UTFMB 249 TUTF1 = %x01-1F / %x21 / %x23-2A / %x2D-3A / 250 %x3D / %x3F-5B / %x5D-7F 252 stringchar = SUTF1 / UTFMB 253 SUTF1 = %x01-21 / %x23-2A / %x2D-3A / 254 %x3D / %x3F-5B / %x5D-7F 256 pair = ESC ( ESC / special / hexpair ) 257 special = escaped / SPACE / SHARP / EQUALS 258 escaped = DQUOTE / PLUS / COMMA / SEMI / LANGLE / RANGLE 259 hexstring = SHARP 1*hexpair 260 hexpair = HEX HEX 262 where the productions , , , , 263 , , , , , , , , 264 , , are defined in [Models]. 266 Each , either a or a , refers to an 267 attribute type of an attribute value assertion (AVA). The 268 is followed by a and an . 269 The is either in or form. 271 If in form, a LDAP string representation asserted value can 272 be obtained by replacing (left-to-right, non-recursively) each 273 appearing in the as follows: 274 replace with ; 275 replace with ; 276 replace with the octet indicated by the . 278 If in form, a BER representation can be obtained from 279 converting each of the to the octet indicated by 280 the . 282 One or more attribute values assertions, separated by , for a 283 relative distinguished name. 285 Zero or more relative distinguished names, separated by , for a 286 distinguished name. 288 Implementations MUST recognize AttributeType name strings 289 (descriptors) listed in the following table, but MAY recognize other 290 name strings. 292 String X.500 AttributeType 293 ------ -------------------------------------------- 294 CN commonName (2.5.4.3) 295 L localityName (2.5.4.7) 296 ST stateOrProvinceName (2.5.4.8) 297 O organizationName (2.5.4.10) 298 OU organizationalUnitName (2.5.4.11) 299 C countryName (2.5.4.6) 300 STREET streetAddress (2.5.4.9) 301 DC domainComponent (0.9.2342.19200300.100.1.25) 302 UID userId (0.9.2342.19200300.100.1.1) 304 Implementations MAY recognize other DN string representations (such as 305 that described in RFC 1779). However, as there is no requirement that 306 alternative DN string representations to be recognized (and, if so, 307 how), implementations SHOULD only generate DN strings in accordance 308 with Section 2 of this document. 310 4. Examples 312 This notation is designed to be convenient for common forms of name. 313 This section gives a few examples of distinguished names written using 314 this notation. First is a name containing three relative 315 distinguished names (RDNs): 317 UID=jsmith,DC=example,DC=net 319 Here is an example name containing three RDNs, in which the first RDN 320 is multi-valued: 322 OU=Sales+CN=J. Smith,DC=example,DC=net 324 This example shows the method of escaping of a comma in a common name: 326 CN=John Smith\, III,DC=example,DC=net 328 An example name in which a value contains a carriage return character: 330 CN=Before\0dAfter,DC=example,DC=net 332 An example name in which an RDN was of an unrecognized type. The 333 value is the BER encoding of an OCTET STRING containing two octets 334 0x48 and 0x69. 336 1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com 338 Finally, an example of an RDN commonName value consisting of 5 339 letters: 341 Unicode Character Code UTF-8 Escaped 342 ------------------------------- ------ ------ -------- 343 LATIN CAPITAL LETTER L U+004C 0x4C L 344 LATIN SMALL LETTER U U+0075 0x75 u 345 LATIN SMALL LETTER C WITH CARON U+010D 0xC48D \C4\8D 346 LATIN SMALL LETTER I U+0069 0x69 i 347 LATIN SMALL LETTER C WITH ACUTE U+0107 0xC487 \C4\87 349 could be written in printable ASCII (useful for debugging purposes): 351 CN=Lu\C4\8Di\C4\87 353 5. Security Considerations 355 The following security considerations are specific to the handling of 356 distinguished names. LDAP security considerations are discussed in 357 [Protocol] and other documents comprising the LDAP Technical 358 Specification [Roadmap]. 360 5.1. Disclosure 362 Distinguished Names typically consist of descriptive information about 363 the entries they name, which can be people, organizations, devices or 364 other real-world objects. This frequently includes some of the 365 following kinds of information: 367 - the common name of the object (i.e. a person's full name) 368 - an email or TCP/IP address 369 - its physical location (country, locality, city, street address) 370 - organizational attributes (such as department name or affiliation) 372 Most countries have privacy laws regarding the publication of 373 information about people. 375 5.2. Use of Distinguished Names in Security Applications 377 The transformations of an AttributeValue value from its X.501 form to 378 an LDAP string representation are not always reversible back to the 379 same BER (Basic Encoding Rules) or DER (Distinguished Encoding rules) 380 form. An example of a situation which requires the DER form of a 381 distinguished name is the verification of an X.509 certificate. 383 For example, a distinguished name consisting of one RDN with one AVA, 384 in which the type is commonName and the value is of the TeletexString 385 choice with the letters 'Sam' would be represented in LDAP as the 386 string . Another distinguished name in which the value is 387 still 'Sam' but of the PrintableString choice would have the same 388 representation . 390 Applications which require the reconstruction of the DER form of the 391 value SHOULD NOT use the string representation of attribute syntaxes 392 when converting a distinguished name to the LDAP format. Instead, 393 they SHOULD use the hexadecimal form prefixed by the number sign ('#') 394 as described in the first paragraph of Section 2.3. 396 6. Acknowledgment 398 This document is an update to RFC 2253, by Mark Wahl, Tim Howes, and 399 Steve Kille. RFC 2253 was a product of the IETF ASID Working Group. 401 This document is a product of the IETF LDAPBIS Working Group. 403 7. Document Editor's Address 405 Kurt D. Zeilenga 406 OpenLDAP Foundation 407 409 8. References 411 [[Note to the RFC Editor: please replace the citation tags used in 412 referencing Internet-Drafts with tags of the form RFCnnnn.]] 414 8.1. Normative References 416 [X.501] International Telecommunication Union - 417 Telecommunication Standardization Sector, "The Directory 418 -- Models," X.501(1993) (also ISO/IEC 9594-2:1994). 420 [X.680] International Telecommunication Union - 421 Telecommunication Standardization Sector, "Abstract 422 Syntax Notation One (ASN.1) - Specification of Basic 423 Notation", X.680(1997) (also ISO/IEC 8824-1:1998). 425 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 426 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 428 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 429 Specifications: ABNF", RFC 2234, November 1997. 431 [RFC3329] Yergeau, F., "UTF-8, a transformation format of ISO 432 10646", RFC 3329 (also STD 64), November 2003. 434 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 435 3.2.0" is defined by "The Unicode Standard, Version 3.0" 436 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), 437 as amended by the "Unicode Standard Annex #27: Unicode 438 3.1" (http://www.unicode.org/reports/tr27/) and by the 439 "Unicode Standard Annex #28: Unicode 3.2" 440 (http://www.unicode.org/reports/tr28/). 442 [Models] Zeilenga, K. (editor), "LDAP: Directory Information 443 Models", draft-ietf-ldapbis-models-xx.txt, a work in 444 progress. 446 [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification 447 Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in 448 progress. 450 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", 451 draft-ietf-ldapbis-protocol-xx.txt, a work in progress. 453 [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules", 454 draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress. 456 [Schema] Dally, K. (editor), "LDAP: User Schema", 457 draft-ietf-ldapbis-user-schema-xx.txt, a work in 458 progress. 460 [REGISTRY] IANA, Object Identifier Descriptors Registry, 461 . 463 8.2. Informative References 465 [ASCII] Coded Character Set--7-bit American Standard Code for 466 Information Interchange, ANSI X3.4-1986. 468 [X.500] International Telecommunication Union - 469 Telecommunication Standardization Sector, "The Directory 470 -- Overview of concepts, models and services," 471 X.500(1993) (also ISO/IEC 9594-1:1994). 473 [X.690] International Telecommunication Union - 474 Telecommunication Standardization Sector, "Specification 475 of ASN.1 encoding rules: Basic Encoding Rules (BER), 476 Canonical Encoding Rules (CER), and Distinguished 477 Encoding Rules (DER)", X.690(1997) (also ISO/IEC 478 8825-1:1998). 480 [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) - 481 Technical Specification", RFC 2849, June 2000. 483 [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP", 484 draft-ietf-ldapbis-bcp64-xx.txt, a work in progress. 486 [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report 487 #17, Character Encoding Model", UTR17, 488 , August 489 2000. 491 [Glossary] The Unicode Consortium, "Unicode Glossary", 492 . 494 Appendix A. Presentation Issues 496 This appendix is provided for informational purposes only, it is not a 497 normative part of this specification. 499 The string representation described in this document is not intended 500 to be presented to humans without translation. However, at times it 501 may be desirable to present non-translated DN strings to users. This 502 section discusses presentation issues associated with non-translated 503 DN strings. Presentation of translated DN strings issues are not 504 discussed in this appendix. Transcoding issues are also not discussed 505 in this appendix. 507 This appendix provides guidance for applications presenting DN strings 508 to users. This section is not comprehensive, it does not discuss all 509 presentation issues which implementors may face. 511 Not all user interfaces are capable of displaying the full set of 512 Unicode characters. Some Unicode characters are not displayable. 514 It is recommended that human interfaces use the optional hex pair 515 escaping mechanism (Section 2.3) to produce a string representation 516 suitable for display to the user. For example, an application can 517 generate a DN string for display which escapes all non-printable 518 characters appearing in the AttributeValue's string representation (as 519 demonstrated in the final example of Section 4). 521 When a DN string is displayed in free form text, it is often necessary 522 to distinguish the DN string from surrounding text. While this is 523 often done with white space (as demonstrated in Section 4), it is 524 noted that DN strings may end with white space. Careful readers of 525 Section 3 will note that characters '<' (U+003C) and '>' (U+003E) may 526 only appear in the DN string if escaped. These characters are 527 intended to be used in free form text to distinguish a DN string from 528 surrounding text. For example, distinguished the string 529 representation of the DN comprised of one RDN consisting of the AVA: 530 the commonName (CN) value 'Sam ' from the surrounding text. It should 531 be noted to the user that the wrapping '<' and '>' characters are not 532 part of the DN string. 534 DN strings can be quite long. It is often desirable to line-wrap 535 overly long DN strings in presentations. Line wrapping should be done 536 by inserting white space after the RDN separator character or, if 537 necessary, after the AVA separator character. It should be noted to 538 the user that the inserted white space is not part of the DN string 539 and is to be removed before use in LDAP. For example, 541 The following DN string is long: 542 CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores, 543 O=OpenLDAP Foundation,ST=California,C=US 544 so it has been line-wrapped for readability. The extra white 545 space is to be removed before the DN string is used in LDAP. 547 It is not advised to insert white space otherwise as it may not be 548 obvious to the user which white space is part of the DN string and 549 which white space was added for readability. 551 Another alternative is to use the LDAP Data Interchange Format (LDIF) 552 [RFC2849]. For example, 554 # This entry has a long DN... 555 dn: CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores, 556 O=OpenLDAP Foundation,ST=California,C=US 558 CN: Kurt D. Zeilenga 559 SN: Zeilenga 560 objectClass: person 562 Appendix B. Changes made since RFC 2253 564 This appendix is provided for informational purposes only, it is not a 565 normative part of this specification. 567 The following substantive changes were made to RFC 2253: 568 - Removed IESG Note. The IESG Note has been addressed. 569 - Replaced all references to ISO 10646-1 with [Unicode]. 570 - Clarified (in Section 1) that this document does not define a 571 canonical string representation. 572 - Revised specification (in Section 2) to allow short names of any 573 registered attribute type to appear in string representations of 574 DNs instead of being restricted to a "published table". Remove 575 "as an example" language. Added statement (in Section 3) allowing 576 recognition of additional names but require recognization of those 577 names in the published table. The table is now published in 578 Section 3. 579 - Replaced specification of additional requirements for LDAPv2 580 implementations which also support LDAPv3 (RFC 2253, Section 4) 581 with a statement (in Section 3) allowing recognition of 582 alternative string representations. 583 - Updated Section 2.3 to indicate attribute type name strings are 584 case insensitive. 585 - Updated Section 2.4 to allow hex pair escaping of all characters 586 and clarified escaping for when multiple octet UTF-8 echodings are 587 present. 588 - Rewrote Section 3 to use ABNF as defined in RFC 2234. 589 - Rewrote Section 3 ABNF to be consistent with 2.4. 590 - Updated Section 3 to describe how to parse elements of the 591 grammar. 592 - Rewrote examples. 593 - Added reference to documentations containing general LDAP security 594 considerations. 595 - Added discussion of presentation issues (Appendix A). 596 - Added this appendix. 598 In addition, numerous editorial changes were made. 600 Intellectual Property Rights 602 The IETF takes no position regarding the validity or scope of any 603 Intellectual Property Rights or other rights that might be claimed to 604 pertain to the implementation or use of the technology described in 605 this document or the extent to which any license under such rights 606 might or might not be available; nor does it represent that it has 607 made any independent effort to identify any such rights. Information 608 on the procedures with respect to rights in RFC documents can be found 609 in BCP 78 and BCP 79. 611 Copies of IPR disclosures made to the IETF Secretariat and any 612 assurances of licenses to be made available, or the result of an 613 attempt made to obtain a general license or permission for the use of 614 such proprietary rights by implementers or users of this specification 615 can be obtained from the IETF on-line IPR repository at 616 http://www.ietf.org/ipr. 618 The IETF invites any interested party to bring to its attention any 619 copyrights, patents or patent applications, or other proprietary 620 rights that may cover technology that may be required to implement 621 this standard. Please address the information to the IETF at 622 ietf-ipr@ietf.org. 624 Full Copyright 626 Copyright (C) The Internet Society (2004). This document is subject 627 to the rights, licenses and restrictions contained in BCP 78, and 628 except as set forth therein, the authors retain all their rights. 630 This document and the information contained herein are provided on an 631 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 632 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 633 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 634 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 635 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 636 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.