Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)
RFC 4520
Document | Type |
RFC - Best Current Practice
(June 2006; No errata)
Obsoletes RFC 3383
Also known as BCP 64
|
|
---|---|---|---|
Author | Kurt Zeilenga | ||
Last updated | 2015-10-14 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4520 (Best Current Practice) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Ted Hardie | ||
Send notices to | (None) |
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 IANAShow full document text