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: [email protected]