Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)
RFC 4520

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 07

Network Working Group                                        K. Zeilenga
Request for Comments: 4520                           OpenLDAP Foundation
BCP: 64                                                        June 2006
Obsoletes: 3383
Category: Best Current Practice

     Internet Assigned Numbers Authority (IANA) Considerations for
            the Lightweight Directory Access Protocol (LDAP)

Status of This Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document provides procedures for registering extensible elements
   of the Lightweight Directory Access Protocol (LDAP).  The document
   also provides guidelines to the Internet Assigned Numbers Authority
   (IANA) describing conditions under which new values can be assigned.

1.  Introduction

   The Lightweight Directory Access Protocol [RFC4510] (LDAP) is an
   extensible protocol.  LDAP supports:

      -  the addition of new operations,
      -  the extension of existing operations, and
      -  the extensible schema.

   This document details procedures for registering values used to
   unambiguously identify extensible elements of the protocol, including
   the following:

      - LDAP message types
      - LDAP extended operations and controls
      - LDAP result codes
      - LDAP authentication methods
      - LDAP attribute description options
      - Object Identifier descriptors

Zeilenga                 Best Current Practice                  [Page 1]
RFC 4520              IANA Considerations for LDAP             June 2006

   These registries are maintained by the Internet Assigned Numbers
   Authority (IANA).

   In addition, this document provides guidelines to IANA describing the
   conditions under which new values can be assigned.

   This document replaces RFC 3383.

2.  Terminology and Conventions

   This section details terms and conventions used in this document.

2.1.  Policy Terminology

   The terms "IESG Approval", "Standards Action", "IETF Consensus",
   "Specification Required", "First Come First Served", "Expert Review",
   and "Private Use" are used as defined in BCP 26 [RFC2434].

   The term "registration owner" (or "owner") refers to the party
   authorized to change a value's registration.

2.2.  Requirement Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14 [RFC2119].  In
   this case, "the specification", as used by BCP 14, refers to the
   processing of protocols being submitted to the IETF standards
   process.

2.3.  Common ABNF Productions

   A number of syntaxes in this document are described using ABNF
   [RFC4234].  These syntaxes rely on the following common productions:

         ALPHA = %x41-5A / %x61-7A    ; "A"-"Z" / "a"-"z"
         LDIGIT = %x31-39             ; "1"-"9"
         DIGIT = %x30 / LDIGIT        ; "0"-"9"
         HYPHEN = %x2D                ; "-"
         DOT = %x2E                   ; "."
         number = DIGIT / ( LDIGIT 1*DIGIT )
         keychar = ALPHA / DIGIT / HYPHEN
         leadkeychar = ALPHA
         keystring = leadkeychar *keychar
         keyword = keystring

   Keywords are case insensitive.

Zeilenga                 Best Current Practice                  [Page 2]
RFC 4520              IANA Considerations for LDAP             June 2006

3.  IANA Considerations for LDAP

   This section details each kind of protocol value that can be
   registered and provides IANA guidelines on how to assign new values.

   IANA may reject obviously bogus registrations.

   LDAP values specified in RFCs MUST be registered.  Other LDAP values,
   except those in private-use name spaces, SHOULD be registered.  RFCs
   SHOULD NOT reference, use, or otherwise recognize unregistered LDAP
   values.

3.1.  Object Identifiers

   Numerous LDAP schema and protocol elements are identified by Object
   Identifiers (OIDs) [X.680].  Specifications that assign OIDs to
   elements SHOULD state who delegated the OIDs for their use.

   For IETF-developed elements, specifications SHOULD use OIDs under
   "Internet Directory Numbers" (1.3.6.1.1.x).  For elements developed
   by others, any properly delegated OID can be used, including those
   under "Internet Directory Numbers" (1.3.6.1.1.x) or "Internet Private
   Enterprise Numbers" (1.3.6.1.4.1.x).

   Internet Directory Numbers (1.3.6.1.1.x) will be assigned upon Expert
   Review with Specification Required.  Only one OID per specification
   will be assigned.  The specification MAY then assign any number of
   OIDs within this arc without further coordination with IANA.

   Internet Private Enterprise Numbers (1.3.6.1.4.1.x) are assigned by
   IANA <http://www.iana.org/cgi-bin/enterprise.pl>.  Practices for IANA