<?xml version='1.0'?>

<reference anchor='RFC2253'>

<front>
<title abbrev='LADPv3 Distinguished Names'>Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names</title>
<author initials='M.' surname='Wahl' fullname='Mark Wahl'>
<organization>Critical Angle Inc.</organization>
<address>
<postal>
<street>4815 W. Braker Lane #502-385</street>
<street>Austin</street>
<street>TX 78759</street>
<country>USA</country></postal>
<email>M.Wahl@critical-angle.com</email></address></author>
<author initials='S.' surname='Kille' fullname='Steve Kille'>
<organization>Isode Ltd.</organization>
<address>
<postal>
<street>The Dome</street>
<street>The Square</street>
<street>Richmond</street>
<street>Surrey</street>
<street>TW9 1DT</street>
<street>England</street></postal>
<phone>+44-181-332-9091</phone>
<email>S.Kille@ISODE.COM</email></address></author>
<author initials='T.' surname='Howes' fullname='Tim Howes'>
<organization>Netscape Communications Corp.</organization>
<address>
<postal>
<street>501 E. Middlefield Rd</street>
<street>MS MV068</street>
<street>Mountain View</street>
<street>CA 94043</street>
<country>USA</country></postal>
<phone>+1 650 937-3419</phone>
<email>howes@netscape.com</email></address></author>
<date month='December' year='1997' />
<area>Applications</area>
<keyword>LDAP</keyword>
<keyword>ITU abstract syntax notation one</keyword>
<keyword>ITU directory service protocol</keyword>
<keyword>UCS transformation format</keyword>
<keyword>directory</keyword>
<keyword>lightweight directory access protocol</keyword>
<abstract>
<t>
   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.
</t>
<t>
   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:

<list>
<t>
   a. to encourage implementation and interoperability testing of
      these protocols (with or without update access) before they
      are deployed, and
</t>
<t>
   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
</t>
<t>
   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.
</t></list></t>
<t>
   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
   UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
   IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
</t>
<t>
   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.
</t>
<t>
   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.
</t>
<t>
   The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;,
   &quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;,  &quot;MAY&quot;, and &quot;OPTIONAL&quot; in this
   document are to be interpreted as described in RFC 2119 .
</t></abstract>
<note title='IESG Note'>
<t>
   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.
</t>
<t>
   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:
</t>
<t>
   a. to encourage implementation and interoperability testing of
      these protocols (with or without update access) before they
      are deployed, and

<list>
<t>
   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
</t>
<t>
   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.
</t></list></t>
<t>
   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
   UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
   IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
</t>
<t>
   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.
</t></note></front>

<seriesInfo name='RFC' value='2253' />
<format type='HTML' octets='35492' target='http://xml.resource.org/public/rfc/html/rfc2253.html' />
<format type='XML' octets='21696' target='http://xml.resource.org/public/rfc/xml/rfc2253.xml' />
</reference>
