representation of the DN composed of one RDN consisting of the AVA
(the commonName (CN) value ’Sam ’) from the surrounding text. It
should be noted to the user that the wrapping ’<’ and ’>’ characters
are not part of the DN string.
DN strings can be quite long. It is often desirable to line-wrap
overly long DN strings in presentations. Line wrapping should be
done by inserting whitespace after the RDN separator character or, if
necessary, after the AVA separator character. It should be noted to
the user that the inserted whitespace is not part of the DN string
and is to be removed before use in LDAP. For example, the following
DN string is long:
CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores,
O=OpenLDAP Foundation,ST=California,C=US
So it has been line-wrapped for readability. The extra whitespace is
to be removed before the DN string is used in LDAP.
Inserting whitespace is not advised because it may not be obvious to
the user which whitespace is part of the DN string and which
whitespace was added for readability.
Another alternative is to use the LDAP Data Interchange Format (LDIF)
[RFC2849]. For example:
# This entry has a long DN...
dn: CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores,
O=OpenLDAP Foundation,ST=California,C=US
CN: Kurt D. Zeilenga
SN: Zeilenga
objectClass: person
Appendix B. Changes Made since RFC 2253
This appendix is provided for informational purposes only, it is not
a normative part of this specification.
The following substantive changes were made to RFC 2253:
- Removed IESG Note. The IESG Note has been addressed.
- Replaced all references to ISO 10646-1 with [Unicode].
- Clarified (in Section 1) that this document does not define a
canonical string representation.
- Clarified that Section 2 describes the RECOMMENDED encoding
algorithm and that alternative algorithms are allowed. Some
encoding options described in RFC 2253 are now treated as
alternative algorithms in this specification.
- Revised specification (in Section 2) to allow short names of any
registered attribute type to appear in string representations of
DNs instead of being restricted to a "published table". Removed
"as an example" language. Added statement (in Section 3)
allowing recognition of additional names but require recognition
of those names in the published table. The table now appears in
Section 3.
- Removed specification of additional requirements for LDAPv2
implementations which also support LDAPv3 (RFC 2253, Section 4)
as LDAPv2 is now Historic.
- Allowed recognition of alternative string representations.
- Updated Section 2.4 to allow hex pair escaping of all characters
and clarified escaping for when multiple octet UTF-8 encodings
are present. Indicated that null (U+0000) character is to be
escaped. Indicated that equals sign (’=’ U+003D) character may
be escaped as ’\=’.
- Rewrote Section 3 to use ABNF as defined in RFC 4234.
- Updated the Section 3 ABNF. Changes include:
+ allowed AttributeType short names of length 1 (e.g., ’L’),
+ used more restrictive <oid> production in AttributeTypes,
+ did not require escaping of equals sign (’=’ U+003D)
characters,
+ did not require escaping of non-leading number sign (’#’
U+0023) characters,
+ allowed space (’ ’ U+0020) to be escaped as ’\ ’,
+ required hex escaping of null (U+0000) characters, and
+ removed LDAPv2-only constructs.
- Updated Section 3 to describe how to parse elements of the
grammar.
- Rewrote examples.
- Added reference to documentations containing general LDAP
security considerations.
- Added discussion of presentation issues (Appendix A).
- Added this appendix.
In addition, numerous editorial changes were made.
Editor’s Address
Kurt D. Zeilenga
OpenLDAP Foundation
EMail: Kurt@OpenLDAP.org
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).