Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names
RFC 2253

Document Type RFC - Proposed Standard (December 1997; Errata)
Obsoleted by RFC 4514, RFC 4510
Updated by RFC 3377
Obsoletes RFC 1779
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2253 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                            M. Wahl
Request for Comments: 2253                           Critical Angle Inc.
Obsoletes: 1779                                                 S. Kille
Category: Standards Track                                     Isode Ltd.
                                                                T. Howes
                                           Netscape Communications Corp.
                                                           December 1997

              Lightweight Directory Access Protocol (v3):
           UTF-8 String Representation of Distinguished Names

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1997).  All Rights Reserved.


   This document describes a directory access protocol that provides
   both read and update access.  Update access requires secure
   authentication, but this document does not mandate implementation of
   any satisfactory authentication mechanisms.

   In accordance with RFC 2026, section 4.4.1, this specification is
   being approved by IESG as a Proposed Standard despite this
   limitation, for the following reasons:

   a. to encourage implementation and interoperability testing of
      these protocols (with or without update access) before they
      are deployed, and

   b. to encourage deployment and use of these protocols in read-only
      applications.  (e.g. applications where LDAPv3 is used as
      a query language for directories which are updated by some
      secure mechanism other than LDAP), and

   c. to avoid delaying the advancement and deployment of other Internet
      standards-track protocols which require the ability to query, but
      not update, LDAPv3 directory servers.

Wahl, et. al.              Proposed Standard                    [Page 1]
RFC 2253               LADPv3 Distinguished Names          December 1997

   Readers are hereby warned that until mandatory authentication
   mechanisms are standardized, clients and servers written according to
   this specification which make use of update functionality are

   Implementors are hereby discouraged from deploying LDAPv3 clients or
   servers which implement the update functionality, until a Proposed
   Standard for mandatory authentication in LDAPv3 has been approved and
   published as an RFC.


   The X.500 Directory uses distinguished names as the primary keys to
   entries in the directory.  Distinguished Names are encoded in ASN.1
   in the X.500 Directory protocols.  In the Lightweight Directory
   Access Protocol, a string representation of distinguished names is
   transferred.  This specification defines the string format for
   representing names, which is designed to give a clean representation
   of commonly used distinguished names, while being able to represent
   any distinguished name.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [6].

1.  Background

   This specification assumes familiarity with X.500 [1], and the
   concept of Distinguished Name.  It is important to have a common
   format to be able to unambiguously represent a distinguished name.
   The primary goal of this specification is ease of encoding and
   decoding.  A secondary goal is to have names that are human readable.
   It is not expected that LDAP clients with a human user interface
   would display these strings directly to the user, but would most
   likely be performing translations (such as expressing attribute type
   names in one of the local national languages).

2.  Converting DistinguishedName from ASN.1 to a String

   In X.501 [2] the ASN.1 structure of distinguished name is defined as:

       DistinguishedName ::= RDNSequence

       RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

Wahl, et. al.              Proposed Standard                    [Page 2]
RFC 2253               LADPv3 Distinguished Names          December 1997

       RelativeDistinguishedName ::= SET SIZE (1..MAX) OF

       AttributeTypeAndValue ::= SEQUENCE {
        type  AttributeType,
        value AttributeValue }

   The following sections define the algorithm for converting from an
   ASN.1 structured representation to a UTF-8 string representation.

2.1. Converting the RDNSequence

   If the RDNSequence is an empty sequence, the result is the empty or
Show full document text