7
Network Working Group K. Zeilenga, Ed.
8
Request for Comments: 4514 OpenLDAP Foundation
9
Obsoletes: 2253 June 2006
10
Category: Standards Track
13
Lightweight Directory Access Protocol (LDAP):
14
String Representation of Distinguished Names
18
This document specifies an Internet standards track protocol for the
19
Internet community, and requests discussion and suggestions for
20
improvements. Please refer to the current edition of the "Internet
21
Official Protocol Standards" (STD 1) for the standardization state
22
and status of this protocol. Distribution of this memo is unlimited.
26
Copyright (C) The Internet Society (2006).
30
The X.500 Directory uses distinguished names (DNs) as primary keys to
31
entries in the directory. This document defines the string
32
representation used in the Lightweight Directory Access Protocol
33
(LDAP) to transfer distinguished names. The string representation is
34
designed to give a clean representation of commonly used
35
distinguished names, while being able to represent any distinguished
38
1. Background and Intended Usage
40
In X.500-based directory systems [X.500], including those accessed
41
using the Lightweight Directory Access Protocol (LDAP) [RFC4510],
42
distinguished names (DNs) are used to unambiguously refer to
43
directory entries [X.501][RFC4512].
45
The structure of a DN [X.501] is described in terms of ASN.1 [X.680].
46
In the X.500 Directory Access Protocol [X.511] (and other ITU-defined
47
directory protocols), DNs are encoded using the Basic Encoding Rules
48
(BER) [X.690]. In LDAP, DNs are represented in the string form
49
described in this document.
51
It is important to have a common format to be able to unambiguously
52
represent a distinguished name. The primary goal of this
53
specification is ease of encoding and decoding. A secondary goal is
54
to have names that are human readable. It is not expected that LDAP
58
Zeilenga Standards Track [Page 1]
60
RFC 4514 LDAP: Distinguished Names June 2006
63
implementations with a human user interface would display these
64
strings directly to the user, but that they would most likely be
65
performing translations (such as expressing attribute type names in
66
the local national language).
68
This document defines the string representation of Distinguished
69
Names used in LDAP [RFC4511][RFC4517]. Section 2 details the
70
RECOMMENDED algorithm for converting a DN from its ASN.1 structured
71
representation to a string. Section 3 details how to convert a DN
72
from a string to an ASN.1 structured representation.
74
While other documents may define other algorithms for converting a DN
75
from its ASN.1 structured representation to a string, all algorithms
76
MUST produce strings that adhere to the requirements of Section 3.
78
This document does not define a canonical string representation for
79
DNs. Comparison of DNs for equality is to be performed in accordance
80
with the distinguishedNameMatch matching rule [RFC4517].
82
This document is a integral part of the LDAP technical specification
83
[RFC4510], which obsoletes the previously defined LDAP technical
84
specification, RFC 3377, in its entirety. This document obsoletes
85
RFC 2253. Changes since RFC 2253 are summarized in Appendix B.
87
This specification assumes familiarity with X.500 [X.500] and the
88
concept of Distinguished Name [X.501][RFC4512].
92
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
93
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
94
document are to be interpreted as described in BCP 14 [RFC2119].
96
Character names in this document use the notation for code points and
97
names from the Unicode Standard [Unicode]. For example, the letter
98
"a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
100
Note: a glossary of terms used in Unicode can be found in [Glossary].
101
Information on the Unicode character encoding model can be found in
114
Zeilenga Standards Track [Page 2]
116
RFC 4514 LDAP: Distinguished Names June 2006
119
2. Converting DistinguishedName from ASN.1 to a String
121
X.501 [X.501] defines the ASN.1 [X.680] structure of distinguished
122
name. The following is a variant provided for discussion purposes.
124
DistinguishedName ::= RDNSequence
126
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
128
RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
129
AttributeTypeAndValue
131
AttributeTypeAndValue ::= SEQUENCE {
133
value AttributeValue }
135
This section defines the RECOMMENDED algorithm for converting a
136
distinguished name from an ASN.1-structured representation to a UTF-8
137
[RFC3629] encoded Unicode [Unicode] character string representation.
138
Other documents may describe other algorithms for converting a
139
distinguished name to a string, but only strings that conform to the
140
grammar defined in Section 3 SHALL be produced by LDAP
143
2.1. Converting the RDNSequence
145
If the RDNSequence is an empty sequence, the result is the empty or
148
Otherwise, the output consists of the string encodings of each
149
RelativeDistinguishedName in the RDNSequence (according to Section
150
2.2), starting with the last element of the sequence and moving
151
backwards toward the first.
153
The encodings of adjoining RelativeDistinguishedNames are separated
154
by a comma (',' U+002C) character.
156
2.2. Converting RelativeDistinguishedName
158
When converting from an ASN.1 RelativeDistinguishedName to a string,
159
the output consists of the string encodings of each
160
AttributeTypeAndValue (according to Section 2.3), in any order.
162
Where there is a multi-valued RDN, the outputs from adjoining
163
AttributeTypeAndValues are separated by a plus sign ('+' U+002B)
170
Zeilenga Standards Track [Page 3]
172
RFC 4514 LDAP: Distinguished Names June 2006
175
2.3. Converting AttributeTypeAndValue
177
The AttributeTypeAndValue is encoded as the string representation of
178
the AttributeType, followed by an equals sign ('=' U+003D) character,
179
followed by the string representation of the AttributeValue. The
180
encoding of the AttributeValue is given in Section 2.4.
182
If the AttributeType is defined to have a short name (descriptor)
183
[RFC4512] and that short name is known to be registered [REGISTRY]
184
[RFC4520] as identifying the AttributeType, that short name, a
185
<descr>, is used. Otherwise the AttributeType is encoded as the
186
dotted-decimal encoding, a <numericoid>, of its OBJECT IDENTIFIER.
187
The <descr> and <numericoid> are defined in [RFC4512].
189
Implementations are not expected to dynamically update their
190
knowledge of registered short names. However, implementations SHOULD
191
provide a mechanism to allow their knowledge of registered short
194
2.4. Converting an AttributeValue from ASN.1 to a String
196
If the AttributeType is of the dotted-decimal form, the
197
AttributeValue is represented by an number sign ('#' U+0023)
198
character followed by the hexadecimal encoding of each of the octets
199
of the BER encoding of the X.500 AttributeValue. This form is also
200
used when the syntax of the AttributeValue does not have an LDAP-
201
specific ([RFC4517], Section 3.1) string encoding defined for it, or
202
the LDAP-specific string encoding is not restricted to UTF-8-encoded
203
Unicode characters. This form may also be used in other cases, such
204
as when a reversible string representation is desired (see Section
207
Otherwise, if the AttributeValue is of a syntax that has a LDAP-
208
specific string encoding, the value is converted first to a UTF-8-
209
encoded Unicode string according to its syntax specification (see
210
[RFC4517], Section 3.3, for examples). If that UTF-8-encoded Unicode
211
string does not have any of the following characters that need
212
escaping, then that string can be used as the string representation
215
- a space (' ' U+0020) or number sign ('#' U+0023) occurring at
216
the beginning of the string;
218
- a space (' ' U+0020) character occurring at the end of the
226
Zeilenga Standards Track [Page 4]
228
RFC 4514 LDAP: Distinguished Names June 2006
231
- one of the characters '"', '+', ',', ';', '<', '>', or '\'
232
(U+0022, U+002B, U+002C, U+003B, U+003C, U+003E, or U+005C,
235
- the null (U+0000) character.
237
Other characters may be escaped.
239
Each octet of the character to be escaped is replaced by a backslash
240
and two hex digits, which form a single octet in the code of the
241
character. Alternatively, if and only if the character to be escaped
244
' ', '"', '#', '+', ',', ';', '<', '=', '>', or '\'
245
(U+0020, U+0022, U+0023, U+002B, U+002C, U+003B,
246
U+003C, U+003D, U+003E, U+005C, respectively)
248
it can be prefixed by a backslash ('\' U+005C).
250
Examples of the escaping mechanism are shown in Section 4.
252
3. Parsing a String Back to a Distinguished Name
254
The string representation of Distinguished Names is restricted to
255
UTF-8 [RFC3629] encoded Unicode [Unicode] characters. The structure
256
of this string representation is specified using the following
257
Augmented BNF [RFC4234] grammar:
259
distinguishedName = [ relativeDistinguishedName
260
*( COMMA relativeDistinguishedName ) ]
261
relativeDistinguishedName = attributeTypeAndValue
262
*( PLUS attributeTypeAndValue )
263
attributeTypeAndValue = attributeType EQUALS attributeValue
264
attributeType = descr / numericoid
265
attributeValue = string / hexstring
267
; The following characters are to be escaped when they appear
268
; in the value to be encoded: ESC, one of <escaped>, leading
269
; SHARP or SPACE, trailing SPACE, and NULL.
270
string = [ ( leadchar / pair ) [ *( stringchar / pair )
271
( trailchar / pair ) ] ]
273
leadchar = LUTF1 / UTFMB
274
LUTF1 = %x01-1F / %x21 / %x24-2A / %x2D-3A /
275
%x3D / %x3F-5B / %x5D-7F
277
trailchar = TUTF1 / UTFMB
278
TUTF1 = %x01-1F / %x21 / %x23-2A / %x2D-3A /
282
Zeilenga Standards Track [Page 5]
284
RFC 4514 LDAP: Distinguished Names June 2006
287
%x3D / %x3F-5B / %x5D-7F
289
stringchar = SUTF1 / UTFMB
290
SUTF1 = %x01-21 / %x23-2A / %x2D-3A /
291
%x3D / %x3F-5B / %x5D-7F
293
pair = ESC ( ESC / special / hexpair )
294
special = escaped / SPACE / SHARP / EQUALS
295
escaped = DQUOTE / PLUS / COMMA / SEMI / LANGLE / RANGLE
296
hexstring = SHARP 1*hexpair
299
where the productions <descr>, <numericoid>, <COMMA>, <DQUOTE>,
300
<EQUALS>, <ESC>, <HEX>, <LANGLE>, <NULL>, <PLUS>, <RANGLE>, <SEMI>,
301
<SPACE>, <SHARP>, and <UTFMB> are defined in [RFC4512].
303
Each <attributeType>, either a <descr> or a <numericoid>, refers to
304
an attribute type of an attribute value assertion (AVA). The
305
<attributeType> is followed by an <EQUALS> and an <attributeValue>.
306
The <attributeValue> is either in <string> or <hexstring> form.
308
If in <string> form, a LDAP string representation asserted value can
309
be obtained by replacing (left to right, non-recursively) each <pair>
310
appearing in the <string> as follows:
312
replace <ESC><ESC> with <ESC>;
313
replace <ESC><special> with <special>;
314
replace <ESC><hexpair> with the octet indicated by the <hexpair>.
316
If in <hexstring> form, a BER representation can be obtained from
317
converting each <hexpair> of the <hexstring> to the octet indicated
320
There is one or more attribute value assertions, separated by <PLUS>,
321
for a relative distinguished name.
323
There is zero or more relative distinguished names, separated by
324
<COMMA>, for a distinguished name.
326
Implementations MUST recognize AttributeType name strings
327
(descriptors) listed in the following table, but MAY recognize other
338
Zeilenga Standards Track [Page 6]
340
RFC 4514 LDAP: Distinguished Names June 2006
343
String X.500 AttributeType
344
------ --------------------------------------------
345
CN commonName (2.5.4.3)
346
L localityName (2.5.4.7)
347
ST stateOrProvinceName (2.5.4.8)
348
O organizationName (2.5.4.10)
349
OU organizationalUnitName (2.5.4.11)
350
C countryName (2.5.4.6)
351
STREET streetAddress (2.5.4.9)
352
DC domainComponent (0.9.2342.19200300.100.1.25)
353
UID userId (0.9.2342.19200300.100.1.1)
355
These attribute types are described in [RFC4519].
357
Implementations MAY recognize other DN string representations.
358
However, as there is no requirement that alternative DN string
359
representations be recognized (and, if so, how), implementations
360
SHOULD only generate DN strings in accordance with Section 2 of this
365
This notation is designed to be convenient for common forms of name.
366
This section gives a few examples of distinguished names written
367
using this notation. First is a name containing three relative
368
distinguished names (RDNs):
370
UID=jsmith,DC=example,DC=net
372
Here is an example of a name containing three RDNs, in which the
373
first RDN is multi-valued:
375
OU=Sales+CN=J. Smith,DC=example,DC=net
377
This example shows the method of escaping of a special characters
378
appearing in a common name:
380
CN=James \"Jim\" Smith\, III,DC=example,DC=net
382
The following shows the method for encoding a value that contains a
383
carriage return character:
385
CN=Before\0dAfter,DC=example,DC=net
387
In this RDN example, the type in the RDN is unrecognized, and the
388
value is the BER encoding of an OCTET STRING containing two octets,
394
Zeilenga Standards Track [Page 7]
396
RFC 4514 LDAP: Distinguished Names June 2006
399
1.3.6.1.4.1.1466.0=#04024869
401
Finally, this example shows an RDN whose commonName value consists of
404
Unicode Character Code UTF-8 Escaped
405
------------------------------- ------ ------ --------
406
LATIN CAPITAL LETTER L U+004C 0x4C L
407
LATIN SMALL LETTER U U+0075 0x75 u
408
LATIN SMALL LETTER C WITH CARON U+010D 0xC48D \C4\8D
409
LATIN SMALL LETTER I U+0069 0x69 i
410
LATIN SMALL LETTER C WITH ACUTE U+0107 0xC487 \C4\87
412
This could be encoded in printable ASCII [ASCII] (useful for
413
debugging purposes) as:
417
5. Security Considerations
419
The following security considerations are specific to the handling of
420
distinguished names. LDAP security considerations are discussed in
421
[RFC4511] and other documents comprising the LDAP Technical
422
Specification [RFC4510].
426
Distinguished Names typically consist of descriptive information
427
about the entries they name, which can be people, organizations,
428
devices, or other real-world objects. This frequently includes some
429
of the following kinds of information:
431
- the common name of the object (i.e., a person's full name)
432
- an email or TCP/IP address
433
- its physical location (country, locality, city, street address)
434
- organizational attributes (such as department name or
437
In some cases, such information can be considered sensitive. In many
438
countries, privacy laws exist that prohibit disclosure of certain
439
kinds of descriptive information (e.g., email addresses). Hence,
440
server implementers are encouraged to support Directory Information
441
Tree (DIT) structural rules and name forms [RFC4512], as these
442
provide a mechanism for administrators to select appropriate naming
443
attributes for entries. Administrators are encouraged to use
444
mechanisms, access controls, and other administrative controls that
445
may be available to restrict use of attributes containing sensitive
446
information in naming of entries. Additionally, use of
450
Zeilenga Standards Track [Page 8]
452
RFC 4514 LDAP: Distinguished Names June 2006
455
authentication and data security services in LDAP [RFC4513][RFC4511]
456
should be considered.
458
5.2. Use of Distinguished Names in Security Applications
460
The transformations of an AttributeValue value from its X.501 form to
461
an LDAP string representation are not always reversible back to the
462
same BER (Basic Encoding Rules) or DER (Distinguished Encoding Rules)
463
form. An example of a situation that requires the DER form of a
464
distinguished name is the verification of an X.509 certificate.
466
For example, a distinguished name consisting of one RDN with one AVA,
467
in which the type is commonName and the value is of the TeletexString
468
choice with the letters 'Sam', would be represented in LDAP as the
469
string <CN=Sam>. Another distinguished name in which the value is
470
still 'Sam', but is of the PrintableString choice, would have the
471
same representation <CN=Sam>.
473
Applications that require the reconstruction of the DER form of the
474
value SHOULD NOT use the string representation of attribute syntaxes
475
when converting a distinguished name to the LDAP format. Instead,
476
they SHOULD use the hexadecimal form prefixed by the number sign ('#'
477
U+0023) as described in the first paragraph of Section 2.4.
481
This document is an update to RFC 2253, by Mark Wahl, Tim Howes, and
482
Steve Kille. RFC 2253 was a product of the IETF ASID Working Group.
484
This document is a product of the IETF LDAPBIS Working Group.
488
7.1. Normative References
490
[REGISTRY] IANA, Object Identifier Descriptors Registry,
491
<http://www.iana.org/assignments/ldap-parameters>.
493
[Unicode] The Unicode Consortium, "The Unicode Standard, Version
494
3.2.0" is defined by "The Unicode Standard, Version
495
3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-
496
61633-5), as amended by the "Unicode Standard Annex
498
(http://www.unicode.org/reports/tr27/) and by the
499
"Unicode Standard Annex #28: Unicode 3.2"
500
(http://www.unicode.org/reports/tr28/).
506
Zeilenga Standards Track [Page 9]
508
RFC 4514 LDAP: Distinguished Names June 2006
511
[X.501] International Telecommunication Union -
512
Telecommunication Standardization Sector, "The
513
Directory -- Models," X.501(1993) (also ISO/IEC 9594-
516
[X.680] International Telecommunication Union -
517
Telecommunication Standardization Sector, "Abstract
518
Syntax Notation One (ASN.1) - Specification of Basic
519
Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
521
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
522
Requirement Levels", BCP 14, RFC 2119, March 1997.
524
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
525
10646", STD 63, RFC 3629, November 2003.
527
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
528
Specifications: ABNF", RFC 4234, October 2005.
530
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access
531
Protocol (LDAP): Technical Specification Road Map", RFC
534
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
535
Protocol (LDAP): The Protocol", RFC 4511, June 2006.
537
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
538
(LDAP): Directory Information Models", RFC 4512, June
541
[RFC4513] Harrison, R., Ed., "Lightweight Directory Access
542
Protocol (LDAP): Authentication Methods and Security
543
Mechanisms", RFC 4513, June 2006.
545
[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
546
(LDAP): Syntaxes and Matching Rules", RFC 4517, June
549
[RFC4519] Sciberras, A., Ed., "Lightweight Directory Access
550
Protocol (LDAP): Schema for User Applications", RFC
553
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
554
(IANA) Considerations for the Lightweight Directory
555
Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
562
Zeilenga Standards Track [Page 10]
564
RFC 4514 LDAP: Distinguished Names June 2006
567
7.2. Informative References
569
[ASCII] Coded Character Set--7-bit American Standard Code for
570
Information Interchange, ANSI X3.4-1986.
572
[CharModel] Whistler, K. and M. Davis, "Unicode Technical Report
573
#17, Character Encoding Model", UTR17,
574
<http://www.unicode.org/unicode/reports/tr17/>, August
577
[Glossary] The Unicode Consortium, "Unicode Glossary",
578
<http://www.unicode.org/glossary/>.
580
[X.500] International Telecommunication Union -
581
Telecommunication Standardization Sector, "The
582
Directory -- Overview of concepts, models and
583
services," X.500(1993) (also ISO/IEC 9594-1:1994).
585
[X.511] International Telecommunication Union -
586
Telecommunication Standardization Sector, "The
587
Directory: Abstract Service Definition", X.511(1993)
588
(also ISO/IEC 9594-3:1993).
590
[X.690] International Telecommunication Union -
591
Telecommunication Standardization Sector,
592
"Specification of ASN.1 encoding rules: Basic Encoding
593
Rules (BER), Canonical Encoding Rules (CER), and
594
Distinguished Encoding Rules (DER)", X.690(1997) (also
595
ISO/IEC 8825-1:1998).
597
[RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) -
598
Technical Specification", RFC 2849, June 2000.
618
Zeilenga Standards Track [Page 11]
620
RFC 4514 LDAP: Distinguished Names June 2006
623
Appendix A. Presentation Issues
625
This appendix is provided for informational purposes only; it is not
626
a normative part of this specification.
628
The string representation described in this document is not intended
629
to be presented to humans without translation. However, at times it
630
may be desirable to present non-translated DN strings to users. This
631
section discusses presentation issues associated with non-translated
632
DN strings. Issues with presentation of translated DN strings are
633
not discussed in this appendix. Transcoding issues are also not
634
discussed in this appendix.
636
This appendix provides guidance for applications presenting DN
637
strings to users. This section is not comprehensive; it does not
638
discuss all presentation issues that implementers may face.
640
Not all user interfaces are capable of displaying the full set of
641
Unicode characters. Some Unicode characters are not displayable.
643
It is recommended that human interfaces use the optional hex pair
644
escaping mechanism (Section 2.3) to produce a string representation
645
suitable for display to the user. For example, an application can
646
generate a DN string for display that escapes all non-printable
647
characters appearing in the AttributeValue's string representation
648
(as demonstrated in the final example of Section 4).
650
When a DN string is displayed in free-form text, it is often
651
necessary to distinguish the DN string from surrounding text. While
652
this is often done with whitespace (as demonstrated in Section 4), it
653
is noted that DN strings may end with whitespace. Careful readers of
654
Section 3 will note that the characters '<' (U+003C) and '>' (U+003E)
655
may only appear in the DN string if escaped. These characters are
656
intended to be used in free-form text to distinguish a DN string from
657
surrounding text. For example, <CN=Sam\ > distinguishes the string
658
representation of the DN composed of one RDN consisting of the AVA
659
(the commonName (CN) value 'Sam ') from the surrounding text. It
660
should be noted to the user that the wrapping '<' and '>' characters
661
are not part of the DN string.
663
DN strings can be quite long. It is often desirable to line-wrap
664
overly long DN strings in presentations. Line wrapping should be
665
done by inserting whitespace after the RDN separator character or, if
666
necessary, after the AVA separator character. It should be noted to
667
the user that the inserted whitespace is not part of the DN string
668
and is to be removed before use in LDAP. For example, the following
674
Zeilenga Standards Track [Page 12]
676
RFC 4514 LDAP: Distinguished Names June 2006
679
CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores,
680
O=OpenLDAP Foundation,ST=California,C=US
682
So it has been line-wrapped for readability. The extra whitespace is
683
to be removed before the DN string is used in LDAP.
685
Inserting whitespace is not advised because it may not be obvious to
686
the user which whitespace is part of the DN string and which
687
whitespace was added for readability.
689
Another alternative is to use the LDAP Data Interchange Format (LDIF)
690
[RFC2849]. For example:
692
# This entry has a long DN...
693
dn: CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores,
694
O=OpenLDAP Foundation,ST=California,C=US
699
Appendix B. Changes Made since RFC 2253
701
This appendix is provided for informational purposes only, it is not
702
a normative part of this specification.
704
The following substantive changes were made to RFC 2253:
706
- Removed IESG Note. The IESG Note has been addressed.
707
- Replaced all references to ISO 10646-1 with [Unicode].
708
- Clarified (in Section 1) that this document does not define a
709
canonical string representation.
710
- Clarified that Section 2 describes the RECOMMENDED encoding
711
algorithm and that alternative algorithms are allowed. Some
712
encoding options described in RFC 2253 are now treated as
713
alternative algorithms in this specification.
714
- Revised specification (in Section 2) to allow short names of any
715
registered attribute type to appear in string representations of
716
DNs instead of being restricted to a "published table". Removed
717
"as an example" language. Added statement (in Section 3)
718
allowing recognition of additional names but require recognition
719
of those names in the published table. The table now appears in
721
- Removed specification of additional requirements for LDAPv2
722
implementations which also support LDAPv3 (RFC 2253, Section 4)
723
as LDAPv2 is now Historic.
724
- Allowed recognition of alternative string representations.
725
- Updated Section 2.4 to allow hex pair escaping of all characters
726
and clarified escaping for when multiple octet UTF-8 encodings
730
Zeilenga Standards Track [Page 13]
732
RFC 4514 LDAP: Distinguished Names June 2006
735
are present. Indicated that null (U+0000) character is to be
736
escaped. Indicated that equals sign ('=' U+003D) character may
738
- Rewrote Section 3 to use ABNF as defined in RFC 4234.
739
- Updated the Section 3 ABNF. Changes include:
740
+ allowed AttributeType short names of length 1 (e.g., 'L'),
741
+ used more restrictive <oid> production in AttributeTypes,
742
+ did not require escaping of equals sign ('=' U+003D)
744
+ did not require escaping of non-leading number sign ('#'
746
+ allowed space (' ' U+0020) to be escaped as '\ ',
747
+ required hex escaping of null (U+0000) characters, and
748
+ removed LDAPv2-only constructs.
749
- Updated Section 3 to describe how to parse elements of the
752
- Added reference to documentations containing general LDAP
753
security considerations.
754
- Added discussion of presentation issues (Appendix A).
755
- Added this appendix.
757
In addition, numerous editorial changes were made.
764
EMail: Kurt@OpenLDAP.org
786
Zeilenga Standards Track [Page 14]
788
RFC 4514 LDAP: Distinguished Names June 2006
791
Full Copyright Statement
793
Copyright (C) The Internet Society (2006).
795
This document is subject to the rights, licenses and restrictions
796
contained in BCP 78, and except as set forth therein, the authors
797
retain all their rights.
799
This document and the information contained herein are provided on an
800
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
801
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
802
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
803
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
804
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
805
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
807
Intellectual Property
809
The IETF takes no position regarding the validity or scope of any
810
Intellectual Property Rights or other rights that might be claimed to
811
pertain to the implementation or use of the technology described in
812
this document or the extent to which any license under such rights
813
might or might not be available; nor does it represent that it has
814
made any independent effort to identify any such rights. Information
815
on the procedures with respect to rights in RFC documents can be
816
found in BCP 78 and BCP 79.
818
Copies of IPR disclosures made to the IETF Secretariat and any
819
assurances of licenses to be made available, or the result of an
820
attempt made to obtain a general license or permission for the use of
821
such proprietary rights by implementers or users of this
822
specification can be obtained from the IETF on-line IPR repository at
823
http://www.ietf.org/ipr.
825
The IETF invites any interested party to bring to its attention any
826
copyrights, patents or patent applications, or other proprietary
827
rights that may cover technology that may be required to implement
828
this standard. Please address the information to the IETF at
833
Funding for the RFC Editor function is provided by the IETF
834
Administrative Support Activity (IASA).
842
Zeilenga Standards Track [Page 15]
added
removed
source4/ldap_server/devdocs/rfc4514.txt
