RFC3383 - Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory A…
减小字体
增大字体Network Working Group K. Zeilenga
Request for Comments: 3383 OpenLDAP Foundation
BCP: 64 September 2002
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 (2002). All Rights Reserved.
Abstract
This document provides procedures for registering extensible elements
of the Lightweight Directory Access Protocol (LDAP). This 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 (LDAP) [RFC3377] is an
extensible protocol. LDAP supports:
- addition of new operations,
- extension of existing operations, and
- extensible schema.
This document details procedures for registering values of used to
unambiguously identify extensible elements of the protocol including:
- LDAP message types;
- LDAP extended operations and controls;
- LDAP result codes;
- LDAP authentication methods;
- LDAP attribute description options; and
- Object Identifier descriptors.
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.
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].
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
[RFC2234]. 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
A keyword is a case-insensitive string of UTF-8 [RFC2279] encoded
characters from the Universal Character Set (UCS) [ISO10646]
restricted to the <keystring> production.
3. IANA Considerations for LDAP
This section details each kind of protocol value which can be
registered and provides IANA guidelines on how to assign new values.
IANA may reject obviously bogus registration requests.
3.1. Object Identifiers
Numerous LDAP schema and protocol elements are identified by Object
Identifiers. Specifications which assign OIDs to elements SHOULD
state who delegated the OIDs for its use.
For IETF developed elements, specifications SHOULD use OIDs under
"Internet Directory Numbers" (1.3.6.1.1.x). Numbers under this OID
arc 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.
For elements developed by others, any properly delegated OID can
be used, including those under "Internet Private Enterprise
Numbers" (1.3.6.1.4.1.x) assigned by IANA
<http://www.iana.org/cgi-bin/enterprise.pl>.
To avoid interoperability problems between early implementations of
"works in progress" and implementations of the published
specification (e.g., the RFC), experimental OIDs SHOULD be used in
"works in progress" and early implementations. OIDs under the
Internet Experimental OID arc (1.3.6.1.3.x) may be used for this
purpose.
Experimental OIDs are not to used in published specifications (e.g.,
RFCs).
Practices for IANA assignment of Internet Enterprise and Experimental
OIDs are detailed in STD 16 [RFC1155].
3.2 Protocol Mechanisms
LDAP provides a number of Root DSE attributes for discovery of
protocol mechanisms identified by OIDs, including:
- supportedControl [RFC2252] and
- supportedExtension [RFC2252].
A registry of OIDs used for discover of protocol mechanisms is
provided to allow implementors and others to locate the technical
specification for these protocol mechanisms. Future specifications
of additional Root DSE attributes holding values identifying protocol
mechanisms MAY extend this registry for their values.
OIDs associated with discoverable protocol mechanisms SHOULD be
registered. These are be considered on a First Come First Served
with Specification Required basis.
OIDs associate
Request for Comments: 3383 OpenLDAP Foundation
BCP: 64 September 2002
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 (2002). All Rights Reserved.
Abstract
This document provides procedures for registering extensible elements
of the Lightweight Directory Access Protocol (LDAP). This 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 (LDAP) [RFC3377] is an
extensible protocol. LDAP supports:
- addition of new operations,
- extension of existing operations, and
- extensible schema.
This document details procedures for registering values of used to
unambiguously identify extensible elements of the protocol including:
- LDAP message types;
- LDAP extended operations and controls;
- LDAP result codes;
- LDAP authentication methods;
- LDAP attribute description options; and
- Object Identifier descriptors.
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.
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].
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
[RFC2234]. 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
A keyword is a case-insensitive string of UTF-8 [RFC2279] encoded
characters from the Universal Character Set (UCS) [ISO10646]
restricted to the <keystring> production.
3. IANA Considerations for LDAP
This section details each kind of protocol value which can be
registered and provides IANA guidelines on how to assign new values.
IANA may reject obviously bogus registration requests.
3.1. Object Identifiers
Numerous LDAP schema and protocol elements are identified by Object
Identifiers. Specifications which assign OIDs to elements SHOULD
state who delegated the OIDs for its use.
For IETF developed elements, specifications SHOULD use OIDs under
"Internet Directory Numbers" (1.3.6.1.1.x). Numbers under this OID
arc 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.
For elements developed by others, any properly delegated OID can
be used, including those under "Internet Private Enterprise
Numbers" (1.3.6.1.4.1.x) assigned by IANA
<http://www.iana.org/cgi-bin/enterprise.pl>.
To avoid interoperability problems between early implementations of
"works in progress" and implementations of the published
specification (e.g., the RFC), experimental OIDs SHOULD be used in
"works in progress" and early implementations. OIDs under the
Internet Experimental OID arc (1.3.6.1.3.x) may be used for this
purpose.
Experimental OIDs are not to used in published specifications (e.g.,
RFCs).
Practices for IANA assignment of Internet Enterprise and Experimental
OIDs are detailed in STD 16 [RFC1155].
3.2 Protocol Mechanisms
LDAP provides a number of Root DSE attributes for discovery of
protocol mechanisms identified by OIDs, including:
- supportedControl [RFC2252] and
- supportedExtension [RFC2252].
A registry of OIDs used for discover of protocol mechanisms is
provided to allow implementors and others to locate the technical
specification for these protocol mechanisms. Future specifications
of additional Root DSE attributes holding values identifying protocol
mechanisms MAY extend this registry for their values.
OIDs associated with discoverable protocol mechanisms SHOULD be
registered. These are be considered on a First Come First Served
with Specification Required basis.
OIDs associate
