idnits 2.17.1 draft-ietf-ldapbis-dn-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 616 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 (27 October 2003) is 7487 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 443, but no explicit reference was found in the text == Unused Reference: 'ASCII' is defined on line 457, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) -- No information found for draft-yergeau-rfc2279bis-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'UTF-8' -- 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' -- Possible downref: Non-RFC (?) normative reference: ref. 'REGISTRY' -- No information found for draft-ietf-ldapbis-bcp64-xx - is the name correct? Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 18 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 27 October 2003 5 Obsoletes: 2253 7 LDAP: String Representation of Distinguished Names 8 10 Status of Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 This document is intended to be, after appropriate review and 16 revision, submitted to the RFC Editor as a Standard Track document 17 replacing RFC 2253. Distribution of this memo is unlimited. 18 Technical discussion of this document will take place on the IETF LDAP 19 Revision (LDAPBIS) Working Group mailing list 20 . Please send editorial comments directly 21 to the document editor . 23 Internet-Drafts are working documents of the Internet Engineering Task 24 Force (IETF), its areas, and its working groups. Note that other 25 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as ``work in progress.'' 31 The list of current Internet-Drafts can be accessed at 32 . The list of 33 Internet-Draft Shadow Directories can be accessed at 34 . 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 Please see the Full Copyright section near the end of this document 39 for more information. 41 Abstract 43 The X.500 Directory uses distinguished names (DNs) as primary keys to 44 entries in the directory. This document defines the string 45 representation used in the Lightweight Directory Access Protocol 46 (LDAP) to transfer distinguished names. The string representation is 47 designed to give a clean representation of commonly used distinguished 48 names, while being able to represent any distinguished name. 50 Conventions 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in BCP 14 [RFC2119]. 56 1. Background and Intended Usage 58 In X.500-based directory systems [X.500], including those accessed 59 using the Lightweight Directory Access Protocol (LDAP) [Roadmap], 60 distinguished names (DNs) are used to unambiguously refer to directory 61 entries [X.501][Models]. 63 The structure of a DN [X.501] is described in terms of ASN.1 [X.680]. 64 In the X.500 Directory Access Protocol [X.511] (and other ITU-defined 65 directory protocols), DNs are encoded using the Basic Encoding Rules 66 (BER) [X.690]. In LDAP, DNs are represented in the string form 67 described in this document. 69 It is important to have a common format to be able to unambiguously 70 represent a distinguished name. The primary goal of this 71 specification is ease of encoding and decoding. A secondary goal is 72 to have names that are human readable. It is not expected that LDAP 73 implementations with a human user interface would display these 74 strings directly to the user, but would most likely be performing 75 translations (such as expressing attribute type names in the local 76 national language). 78 This document defines the string representation of Distinguished Names 79 used in LDAP [Protocol][Syntaxes]. Section 2 details the RECOMMENDED 80 algorithm for converting a DN from its ASN.1 structured representation 81 to a string. Section 3 details how to convert a DN from a string to a 82 ASN.1 structured representation. 84 While other documents may define other algorithms for converting a DN 85 from its ASN.1 structured representation to a string, all algorithms 86 MUST produce strings which adhere to the requirements of Section 3. 88 This document does not define a canonical string representation for 89 DNs. Comparison of DNs for equality is to be performed in accordance 90 with the distinguishedNameMatch matching rule [Syntaxes]. 92 This document is an integral part of the LDAP Technical Specification 93 [Roadmap]. 95 This document obsoletes RFC 2253. Changes since RFC 2253 are 96 summarized in Appendix B. 98 This specification assumes familiarity with X.500 [X.500], and the 99 concept of Distinguished Name [X.501][Models]. 101 2. Converting DistinguishedName from ASN.1 to a String 103 X.501 [X.501] defines the ASN.1 [X.680] structure of distinguished 104 name. The following is a variant provided for discussion purposes. 106 DistinguishedName ::= RDNSequence 108 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 110 RelativeDistinguishedName ::= SET SIZE (1..MAX) OF 111 AttributeTypeAndValue 113 AttributeTypeAndValue ::= SEQUENCE { 114 type AttributeType, 115 value AttributeValue } 117 This section defines the RECOMMENDED algorithm for converting a 118 distinguished name from an ASN.1 structured representation to an UTF-8 119 [UTF-8] encoded Universal Character Set (UCS) [ISO10646] character 120 string representation. Other documents may describe other algorithms 121 for converting a distinguished name to a string, but only strings 122 which conform to the grammar defined in Section 3 MUST be produced by 123 LDAP implementations. 125 2.1. Converting the RDNSequence 127 If the RDNSequence is an empty sequence, the result is the empty or 128 zero length string. 130 Otherwise, the output consists of the string encodings of each 131 RelativeDistinguishedName in the RDNSequence (according to Section 132 2.2), starting with the last element of the sequence and moving 133 backwards toward the first. 135 The encodings of adjoining RelativeDistinguishedNames are separated by 136 a comma ("," U+002C) character. 138 2.2. Converting RelativeDistinguishedName 140 When converting from an ASN.1 RelativeDistinguishedName to a string, 141 the output consists of the string encodings of each 142 AttributeTypeAndValue (according to Section 2.3), in any order. 144 Where there is a multi-valued RDN, the outputs from adjoining 145 AttributeTypeAndValues are separated by a plus sign ("+" U+002B) 146 character. 148 2.3. Converting AttributeTypeAndValue 150 The AttributeTypeAndValue is encoded as the string representation of 151 the AttributeType, followed by an equals ("=" U+003D) character, 152 followed by the string representation of the AttributeValue. The 153 encoding of the AttributeValue is given in Section 2.4. 155 If the AttributeType is defined to have a short name and that short 156 name is known to be registered [REGISTRY][BCP64bis] as identifying the 157 AttributeType, that short name, a , is used. Otherwise the 158 AttributeType is encoded as the dotted-decimal encoding, a 159 , of its OBJECT IDENTIFIER. The and 160 is defined in [Models]. 162 Implementations are not expected to dynamically update their knowledge 163 of registered short names. However, implementations SHOULD provide a 164 mechanism to allow its knowledge of registered short names to be 165 updated. 167 2.4. Converting an AttributeValue from ASN.1 to a String 169 If the AttributeType is of the dotted-decimal form, the AttributeValue 170 is represented by an number sign ("#" U+0023) character followed by 171 the hexadecimal encoding of each of the octets of the BER encoding of 172 the X.500 AttributeValue. This form is also used when the syntax of 173 the AttributeValue does not have a native string encoding defined for 174 it or the native string encoding is not restricted to UTF-8 encoded 175 UCS (or a subset of UCS) characters. This form may also be used in 176 other cases, such as when a reversible string representation is 177 desired (see Section 5.2). 179 Otherwise, if the AttributeValue is of a syntax which has a native 180 string encoding, the value is converted first to a UTF-8 encoded UCS 181 string according to its syntax specification (see for example Section 182 6 of [Syntaxes]). If that UTF-8 encoded UCS string does not have any 183 of the following characters which need escaping, then that string can 184 be used as the string representation of the value. 186 - a space (" " U+0020) or number sign ("#" U+0023) occurring at 187 the beginning of the string; 189 - a space (" " U+0020) character occurring at the end of the 190 string; 192 - one of the characters """, "+", ",", ";", "<", ">", or "\" 193 (U+0022, U+002B, U+002C, U+003B, U+003C, U+003E, or U+005C 194 respectively); 196 - the null (U+0000) character. 198 Other characters may be escaped. 200 Each octet of the character to be escaped is replaced by a backslash 201 and two hex digits, which form a single octet in the code of the 202 character. Alternatively, if and only if the character to be escaped 203 is one of 205 " ", """, "#", "+", ",", ";", "<", "=", ">", or "\" 206 (U+0020, U+0022, U+0023, U+002B, U+002C, U+003B, 207 U+003C, U+003D, U+003E, U+005C respectively) 209 it can be prefixed by a backslash ("\" U+0005C). 211 Examples of the escaping mechanism are shown in Section 4. 213 3. Parsing a String back to a Distinguished Name 215 The string representation of Distinguished Names is restricted to 216 UTF-8 [UTF-8] encoded characters from the Universal Character Set 217 (UCS) [ISO10646]. The structure of this string representation is 218 specified using the following Augmented BNF [RFC2234] grammar: 220 distinguishedName = [ relativeDistinguishedName 221 *( COMMA relativeDistinguishedName ) ] 223 relativeDistinguishedName = attributeTypeAndValue 224 *( PLUS attributeTypeAndValue ) 226 attributeTypeAndValue = attributeType EQUALS attributeValue 227 attributeType = descr / numericoid 229 attributeValue = string / hexstring 231 ; The UTF-8 string shall not contain NULL, ESC, or 232 ; one of escaped, shall not start with SHARP or SPACE, 233 ; and shall must not end with SPACE. 234 string = [ (leadchar / pair) 235 [ *( stringchar / pair ) ( trailchar / pair ) ] ] 237 leadchar = LUTF1 / UTFMB 238 LUTF1 = %x01-1F / %x21 / %x24-2A / %x2D-3A / 239 %x3D / %x3F-5B / %x5D-7F 241 trailchar = TUTF1 / UTFMB 242 TUTF1 = %x01-1F / %x21 / %x23-2A / %x2D-3A / 243 %x3D / %x3F-5B / %x5D-7F 245 stringchar = SUTF1 / UTFMB 246 SUTF1 = %x01-21 / %x23-2A / %x2D-3A / 247 %x3D / %x3F-5B / %x5D-7F 249 pair = ESC ( ESC / special / hexpair ) 251 special = escaped / SPACE / SHARP / EQUALS 253 escaped = DQUOTE / PLUS / COMMA / SEMI / LANGLE / RANGLE 255 hexstring = SHARP 1*hexpair 257 hexpair = HEX HEX 259 where the productions , , , , 260 , , , , , , , , 261 , , are defined in [Models]. 263 Each , either a or a , refers to an 264 attribute type of an attribute value assertion (AVA). The 265 is followed by a and an . 266 The is either in or form. 268 If in form, a LDAP string representation asserted value can 269 be obtained by replacing (left-to-right, non-recursively) each 270 appearing in the as follows: 271 replace with ; 272 replace with ; 273 replace with the octet indicated by the . 275 If in form, a BER representation can be obtained from 276 converting each of the to the octet indicated by 277 the . 279 One or more attribute values assertions, separated by , for a 280 relative distinguished name. 282 Zero or more relative distinguished names, separated by , for a 283 distinguished name. 285 Implementations MUST recognize AttributeType name strings 286 (descriptors) listed in the following table, but MAY recognize other 287 name strings. 289 String X.500 AttributeType 290 ------ -------------------------------------------- 291 CN commonName (2.5.4.3) 292 L localityName (2.5.4.7) 293 ST stateOrProvinceName (2.5.4.8) 294 O organizationName (2.5.4.10) 295 OU organizationalUnitName (2.5.4.11) 296 C countryName (2.5.4.6) 297 STREET streetAddress (2.5.4.9) 298 DC domainComponent (0.9.2342.19200300.100.1.25) 299 UID userId (0.9.2342.19200300.100.1.1) 301 Implementations MAY recognize other DN string representations 302 (such as that described in RFC 1779). However, as there is no 303 requirement that alternative DN string representations to be 304 recognized (and, if so, how), implementations SHOULD only generate 305 DN strings in accordance with Section 2 of this document. 307 4. Examples 309 This notation is designed to be convenient for common forms of 310 name. This section gives a few examples of distinguished names 311 written using this notation. First is a name containing three 312 relative distinguished names (RDNs): 314 UID=jsmith,DC=example,DC=net 316 Here is an example name containing three RDNs, in which the first 317 RDN is multi-valued: 319 OU=Sales+CN=J. Smith,DC=example,DC=net 321 This example shows the method of escaping of a comma in a common 322 name: 324 CN=John Smith\, III,DC=example,DC=net 326 An example name in which a value contains a carriage return 327 character: 329 CN=Before\0dAfter,DC=example,DC=net 331 An example name in which an RDN was of an unrecognized type. The 332 value is the BER encoding of an OCTET STRING containing two octets 333 0x48 and 0x69. 335 1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com 337 Finally, an example of an RDN commonName value consisting of 5 338 letters: 340 Unicode Letter Description UCS code UTF-8 Escaped 341 ------------------------------- -------- ------ -------- 342 LATIN CAPITAL LETTER L U+004C 0x4C L 343 LATIN SMALL LETTER U U+0075 0x75 u 344 LATIN SMALL LETTER C WITH CARON U+010D 0xC48D \C4\8D 345 LATIN SMALL LETTER I U+0069 0x69 i 346 LATIN SMALL LETTER C WITH ACUTE U+0107 0xC487 \C4\87 348 could be written in printable ASCII (useful for debugging purposes): 350 CN=Lu\C4\8Di\C4\87 352 5. Security Considerations 354 The following security considerations are specific to the handling of 355 distinguished names. LDAP security considerations are discussed in 356 [Protocol] and other documents comprising the LDAP Technical 357 Specification [Roadmap]. 359 5.1. Disclosure 361 Distinguished Names typically consist of descriptive information about 362 the entries they name, which can be people, organizations, devices or 363 other real-world objects. This frequently includes some of the 364 following kinds of information: 366 - the common name of the object (i.e. a person's full name) 367 - an email or TCP/IP address 368 - its physical location (country, locality, city, street address) 369 - organizational attributes (such as department name or affiliation) 371 Most countries have privacy laws regarding the publication of 372 information about people. 374 5.2. Use of Distinguished Names in Security Applications 376 The transformations of an AttributeValue value from its X.501 form to 377 an LDAP string representation are not always reversible back to the 378 same BER (Basic Encoding Rules) or DER (Distinguished Encoding rules) 379 form. An example of a situation which requires the DER form of a 380 distinguished name is the verification of an X.509 certificate. 382 For example, a distinguished name consisting of one RDN with one AVA, 383 in which the type is commonName and the value is of the TeletexString 384 choice with the letters 'Sam' would be represented in LDAP as the 385 string CN=Sam. Another distinguished name in which the value is still 386 'Sam' but of the PrintableString choice would have the same 387 representation CN=Sam. 389 Applications which require the reconstruction of the DER form of the 390 value SHOULD NOT use the string representation of attribute syntaxes 391 when converting a distinguished name to the LDAP format. Instead, 392 they SHOULD use the hexadecimal form prefixed by the number sign ('#') 393 as described in the first paragraph of Section 2.3. 395 6. Acknowledgment 397 This document is an update to RFC 2253, by Mark Wahl, Tim Howes, and 398 Steve Kille. RFC 2253 was a product of the IETF ASID Working Group. 400 This document is a product of the IETF LDAPBIS Working Group. 402 7. Document Editor's Address 404 Kurt D. Zeilenga 405 OpenLDAP Foundation 406 408 8. Normative References 410 [X.501] International Telecommunication Union - 411 Telecommunication Standardization Sector, "The Directory 412 -- Models," X.501(1993) (also ISO/IEC 9594-2:1994). 414 [X.680] International Telecommunication Union - 415 Telecommunication Standardization Sector, "Abstract 416 Syntax Notation One (ASN.1) - Specification of Basic 417 Notation", X.680(1997) (also ISO/IEC 8824-1:1998). 419 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 420 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 422 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 423 Specifications: ABNF", RFC 2234, November 1997. 425 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 426 10646", draft-yergeau-rfc2279bis-xx.txt, a work in 427 progress. 429 [Models] Zeilenga, K. (editor), "LDAP: Directory Information 430 Models", draft-ietf-ldapbis-models-xx.txt, a work in 431 progress. 433 [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification 434 Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in 435 progress. 437 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", 438 draft-ietf-ldapbis-protocol-xx.txt, a work in progress. 440 [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules", 441 draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress. 443 [Schema] Dally, K. (editor), "LDAP: User Schema", 444 draft-ietf-ldapbis-user-schema-xx.txt, a work in 445 progress. 447 [ISO10646] International Organization for Standardization, 448 "Universal Multiple-Octet Coded Character Set (UCS) - 449 Architecture and Basic Multilingual Plane", ISO/IEC 450 10646-1 : 1993. 452 [REGISTRY] IANA, Object Identifier Descriptors Registry, 453 . 455 9. Informative References 457 [ASCII] Coded Character Set--7-bit American Standard Code for 458 Information Interchange, ANSI X3.4-1986. 460 [X.500] International Telecommunication Union - 461 Telecommunication Standardization Sector, "The Directory 462 -- Overview of concepts, models and services," 463 X.500(1993) (also ISO/IEC 9594-1:1994). 465 [X.690] International Telecommunication Union - 466 Telecommunication Standardization Sector, "Specification 467 of ASN.1 encoding rules: Basic Encoding Rules (BER), 468 Canonical Encoding Rules (CER), and Distinguished 469 Encoding Rules (DER)", X.690(1997) (also ISO/IEC 470 8825-1:1998). 472 [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) - 473 Technical Specification", RFC 2849, June 2000. 475 [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP", draft- 476 ietf-ldapbis-bcp64-xx.txt, a work in progress. 478 Appendix A. Presentation Issues 480 This appendix is provided for informational purposes only, it is not a 481 normative part of this specification. 483 The string representation described in this document is not intended 484 to be presented to humans without translation. However, at times it 485 may be desirable to present non-translated DN strings to users. This 486 section discusses presentation issues associated with non-translated 487 DN strings. Presentation of translated DN strings issues are not 488 discussed in this appendix. Transcoding issues are also not discussed 489 in this appendix. 491 This appendix provides guidance for applications presenting DN strings 492 to users. This section is not comprehensive, it does not discuss all 493 presentation issues which implementors may face. 495 Not all user interfaces are capable of displaying the full set of UCS 496 characters. Some UCS characters are not displayable. 498 It is recommended that human interfaces use the optional hex pair 499 escaping mechanism (Section 2.3) to produce a string representation 500 suitable for display to the user. For example, an application can 501 generate a DN string for display which escapes all non-printable 502 characters appearing in the AttributeValue's string representation (as 503 demonstrated in the final example of Section 4). 505 When a DN string is displayed in free form text, it is often necessary 506 to distinguish the DN string from surrounding text. While this is 507 often done with white space (as demonstrated in Section 4), it is 508 noted that DN strings may end with white space. Careful readers of 509 Section 3 will note that characters "<" (U+003C) and ">" (U+003E) may 510 only appear in the DN string if escaped. These characters are 511 intended to be used in free form text to distinguish a DN string from 512 surrounding text. For example, distinguished the string 513 representation of the DN comprised of one RDN consisting of the AVA: 514 the commonName (CN) value "Sam " from the surrounding text. It should 515 be noted to the user that the wrapping "<" and ">" characters are not 516 part of the DN string. 518 DN strings can be quite long. It is often desirable to line-wrap 519 overly long DN strings in presentations. Line wrapping should be done 520 by inserting white space after the RDN separator character or, if 521 necessary, after the AVA separator character. It should be noted to 522 the user that the inserted white space is not part of the DN string 523 and is to be removed before use in LDAP. For example, 525 The following DN string is long: 526 CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores, 527 O=OpenLDAP Foundation,ST=California,C=US 528 so it has been line-wrapped for readability. The extra white 529 space is to be removed before the DN string is used in LDAP. 531 It is not advised to insert white space otherwise as it may not be 532 obvious to the user which white space is part of the DN string and 533 which white space was added for readability. 535 Another alternative is to use the LDAP Data Interchange Format (LDIF) 536 [RFC2849]. For example, 538 # This entry has a long DN... 539 dn: CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores, 540 O=OpenLDAP Foundation,ST=California,C=US 541 CN: Kurt D. Zeilenga 542 SN: Zeilenga 543 objectClass: person 545 Appendix B. Changes made since RFC 2253 547 This appendix is provided for informational purposes only, it is not a 548 normative part of this specification. 550 The following substantive changes were made to RFC 2253: 551 - Removed IESG Note. The IESG Note has been addressed. 552 - Clarified (in Section 1) that this document does not define a 553 canonical string representation. 554 - Revised specification (in Section 2) to allow short names of any 555 registered attribute type to appear in string representations of 556 DNs instead of being restricted to a "published table". Remove 557 "as an example" language. Added statement (in Section 3) allowing 558 recognition of additional names but require recognization of those 559 names in the published table. The table is now published in 560 Section 3. 561 - Replaced specification of additional requirements for LDAPv2 562 implementations which also support LDAPv3 (RFC 2253, Section 4) 563 with a statement (in Section 3) allowing recognition of 564 alternative string representations. 565 - Updated Section 2.3 to indicate attribute type name strings are 566 case insensitive. 567 - Updated Section 2.4 to allow hex pair escaping of all characters 568 and clarified escaping for when multiple octet UTF-8 characters 569 are present. 570 - Rewrote Section 3 to use ABNF as defined in RFC 2234. 571 - Rewrote Section 3 ABNF to be consistent with 2.4. 572 - Updated Section 3 to describe how to parse elements of the 573 grammar. 574 - Rewrote examples. 575 - Added reference to documentations containing general LDAP security 576 considerations. 577 - Added discussion of presentation issues (Appendix A). 578 - Added this appendix. 580 In addition, numerous editorial changes were made. 582 Intellectual Property Rights 584 The IETF takes no position regarding the validity or scope of any 585 intellectual property or other rights that might be claimed to pertain 586 to the implementation or use of the technology described in this 587 document or the extent to which any license under such rights might or 588 might not be available; neither does it represent that it has made any 589 effort to identify any such rights. Information on the IETF's 590 procedures with respect to rights in standards-track and 591 standards-related documentation can be found in BCP-11. Copies of 592 claims of rights made available for publication and any assurances of 593 licenses to be made available, or the result of an attempt made to 594 obtain a general license or permission for the use of such proprietary 595 rights by implementors or users of this specification can be obtained 596 from the IETF Secretariat. 598 The IETF invites any interested party to bring to its attention any 599 copyrights, patents or patent applications, or other proprietary 600 rights which may cover technology that may be required to practice 601 this standard. Please address the information to the IETF Executive 602 Director. 604 Full Copyright 606 Copyright (C) The Internet Society (2003). All Rights Reserved. 608 This document and translations of it may be copied and furnished to 609 others, and derivative works that comment on or otherwise explain it 610 or assist in its implmentation may be prepared, copied, published and 611 distributed, in whole or in part, without restriction of any kind, 612 provided that the above copyright notice and this paragraph are 613 included on all such copies and derivative works. However, this 614 document itself may not be modified in any way, such as by removing 615 the copyright notice or references to the Internet Society or other 616 Internet organizations, except as needed for the purpose of 617 developing Internet standards in which case the procedures for 618 copyrights defined in the Internet Standards process must be followed, 619 or as required to translate it into languages other than English.