1 INTERNET-DRAFT Editor: Kurt D. Zeilenga
2 Intended Category: Standard Track OpenLDAP Foundation
3 Expires in six months 24 October 2004
9 LDAP: String Representation of Distinguished Names
10 <draft-ietf-ldapbis-dn-15.txt>
18 This document is intended to be, after appropriate review and
19 revision, submitted to the RFC Editor as a Standard Track document
20 replacing RFC 2253. Distribution of this memo is unlimited.
21 Technical discussion of this document will take place on the IETF LDAP
22 Revision (LDAPBIS) Working Group mailing list
23 <ietf-ldapbis@openldap.org>. Please send editorial comments directly
24 to the document editor <Kurt@OpenLDAP.org>.
27 By submitting this Internet-Draft, I accept the provisions of Section
28 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
29 applicable patent or other IPR claims of which I am aware have been
30 disclosed, or will be disclosed, and any of which I become aware will
31 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.
39 Internet-Drafts are draft documents valid for a maximum of six months
40 and may be updated, replaced, or obsoleted by other documents at any
41 time. It is inappropriate to use Internet-Drafts as reference material
42 or to cite them other than as "work in progress."
45 The list of current Internet-Drafts can be accessed at
46 <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
47 Internet-Draft Shadow Directories can be accessed at
48 <http://www.ietf.org/shadow.html>.
51 Copyright (C) The Internet Society (2004). All Rights Reserved.
54 Please see the Full Copyright section near the end of this document
62 Zeilenga LDAP: Distinguished Names [Page 1]
63 INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
70 The X.500 Directory uses distinguished names (DNs) as primary keys to
71 entries in the directory. This document defines the string
72 representation used in the Lightweight Directory Access Protocol
73 (LDAP) to transfer distinguished names. The string representation is
74 designed to give a clean representation of commonly used distinguished
75 names, while being able to represent any distinguished name.
79 1. Background and Intended Usage
82 In X.500-based directory systems [X.500], including those accessed
83 using the Lightweight Directory Access Protocol (LDAP) [Roadmap],
84 distinguished names (DNs) are used to unambiguously refer to directory
85 entries [X.501][Models].
88 The structure of a DN [X.501] is described in terms of ASN.1 [X.680].
89 In the X.500 Directory Access Protocol [X.511] (and other ITU-defined
90 directory protocols), DNs are encoded using the Basic Encoding Rules
91 (BER) [X.690]. In LDAP, DNs are represented in the string form
92 described in this document.
95 It is important to have a common format to be able to unambiguously
96 represent a distinguished name. The primary goal of this
97 specification is ease of encoding and decoding. A secondary goal is
98 to have names that are human readable. It is not expected that LDAP
99 implementations with a human user interface would display these
100 strings directly to the user, but would most likely be performing
101 translations (such as expressing attribute type names in the local
105 This document defines the string representation of Distinguished Names
106 used in LDAP [Protocol][Syntaxes]. Section 2 details the RECOMMENDED
107 algorithm for converting a DN from its ASN.1 structured representation
108 to a string. Section 3 details how to convert a DN from a string to a
109 ASN.1 structured representation.
112 While other documents may define other algorithms for converting a DN
113 from its ASN.1 structured representation to a string, all algorithms
114 MUST produce strings which adhere to the requirements of Section 3.
117 This document does not define a canonical string representation for
118 DNs. Comparison of DNs for equality is to be performed in accordance
119 with the distinguishedNameMatch matching rule [Syntaxes].
122 This document is an integral part of the LDAP Technical Specification
123 [Roadmap]. This document obsoletes RFC 2253. Changes since RFC 2253
128 Zeilenga LDAP: Distinguished Names [Page 2]
129 INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
133 are summarized in Appendix B.
136 This specification assumes familiarity with X.500 [X.500] and the
137 concept of Distinguished Name [X.501][Models].
144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
146 document are to be interpreted as described in BCP 14 [RFC2119].
149 Character names in this document use the notation for code points and
150 names from the Unicode Standard [Unicode]. For example, the letter
151 "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
154 Note: a glossary of terms used in Unicode can be found in [Glossary].
155 Information on the Unicode character encoding model can be found in
160 2. Converting DistinguishedName from ASN.1 to a String
163 X.501 [X.501] defines the ASN.1 [X.680] structure of distinguished
164 name. The following is a variant provided for discussion purposes.
167 DistinguishedName ::= RDNSequence
170 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
173 RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
174 AttributeTypeAndValue
177 AttributeTypeAndValue ::= SEQUENCE {
179 value AttributeValue }
182 This section defines the RECOMMENDED algorithm for converting a
183 distinguished name from an ASN.1 structured representation to an UTF-8
184 [RFC3629] encoded Unicode [Unicode] character string representation.
185 Other documents may describe other algorithms for converting a
186 distinguished name to a string, but only strings which conform to the
187 grammar defined in Section 3 SHALL be produced by LDAP
192 2.1. Converting the RDNSequence
198 Zeilenga LDAP: Distinguished Names [Page 3]
199 INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
203 If the RDNSequence is an empty sequence, the result is the empty or
207 Otherwise, the output consists of the string encodings of each
208 RelativeDistinguishedName in the RDNSequence (according to Section
209 2.2), starting with the last element of the sequence and moving
210 backwards toward the first.
213 The encodings of adjoining RelativeDistinguishedNames are separated by
214 a comma (',' U+002C) character.
218 2.2. Converting RelativeDistinguishedName
221 When converting from an ASN.1 RelativeDistinguishedName to a string,
222 the output consists of the string encodings of each
223 AttributeTypeAndValue (according to Section 2.3), in any order.
226 Where there is a multi-valued RDN, the outputs from adjoining
227 AttributeTypeAndValues are separated by a plus sign ('+' U+002B)
232 2.3. Converting AttributeTypeAndValue
235 The AttributeTypeAndValue is encoded as the string representation of
236 the AttributeType, followed by an equals sign ('=' U+003D) character,
237 followed by the string representation of the AttributeValue. The
238 encoding of the AttributeValue is given in Section 2.4.
241 If the AttributeType is defined to have a short name and that short
242 name is known to be registered [REGISTRY][BCP64bis] as identifying the
243 AttributeType, that short name, a <descr>, is used. Otherwise the
244 AttributeType is encoded as the dotted-decimal encoding, a
245 <numericoid>, of its OBJECT IDENTIFIER. The <descr> and <numericoid>
246 is defined in [Models].
249 Implementations are not expected to dynamically update their knowledge
250 of registered short names. However, implementations SHOULD provide a
251 mechanism to allow its knowledge of registered short names to be
256 2.4. Converting an AttributeValue from ASN.1 to a String
259 If the AttributeType is of the dotted-decimal form, the AttributeValue
260 is represented by an number sign ('#' U+0023) character followed by
261 the hexadecimal encoding of each of the octets of the BER encoding of
266 Zeilenga LDAP: Distinguished Names [Page 4]
267 INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
271 the X.500 AttributeValue. This form is also used when the syntax of
272 the AttributeValue does not have a LDAP-specific [Syntaxes, Section
273 3.1] string encoding defined for it or the LDAP-specific string
274 encoding is not restricted to UTF-8 encoded Unicode characters. This
275 form may also be used in other cases, such as when a reversible string
276 representation is desired (see Section 5.2).
279 Otherwise, if the AttributeValue is of a syntax which has a
280 LDAP-specific string encoding, the value is converted first to a UTF-8
281 encoded Unicode string according to its syntax specification (see
282 [Syntaxes, Section 3.3] for examples). If that UTF-8 encoded Unicode
283 string does not have any of the following characters which need
284 escaping, then that string can be used as the string representation of
288 - a space (' ' U+0020) or number sign ('#' U+0023) occurring at
289 the beginning of the string;
292 - a space (' ' U+0020) character occurring at the end of the
296 - one of the characters '"', '+', ',', ';', '<', '>', or '\'
297 (U+0022, U+002B, U+002C, U+003B, U+003C, U+003E, or U+005C
301 - the null (U+0000) character.
304 Other characters may be escaped.
307 Each octet of the character to be escaped is replaced by a backslash
308 and two hex digits, which form a single octet in the code of the
309 character. Alternatively, if and only if the character to be escaped
313 ' ', '"', '#', '+', ',', ';', '<', '=', '>', or '\'
314 (U+0020, U+0022, U+0023, U+002B, U+002C, U+003B,
315 U+003C, U+003D, U+003E, U+005C respectively)
318 it can be prefixed by a backslash ('\' U+0005C).
321 Examples of the escaping mechanism are shown in Section 4.
325 3. Parsing a String back to a Distinguished Name
328 The string representation of Distinguished Names is restricted to
329 UTF-8 [RFC3629] encoded Unicode [Unicode] characters. The structure
330 of this string representation is specified using the following
335 Zeilenga LDAP: Distinguished Names [Page 5]
336 INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
340 Augmented BNF [RFC2234] grammar:
343 distinguishedName = [ relativeDistinguishedName
344 *( COMMA relativeDistinguishedName ) ]
345 relativeDistinguishedName = attributeTypeAndValue
346 *( PLUS attributeTypeAndValue )
347 attributeTypeAndValue = attributeType EQUALS attributeValue
348 attributeType = descr / numericoid
349 attributeValue = string / hexstring
352 ; The following characters are to be escaped when they appear
353 ; in the value to be encoded: ESC, one of <escaped>, leading
354 ; SHARP or SPACE, trailing SPACE, and NULL.
355 string = [ ( leadchar / pair ) [ *( stringchar / pair )
356 ( trailchar / pair ) ] ]
359 leadchar = LUTF1 / UTFMB
360 LUTF1 = %x01-1F / %x21 / %x24-2A / %x2D-3A /
361 %x3D / %x3F-5B / %x5D-7F
364 trailchar = TUTF1 / UTFMB
365 TUTF1 = %x01-1F / %x21 / %x23-2A / %x2D-3A /
366 %x3D / %x3F-5B / %x5D-7F
369 stringchar = SUTF1 / UTFMB
370 SUTF1 = %x01-21 / %x23-2A / %x2D-3A /
371 %x3D / %x3F-5B / %x5D-7F
374 pair = ESC ( ESC / special / hexpair )
375 special = escaped / SPACE / SHARP / EQUALS
376 escaped = DQUOTE / PLUS / COMMA / SEMI / LANGLE / RANGLE
377 hexstring = SHARP 1*hexpair
381 where the productions <descr>, <numericoid>, <COMMA>, <DQUOTE>,
382 <EQUALS>, <ESC>, <HEX>, <LANGLE>, <NULL>, <PLUS>, <RANGLE>, <SEMI>,
383 <SPACE>, <SHARP>, <UTFMB> are defined in [Models].
386 Each <attributeType>, either a <descr> or a <numericoid>, refers to an
387 attribute type of an attribute value assertion (AVA). The
388 <attributeType> is followed by a <EQUALS> and an <attributeValue>.
389 The <attributeValue> is either in <string> or <hexstring> form.
392 If in <string> form, a LDAP string representation asserted value can
393 be obtained by replacing (left-to-right, non-recursively) each <pair>
394 appearing in the <string> as follows:
395 replace <ESC><ESC> with <ESC>;
396 replace <ESC><special> with <special>;
401 Zeilenga LDAP: Distinguished Names [Page 6]
402 INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
406 replace <ESC><hexpair> with the octet indicated by the <hexpair>.
409 If in <hexstring> form, a BER representation can be obtained from
410 converting each <hexpair> of the <hexstring> to the octet indicated by
414 One or more attribute values assertions, separated by <PLUS>, for a
415 relative distinguished name.
418 Zero or more relative distinguished names, separated by <COMMA>, for a
422 Implementations MUST recognize AttributeType name strings
423 (descriptors) listed in the following table, but MAY recognize other
427 String X.500 AttributeType
428 ------ --------------------------------------------
429 CN commonName (2.5.4.3)
430 L localityName (2.5.4.7)
431 ST stateOrProvinceName (2.5.4.8)
432 O organizationName (2.5.4.10)
433 OU organizationalUnitName (2.5.4.11)
434 C countryName (2.5.4.6)
435 STREET streetAddress (2.5.4.9)
436 DC domainComponent (0.9.2342.19200300.100.1.25)
437 UID userId (0.9.2342.19200300.100.1.1)
440 Implementations MAY recognize other DN string representations (such as
441 that described in RFC 1779). However, as there is no requirement that
442 alternative DN string representations to be recognized (and, if so,
443 how), implementations SHOULD only generate DN strings in accordance
444 with Section 2 of this document.
451 This notation is designed to be convenient for common forms of name.
452 This section gives a few examples of distinguished names written using
453 this notation. First is a name containing three relative
454 distinguished names (RDNs):
457 UID=jsmith,DC=example,DC=net
460 Here is an example name containing three RDNs, in which the first RDN
464 OU=Sales+CN=J. Smith,DC=example,DC=net
469 Zeilenga LDAP: Distinguished Names [Page 7]
470 INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
474 This example shows the method of escaping of a special characters
475 appearing in a common name:
478 CN=James \"Jim\" Smith\, III,DC=example,DC=net
481 The following shows the method for encoding a value which contains a
482 carriage return character:
485 CN=Before\0dAfter,DC=example,DC=net
488 In this RDN example, the type in the RDN is unrecognized, and the
489 value is the BER encoding of an OCTET STRING containing two octets
493 1.3.6.1.4.1.1466.0=#04024869
496 Finally, this example shows an RDN whose commonName value consisting
500 Unicode Character Code UTF-8 Escaped
501 ------------------------------- ------ ------ --------
502 LATIN CAPITAL LETTER L U+004C 0x4C L
503 LATIN SMALL LETTER U U+0075 0x75 u
504 LATIN SMALL LETTER C WITH CARON U+010D 0xC48D \C4\8D
505 LATIN SMALL LETTER I U+0069 0x69 i
506 LATIN SMALL LETTER C WITH ACUTE U+0107 0xC487 \C4\87
509 could be encoded in printable ASCII (useful for debugging purposes)
517 5. Security Considerations
520 The following security considerations are specific to the handling of
521 distinguished names. LDAP security considerations are discussed in
522 [Protocol] and other documents comprising the LDAP Technical
523 Specification [Roadmap].
530 Distinguished Names typically consist of descriptive information about
531 the entries they name, which can be people, organizations, devices or
532 other real-world objects. This frequently includes some of the
533 following kinds of information:
539 Zeilenga LDAP: Distinguished Names [Page 8]
540 INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
544 - the common name of the object (i.e. a person's full name)
545 - an email or TCP/IP address
546 - its physical location (country, locality, city, street address)
547 - organizational attributes (such as department name or affiliation)
550 Most countries have privacy laws regarding the publication of
551 information about people.
555 5.2. Use of Distinguished Names in Security Applications
558 The transformations of an AttributeValue value from its X.501 form to
559 an LDAP string representation are not always reversible back to the
560 same BER (Basic Encoding Rules) or DER (Distinguished Encoding rules)
561 form. An example of a situation which requires the DER form of a
562 distinguished name is the verification of an X.509 certificate.
565 For example, a distinguished name consisting of one RDN with one AVA,
566 in which the type is commonName and the value is of the TeletexString
567 choice with the letters 'Sam' would be represented in LDAP as the
568 string <CN=Sam>. Another distinguished name in which the value is
569 still 'Sam' but of the PrintableString choice would have the same
570 representation <CN=Sam>.
573 Applications which require the reconstruction of the DER form of the
574 value SHOULD NOT use the string representation of attribute syntaxes
575 when converting a distinguished name to the LDAP format. Instead,
576 they SHOULD use the hexadecimal form prefixed by the number sign ('#'
577 U+0023) as described in the first paragraph of Section 2.4.
584 This document is an update to RFC 2253, by Mark Wahl, Tim Howes, and
585 Steve Kille. RFC 2253 was a product of the IETF ASID Working Group.
588 This document is a product of the IETF LDAPBIS Working Group.
592 7. Document Editor's Address
607 Zeilenga LDAP: Distinguished Names [Page 9]
608 INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
612 [[Note to the RFC Editor: please replace the citation tags used in
613 referencing Internet-Drafts with tags of the form RFCnnnn.]]
617 8.1. Normative References
620 [X.501] International Telecommunication Union -
621 Telecommunication Standardization Sector, "The Directory
622 -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
625 [X.680] International Telecommunication Union -
626 Telecommunication Standardization Sector, "Abstract
627 Syntax Notation One (ASN.1) - Specification of Basic
628 Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
631 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
632 Requirement Levels", BCP 14 (also RFC 2119), March 1997.
635 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
636 Specifications: ABNF", RFC 2234, November 1997.
639 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
640 10646", RFC 3629 (also STD 63), November 2003.
643 [Unicode] The Unicode Consortium, "The Unicode Standard, Version
644 3.2.0" is defined by "The Unicode Standard, Version 3.0"
645 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
646 as amended by the "Unicode Standard Annex #27: Unicode
647 3.1" (http://www.unicode.org/reports/tr27/) and by the
648 "Unicode Standard Annex #28: Unicode 3.2"
649 (http://www.unicode.org/reports/tr28/).
652 [Models] Zeilenga, K. (editor), "LDAP: Directory Information
653 Models", draft-ietf-ldapbis-models-xx.txt, a work in
657 [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
658 Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
662 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
663 draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
666 [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
667 draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
670 [Schema] Dally, K. (editor), "LDAP: User Schema",
671 draft-ietf-ldapbis-user-schema-xx.txt, a work in
676 Zeilenga LDAP: Distinguished Names [Page 10]
677 INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
684 [REGISTRY] IANA, Object Identifier Descriptors Registry,
685 <http://www.iana.org/...>.
688 8.2. Informative References
691 [ASCII] Coded Character Set--7-bit American Standard Code for
692 Information Interchange, ANSI X3.4-1986.
695 [X.500] International Telecommunication Union -
696 Telecommunication Standardization Sector, "The Directory
697 -- Overview of concepts, models and services,"
698 X.500(1993) (also ISO/IEC 9594-1:1994).
701 [X.690] International Telecommunication Union -
702 Telecommunication Standardization Sector, "Specification
703 of ASN.1 encoding rules: Basic Encoding Rules (BER),
704 Canonical Encoding Rules (CER), and Distinguished
705 Encoding Rules (DER)", X.690(1997) (also ISO/IEC
709 [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) -
710 Technical Specification", RFC 2849, June 2000.
713 [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
714 draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
717 [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report
718 #17, Character Encoding Model", UTR17,
719 <http://www.unicode.org/unicode/reports/tr17/>, August
723 [Glossary] The Unicode Consortium, "Unicode Glossary",
724 <http://www.unicode.org/glossary/>.
729 Appendix A. Presentation Issues
732 This appendix is provided for informational purposes only, it is not a
733 normative part of this specification.
736 The string representation described in this document is not intended
737 to be presented to humans without translation. However, at times it
738 may be desirable to present non-translated DN strings to users. This
739 section discusses presentation issues associated with non-translated
740 DN strings. Presentation of translated DN strings issues are not
745 Zeilenga LDAP: Distinguished Names [Page 11]
746 INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
750 discussed in this appendix. Transcoding issues are also not discussed
754 This appendix provides guidance for applications presenting DN strings
755 to users. This section is not comprehensive, it does not discuss all
756 presentation issues which implementors may face.
759 Not all user interfaces are capable of displaying the full set of
760 Unicode characters. Some Unicode characters are not displayable.
763 It is recommended that human interfaces use the optional hex pair
764 escaping mechanism (Section 2.3) to produce a string representation
765 suitable for display to the user. For example, an application can
766 generate a DN string for display which escapes all non-printable
767 characters appearing in the AttributeValue's string representation (as
768 demonstrated in the final example of Section 4).
771 When a DN string is displayed in free form text, it is often necessary
772 to distinguish the DN string from surrounding text. While this is
773 often done with white space (as demonstrated in Section 4), it is
774 noted that DN strings may end with white space. Careful readers of
775 Section 3 will note that characters '<' (U+003C) and '>' (U+003E) may
776 only appear in the DN string if escaped. These characters are
777 intended to be used in free form text to distinguish a DN string from
778 surrounding text. For example, <CN=Sam\ > distinguished the string
779 representation of the DN comprised of one RDN consisting of the AVA:
780 the commonName (CN) value 'Sam ' from the surrounding text. It should
781 be noted to the user that the wrapping '<' and '>' characters are not
782 part of the DN string.
785 DN strings can be quite long. It is often desirable to line-wrap
786 overly long DN strings in presentations. Line wrapping should be done
787 by inserting white space after the RDN separator character or, if
788 necessary, after the AVA separator character. It should be noted to
789 the user that the inserted white space is not part of the DN string
790 and is to be removed before use in LDAP. For example,
793 The following DN string is long:
794 CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores,
795 O=OpenLDAP Foundation,ST=California,C=US
796 so it has been line-wrapped for readability. The extra white
797 space is to be removed before the DN string is used in LDAP.
800 It is not advised to insert white space otherwise as it may not be
801 obvious to the user which white space is part of the DN string and
802 which white space was added for readability.
805 Another alternative is to use the LDAP Data Interchange Format (LDIF)
810 Zeilenga LDAP: Distinguished Names [Page 12]
811 INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
815 [RFC2849]. For example,
818 # This entry has a long DN...
819 dn: CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores,
820 O=OpenLDAP Foundation,ST=California,C=US
827 Appendix B. Changes made since RFC 2253
830 This appendix is provided for informational purposes only, it is not a
831 normative part of this specification.
834 The following substantive changes were made to RFC 2253:
835 - Removed IESG Note. The IESG Note has been addressed.
836 - Replaced all references to ISO 10646-1 with [Unicode].
837 - Clarified (in Section 1) that this document does not define a
838 canonical string representation.
839 - Clarified that Section 2 describes the RECOMMENDED encoding
840 algorithm and that alternative algorithms are allowed. Some
841 encoding options described in RFC 2253 are now treated as
842 alternative algorithms in this specification.
843 - Revised specification (in Section 2) to allow short names of any
844 registered attribute type to appear in string representations of
845 DNs instead of being restricted to a "published table". Remove
846 "as an example" language. Added statement (in Section 3) allowing
847 recognition of additional names but require recognization of those
848 names in the published table. The table is now published in
850 - Removed specification of additional requirements for LDAPv2
851 implementations which also support LDAPv3 (RFC 2253, Section 4) as
852 LDAPv2 is now Historic.
853 - Allow recognition of alternative string representations.
854 - Updated Section 2.4 to allow hex pair escaping of all characters
855 and clarified escaping for when multiple octet UTF-8 encodings are
856 present. Indicated that null (U+0000) character is to be escaped.
857 Indicated that equals sign ('=' U+003D) character may be escaped
859 - Rewrote Section 3 to use ABNF as defined in RFC 2234.
860 - Updated the Section 3 ABNF. Changes include:
861 + allow AttributeType short names of length 1 (e.g., 'L'),
862 + use more restrictive <oid> production in AttributeTypes,
863 + do not require escaping of equals sign ('=' U+003D) characters,
864 + do not require escaping of non-leading number sign ('#' U+0023)
866 + allow space (' ' U+0020) to escaped as '\ ',
871 Zeilenga LDAP: Distinguished Names [Page 13]
872 INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
876 + require hex escaping of null (U+0000) characters, and
877 + removed LDAPv2-only constructs.
878 - Updated Section 3 to describe how to parse elements of the
881 - Added reference to documentations containing general LDAP security
883 - Added discussion of presentation issues (Appendix A).
884 - Added this appendix.
887 In addition, numerous editorial changes were made.
891 Intellectual Property Rights
894 The IETF takes no position regarding the validity or scope of any
895 Intellectual Property Rights or other rights that might be claimed to
896 pertain to the implementation or use of the technology described in
897 this document or the extent to which any license under such rights
898 might or might not be available; nor does it represent that it has
899 made any independent effort to identify any such rights. Information
900 on the procedures with respect to rights in RFC documents can be found
901 in BCP 78 and BCP 79.
904 Copies of IPR disclosures made to the IETF Secretariat and any
905 assurances of licenses to be made available, or the result of an
906 attempt made to obtain a general license or permission for the use of
907 such proprietary rights by implementers or users of this specification
908 can be obtained from the IETF on-line IPR repository at
909 http://www.ietf.org/ipr.
912 The IETF invites any interested party to bring to its attention any
913 copyrights, patents or patent applications, or other proprietary
914 rights that may cover technology that may be required to implement
915 this standard. Please address the information to the IETF at
924 Copyright (C) The Internet Society (2004). This document is subject
925 to the rights, licenses and restrictions contained in BCP 78, and
926 except as set forth therein, the authors retain all their rights.
929 This document and the information contained herein are provided on an
930 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
931 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
936 Zeilenga LDAP: Distinguished Names [Page 14]
937 INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
941 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
942 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
943 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
944 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
992 Zeilenga LDAP: Distinguished Names [Page 15]