RFC 3494 (rfc3494) - Page 2 of 5

Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status

RFC 3494               LDAPv2 to Historic Status              March 2003


   implementations use syntaxes and semantics different than those
   prescribed by the specification.  Below are two examples.

      1) Existing LDAPv2 implementations do not commonly restrict
         textual values to IA5 (ASCII) and T.61 (Teletex) as required by
         RFC 1777 and RFC 1778.  Some existing implementations use ISO
         8859-1, others use UCS-2, others use UTF-8, and some use the
         current local character set.

      2) RFC 1777 requires use of the textual string associated with
         AttributeType in the X.500 Directory standards.  However,
         existing implementations use the NAME associated with the
         AttributeType in the LDAPv3 schema [RFC 2252].  That is, LDAPv2
         requires the organization name attribute be named
         "organizationName", not "o".

   In addition, LDAPv2 does not provide adequate security features for
   use on the Internet.  LDAPv2 does not provide any mechanism for data
   integrity or confidentiality.  LDAPv2 does not support modern
   authentication mechanisms such as those based on DIGEST-MD5, Kerberos
   V, and X.509 public keys.

Dependent Specifications

   Since the publication of RFC 1777, 1778, and 1779, there have been
   additional standard track RFCs published that are dependent on these
   technical specifications, including:

      "Using the OSI Directory to Achieve User Friendly Naming"
      [RFC 1781]

         and

      "Internet X.509 Public Key Infrastructure Operational Protocols -
      LDAPv2" [RFC 2559].

   RFC 1781 is a technical specification for "User Friendly Naming"
   which replies on particular syntaxes described in RFC 1779.  RFC
   2253, which replaced RFC 1779, eliminated support for the "User
   Friendly Naming" syntaxes.  RFC 1781 is currently a Proposed
   Standard.

   RFC 2559 is primarily an applicability statement for using LDAPv2 in
   providing Public Key Infrastructure.  It depends on RFC 1777 and
   updates RFC 1778.  If LDAPv2 is moved to Historic status, so must
   this document.  RFC 2559 is currently a Proposed Standard.





Zeilenga                     Informational