7 INTERNET-DRAFT Editor: Kurt D. Zeilenga
8 Intended Category: Standard Track OpenLDAP Foundation
9 Expires in six months 27 October 2003
14 LDAP: String Representation of Distinguished Names
15 <draft-ietf-ldapbis-dn-12.txt>
21 This document is an Internet-Draft and is in full conformance with all
22 provisions of Section 10 of RFC2026.
24 This document is intended to be, after appropriate review and
25 revision, submitted to the RFC Editor as a Standard Track document
26 replacing RFC 2253. Distribution of this memo is unlimited.
27 Technical discussion of this document will take place on the IETF LDAP
28 Revision (LDAPBIS) Working Group mailing list
29 <ietf-ldapbis@openldap.org>. Please send editorial comments directly
30 to the document editor <Kurt@OpenLDAP.org>.
32 Internet-Drafts are working documents of the Internet Engineering Task
33 Force (IETF), its areas, and its working groups. Note that other
34 groups may also distribute working documents as Internet-Drafts.
35 Internet-Drafts are draft documents valid for a maximum of six months
36 and may be updated, replaced, or obsoleted by other documents at any
37 time. It is inappropriate to use Internet-Drafts as reference
38 material or to cite them other than as ``work in progress.''
40 The list of current Internet-Drafts can be accessed at
41 <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
42 Internet-Draft Shadow Directories can be accessed at
43 <http://www.ietf.org/shadow.html>.
45 Copyright (C) The Internet Society (2003). All Rights Reserved.
47 Please see the Full Copyright section near the end of this document
58 Zeilenga LDAP: Distinguished Names [Page 1]
60 INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
65 The X.500 Directory uses distinguished names (DNs) as primary keys to
66 entries in the directory. This document defines the string
67 representation used in the Lightweight Directory Access Protocol
68 (LDAP) to transfer distinguished names. The string representation is
69 designed to give a clean representation of commonly used distinguished
70 names, while being able to represent any distinguished name.
75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
77 document are to be interpreted as described in BCP 14 [RFC2119].
80 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].
87 The structure of a DN [X.501] is described in terms of ASN.1 [X.680].
88 In the X.500 Directory Access Protocol [X.511] (and other ITU-defined
89 directory protocols), DNs are encoded using the Basic Encoding Rules
90 (BER) [X.690]. In LDAP, DNs are represented in the string form
91 described in this document.
93 It is important to have a common format to be able to unambiguously
94 represent a distinguished name. The primary goal of this
95 specification is ease of encoding and decoding. A secondary goal is
96 to have names that are human readable. It is not expected that LDAP
97 implementations with a human user interface would display these
98 strings directly to the user, but would most likely be performing
99 translations (such as expressing attribute type names in the local
102 This document defines the string representation of Distinguished Names
103 used in LDAP [Protocol][Syntaxes]. Section 2 details the RECOMMENDED
104 algorithm for converting a DN from its ASN.1 structured representation
105 to a string. Section 3 details how to convert a DN from a string to a
106 ASN.1 structured representation.
108 While other documents may define other algorithms for converting a DN
109 from its ASN.1 structured representation to a string, all algorithms
110 MUST produce strings which adhere to the requirements of Section 3.
114 Zeilenga LDAP: Distinguished Names [Page 2]
116 INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
119 This document does not define a canonical string representation for
120 DNs. Comparison of DNs for equality is to be performed in accordance
121 with the distinguishedNameMatch matching rule [Syntaxes].
123 This document is an integral part of the LDAP Technical Specification
126 This document obsoletes RFC 2253. Changes since RFC 2253 are
127 summarized in Appendix B.
129 This specification assumes familiarity with X.500 [X.500], and the
130 concept of Distinguished Name [X.501][Models].
133 2. Converting DistinguishedName from ASN.1 to a String
135 X.501 [X.501] defines the ASN.1 [X.680] structure of distinguished
136 name. The following is a variant provided for discussion purposes.
138 DistinguishedName ::= RDNSequence
140 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
142 RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
143 AttributeTypeAndValue
145 AttributeTypeAndValue ::= SEQUENCE {
147 value AttributeValue }
149 This section defines the RECOMMENDED algorithm for converting a
150 distinguished name from an ASN.1 structured representation to an UTF-8
151 [UTF-8] encoded Universal Character Set (UCS) [ISO10646] character
152 string representation. Other documents may describe other algorithms
153 for converting a distinguished name to a string, but only strings
154 which conform to the grammar defined in Section 3 MUST be produced by
155 LDAP implementations.
158 2.1. Converting the RDNSequence
160 If the RDNSequence is an empty sequence, the result is the empty or
163 Otherwise, the output consists of the string encodings of each
164 RelativeDistinguishedName in the RDNSequence (according to Section
165 2.2), starting with the last element of the sequence and moving
166 backwards toward the first.
170 Zeilenga LDAP: Distinguished Names [Page 3]
172 INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
175 The encodings of adjoining RelativeDistinguishedNames are separated by
176 a comma ("," U+002C) character.
179 2.2. Converting RelativeDistinguishedName
181 When converting from an ASN.1 RelativeDistinguishedName to a string,
182 the output consists of the string encodings of each
183 AttributeTypeAndValue (according to Section 2.3), in any order.
185 Where there is a multi-valued RDN, the outputs from adjoining
186 AttributeTypeAndValues are separated by a plus sign ("+" U+002B)
190 2.3. Converting AttributeTypeAndValue
192 The AttributeTypeAndValue is encoded as the string representation of
193 the AttributeType, followed by an equals ("=" U+003D) character,
194 followed by the string representation of the AttributeValue. The
195 encoding of the AttributeValue is given in Section 2.4.
197 If the AttributeType is defined to have a short name and that short
198 name is known to be registered [REGISTRY][BCP64bis] as identifying the
199 AttributeType, that short name, a <descr>, is used. Otherwise the
200 AttributeType is encoded as the dotted-decimal encoding, a
201 <numericoid>, of its OBJECT IDENTIFIER. The <descr> and <numericoid>
202 is defined in [Models].
204 Implementations are not expected to dynamically update their knowledge
205 of registered short names. However, implementations SHOULD provide a
206 mechanism to allow its knowledge of registered short names to be
210 2.4. Converting an AttributeValue from ASN.1 to a String
212 If the AttributeType is of the dotted-decimal form, the AttributeValue
213 is represented by an number sign ("#" U+0023) character followed by
214 the hexadecimal encoding of each of the octets of the BER encoding of
215 the X.500 AttributeValue. This form is also used when the syntax of
216 the AttributeValue does not have a native string encoding defined for
217 it or the native string encoding is not restricted to UTF-8 encoded
218 UCS (or a subset of UCS) characters. This form may also be used in
219 other cases, such as when a reversible string representation is
220 desired (see Section 5.2).
222 Otherwise, if the AttributeValue is of a syntax which has a native
226 Zeilenga LDAP: Distinguished Names [Page 4]
228 INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
231 string encoding, the value is converted first to a UTF-8 encoded UCS
232 string according to its syntax specification (see for example Section
233 6 of [Syntaxes]). If that UTF-8 encoded UCS string does not have any
234 of the following characters which need escaping, then that string can
235 be used as the string representation of the value.
237 - a space (" " U+0020) or number sign ("#" U+0023) occurring at
238 the beginning of the string;
240 - a space (" " U+0020) character occurring at the end of the
243 - one of the characters """, "+", ",", ";", "<", ">", or "\"
244 (U+0022, U+002B, U+002C, U+003B, U+003C, U+003E, or U+005C
247 - the null (U+0000) character.
249 Other characters may be escaped.
251 Each octet of the character to be escaped is replaced by a backslash
252 and two hex digits, which form a single octet in the code of the
253 character. Alternatively, if and only if the character to be escaped
256 " ", """, "#", "+", ",", ";", "<", "=", ">", or "\"
257 (U+0020, U+0022, U+0023, U+002B, U+002C, U+003B,
258 U+003C, U+003D, U+003E, U+005C respectively)
260 it can be prefixed by a backslash ("\" U+0005C).
262 Examples of the escaping mechanism are shown in Section 4.
265 3. Parsing a String back to a Distinguished Name
267 The string representation of Distinguished Names is restricted to
268 UTF-8 [UTF-8] encoded characters from the Universal Character Set
269 (UCS) [ISO10646]. The structure of this string representation is
270 specified using the following Augmented BNF [RFC2234] grammar:
272 distinguishedName = [ relativeDistinguishedName
273 *( COMMA relativeDistinguishedName ) ]
275 relativeDistinguishedName = attributeTypeAndValue
276 *( PLUS attributeTypeAndValue )
278 attributeTypeAndValue = attributeType EQUALS attributeValue
282 Zeilenga LDAP: Distinguished Names [Page 5]
284 INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
287 attributeType = descr / numericoid
289 attributeValue = string / hexstring
291 ; The UTF-8 string shall not contain NULL, ESC, or
292 ; one of escaped, shall not start with SHARP or SPACE,
293 ; and shall must not end with SPACE.
294 string = [ (leadchar / pair)
295 [ *( stringchar / pair ) ( trailchar / pair ) ] ]
297 leadchar = LUTF1 / UTFMB
298 LUTF1 = %x01-1F / %x21 / %x24-2A / %x2D-3A /
299 %x3D / %x3F-5B / %x5D-7F
301 trailchar = TUTF1 / UTFMB
302 TUTF1 = %x01-1F / %x21 / %x23-2A / %x2D-3A /
303 %x3D / %x3F-5B / %x5D-7F
305 stringchar = SUTF1 / UTFMB
306 SUTF1 = %x01-21 / %x23-2A / %x2D-3A /
307 %x3D / %x3F-5B / %x5D-7F
309 pair = ESC ( ESC / special / hexpair )
311 special = escaped / SPACE / SHARP / EQUALS
313 escaped = DQUOTE / PLUS / COMMA / SEMI / LANGLE / RANGLE
315 hexstring = SHARP 1*hexpair
319 where the productions <descr>, <numericoid>, <COMMA>, <DQUOTE>,
320 <EQUALS>, <ESC>, <HEX>, <LANGLE>, <NULL>, <PLUS>, <RANGLE>, <SEMI>,
321 <SPACE>, <SHARP>, <UTFMB> are defined in [Models].
323 Each <attributeType>, either a <descr> or a <numericoid>, refers to an
324 attribute type of an attribute value assertion (AVA). The
325 <attributeType> is followed by a <EQUALS> and an <attributeValue>.
326 The <attributeValue> is either in <string> or <hexstring> form.
328 If in <string> form, a LDAP string representation asserted value can
329 be obtained by replacing (left-to-right, non-recursively) each <pair>
330 appearing in the <string> as follows:
331 replace <ESC><ESC> with <ESC>;
332 replace <ESC><special> with <special>;
333 replace <ESC><hexpair> with the octet indicated by the <hexpair>.
338 Zeilenga LDAP: Distinguished Names [Page 6]
340 INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
343 If in <hexstring> form, a BER representation can be obtained from
344 converting each <hexpair> of the <hexstring> to the octet indicated by
347 One or more attribute values assertions, separated by <PLUS>, for a
348 relative distinguished name.
350 Zero or more relative distinguished names, separated by <COMMA>, for a
353 Implementations MUST recognize AttributeType name strings
354 (descriptors) listed in the following table, but MAY recognize other
357 String X.500 AttributeType
358 ------ --------------------------------------------
359 CN commonName (2.5.4.3)
360 L localityName (2.5.4.7)
361 ST stateOrProvinceName (2.5.4.8)
362 O organizationName (2.5.4.10)
363 OU organizationalUnitName (2.5.4.11)
364 C countryName (2.5.4.6)
365 STREET streetAddress (2.5.4.9)
366 DC domainComponent (0.9.2342.19200300.100.1.25)
367 UID userId (0.9.2342.19200300.100.1.1)
369 Implementations MAY recognize other DN string representations
370 (such as that described in RFC 1779). However, as there is no
371 requirement that alternative DN string representations to be
372 recognized (and, if so, how), implementations SHOULD only generate
373 DN strings in accordance with Section 2 of this document.
378 This notation is designed to be convenient for common forms of
379 name. This section gives a few examples of distinguished names
380 written using this notation. First is a name containing three
381 relative distinguished names (RDNs):
383 UID=jsmith,DC=example,DC=net
385 Here is an example name containing three RDNs, in which the first
388 OU=Sales+CN=J. Smith,DC=example,DC=net
390 This example shows the method of escaping of a comma in a common
394 Zeilenga LDAP: Distinguished Names [Page 7]
396 INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
401 CN=John Smith\, III,DC=example,DC=net
403 An example name in which a value contains a carriage return
406 CN=Before\0dAfter,DC=example,DC=net
408 An example name in which an RDN was of an unrecognized type. The
409 value is the BER encoding of an OCTET STRING containing two octets
412 1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com
414 Finally, an example of an RDN commonName value consisting of 5
417 Unicode Letter Description UCS 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 written in printable ASCII (useful for debugging purposes):
430 5. Security Considerations
432 The following security considerations are specific to the handling of
433 distinguished names. LDAP security considerations are discussed in
434 [Protocol] and other documents comprising the LDAP Technical
435 Specification [Roadmap].
440 Distinguished Names typically consist of descriptive information about
441 the entries they name, which can be people, organizations, devices or
442 other real-world objects. This frequently includes some of the
443 following kinds of information:
445 - the common name of the object (i.e. a person's full name)
446 - an email or TCP/IP address
450 Zeilenga LDAP: Distinguished Names [Page 8]
452 INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
455 - its physical location (country, locality, city, street address)
456 - organizational attributes (such as department name or affiliation)
458 Most countries have privacy laws regarding the publication of
459 information about people.
462 5.2. Use of Distinguished Names in Security Applications
464 The transformations of an AttributeValue value from its X.501 form to
465 an LDAP string representation are not always reversible back to the
466 same BER (Basic Encoding Rules) or DER (Distinguished Encoding rules)
467 form. An example of a situation which requires the DER form of a
468 distinguished name is the verification of an X.509 certificate.
470 For example, a distinguished name consisting of one RDN with one AVA,
471 in which the type is commonName and the value is of the TeletexString
472 choice with the letters 'Sam' would be represented in LDAP as the
473 string CN=Sam. Another distinguished name in which the value is still
474 'Sam' but of the PrintableString choice would have the same
475 representation CN=Sam.
477 Applications which require the reconstruction of the DER form of the
478 value SHOULD NOT use the string representation of attribute syntaxes
479 when converting a distinguished name to the LDAP format. Instead,
480 they SHOULD use the hexadecimal form prefixed by the number sign ('#')
481 as described in the first paragraph of Section 2.3.
486 This document is an update to RFC 2253, by Mark Wahl, Tim Howes, and
487 Steve Kille. RFC 2253 was a product of the IETF ASID Working Group.
489 This document is a product of the IETF LDAPBIS Working Group.
492 7. Document Editor's Address
499 8. Normative References
501 [X.501] International Telecommunication Union -
502 Telecommunication Standardization Sector, "The Directory
506 Zeilenga LDAP: Distinguished Names [Page 9]
508 INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
511 -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
513 [X.680] International Telecommunication Union -
514 Telecommunication Standardization Sector, "Abstract
515 Syntax Notation One (ASN.1) - Specification of Basic
516 Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
518 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
519 Requirement Levels", BCP 14 (also RFC 2119), March 1997.
521 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
522 Specifications: ABNF", RFC 2234, November 1997.
524 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
525 10646", draft-yergeau-rfc2279bis-xx.txt, a work in
528 [Models] Zeilenga, K. (editor), "LDAP: Directory Information
529 Models", draft-ietf-ldapbis-models-xx.txt, a work in
532 [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
533 Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
536 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
537 draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
539 [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
540 draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
542 [Schema] Dally, K. (editor), "LDAP: User Schema",
543 draft-ietf-ldapbis-user-schema-xx.txt, a work in
546 [ISO10646] International Organization for Standardization,
547 "Universal Multiple-Octet Coded Character Set (UCS) -
548 Architecture and Basic Multilingual Plane", ISO/IEC
551 [REGISTRY] IANA, Object Identifier Descriptors Registry,
552 <http://www.iana.org/...>.
554 9. Informative References
556 [ASCII] Coded Character Set--7-bit American Standard Code for
557 Information Interchange, ANSI X3.4-1986.
562 Zeilenga LDAP: Distinguished Names [Page 10]
564 INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
567 [X.500] International Telecommunication Union -
568 Telecommunication Standardization Sector, "The Directory
569 -- Overview of concepts, models and services,"
570 X.500(1993) (also ISO/IEC 9594-1:1994).
572 [X.690] International Telecommunication Union -
573 Telecommunication Standardization Sector, "Specification
574 of ASN.1 encoding rules: Basic Encoding Rules (BER),
575 Canonical Encoding Rules (CER), and Distinguished
576 Encoding Rules (DER)", X.690(1997) (also ISO/IEC
579 [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) -
580 Technical Specification", RFC 2849, June 2000.
582 [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP", draft-
583 ietf-ldapbis-bcp64-xx.txt, a work in progress.
587 Appendix A. Presentation Issues
589 This appendix is provided for informational purposes only, it is not a
590 normative part of this specification.
592 The string representation described in this document is not intended
593 to be presented to humans without translation. However, at times it
594 may be desirable to present non-translated DN strings to users. This
595 section discusses presentation issues associated with non-translated
596 DN strings. Presentation of translated DN strings issues are not
597 discussed in this appendix. Transcoding issues are also not discussed
600 This appendix provides guidance for applications presenting DN strings
601 to users. This section is not comprehensive, it does not discuss all
602 presentation issues which implementors may face.
604 Not all user interfaces are capable of displaying the full set of UCS
605 characters. Some UCS characters are not displayable.
607 It is recommended that human interfaces use the optional hex pair
608 escaping mechanism (Section 2.3) to produce a string representation
609 suitable for display to the user. For example, an application can
610 generate a DN string for display which escapes all non-printable
611 characters appearing in the AttributeValue's string representation (as
612 demonstrated in the final example of Section 4).
614 When a DN string is displayed in free form text, it is often necessary
618 Zeilenga LDAP: Distinguished Names [Page 11]
620 INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
623 to distinguish the DN string from surrounding text. While this is
624 often done with white space (as demonstrated in Section 4), it is
625 noted that DN strings may end with white space. Careful readers of
626 Section 3 will note that characters "<" (U+003C) and ">" (U+003E) may
627 only appear in the DN string if escaped. These characters are
628 intended to be used in free form text to distinguish a DN string from
629 surrounding text. For example, <CN=Sam\ > distinguished the string
630 representation of the DN comprised of one RDN consisting of the AVA:
631 the commonName (CN) value "Sam " from the surrounding text. It should
632 be noted to the user that the wrapping "<" and ">" characters are not
633 part of the DN string.
635 DN strings can be quite long. It is often desirable to line-wrap
636 overly long DN strings in presentations. Line wrapping should be done
637 by inserting white space after the RDN separator character or, if
638 necessary, after the AVA separator character. It should be noted to
639 the user that the inserted white space is not part of the DN string
640 and is to be removed before use in LDAP. For example,
642 The following DN string is long:
643 CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores,
644 O=OpenLDAP Foundation,ST=California,C=US
645 so it has been line-wrapped for readability. The extra white
646 space is to be removed before the DN string is used in LDAP.
648 It is not advised to insert white space otherwise as it may not be
649 obvious to the user which white space is part of the DN string and
650 which white space was added for readability.
652 Another alternative is to use the LDAP Data Interchange Format (LDIF)
653 [RFC2849]. For example,
655 # This entry has a long DN...
656 dn: CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores,
657 O=OpenLDAP Foundation,ST=California,C=US
663 Appendix B. Changes made since RFC 2253
665 This appendix is provided for informational purposes only, it is not a
666 normative part of this specification.
668 The following substantive changes were made to RFC 2253:
669 - Removed IESG Note. The IESG Note has been addressed.
670 - Clarified (in Section 1) that this document does not define a
674 Zeilenga LDAP: Distinguished Names [Page 12]
676 INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
679 canonical string representation.
680 - Revised specification (in Section 2) to allow short names of any
681 registered attribute type to appear in string representations of
682 DNs instead of being restricted to a "published table". Remove
683 "as an example" language. Added statement (in Section 3) allowing
684 recognition of additional names but require recognization of those
685 names in the published table. The table is now published in
687 - Replaced specification of additional requirements for LDAPv2
688 implementations which also support LDAPv3 (RFC 2253, Section 4)
689 with a statement (in Section 3) allowing recognition of
690 alternative string representations.
691 - Updated Section 2.3 to indicate attribute type name strings are
693 - Updated Section 2.4 to allow hex pair escaping of all characters
694 and clarified escaping for when multiple octet UTF-8 characters
696 - Rewrote Section 3 to use ABNF as defined in RFC 2234.
697 - Rewrote Section 3 ABNF to be consistent with 2.4.
698 - Updated Section 3 to describe how to parse elements of the
701 - Added reference to documentations containing general LDAP security
703 - Added discussion of presentation issues (Appendix A).
704 - Added this appendix.
706 In addition, numerous editorial changes were made.
709 Intellectual Property Rights
711 The IETF takes no position regarding the validity or scope of any
712 intellectual property or other rights that might be claimed to pertain
713 to the implementation or use of the technology described in this
714 document or the extent to which any license under such rights might or
715 might not be available; neither does it represent that it has made any
716 effort to identify any such rights. Information on the IETF's
717 procedures with respect to rights in standards-track and
718 standards-related documentation can be found in BCP-11. Copies of
719 claims of rights made available for publication and any assurances of
720 licenses to be made available, or the result of an attempt made to
721 obtain a general license or permission for the use of such proprietary
722 rights by implementors or users of this specification can be obtained
723 from the IETF Secretariat.
725 The IETF invites any interested party to bring to its attention any
726 copyrights, patents or patent applications, or other proprietary
730 Zeilenga LDAP: Distinguished Names [Page 13]
732 INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
735 rights which may cover technology that may be required to practice
736 this standard. Please address the information to the IETF Executive
743 Copyright (C) The Internet Society (2003). All Rights Reserved.
745 This document and translations of it may be copied and furnished to
746 others, and derivative works that comment on or otherwise explain it
747 or assist in its implmentation may be prepared, copied, published and
748 distributed, in whole or in part, without restriction of any kind,
749 provided that the above copyright notice and this paragraph are
750 included on all such copies and derivative works. However, this
751 document itself may not be modified in any way, such as by removing
752 the copyright notice or references to the Internet Society or other
753 Internet organizations, except as needed for the purpose of
754 developing Internet standards in which case the procedures for
755 copyrights defined in the Internet Standards process must be followed,
756 or as required to translate it into languages other than English.
786 Zeilenga LDAP: Distinguished Names [Page 14]