idnits 2.17.1 draft-ietf-ldapbis-dn-15.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 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 650. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 623. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 630. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 636. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 642), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** 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: ---------------------------------------------------------------------------- ** 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. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages 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 (24 October 2004) is 7096 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) == Unused Reference: 'Schema' is defined on line 458, but no explicit reference was found in the text == Unused Reference: 'ASCII' is defined on line 467, 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: 11 errors (**), 0 flaws (~~), 5 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Editor: Kurt D. Zeilenga 2 Intended Category: Standard Track OpenLDAP Foundation 3 Expires in six months 24 October 2004 4 Obsoletes: 2253 6 LDAP: String Representation of Distinguished Names 7 9 Status of Memo 11 This document is intended to be, after appropriate review and 12 revision, submitted to the RFC Editor as a Standard Track document 13 replacing RFC 2253. Distribution of this memo is unlimited. 14 Technical discussion of this document will take place on the IETF LDAP 15 Revision (LDAPBIS) Working Group mailing list 16 . Please send editorial comments directly 17 to the document editor . 19 By submitting this Internet-Draft, I accept the provisions of Section 20 4 of RFC 3667. By submitting this Internet-Draft, I certify that any 21 applicable patent or other IPR claims of which I am aware have been 22 disclosed, or will be disclosed, and any of which I become aware will 23 be disclosed, in accordance with RFC 3668. 25 Internet-Drafts are working documents of the Internet Engineering Task 26 Force (IETF), its areas, and its working groups. Note that other 27 groups may also distribute working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference material 32 or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 . The list of 36 Internet-Draft Shadow Directories can be accessed at 37 . 39 Copyright (C) The Internet Society (2004). All Rights Reserved. 41 Please see the Full Copyright section near the end of this document 42 for more information. 44 Abstract 46 The X.500 Directory uses distinguished names (DNs) as primary keys to 47 entries in the directory. This document defines the string 48 representation used in the Lightweight Directory Access Protocol 49 (LDAP) to transfer distinguished names. The string representation is 50 designed to give a clean representation of commonly used distinguished 51 names, while being able to represent any distinguished name. 53 1. Background and Intended Usage 55 In X.500-based directory systems [X.500], including those accessed 56 using the Lightweight Directory Access Protocol (LDAP) [Roadmap], 57 distinguished names (DNs) are used to unambiguously refer to directory 58 entries [X.501][Models]. 60 The structure of a DN [X.501] is described in terms of ASN.1 [X.680]. 61 In the X.500 Directory Access Protocol [X.511] (and other ITU-defined 62 directory protocols), DNs are encoded using the Basic Encoding Rules 63 (BER) [X.690]. In LDAP, DNs are represented in the string form 64 described in this document. 66 It is important to have a common format to be able to unambiguously 67 represent a distinguished name. The primary goal of this 68 specification is ease of encoding and decoding. A secondary goal is 69 to have names that are human readable. It is not expected that LDAP 70 implementations with a human user interface would display these 71 strings directly to the user, but would most likely be performing 72 translations (such as expressing attribute type names in the local 73 national language). 75 This document defines the string representation of Distinguished Names 76 used in LDAP [Protocol][Syntaxes]. Section 2 details the RECOMMENDED 77 algorithm for converting a DN from its ASN.1 structured representation 78 to a string. Section 3 details how to convert a DN from a string to a 79 ASN.1 structured representation. 81 While other documents may define other algorithms for converting a DN 82 from its ASN.1 structured representation to a string, all algorithms 83 MUST produce strings which adhere to the requirements of Section 3. 85 This document does not define a canonical string representation for 86 DNs. Comparison of DNs for equality is to be performed in accordance 87 with the distinguishedNameMatch matching rule [Syntaxes]. 89 This document is an integral part of the LDAP Technical Specification 90 [Roadmap]. This document obsoletes RFC 2253. Changes since RFC 2253 91 are summarized in Appendix B. 93 This specification assumes familiarity with X.500 [X.500] and the 94 concept of Distinguished Name [X.501][Models]. 96 1.1. Conventions 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in BCP 14 [RFC2119]. 102 Character names in this document use the notation for code points and 103 names from the Unicode Standard [Unicode]. For example, the letter 104 "a" may be represented as either or . 106 Note: a glossary of terms used in Unicode can be found in [Glossary]. 107 Information on the Unicode character encoding model can be found in 108 [CharModel]. 110 2. Converting DistinguishedName from ASN.1 to a String 112 X.501 [X.501] defines the ASN.1 [X.680] structure of distinguished 113 name. The following is a variant provided for discussion purposes. 115 DistinguishedName ::= RDNSequence 117 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 119 RelativeDistinguishedName ::= SET SIZE (1..MAX) OF 120 AttributeTypeAndValue 122 AttributeTypeAndValue ::= SEQUENCE { 123 type AttributeType, 124 value AttributeValue } 126 This section defines the RECOMMENDED algorithm for converting a 127 distinguished name from an ASN.1 structured representation to an UTF-8 128 [RFC3629] encoded Unicode [Unicode] character string representation. 129 Other documents may describe other algorithms for converting a 130 distinguished name to a string, but only strings which conform to the 131 grammar defined in Section 3 SHALL be produced by LDAP 132 implementations. 134 2.1. Converting the RDNSequence 135 If the RDNSequence is an empty sequence, the result is the empty or 136 zero length string. 138 Otherwise, the output consists of the string encodings of each 139 RelativeDistinguishedName in the RDNSequence (according to Section 140 2.2), starting with the last element of the sequence and moving 141 backwards toward the first. 143 The encodings of adjoining RelativeDistinguishedNames are separated by 144 a comma (',' U+002C) character. 146 2.2. Converting RelativeDistinguishedName 148 When converting from an ASN.1 RelativeDistinguishedName to a string, 149 the output consists of the string encodings of each 150 AttributeTypeAndValue (according to Section 2.3), in any order. 152 Where there is a multi-valued RDN, the outputs from adjoining 153 AttributeTypeAndValues are separated by a plus sign ('+' U+002B) 154 character. 156 2.3. Converting AttributeTypeAndValue 158 The AttributeTypeAndValue is encoded as the string representation of 159 the AttributeType, followed by an equals sign ('=' U+003D) character, 160 followed by the string representation of the AttributeValue. The 161 encoding of the AttributeValue is given in Section 2.4. 163 If the AttributeType is defined to have a short name and that short 164 name is known to be registered [REGISTRY][BCP64bis] as identifying the 165 AttributeType, that short name, a , is used. Otherwise the 166 AttributeType is encoded as the dotted-decimal encoding, a 167 , of its OBJECT IDENTIFIER. The and 168 is defined in [Models]. 170 Implementations are not expected to dynamically update their knowledge 171 of registered short names. However, implementations SHOULD provide a 172 mechanism to allow its knowledge of registered short names to be 173 updated. 175 2.4. Converting an AttributeValue from ASN.1 to a String 177 If the AttributeType is of the dotted-decimal form, the AttributeValue 178 is represented by an number sign ('#' U+0023) character followed by 179 the hexadecimal encoding of each of the octets of the BER encoding of 180 the X.500 AttributeValue. This form is also used when the syntax of 181 the AttributeValue does not have a LDAP-specific [Syntaxes, Section 182 3.1] string encoding defined for it or the LDAP-specific string 183 encoding is not restricted to UTF-8 encoded Unicode characters. This 184 form may also be used in other cases, such as when a reversible string 185 representation is desired (see Section 5.2). 187 Otherwise, if the AttributeValue is of a syntax which has a 188 LDAP-specific string encoding, the value is converted first to a UTF-8 189 encoded Unicode string according to its syntax specification (see 190 [Syntaxes, Section 3.3] for examples). If that UTF-8 encoded Unicode 191 string does not have any of the following characters which need 192 escaping, then that string can be used as the string representation of 193 the value. 195 - a space (' ' U+0020) or number sign ('#' U+0023) occurring at 196 the beginning of the string; 198 - a space (' ' U+0020) character occurring at the end of the 199 string; 201 - one of the characters '"', '+', ',', ';', '<', '>', or '\' 202 (U+0022, U+002B, U+002C, U+003B, U+003C, U+003E, or U+005C 203 respectively); 205 - the null (U+0000) character. 207 Other characters may be escaped. 209 Each octet of the character to be escaped is replaced by a backslash 210 and two hex digits, which form a single octet in the code of the 211 character. Alternatively, if and only if the character to be escaped 212 is one of 214 ' ', '"', '#', '+', ',', ';', '<', '=', '>', or '\' 215 (U+0020, U+0022, U+0023, U+002B, U+002C, U+003B, 216 U+003C, U+003D, U+003E, U+005C respectively) 218 it can be prefixed by a backslash ('\' U+0005C). 220 Examples of the escaping mechanism are shown in Section 4. 222 3. Parsing a String back to a Distinguished Name 224 The string representation of Distinguished Names is restricted to 225 UTF-8 [RFC3629] encoded Unicode [Unicode] characters. The structure 226 of this string representation is specified using the following 227 Augmented BNF [RFC2234] grammar: 229 distinguishedName = [ relativeDistinguishedName 230 *( COMMA relativeDistinguishedName ) ] 231 relativeDistinguishedName = attributeTypeAndValue 232 *( PLUS attributeTypeAndValue ) 233 attributeTypeAndValue = attributeType EQUALS attributeValue 234 attributeType = descr / numericoid 235 attributeValue = string / hexstring 237 ; The following characters are to be escaped when they appear 238 ; in the value to be encoded: ESC, one of , leading 239 ; SHARP or SPACE, trailing SPACE, and NULL. 240 string = [ ( leadchar / pair ) [ *( stringchar / pair ) 241 ( trailchar / pair ) ] ] 243 leadchar = LUTF1 / UTFMB 244 LUTF1 = %x01-1F / %x21 / %x24-2A / %x2D-3A / 245 %x3D / %x3F-5B / %x5D-7F 247 trailchar = TUTF1 / UTFMB 248 TUTF1 = %x01-1F / %x21 / %x23-2A / %x2D-3A / 249 %x3D / %x3F-5B / %x5D-7F 251 stringchar = SUTF1 / UTFMB 252 SUTF1 = %x01-21 / %x23-2A / %x2D-3A / 253 %x3D / %x3F-5B / %x5D-7F 255 pair = ESC ( ESC / special / hexpair ) 256 special = escaped / SPACE / SHARP / EQUALS 257 escaped = DQUOTE / PLUS / COMMA / SEMI / LANGLE / RANGLE 258 hexstring = SHARP 1*hexpair 259 hexpair = HEX HEX 261 where the productions , , , , 262 , , , , , , , , 263 , , are defined in [Models]. 265 Each , either a or a , refers to an 266 attribute type of an attribute value assertion (AVA). The 267 is followed by a and an . 268 The is either in or form. 270 If in form, a LDAP string representation asserted value can 271 be obtained by replacing (left-to-right, non-recursively) each 272 appearing in the as follows: 273 replace with ; 274 replace with ; 275 replace with the octet indicated by the . 277 If in form, a BER representation can be obtained from 278 converting each of the to the octet indicated by 279 the . 281 One or more attribute values assertions, separated by , for a 282 relative distinguished name. 284 Zero or more relative distinguished names, separated by , for a 285 distinguished name. 287 Implementations MUST recognize AttributeType name strings 288 (descriptors) listed in the following table, but MAY recognize other 289 name strings. 291 String X.500 AttributeType 292 ------ -------------------------------------------- 293 CN commonName (2.5.4.3) 294 L localityName (2.5.4.7) 295 ST stateOrProvinceName (2.5.4.8) 296 O organizationName (2.5.4.10) 297 OU organizationalUnitName (2.5.4.11) 298 C countryName (2.5.4.6) 299 STREET streetAddress (2.5.4.9) 300 DC domainComponent (0.9.2342.19200300.100.1.25) 301 UID userId (0.9.2342.19200300.100.1.1) 303 Implementations MAY recognize other DN string representations (such as 304 that described in RFC 1779). However, as there is no requirement that 305 alternative DN string representations to be recognized (and, if so, 306 how), implementations SHOULD only generate DN strings in accordance 307 with Section 2 of this document. 309 4. Examples 311 This notation is designed to be convenient for common forms of name. 312 This section gives a few examples of distinguished names written using 313 this notation. First is a name containing three relative 314 distinguished names (RDNs): 316 UID=jsmith,DC=example,DC=net 318 Here is an example name containing three RDNs, in which the first RDN 319 is multi-valued: 321 OU=Sales+CN=J. Smith,DC=example,DC=net 323 This example shows the method of escaping of a special characters 324 appearing in a common name: 326 CN=James \"Jim\" Smith\, III,DC=example,DC=net 328 The following shows the method for encoding a value which contains a 329 carriage return character: 331 CN=Before\0dAfter,DC=example,DC=net 333 In this RDN example, the type in the RDN is unrecognized, and the 334 value is the BER encoding of an OCTET STRING containing two octets 335 0x48 and 0x69. 337 1.3.6.1.4.1.1466.0=#04024869 339 Finally, this example shows an RDN whose commonName value consisting 340 of 5 letters: 342 Unicode Character Code UTF-8 Escaped 343 ------------------------------- ------ ------ -------- 344 LATIN CAPITAL LETTER L U+004C 0x4C L 345 LATIN SMALL LETTER U U+0075 0x75 u 346 LATIN SMALL LETTER C WITH CARON U+010D 0xC48D \C4\8D 347 LATIN SMALL LETTER I U+0069 0x69 i 348 LATIN SMALL LETTER C WITH ACUTE U+0107 0xC487 \C4\87 350 could be encoded in printable ASCII (useful for debugging purposes) 351 as: 353 CN=Lu\C4\8Di\C4\87 355 5. Security Considerations 357 The following security considerations are specific to the handling of 358 distinguished names. LDAP security considerations are discussed in 359 [Protocol] and other documents comprising the LDAP Technical 360 Specification [Roadmap]. 362 5.1. Disclosure 364 Distinguished Names typically consist of descriptive information about 365 the entries they name, which can be people, organizations, devices or 366 other real-world objects. This frequently includes some of the 367 following kinds of information: 369 - the common name of the object (i.e. a person's full name) 370 - an email or TCP/IP address 371 - its physical location (country, locality, city, street address) 372 - organizational attributes (such as department name or affiliation) 374 Most countries have privacy laws regarding the publication of 375 information about people. 377 5.2. Use of Distinguished Names in Security Applications 379 The transformations of an AttributeValue value from its X.501 form to 380 an LDAP string representation are not always reversible back to the 381 same BER (Basic Encoding Rules) or DER (Distinguished Encoding rules) 382 form. An example of a situation which requires the DER form of a 383 distinguished name is the verification of an X.509 certificate. 385 For example, a distinguished name consisting of one RDN with one AVA, 386 in which the type is commonName and the value is of the TeletexString 387 choice with the letters 'Sam' would be represented in LDAP as the 388 string . Another distinguished name in which the value is 389 still 'Sam' but of the PrintableString choice would have the same 390 representation . 392 Applications which require the reconstruction of the DER form of the 393 value SHOULD NOT use the string representation of attribute syntaxes 394 when converting a distinguished name to the LDAP format. Instead, 395 they SHOULD use the hexadecimal form prefixed by the number sign ('#' 396 U+0023) as described in the first paragraph of Section 2.4. 398 6. Acknowledgment 400 This document is an update to RFC 2253, by Mark Wahl, Tim Howes, and 401 Steve Kille. RFC 2253 was a product of the IETF ASID Working Group. 403 This document is a product of the IETF LDAPBIS Working Group. 405 7. Document Editor's Address 407 Kurt D. Zeilenga 408 OpenLDAP Foundation 409 411 8. References 413 [[Note to the RFC Editor: please replace the citation tags used in 414 referencing Internet-Drafts with tags of the form RFCnnnn.]] 416 8.1. Normative References 418 [X.501] International Telecommunication Union - 419 Telecommunication Standardization Sector, "The Directory 420 -- Models," X.501(1993) (also ISO/IEC 9594-2:1994). 422 [X.680] International Telecommunication Union - 423 Telecommunication Standardization Sector, "Abstract 424 Syntax Notation One (ASN.1) - Specification of Basic 425 Notation", X.680(1997) (also ISO/IEC 8824-1:1998). 427 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 428 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 430 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 431 Specifications: ABNF", RFC 2234, November 1997. 433 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 434 10646", RFC 3629 (also STD 63), November 2003. 436 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 437 3.2.0" is defined by "The Unicode Standard, Version 3.0" 438 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), 439 as amended by the "Unicode Standard Annex #27: Unicode 440 3.1" (http://www.unicode.org/reports/tr27/) and by the 441 "Unicode Standard Annex #28: Unicode 3.2" 442 (http://www.unicode.org/reports/tr28/). 444 [Models] Zeilenga, K. (editor), "LDAP: Directory Information 445 Models", draft-ietf-ldapbis-models-xx.txt, a work in 446 progress. 448 [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification 449 Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in 450 progress. 452 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", 453 draft-ietf-ldapbis-protocol-xx.txt, a work in progress. 455 [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules", 456 draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress. 458 [Schema] Dally, K. (editor), "LDAP: User Schema", 459 draft-ietf-ldapbis-user-schema-xx.txt, a work in 460 progress. 462 [REGISTRY] IANA, Object Identifier Descriptors Registry, 463 . 465 8.2. Informative References 467 [ASCII] Coded Character Set--7-bit American Standard Code for 468 Information Interchange, ANSI X3.4-1986. 470 [X.500] International Telecommunication Union - 471 Telecommunication Standardization Sector, "The Directory 472 -- Overview of concepts, models and services," 473 X.500(1993) (also ISO/IEC 9594-1:1994). 475 [X.690] International Telecommunication Union - 476 Telecommunication Standardization Sector, "Specification 477 of ASN.1 encoding rules: Basic Encoding Rules (BER), 478 Canonical Encoding Rules (CER), and Distinguished 479 Encoding Rules (DER)", X.690(1997) (also ISO/IEC 480 8825-1:1998). 482 [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) - 483 Technical Specification", RFC 2849, June 2000. 485 [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP", 486 draft-ietf-ldapbis-bcp64-xx.txt, a work in progress. 488 [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report 489 #17, Character Encoding Model", UTR17, 490 , August 491 2000. 493 [Glossary] The Unicode Consortium, "Unicode Glossary", 494 . 496 Appendix A. Presentation Issues 498 This appendix is provided for informational purposes only, it is not a 499 normative part of this specification. 501 The string representation described in this document is not intended 502 to be presented to humans without translation. However, at times it 503 may be desirable to present non-translated DN strings to users. This 504 section discusses presentation issues associated with non-translated 505 DN strings. Presentation of translated DN strings issues are not 506 discussed in this appendix. Transcoding issues are also not discussed 507 in this appendix. 509 This appendix provides guidance for applications presenting DN strings 510 to users. This section is not comprehensive, it does not discuss all 511 presentation issues which implementors may face. 513 Not all user interfaces are capable of displaying the full set of 514 Unicode characters. Some Unicode characters are not displayable. 516 It is recommended that human interfaces use the optional hex pair 517 escaping mechanism (Section 2.3) to produce a string representation 518 suitable for display to the user. For example, an application can 519 generate a DN string for display which escapes all non-printable 520 characters appearing in the AttributeValue's string representation (as 521 demonstrated in the final example of Section 4). 523 When a DN string is displayed in free form text, it is often necessary 524 to distinguish the DN string from surrounding text. While this is 525 often done with white space (as demonstrated in Section 4), it is 526 noted that DN strings may end with white space. Careful readers of 527 Section 3 will note that characters '<' (U+003C) and '>' (U+003E) may 528 only appear in the DN string if escaped. These characters are 529 intended to be used in free form text to distinguish a DN string from 530 surrounding text. For example, distinguished the string 531 representation of the DN comprised of one RDN consisting of the AVA: 532 the commonName (CN) value 'Sam ' from the surrounding text. It should 533 be noted to the user that the wrapping '<' and '>' characters are not 534 part of the DN string. 536 DN strings can be quite long. It is often desirable to line-wrap 537 overly long DN strings in presentations. Line wrapping should be done 538 by inserting white space after the RDN separator character or, if 539 necessary, after the AVA separator character. It should be noted to 540 the user that the inserted white space is not part of the DN string 541 and is to be removed before use in LDAP. For example, 543 The following DN string is long: 544 CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores, 545 O=OpenLDAP Foundation,ST=California,C=US 546 so it has been line-wrapped for readability. The extra white 547 space is to be removed before the DN string is used in LDAP. 549 It is not advised to insert white space otherwise as it may not be 550 obvious to the user which white space is part of the DN string and 551 which white space was added for readability. 553 Another alternative is to use the LDAP Data Interchange Format (LDIF) 555 [RFC2849]. For example, 557 # This entry has a long DN... 558 dn: CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores, 559 O=OpenLDAP Foundation,ST=California,C=US 560 CN: Kurt D. Zeilenga 561 SN: Zeilenga 562 objectClass: person 564 Appendix B. Changes made since RFC 2253 566 This appendix is provided for informational purposes only, it is not a 567 normative part of this specification. 569 The following substantive changes were made to RFC 2253: 570 - Removed IESG Note. The IESG Note has been addressed. 571 - Replaced all references to ISO 10646-1 with [Unicode]. 572 - Clarified (in Section 1) that this document does not define a 573 canonical string representation. 574 - Clarified that Section 2 describes the RECOMMENDED encoding 575 algorithm and that alternative algorithms are allowed. Some 576 encoding options described in RFC 2253 are now treated as 577 alternative algorithms in this specification. 578 - Revised specification (in Section 2) to allow short names of any 579 registered attribute type to appear in string representations of 580 DNs instead of being restricted to a "published table". Remove 581 "as an example" language. Added statement (in Section 3) allowing 582 recognition of additional names but require recognization of those 583 names in the published table. The table is now published in 584 Section 3. 585 - Removed specification of additional requirements for LDAPv2 586 implementations which also support LDAPv3 (RFC 2253, Section 4) as 587 LDAPv2 is now Historic. 588 - Allow recognition of alternative string representations. 589 - Updated Section 2.4 to allow hex pair escaping of all characters 590 and clarified escaping for when multiple octet UTF-8 encodings are 591 present. Indicated that null (U+0000) character is to be escaped. 592 Indicated that equals sign ('=' U+003D) character may be escaped 593 as '\='. 594 - Rewrote Section 3 to use ABNF as defined in RFC 2234. 595 - Updated the Section 3 ABNF. Changes include: 596 + allow AttributeType short names of length 1 (e.g., 'L'), 597 + use more restrictive production in AttributeTypes, 598 + do not require escaping of equals sign ('=' U+003D) characters, 599 + do not require escaping of non-leading number sign ('#' U+0023) 600 characters, 601 + allow space (' ' U+0020) to escaped as '\ ', 602 + require hex escaping of null (U+0000) characters, and 603 + removed LDAPv2-only constructs. 604 - Updated Section 3 to describe how to parse elements of the 605 grammar. 606 - Rewrote examples. 607 - Added reference to documentations containing general LDAP security 608 considerations. 609 - Added discussion of presentation issues (Appendix A). 610 - Added this appendix. 612 In addition, numerous editorial changes were made. 614 Intellectual Property Rights 616 The IETF takes no position regarding the validity or scope of any 617 Intellectual Property Rights or other rights that might be claimed to 618 pertain to the implementation or use of the technology described in 619 this document or the extent to which any license under such rights 620 might or might not be available; nor does it represent that it has 621 made any independent effort to identify any such rights. Information 622 on the procedures with respect to rights in RFC documents can be found 623 in BCP 78 and BCP 79. 625 Copies of IPR disclosures made to the IETF Secretariat and any 626 assurances of licenses to be made available, or the result of an 627 attempt made to obtain a general license or permission for the use of 628 such proprietary rights by implementers or users of this specification 629 can be obtained from the IETF on-line IPR repository at 630 http://www.ietf.org/ipr. 632 The IETF invites any interested party to bring to its attention any 633 copyrights, patents or patent applications, or other proprietary 634 rights that may cover technology that may be required to implement 635 this standard. Please address the information to the IETF at 636 ietf-ipr@ietf.org. 638 Full Copyright 640 Copyright (C) The Internet Society (2004). This document is subject 641 to the rights, licenses and restrictions contained in BCP 78, and 642 except as set forth therein, the authors retain all their rights. 644 This document and the information contained herein are provided on an 645 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 646 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 647 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 648 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 649 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 650 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.