rfc4514.txt

samba最新软件

7.2.  Informative References

   [ASCII]       Coded Character Set--7-bit American Standard Code for
                 Information Interchange, ANSI X3.4-1986.

   [CharModel]   Whistler, K. and M. Davis, "Unicode Technical Report
                 #17, Character Encoding Model", UTR17,
                 <http://www.unicode.org/unicode/reports/tr17/>, August
                 2000.

   [Glossary]    The Unicode Consortium, "Unicode Glossary",
                 <http://www.unicode.org/glossary/>.

   [X.500]       International Telecommunication Union -
                 Telecommunication Standardization Sector, "The
                 Directory -- Overview of concepts, models and
                 services," X.500(1993) (also ISO/IEC 9594-1:1994).

   [X.511]       International Telecommunication Union -
                 Telecommunication Standardization Sector, "The
                 Directory: Abstract Service Definition", X.511(1993)
                 (also ISO/IEC 9594-3:1993).

   [X.690]       International Telecommunication Union -
                 Telecommunication Standardization Sector,
                 "Specification of ASN.1 encoding rules: Basic Encoding
                 Rules (BER), Canonical Encoding Rules (CER), and
                 Distinguished Encoding Rules (DER)", X.690(1997) (also
                 ISO/IEC 8825-1:1998).

   [RFC2849]     Good, G., "The LDAP Data Interchange Format (LDIF) -
                 Technical Specification", RFC 2849, June 2000.



















Zeilenga                    Standards Track                    [Page 11]

RFC 4514               LDAP: Distinguished Names               June 2006


Appendix A.  Presentation Issues

   This appendix is provided for informational purposes only; it is not
   a normative part of this specification.

   The string representation described in this document is not intended
   to be presented to humans without translation.  However, at times it
   may be desirable to present non-translated DN strings to users.  This
   section discusses presentation issues associated with non-translated
   DN strings.  Issues with presentation of translated DN strings are
   not discussed in this appendix.  Transcoding issues are also not
   discussed in this appendix.

   This appendix provides guidance for applications presenting DN
   strings to users.  This section is not comprehensive; it does not
   discuss all presentation issues that implementers may face.

   Not all user interfaces are capable of displaying the full set of
   Unicode characters.  Some Unicode characters are not displayable.

   It is recommended that human interfaces use the optional hex pair
   escaping mechanism (Section 2.3) to produce a string representation
   suitable for display to the user.  For example, an application can
   generate a DN string for display that escapes all non-printable
   characters appearing in the AttributeValue's string representation
   (as demonstrated in the final example of Section 4).

   When a DN string is displayed in free-form text, it is often
   necessary to distinguish the DN string from surrounding text.  While
   this is often done with whitespace (as demonstrated in Section 4), it
   is noted that DN strings may end with whitespace.  Careful readers of
   Section 3 will note that the characters '<' (U+003C) and '>' (U+003E)
   may only appear in the DN string if escaped.  These characters are
   intended to be used in free-form text to distinguish a DN string from
   surrounding text.  For example, <CN=Sam\ > distinguishes the string
   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:




Zeilenga                    Standards Track                    [Page 12]

RFC 4514               LDAP: Distinguished Names               June 2006


         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



Zeilenga                    Standards Track                    [Page 13]

RFC 4514               LDAP: Distinguished Names               June 2006


        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: [e-mail]





















Zeilenga                    Standards Track                    [Page 14]

RFC 4514               LDAP: Distinguished Names               June 2006


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
   [e-mail].

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).







Zeilenga                    Standards Track                    [Page 15]