6 INTERNET-DRAFT Editor: Kurt D. Zeilenga
7 Intended Category: Standard Track OpenLDAP Foundation
8 Expires in six months 10 February 2005
13 LDAP: String Representation of Distinguished Names
14 <draft-ietf-ldapbis-dn-16.txt>
20 This document is intended to be, after appropriate review and
21 revision, submitted to the RFC Editor as a Standard Track document
22 replacing RFC 2253. Distribution of this memo is unlimited.
23 Technical discussion of this document will take place on the IETF LDAP
24 Revision (LDAPBIS) Working Group mailing list
25 <ietf-ldapbis@openldap.org>. Please send editorial comments directly
26 to the document editor <Kurt@OpenLDAP.org>.
28 By submitting this Internet-Draft, I accept the provisions of Section
29 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
30 applicable patent or other IPR claims of which I am aware have been
31 disclosed, or will be disclosed, and any of which I become aware will
32 be disclosed, in accordance with RFC 3668.
34 Internet-Drafts are working documents of the Internet Engineering Task
35 Force (IETF), its areas, and its working groups. Note that other
36 groups may also distribute working documents as Internet-Drafts.
38 Internet-Drafts are draft documents valid for a maximum of six months
39 and may be updated, replaced, or obsoleted by other documents at any
40 time. It is inappropriate to use Internet-Drafts as reference material
41 or to cite them other than as "work in progress."
43 The list of current Internet-Drafts can be accessed at
44 http://www.ietf.org/1id-abstracts.html
46 The list of Internet-Draft Shadow Directories can be accessed at
47 http://www.ietf.org/shadow.html
50 Copyright (C) The Internet Society (2005). All Rights Reserved.
52 Please see the Full Copyright section near the end of this document
57 Zeilenga LDAP: Distinguished Names [Page 1]
59 INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
64 The X.500 Directory uses distinguished names (DNs) as primary keys to
65 entries in the directory. This document defines the string
66 representation used in the Lightweight Directory Access Protocol
67 (LDAP) to transfer distinguished names. The string representation is
68 designed to give a clean representation of commonly used distinguished
69 names, while being able to represent any distinguished name.
72 1. Background and Intended Usage
74 In X.500-based directory systems [X.500], including those accessed
75 using the Lightweight Directory Access Protocol (LDAP) [Roadmap],
76 distinguished names (DNs) are used to unambiguously refer to directory
77 entries [X.501][Models].
79 The structure of a DN [X.501] is described in terms of ASN.1 [X.680].
80 In the X.500 Directory Access Protocol [X.511] (and other ITU-defined
81 directory protocols), DNs are encoded using the Basic Encoding Rules
82 (BER) [X.690]. In LDAP, DNs are represented in the string form
83 described in this document.
85 It is important to have a common format to be able to unambiguously
86 represent a distinguished name. The primary goal of this
87 specification is ease of encoding and decoding. A secondary goal is
88 to have names that are human readable. It is not expected that LDAP
89 implementations with a human user interface would display these
90 strings directly to the user, but would most likely be performing
91 translations (such as expressing attribute type names in the local
94 This document defines the string representation of Distinguished Names
95 used in LDAP [Protocol][Syntaxes]. Section 2 details the RECOMMENDED
96 algorithm for converting a DN from its ASN.1 structured representation
97 to a string. Section 3 details how to convert a DN from a string to a
98 ASN.1 structured representation.
100 While other documents may define other algorithms for converting a DN
101 from its ASN.1 structured representation to a string, all algorithms
102 MUST produce strings which adhere to the requirements of Section 3.
104 This document does not define a canonical string representation for
105 DNs. Comparison of DNs for equality is to be performed in accordance
106 with the distinguishedNameMatch matching rule [Syntaxes].
108 This document is a integral part of the LDAP technical specification
109 [Roadmap] which obsoletes the previously defined LDAP technical
113 Zeilenga LDAP: Distinguished Names [Page 2]
115 INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
118 specification, RFC 3377, in its entirety. This document obsoletes RFC
119 2253. Changes since RFC 2253 are summarized in Appendix B.
121 This specification assumes familiarity with X.500 [X.500] and the
122 concept of Distinguished Name [X.501][Models].
127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
129 document are to be interpreted as described in BCP 14 [RFC2119].
131 Character names in this document use the notation for code points and
132 names from the Unicode Standard [Unicode]. For example, the letter
133 "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
135 Note: a glossary of terms used in Unicode can be found in [Glossary].
136 Information on the Unicode character encoding model can be found in
140 2. Converting DistinguishedName from ASN.1 to a String
142 X.501 [X.501] defines the ASN.1 [X.680] structure of distinguished
143 name. The following is a variant provided for discussion purposes.
145 DistinguishedName ::= RDNSequence
147 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
149 RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
150 AttributeTypeAndValue
152 AttributeTypeAndValue ::= SEQUENCE {
154 value AttributeValue }
156 This section defines the RECOMMENDED algorithm for converting a
157 distinguished name from an ASN.1 structured representation to an UTF-8
158 [RFC3629] encoded Unicode [Unicode] character string representation.
159 Other documents may describe other algorithms for converting a
160 distinguished name to a string, but only strings which conform to the
161 grammar defined in Section 3 SHALL be produced by LDAP
165 2.1. Converting the RDNSequence
169 Zeilenga LDAP: Distinguished Names [Page 3]
171 INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
174 If the RDNSequence is an empty sequence, the result is the empty or
177 Otherwise, the output consists of the string encodings of each
178 RelativeDistinguishedName in the RDNSequence (according to Section
179 2.2), starting with the last element of the sequence and moving
180 backwards toward the first.
182 The encodings of adjoining RelativeDistinguishedNames are separated by
183 a comma (',' U+002C) character.
186 2.2. Converting RelativeDistinguishedName
188 When converting from an ASN.1 RelativeDistinguishedName to a string,
189 the output consists of the string encodings of each
190 AttributeTypeAndValue (according to Section 2.3), in any order.
192 Where there is a multi-valued RDN, the outputs from adjoining
193 AttributeTypeAndValues are separated by a plus sign ('+' U+002B)
197 2.3. Converting AttributeTypeAndValue
199 The AttributeTypeAndValue is encoded as the string representation of
200 the AttributeType, followed by an equals sign ('=' U+003D) character,
201 followed by the string representation of the AttributeValue. The
202 encoding of the AttributeValue is given in Section 2.4.
204 If the AttributeType is defined to have a short name (descriptor)
205 [Models] and that short name is known to be registered
206 [REGISTRY][BCP64bis] as identifying the AttributeType, that short
207 name, a <descr>, is used. Otherwise the AttributeType is encoded as
208 the dotted-decimal encoding, a <numericoid>, of its OBJECT IDENTIFIER.
209 The <descr> and <numericoid> is defined in [Models].
211 Implementations are not expected to dynamically update their knowledge
212 of registered short names. However, implementations SHOULD provide a
213 mechanism to allow its knowledge of registered short names to be
217 2.4. Converting an AttributeValue from ASN.1 to a String
219 If the AttributeType is of the dotted-decimal form, the AttributeValue
220 is represented by an number sign ('#' U+0023) character followed by
221 the hexadecimal encoding of each of the octets of the BER encoding of
225 Zeilenga LDAP: Distinguished Names [Page 4]
227 INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
230 the X.500 AttributeValue. This form is also used when the syntax of
231 the AttributeValue does not have a LDAP-specific [Syntaxes, Section
232 3.1] string encoding defined for it or the LDAP-specific string
233 encoding is not restricted to UTF-8 encoded Unicode characters. This
234 form may also be used in other cases, such as when a reversible string
235 representation is desired (see Section 5.2).
237 Otherwise, if the AttributeValue is of a syntax which has a
238 LDAP-specific string encoding, the value is converted first to a UTF-8
239 encoded Unicode string according to its syntax specification (see
240 [Syntaxes, Section 3.3] for examples). If that UTF-8 encoded Unicode
241 string does not have any of the following characters which need
242 escaping, then that string can be used as the string representation of
245 - a space (' ' U+0020) or number sign ('#' U+0023) occurring at
246 the beginning of the string;
248 - a space (' ' U+0020) character occurring at the end of the
251 - one of the characters '"', '+', ',', ';', '<', '>', or '\'
252 (U+0022, U+002B, U+002C, U+003B, U+003C, U+003E, or U+005C
255 - the null (U+0000) character.
257 Other characters may be escaped.
259 Each octet of the character to be escaped is replaced by a backslash
260 and two hex digits, which form a single octet in the code of the
261 character. Alternatively, if and only if the character to be escaped
264 ' ', '"', '#', '+', ',', ';', '<', '=', '>', or '\'
265 (U+0020, U+0022, U+0023, U+002B, U+002C, U+003B,
266 U+003C, U+003D, U+003E, U+005C respectively)
268 it can be prefixed by a backslash ('\' U+005C).
270 Examples of the escaping mechanism are shown in Section 4.
273 3. Parsing a String back to a Distinguished Name
275 The string representation of Distinguished Names is restricted to
276 UTF-8 [RFC3629] encoded Unicode [Unicode] characters. The structure
277 of this string representation is specified using the following
281 Zeilenga LDAP: Distinguished Names [Page 5]
283 INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
286 Augmented BNF [RFC2234] grammar:
288 distinguishedName = [ relativeDistinguishedName
289 *( COMMA relativeDistinguishedName ) ]
290 relativeDistinguishedName = attributeTypeAndValue
291 *( PLUS attributeTypeAndValue )
292 attributeTypeAndValue = attributeType EQUALS attributeValue
293 attributeType = descr / numericoid
294 attributeValue = string / hexstring
296 ; The following characters are to be escaped when they appear
297 ; in the value to be encoded: ESC, one of <escaped>, leading
298 ; SHARP or SPACE, trailing SPACE, and NULL.
299 string = [ ( leadchar / pair ) [ *( stringchar / pair )
300 ( trailchar / pair ) ] ]
302 leadchar = LUTF1 / UTFMB
303 LUTF1 = %x01-1F / %x21 / %x24-2A / %x2D-3A /
304 %x3D / %x3F-5B / %x5D-7F
306 trailchar = TUTF1 / UTFMB
307 TUTF1 = %x01-1F / %x21 / %x23-2A / %x2D-3A /
308 %x3D / %x3F-5B / %x5D-7F
310 stringchar = SUTF1 / UTFMB
311 SUTF1 = %x01-21 / %x23-2A / %x2D-3A /
312 %x3D / %x3F-5B / %x5D-7F
314 pair = ESC ( ESC / special / hexpair )
315 special = escaped / SPACE / SHARP / EQUALS
316 escaped = DQUOTE / PLUS / COMMA / SEMI / LANGLE / RANGLE
317 hexstring = SHARP 1*hexpair
320 where the productions <descr>, <numericoid>, <COMMA>, <DQUOTE>,
321 <EQUALS>, <ESC>, <HEX>, <LANGLE>, <NULL>, <PLUS>, <RANGLE>, <SEMI>,
322 <SPACE>, <SHARP>, <UTFMB> are defined in [Models].
324 Each <attributeType>, either a <descr> or a <numericoid>, refers to an
325 attribute type of an attribute value assertion (AVA). The
326 <attributeType> is followed by a <EQUALS> and an <attributeValue>.
327 The <attributeValue> is either in <string> or <hexstring> form.
329 If in <string> form, a LDAP string representation asserted value can
330 be obtained by replacing (left-to-right, non-recursively) each <pair>
331 appearing in the <string> as follows:
332 replace <ESC><ESC> with <ESC>;
333 replace <ESC><special> with <special>;
337 Zeilenga LDAP: Distinguished Names [Page 6]
339 INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
342 replace <ESC><hexpair> with the octet indicated by the <hexpair>.
344 If in <hexstring> form, a BER representation can be obtained from
345 converting each <hexpair> of the <hexstring> to the octet indicated by
348 One or more attribute values assertions, separated by <PLUS>, for a
349 relative distinguished name.
351 Zero or more relative distinguished names, separated by <COMMA>, for a
354 Implementations MUST recognize AttributeType name strings
355 (descriptors) listed in the following table, but MAY recognize other
358 String X.500 AttributeType
359 ------ --------------------------------------------
360 CN commonName (2.5.4.3)
361 L localityName (2.5.4.7)
362 ST stateOrProvinceName (2.5.4.8)
363 O organizationName (2.5.4.10)
364 OU organizationalUnitName (2.5.4.11)
365 C countryName (2.5.4.6)
366 STREET streetAddress (2.5.4.9)
367 DC domainComponent (0.9.2342.19200300.100.1.25)
368 UID userId (0.9.2342.19200300.100.1.1)
370 Implementations MAY recognize other DN string representations (such as
371 that described in RFC 1779). However, as there is no requirement that
372 alternative DN string representations to be recognized (and, if so,
373 how), implementations SHOULD only generate DN strings in accordance
374 with Section 2 of this document.
379 This notation is designed to be convenient for common forms of name.
380 This section gives a few examples of distinguished names written using
381 this notation. First is a name containing three relative
382 distinguished names (RDNs):
384 UID=jsmith,DC=example,DC=net
386 Here is an example name containing three RDNs, in which the first RDN
389 OU=Sales+CN=J. Smith,DC=example,DC=net
393 Zeilenga LDAP: Distinguished Names [Page 7]
395 INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
398 This example shows the method of escaping of a special characters
399 appearing in a common name:
401 CN=James \"Jim\" Smith\, III,DC=example,DC=net
403 The following shows the method for encoding a value which contains a
404 carriage return character:
406 CN=Before\0dAfter,DC=example,DC=net
408 In this RDN example, the type in the RDN is unrecognized, and the
409 value is the BER encoding of an OCTET STRING containing two octets
412 1.3.6.1.4.1.1466.0=#04024869
414 Finally, this example shows an RDN whose commonName value consisting
417 Unicode Character Code UTF-8 Escaped
418 ------------------------------- ------ ------ --------
419 LATIN CAPITAL LETTER L U+004C 0x4C L
420 LATIN SMALL LETTER U U+0075 0x75 u
421 LATIN SMALL LETTER C WITH CARON U+010D 0xC48D \C4\8D
422 LATIN SMALL LETTER I U+0069 0x69 i
423 LATIN SMALL LETTER C WITH ACUTE U+0107 0xC487 \C4\87
425 could be encoded in printable ASCII (useful for debugging purposes)
431 5. Security Considerations
433 The following security considerations are specific to the handling of
434 distinguished names. LDAP security considerations are discussed in
435 [Protocol] and other documents comprising the LDAP Technical
436 Specification [Roadmap].
441 Distinguished Names typically consist of descriptive information about
442 the entries they name, which can be people, organizations, devices or
443 other real-world objects. This frequently includes some of the
444 following kinds of information:
449 Zeilenga LDAP: Distinguished Names [Page 8]
451 INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
454 - the common name of the object (i.e. a person's full name)
455 - an email or TCP/IP address
456 - its physical location (country, locality, city, street address)
457 - organizational attributes (such as department name or affiliation)
459 In some cases, such information can be considered sensitive. In many
460 countries, privacy laws exist which prohibit disclosure of certain
461 kinds of descriptive information (e.g., email addresses). Hence,
462 servers implementors are encouraged to support DIT structural rules
463 and name forms [Models] as these provide a mechanism for
464 administrators to select appropriate naming attributes for entries.
465 Administrators are encouraged to use these mechanisms, access
466 controls, and other administrative controls which may be available to
467 restrict use of attributes containing sensitive information in naming
468 of entries. Additionally, use of authentication and data security
469 services in LDAP [AuthMeth][Protocol] should be considered.
472 5.2. Use of Distinguished Names in Security Applications
474 The transformations of an AttributeValue value from its X.501 form to
475 an LDAP string representation are not always reversible back to the
476 same BER (Basic Encoding Rules) or DER (Distinguished Encoding rules)
477 form. An example of a situation which requires the DER form of a
478 distinguished name is the verification of an X.509 certificate.
480 For example, a distinguished name consisting of one RDN with one AVA,
481 in which the type is commonName and the value is of the TeletexString
482 choice with the letters 'Sam' would be represented in LDAP as the
483 string <CN=Sam>. Another distinguished name in which the value is
484 still 'Sam' but of the PrintableString choice would have the same
485 representation <CN=Sam>.
487 Applications which require the reconstruction of the DER form of the
488 value SHOULD NOT use the string representation of attribute syntaxes
489 when converting a distinguished name to the LDAP format. Instead,
490 they SHOULD use the hexadecimal form prefixed by the number sign ('#'
491 U+0023) as described in the first paragraph of Section 2.4.
496 This document is an update to RFC 2253, by Mark Wahl, Tim Howes, and
497 Steve Kille. RFC 2253 was a product of the IETF ASID Working Group.
499 This document is a product of the IETF LDAPBIS Working Group.
505 Zeilenga LDAP: Distinguished Names [Page 9]
507 INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
510 7. Document Editor's Address
515 Email: Kurt@OpenLDAP.org
520 [[Note to the RFC Editor: please replace the citation tags used in
521 referencing Internet-Drafts with tags of the form RFCnnnn where
525 8.1. Normative References
527 [X.501] International Telecommunication Union -
528 Telecommunication Standardization Sector, "The Directory
529 -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
531 [X.680] International Telecommunication Union -
532 Telecommunication Standardization Sector, "Abstract
533 Syntax Notation One (ASN.1) - Specification of Basic
534 Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
536 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
537 Requirement Levels", BCP 14 (also RFC 2119), March 1997.
539 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
540 Specifications: ABNF", RFC 2234, November 1997.
542 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
543 10646", RFC 3629 (also STD 63), November 2003.
545 [Unicode] The Unicode Consortium, "The Unicode Standard, Version
546 3.2.0" is defined by "The Unicode Standard, Version 3.0"
547 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
548 as amended by the "Unicode Standard Annex #27: Unicode
549 3.1" (http://www.unicode.org/reports/tr27/) and by the
550 "Unicode Standard Annex #28: Unicode 3.2"
551 (http://www.unicode.org/reports/tr28/).
553 [Models] Zeilenga, K. (editor), "LDAP: Directory Information
554 Models", draft-ietf-ldapbis-models-xx.txt, a work in
557 [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
561 Zeilenga LDAP: Distinguished Names [Page 10]
563 INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
566 Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
569 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
570 draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
572 [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
573 draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
575 [Schema] Dally, K. (editor), "LDAP: User Schema",
576 draft-ietf-ldapbis-user-schema-xx.txt, a work in
579 [REGISTRY] IANA, Object Identifier Descriptors Registry,
580 <http://www.iana.org/...>.
582 8.2. Informative References
584 [ASCII] Coded Character Set--7-bit American Standard Code for
585 Information Interchange, ANSI X3.4-1986.
587 [X.500] International Telecommunication Union -
588 Telecommunication Standardization Sector, "The Directory
589 -- Overview of concepts, models and services,"
590 X.500(1993) (also ISO/IEC 9594-1:1994).
592 [X.690] International Telecommunication Union -
593 Telecommunication Standardization Sector, "Specification
594 of ASN.1 encoding rules: Basic Encoding Rules (BER),
595 Canonical Encoding Rules (CER), and Distinguished
596 Encoding Rules (DER)", X.690(1997) (also ISO/IEC
599 [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) -
600 Technical Specification", RFC 2849, June 2000.
602 [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
603 draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
605 [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report
606 #17, Character Encoding Model", UTR17,
607 <http://www.unicode.org/unicode/reports/tr17/>, August
610 [Glossary] The Unicode Consortium, "Unicode Glossary",
611 <http://www.unicode.org/glossary/>.
617 Zeilenga LDAP: Distinguished Names [Page 11]
619 INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
622 Appendix A. Presentation Issues
624 This appendix is provided for informational purposes only, it is not a
625 normative part of this specification.
627 The string representation described in this document is not intended
628 to be presented to humans without translation. However, at times it
629 may be desirable to present non-translated DN strings to users. This
630 section discusses presentation issues associated with non-translated
631 DN strings. Presentation of translated DN strings issues are not
632 discussed in this appendix. Transcoding issues are also not discussed
635 This appendix provides guidance for applications presenting DN strings
636 to users. This section is not comprehensive, it does not discuss all
637 presentation issues which implementors may face.
639 Not all user interfaces are capable of displaying the full set of
640 Unicode characters. Some Unicode characters are not displayable.
642 It is recommended that human interfaces use the optional hex pair
643 escaping mechanism (Section 2.3) to produce a string representation
644 suitable for display to the user. For example, an application can
645 generate a DN string for display which escapes all non-printable
646 characters appearing in the AttributeValue's string representation (as
647 demonstrated in the final example of Section 4).
649 When a DN string is displayed in free form text, it is often necessary
650 to distinguish the DN string from surrounding text. While this is
651 often done with white space (as demonstrated in Section 4), it is
652 noted that DN strings may end with white space. Careful readers of
653 Section 3 will note that characters '<' (U+003C) and '>' (U+003E) may
654 only appear in the DN string if escaped. These characters are
655 intended to be used in free form text to distinguish a DN string from
656 surrounding text. For example, <CN=Sam\ > distinguished the string
657 representation of the DN comprised of one RDN consisting of the AVA:
658 the commonName (CN) value 'Sam ' from the surrounding text. It should
659 be noted to the user that the wrapping '<' and '>' characters are not
660 part of the DN string.
662 DN strings can be quite long. It is often desirable to line-wrap
663 overly long DN strings in presentations. Line wrapping should be done
664 by inserting white space after the RDN separator character or, if
665 necessary, after the AVA separator character. It should be noted to
666 the user that the inserted white space is not part of the DN string
667 and is to be removed before use in LDAP. For example,
669 The following DN string is long:
673 Zeilenga LDAP: Distinguished Names [Page 12]
675 INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
678 CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores,
679 O=OpenLDAP Foundation,ST=California,C=US
680 so it has been line-wrapped for readability. The extra white
681 space is to be removed before the DN string is used in LDAP.
683 It is not advised to insert white space otherwise as it may not be
684 obvious to the user which white space is part of the DN string and
685 which white space was added for readability.
687 Another alternative is to use the LDAP Data Interchange Format (LDIF)
688 [RFC2849]. For example,
690 # This entry has a long DN...
691 dn: CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores,
692 O=OpenLDAP Foundation,ST=California,C=US
698 Appendix B. Changes made since RFC 2253
700 This appendix is provided for informational purposes only, it is not a
701 normative part of this specification.
703 The following substantive changes were made to RFC 2253:
704 - Removed IESG Note. The IESG Note has been addressed.
705 - Replaced all references to ISO 10646-1 with [Unicode].
706 - Clarified (in Section 1) that this document does not define a
707 canonical string representation.
708 - Clarified that Section 2 describes the RECOMMENDED encoding
709 algorithm and that alternative algorithms are allowed. Some
710 encoding options described in RFC 2253 are now treated as
711 alternative algorithms in this specification.
712 - Revised specification (in Section 2) to allow short names of any
713 registered attribute type to appear in string representations of
714 DNs instead of being restricted to a "published table". Remove
715 "as an example" language. Added statement (in Section 3) allowing
716 recognition of additional names but require recognization of those
717 names in the published table. The table is now published in
719 - Removed specification of additional requirements for LDAPv2
720 implementations which also support LDAPv3 (RFC 2253, Section 4) as
721 LDAPv2 is now Historic.
722 - Allow recognition of alternative string representations.
723 - Updated Section 2.4 to allow hex pair escaping of all characters
724 and clarified escaping for when multiple octet UTF-8 encodings are
725 present. Indicated that null (U+0000) character is to be escaped.
729 Zeilenga LDAP: Distinguished Names [Page 13]
731 INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
734 Indicated that equals sign ('=' U+003D) character may be escaped
736 - Rewrote Section 3 to use ABNF as defined in RFC 2234.
737 - Updated the Section 3 ABNF. Changes include:
738 + allow AttributeType short names of length 1 (e.g., 'L'),
739 + use more restrictive <oid> production in AttributeTypes,
740 + do not require escaping of equals sign ('=' U+003D) characters,
741 + do not require escaping of non-leading number sign ('#' U+0023)
743 + allow space (' ' U+0020) to escaped as '\ ',
744 + require hex escaping of null (U+0000) characters, and
745 + removed LDAPv2-only constructs.
746 - Updated Section 3 to describe how to parse elements of the
749 - Added reference to documentations containing general LDAP security
751 - Added discussion of presentation issues (Appendix A).
752 - Added this appendix.
754 In addition, numerous editorial changes were made.
757 Intellectual Property Rights
759 The IETF takes no position regarding the validity or scope of any
760 Intellectual Property Rights or other rights that might be claimed to
761 pertain to the implementation or use of the technology described in
762 this document or the extent to which any license under such rights
763 might or might not be available; nor does it represent that it has
764 made any independent effort to identify any such rights. Information
765 on the procedures with respect to rights in RFC documents can be found
766 in BCP 78 and BCP 79.
768 Copies of IPR disclosures made to the IETF Secretariat and any
769 assurances of licenses to be made available, or the result of an
770 attempt made to obtain a general license or permission for the use of
771 such proprietary rights by implementers or users of this specification
772 can be obtained from the IETF on-line IPR repository at
773 http://www.ietf.org/ipr.
775 The IETF invites any interested party to bring to its attention any
776 copyrights, patents or patent applications, or other proprietary
777 rights that may cover technology that may be required to implement
778 this standard. Please address the information to the IETF at
785 Zeilenga LDAP: Distinguished Names [Page 14]
787 INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
792 Copyright (C) The Internet Society (2005). This document is subject
793 to the rights, licenses and restrictions contained in BCP 78, and
794 except as set forth therein, the authors retain all their rights.
796 This document and the information contained herein are provided on an
797 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
798 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
799 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
800 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
801 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
802 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
841 Zeilenga LDAP: Distinguished Names [Page 15]