Network Working Group K. Zeilenga
Request for Comments: 4520 OpenLDAP Foundation
BCP: 64 June 2006
Obsoletes: 3383
Category: Best Current Practice
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)
轻量级目录访问协议（LDAP）的Internet分配号码管理局（IANA）注意事项
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).
版权所有（C）互联网协会（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.
本文档提供了注册轻量级目录访问协议（LDAP）的可扩展元素的过程。该文件还向互联网分配号码管理局（IANA）提供了指南，说明了可以分配新值的条件。
The Lightweight Directory Access Protocol [RFC4510] (LDAP) is an extensible protocol. LDAP supports:
轻量级目录访问协议[RFC4510]（LDAP）是一种可扩展协议。LDAP支持：
- 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
- LDAP消息类型-LDAP扩展操作和控制-LDAP结果代码-LDAP身份验证方法-LDAP属性描述选项-对象标识符描述符
These registries are maintained by the Internet Assigned Numbers Authority (IANA).
这些登记册由互联网分配号码管理局（IANA）维护。
In addition, this document provides guidelines to IANA describing the conditions under which new values can be assigned.
此外，本文件为IANA提供了指南，说明了可分配新值的条件。
This document replaces RFC 3383.
本文件取代RFC 3383。
This section details terms and conventions used in this document.
本节详细介绍了本文件中使用的术语和约定。
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].
术语“IESG批准”、“标准行动”、“IETF共识”、“所需规范”、“先到先得”、“专家评审”和“私人使用”的使用如BCP 26[RFC2434]所定义。
The term "registration owner" (or "owner") refers to the party authorized to change a value's registration.
术语“登记所有人”（或“所有人”）指有权更改价值登记的一方。
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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14[RFC2119]中所述进行解释。在这种情况下，BCP 14使用的“规范”指的是提交给IETF标准过程的协议处理。
A number of syntaxes in this document are described using ABNF [RFC4234]. These syntaxes rely on the following common productions:
本文档中的许多语法使用ABNF[RFC4234]进行描述。这些语法依赖于以下常见结果：
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
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.
关键字不区分大小写。
This section details each kind of protocol value that can be registered and provides IANA guidelines on how to assign new values.
本节详细介绍了可以注册的每种协议值，并提供了IANA关于如何分配新值的指南。
IANA may reject obviously bogus registrations.
IANA可能会拒绝明显虚假的注册。
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.
必须注册RFCs中指定的LDAP值。应该注册其他LDAP值（专用名称空间中的值除外）。RFC不应引用、使用或以其他方式识别未注册的LDAP值。
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.
许多LDAP模式和协议元素由对象标识符（OID）标识[X.680]。将OID分配给元素的规范应说明是谁委托OID使用。
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).
对于IETF开发的元件，规范应使用“互联网目录号”（1.3.6.1.1.x）下的OID。对于其他人开发的元素，可以使用任何适当授权的OID，包括“互联网目录号”（1.3.6.1.1.x）或“互联网私有企业号”（1.3.6.1.4.1.x）下的OID。
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.
互联网目录号（1.3.6.1.1.x）将在专家审查后按照要求的规范进行分配。每个规范仅分配一个OID。然后，规范可在此arc内分配任意数量的OID，而无需与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 assignment of Internet Private Enterprise Numbers are detailed in RFC 2578 [RFC2578].
互联网私人企业编号（1.3.6.1.4.1.x）由IANA分配<http://www.iana.org/cgi-bin/enterprise.pl>. 互联网私有企业编号的IANA分配实践详见RFC 2578[RFC2578]。
To avoid interoperability problems between early implementations of a "work 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. Practices for IANA assignment of these Internet Experimental numbers are detailed in RFC 2578 [RFC2578].
为了避免“正在进行的工作”的早期实现和已发布规范（如RFC）的实现之间的互操作性问题，应在“正在进行的工作”和早期实现中使用实验OID。互联网实验OID arc（1.3.6.1.3.x）下的OID可用于此目的。RFC 2578[RFC2578]中详细介绍了这些互联网实验编号的IANA分配实践。
LDAP provides a number of Root DSA-Specific Entry (DSE) attributes for discovery of protocol mechanisms identified by OIDs, including the supportedControl, supportedExtension, and supportedFeatures attributes [RFC4512].
LDAP提供了许多根DSA特定条目（DSE）属性，用于发现由OID标识的协议机制，包括supportedControl、supportedExtension和supportedFeatures属性[RFC4512]。
A registry of OIDs used for discovery 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.
提供了用于发现协议机制的OID注册表，以允许实现者和其他人找到这些协议机制的技术规范。持有用于识别协议机制的值的附加根DSE属性的未来规范可能会扩展此注册表以获取其值。
Protocol mechanisms are registered on a First Come First Served basis.
协议机制以先到先得的方式注册。
This registry provides a listing of LDAP syntaxes [RFC4512]. Each LDAP syntax is identified by an OID. This registry is provided to allow implementors and others to locate the technical specification describing a particular LDAP Syntax.
此注册表提供LDAP语法列表[RFC4512]。每个LDAP语法都由一个OID标识。提供此注册表是为了允许实现者和其他人找到描述特定LDAP语法的技术规范。
LDAP Syntaxes are registered on a First Come First Served with Specification Required basis.
LDAP语法以先到先得的方式注册，并提供所需的规范。
Note: Unlike object classes, attribute types, and various other kinds of schema elements, descriptors are not used in LDAP to identify LDAP Syntaxes.
注意：与对象类、属性类型和各种其他类型的模式元素不同，LDAP中不使用描述符来标识LDAP语法。
LDAP allows short descriptive names (or descriptors) to be used instead of a numeric Object Identifier to identify select protocol extensions [RFC4511], schema elements [RFC4512], LDAP URL [RFC4516] extensions, and other objects.
LDAP允许使用简短的描述性名称（或描述符）而不是数字对象标识符来标识选定协议扩展[RFC4511]、模式元素[RFC4512]、LDAP URL[RFC4516]扩展和其他对象。
Although the protocol allows the same descriptor to refer to different object identifiers in certain cases and the registry supports multiple registrations of the same descriptor (each indicating a different kind of schema element and different object identifier), multiple registrations of the same descriptor are to be avoided. All such multiple registration requests require Expert Review.
尽管协议允许同一描述符在某些情况下引用不同的对象标识符，并且注册表支持同一描述符的多个注册（每个注册表示不同类型的模式元素和不同的对象标识符），但应避免同一描述符的多个注册。所有此类多重注册请求都需要专家审查。
Descriptors are restricted to strings of UTF-8 [RFC3629] encoded Unicode characters restricted by the following ABNF:
描述符仅限于UTF-8[RFC3629]编码的Unicode字符字符串，受以下ABNF限制：
name = keystring
name = keystring
Descriptors are case insensitive.
描述符不区分大小写。
Multiple names may be assigned to a given OID. For purposes of registration, an OID is to be represented in numeric OID form (e.g., 1.1.0.23.40) conforming to the following ABNF:
可以为给定OID分配多个名称。出于注册目的，OID应以符合以下ABNF的数字OID形式（如1.1.0.23.40）表示：
numericoid = number 1*( DOT number )
numericoid=编号1*（点编号）
While the protocol places no maximum length restriction upon descriptors, they should be short. Descriptors longer than 48 characters may be viewed as too long to register.
虽然协议没有对描述符设置最大长度限制，但是描述符应该很短。超过48个字符的描述符可能被视为太长而无法注册。
A value ending with a hyphen ("-") reserves all descriptors that start with that value. For example, the registration of the option "descrFamily-" reserves all options that start with "descrFamily-" for some related purpose.
以连字符（“-”）结尾的值保留以该值开头的所有描述符。例如，注册选项“descrFamily-”将保留所有以“descrFamily-”开头的选项，以用于某些相关目的。
Descriptors beginning with "x-" are for Private Use and cannot be registered.
以“x-”开头的描述符仅供私人使用，不能注册。
Descriptors beginning with "e-" are reserved for experiments and will be registered on a First Come First Served basis.
以“e-”开头的描述符保留用于实验，并将按照先到先得的原则进行注册。
All other descriptors require Expert Review to be registered.
所有其他描述符都需要注册专家评审。
The registrant need not "own" the OID being named.
注册人不需要“拥有”被命名的OID。
The OID name space is managed by the ISO/IEC Joint Technical Committee 1 - Subcommittee 6.
OID名称空间由ISO/IEC联合技术委员会1-小组委员会6管理。
An AttributeDescription [RFC4512] can contain zero or more options specifying additional semantics. An option SHALL be restricted to a string of UTF-8 encoded Unicode characters limited by the following ABNF:
AttributeDescription[RFC4512]可以包含零个或多个指定附加语义的选项。选项应限制为UTF-8编码的Unicode字符字符串，并受以下ABNF限制：
option = keystring
option = keystring
Options are case insensitive.
选项不区分大小写。
While the protocol places no maximum length restriction upon option strings, they should be short. Options longer than 24 characters may be viewed as too long to register.
虽然协议对选项字符串没有最大长度限制，但它们应该很短。超过24个字符的选项可能被视为太长而无法注册。
Values ending with a hyphen ("-") reserve all option names that start with the name. For example, the registration of the option "optionFamily-" reserves all options that start with "optionFamily-" for some related purpose.
以连字符（“-”）结尾的值保留以该名称开头的所有选项名称。例如，选项“optionFamily-”的注册保留了所有以“optionFamily-”开头的选项，用于某些相关目的。
Options beginning with "x-" are for Private Use and cannot be registered.
以“x-”开头的选项仅供私人使用，不能注册。
Options beginning with "e-" are reserved for experiments and will be registered on a First Come First Served basis.
以“e-”开头的选项保留用于实验，并将以先到先得的方式注册。
All other options require Standards Action or Expert Review with Specification Required to be registered.
所有其他选项需要标准行动或专家审查，规范需要注册。
Each protocol message is encapsulated in an LDAPMessage envelope [RFC4511. The protocolOp CHOICE indicates the type of message encapsulated. Each message type consists of an ASN.1 identifier in the form of a keyword and a non-negative choice number. The choice number is combined with the class (APPLICATION) and data type (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the message's encoding. The choice numbers for existing protocol messages are implicit in the protocol's ASN.1 defined in [RFC4511].
每个协议消息封装在LDAPMessage信封[RFC4511]中。protocolOp选项表示封装的消息类型。每个消息类型包括一个ASN.1标识符（以关键字的形式）和一个非负选择号。选择号与类（应用程序）和数据类型（构造的或基本的）相结合在消息编码中构造BER标记。现有协议消息的选择号隐含在[RFC4511]中定义的协议ASN.1中。
New values will be registered upon Standards Action.
新值将在标准行动时登记。
Note: LDAP provides extensible messages that reduce but do not eliminate the need to add new message types.
注意：LDAP提供可扩展消息，可减少但不消除添加新消息类型的需要。
The LDAP Bind operation supports multiple authentication methods [RFC4511]. Each authentication choice consists of an ASN.1 identifier in the form of a keyword and a non-negative integer.
LDAP绑定操作支持多种身份验证方法[RFC4511]。每个身份验证选项都包含一个ASN.1标识符，其形式为关键字和一个非负整数。
The registrant SHALL classify the authentication method usage using one of the following terms:
注册人应使用以下术语之一对认证方法的使用进行分类：
COMMON - method is appropriate for common use on the Internet. LIMITED USE - method is appropriate for limited use. OBSOLETE - method has been deprecated or otherwise found to be inappropriate for any use.
通用-此方法适合在Internet上通用。有限使用-该方法适用于有限使用。过时-方法已被弃用或发现不适合任何用途。
Methods without publicly available specifications SHALL NOT be classified as COMMON. New registrations of the class OBSOLETE cannot be registered.
没有公开可用规范的方法不得归类为普通方法。无法注册过时类的新注册。
New authentication method integers in the range 0-1023 require Standards Action to be registered. New authentication method integers in the range 1024-4095 require Expert Review with Specification Required. New authentication method integers in the range 4096-16383 will be registered on a First Come First Served basis. Keywords associated with integers in the range 0-4095 SHALL NOT start with "e-" or "x-". Keywords associated with integers in
范围为0-1023的新身份验证方法整数需要注册标准操作。1024-4095范围内的新身份验证方法整数需要专家审查，并需要规范。范围4096-16383的新身份验证方法整数将以先到先得的方式注册。与0-4095范围内整数相关的关键字不得以“e-”或“x-”开头。中与整数关联的关键字
the range 4096-16383 SHALL start with "e-". Values greater than or equal to 16384 and keywords starting with "x-" are for Private Use and cannot be registered.
4096-16383范围应以“e-”开头。大于或等于16384的值和以“x-”开头的关键字仅供私人使用，无法注册。
Note: LDAP supports Simple Authentication and Security Layers [RFC4422] as an authentication choice. SASL is an extensible authentication framework.
注意：LDAP支持简单身份验证和安全层[RFC4422]作为身份验证选项。SASL是一个可扩展的身份验证框架。
LDAP result messages carry a resultCode enumerated value to indicate the outcome of the operation [RFC4511]. Each result code consists of an ASN.1 identifier in the form of a keyword and a non-negative integer.
LDAP结果消息带有resultCode枚举值，以指示操作的结果[RFC4511]。每个结果代码都由一个ASN.1标识符（以关键字和非负整数的形式）组成。
New resultCodes integers in the range 0-1023 require Standards Action to be registered. New resultCode integers in the range 1024-4095 require Expert Review with Specification Required. New resultCode integers in the range 4096-16383 will be registered on a First Come First Served basis. Keywords associated with integers in the range 0-4095 SHALL NOT start with "e-" or "x-". Keywords associated with integers in the range 4096-16383 SHALL start with "e-". Values greater than or equal to 16384 and keywords starting with "x-" are for Private Use and cannot be registered.
范围为0-1023的新resultCodes整数需要注册标准操作。1024-4095范围内的新resultCode整数需要专家审查，并需要规范。范围为4096-16383的新resultCode整数将以先到先得的方式注册。与0-4095范围内整数相关的关键字不得以“e-”或“x-”开头。与4096-16383范围内的整数关联的关键字应以“e-”开头。大于或等于16384的值和以“x-”开头的关键字仅供私人使用，无法注册。
LDAP SearchRequest messages carry a scope-enumerated value to indicate the extent of search within the DIT [RFC4511]. Each search value consists of an ASN.1 identifier in the form of a keyword and a non-negative integer.
LDAP SearchRequest消息带有一个作用域枚举值，用于指示DIT内的搜索范围[RFC4511]。每个搜索值都由一个ASN.1标识符（以关键字和非负整数的形式）组成。
New scope integers in the range 0-1023 require Standards Action to be registered. New scope integers in the range 1024-4095 require Expert Review with Specification Required. New scope integers in the range 4096-16383 will be registered on a First Come First Served basis. Keywords associated with integers in the range 0-4095 SHALL NOT start with "e-" or "x-". Keywords associated with integers in the range 4096-16383 SHALL start with "e-". Values greater than or equal to 16384 and keywords starting with "x-" are for Private Use and cannot be registered.
范围为0-1023的新范围整数需要注册标准操作。1024-4095范围内的新范围整数需要专家审查，并需要规范。范围4096-16383的新作用域整数将按照先到先得的原则进行注册。与0-4095范围内整数相关的关键字不得以“e-”或“x-”开头。与4096-16383范围内的整数关联的关键字应以“e-”开头。大于或等于16384的值和以“x-”开头的关键字仅供私人使用，无法注册。
LDAP filters are used in making assertions against an object represented in the directory [RFC4511]. The Filter CHOICE indicates a type of assertion. Each Filter CHOICE consists of an ASN.1 identifier in the form of a keyword and a non-negative choice number.
LDAP筛选器用于对目录[RFC4511]中表示的对象进行断言。过滤器选项指示一种断言类型。每个过滤器选项由一个ASN.1标识符（以关键字的形式）和一个非负数选项号组成。
The choice number is combined with the class (APPLICATION) and data type (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the message's encoding.
选择号与类（应用程序）和数据类型（构造的或原语）组合，以构造消息编码中的BER标记。
Note: LDAP provides the extensibleMatching choice, which reduces but does not eliminate the need to add new filter choices.
注意：LDAP提供了ExtensionMatching选项，这减少了但并没有消除添加新筛选器选项的需要。
The LDAP ModifyRequest carries a sequence of modification operations [RFC4511]. Each kind (e.g., add, delete, replace) of operation consists of an ASN.1 identifier in the form of a keyword and a non-negative integer.
LDAP ModifyRequest包含一系列修改操作[RFC4511]。每种操作（例如，添加、删除、替换）都包含一个ASN.1标识符，其形式为关键字和一个非负整数。
New operation type integers in the range 0-1023 require Standards Action to be registered. New operation type integers in the range 1024-4095 require Expert Review with Specification Required. New operation type integers in the range 4096-16383 will be registered on a First Come First Served basis. Keywords associated with integers in the range 0-4095 SHALL NOT start with "e-" or "x-". Keywords associated with integers in the range 4096-16383 SHALL start with "e-". Values greater than or equal to 16384 and keywords starting with "x-" are for Private Use and cannot be registered.
0-1023范围内的新操作类型整数需要注册标准操作。1024-4095范围内的新运算类型整数需要专家审查，并需要规范。4096-16383范围内的新运算类型整数将以先到先得的方式注册。与0-4095范围内整数相关的关键字不得以“e-”或“x-”开头。与4096-16383范围内的整数关联的关键字应以“e-”开头。大于或等于16384的值和以“x-”开头的关键字仅供私人使用，无法注册。
Authorization Identities in LDAP are strings conforming to the <authzId> production [RFC4513]. This production is extensible. Each new specific authorization form is identified by a prefix string conforming to the following ABNF:
LDAP中的授权标识是符合<authzId>产品[RFC4513]的字符串。这个产品是可扩展的。每个新的特定授权表格由符合以下ABNF的前缀字符串标识：
prefix = keystring COLON
COLON = %x3A ; COLON (":" U+003A)
prefix = keystring COLON
COLON = %x3A ; COLON (":" U+003A)
Prefixes are case insensitive.
前缀不区分大小写。
While the protocol places no maximum length restriction upon prefix strings, they should be short. Prefixes longer than 12 characters may be viewed as too long to register.
虽然协议对前缀字符串没有最大长度限制，但它们应该很短。超过12个字符的前缀可能被视为太长而无法注册。
Prefixes beginning with "x-" are for Private Use and cannot be registered.
以“x-”开头的前缀仅供私人使用，不能注册。
Prefixes beginning with "e-" are reserved for experiments and will be registered on a First Come First Served basis.
以“e-”开头的前缀保留用于实验，并将按照先到先得的原则进行注册。
All other prefixes require Standards Action or Expert Review with Specification Required to be registered.
所有其他前缀需要标准行动或专家审查，规范需要注册。
The IANA-maintained "Directory Systems Names" registry [IANADSN] of valid keywords for well-known attributes was used in the LDAPv2 string representation of a distinguished name [RFC1779]. LDAPv2 is now Historic [RFC3494].
IANA维护的已知属性有效关键字的“目录系统名称”注册表[IANADSN]用于可分辨名称[RFC1779]的LDAPv2字符串表示。LDAPv2现已成为历史记录[RFC3494]。
Directory systems names are not known to be used in any other context. LDAPv3 [RFC4514] uses Object Identifier Descriptors [Section 3.2] (which have a different syntax than directory system names).
在任何其他上下文中都无法使用目录系统名称。LDAPv3[RFC4514]使用对象标识符描述符[第3.2节]（其语法与目录系统名称不同）。
New Directory System Names will no longer be accepted. For historical purposes, the current list of registered names should remain publicly available.
将不再接受新的目录系统名称。出于历史目的，当前的注册名称列表应保持公开。
The procedure given here MUST be used by anyone who wishes to use a new value of a type described in Section 3 of this document.
希望使用本文件第3节所述类型的新值的任何人必须使用此处给出的程序。
The first step is for the requester to fill out the appropriate form. Templates are provided in Appendix A.
第一步是请求者填写适当的表格。附录A中提供了模板。
If the policy is Standards Action, the completed form SHOULD be provided to the IESG with the request for Standards Action. Upon approval of the Standards Action, the IESG SHALL forward the request (possibly revised) to IANA. The IESG SHALL be regarded as the registration owner of all values requiring Standards Action.
如果政策是标准行动，则应向IESG提供填写完整的表格以及标准行动请求。在批准标准行动后，IESG应将请求（可能修改）转发给IANA。IESG应被视为所有需要标准行动的价值观的登记所有者。
If the policy is Expert Review, the requester SHALL post the completed form to the <directory@apps.ietf.org> mailing list for public review. The review period is two (2) weeks. If a revised form is later submitted, the review period is restarted. Anyone may subscribe to this list by sending a request to <directory-request@apps.ietf.org>. During the review, objections may be raised by anyone (including the Expert) on the list. After completion of the review, the Expert, based on public comments, SHALL either approve the request and forward it to the IANA OR deny the request. In either case, the Expert SHALL promptly notify the requester of the action. Actions of the Expert may be appealed [RFC2026]. The Expert is appointed by Applications Area Directors. The requester is viewed as the registration owner of values registered under Expert Review.
如果政策是专家评审，申请人应将填写好的表格张贴到<directory@apps.ietf.org>供公众查阅的邮件列表。审查期为两（2）周。如果以后提交了修订后的表格，则重新开始审查期。任何人都可以通过向<目录发送请求来订阅此列表-request@apps.ietf.org>. 审查期间，名单上的任何人（包括专家）都可能提出反对意见。审查完成后，专家应根据公众意见批准该请求并将其转发给IANA，或拒绝该请求。在任何一种情况下，专家都应立即将行动通知请求者。可对专家的行为提出上诉[RFC2026]。专家由应用领域主管任命。申请人被视为在专家审查下登记的价值的登记所有人。
If the policy is First Come First Served, the requester SHALL submit the completed form directly to the IANA: <iana@iana.org>. The requester is viewed as the registration owner of values registered under First Come First Served.
如果政策先到先得，申请人应直接向IANA提交填妥的表格：<iana@iana.org>. 请求者被视为根据先到先得原则注册的值的注册所有者。
Neither the Expert nor IANA will take position on the claims of copyright or trademark issues regarding completed forms.
专家和IANA都不会就已完成表格的版权或商标问题采取立场。
Prior to submission of the Internet Draft (I-D) to the RFC Editor but after IESG review and tentative approval, the document editor SHOULD revise the I-D to use registered values.
在向RFC编辑提交互联网草案（I-D）之前，但在IESG审查和初步批准之后，文件编辑应修改I-D以使用注册值。
This section discusses maintenance of registrations.
本节讨论注册的维护。
IANA makes lists of registered values readily available to the Internet community on its web site: <http://www.iana.org/>.
IANA在其网站上为互联网社区提供注册价值清单：<http://www.iana.org/>.
The registration owner MAY update the registration subject to the same constraints and review as with new registrations. In cases where the registration owner is unable or is unwilling to make necessary updates, the IESG MAY assume ownership of the registration in order to update the registration.
登记所有人可根据与新登记相同的约束条件和审查条件更新登记。如果登记所有人无法或不愿意进行必要的更新，IESG可承担登记所有权，以更新登记。
For cases where others (anyone other than the registration owner) have significant objections to the claims in a registration and the registration owner does not agree to change the registration, comments MAY be attached to a registration upon Expert Review. For registrations owned by the IESG, the objections SHOULD be addressed by initiating a request for Expert Review.
如果其他人（除登记所有人以外的任何人）对登记中的权利主张有重大异议，并且登记所有人不同意更改登记，则可在专家审查后将意见附在登记上。对于IESG拥有的注册，应通过提出专家审查请求来解决异议。
The form of these requests is ad hoc, but MUST include the specific objections to be reviewed and SHOULD contain (directly or by reference) materials supporting the objections.
这些请求的形式是临时的，但必须包括要审查的具体反对意见，并应包含（直接或通过引用）支持反对意见的材料。
The security considerations detailed in BCP 26 [RFC2434] are generally applicable to this document. Additional security considerations specific to each name space are discussed in Section 3, where appropriate.
BCP 26[RFC2434]中详述的安全注意事项通常适用于本文件。第3节讨论了特定于每个名称空间的其他安全注意事项（如适用）。
Security considerations for LDAP are discussed in documents comprising the technical specification [RFC4510].
包含技术规范[RFC4510]的文件中讨论了LDAP的安全注意事项。
This document is a product of the IETF LDAP Revision (LDAPBIS) Working Group (WG). This document is a revision of RFC 3383, also a product of the LDAPBIS WG.
本文件是IETF LDAP修订版（LDAPBIS）工作组（WG）的产品。本文件是RFC 3383的修订版，也是LDAPBIS工作组的产品。
This document includes text borrowed from "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC2434] by Thomas Narten and Harald Alvestrand.
本文件包括从Thomas Narten和Harald Alvestrand的“在RFCs中编写IANA注意事项部分的指南”[RFC2434]中借用的文本。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578]McCloghrie，K.，Perkins，D.，和J.Schoenwaeld，“管理信息的结构版本2（SMIv2）”，STD 58，RFC 2578，1999年4月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 4234，2005年10月。
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
[RFC4510]Zeilenga，K.，Ed.“轻量级目录访问协议（LDAP）：技术规范路线图”，RFC45102006年6月。
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511]Sermersheim，J.，Ed.，“轻量级目录访问协议（LDAP）：协议”，RFC4511，2006年6月。
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006.
[RFC4512]Zeilenga，K.，“轻量级目录访问协议（LDAP）：目录信息模型”，RFC4512，2006年6月。
[RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006.
[RFC4513]Harrison，R.，Ed.“轻量级目录访问协议（LDAP）：身份验证方法和安全机制”，RFC4513，2006年6月。
[RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator", RFC 4516, June 2006.
[RFC4516]Smith，M.，Ed.和T.Howes，“轻量级目录访问协议（LDAP）：统一资源定位器”，RFC4516，2006年6月。
[Unicode] The Unicode Consortium, "The Unicode Standard, Version 3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the "Unicode Standard Annex #27: Unicode 3.1" (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/).
[Unicode]Unicode联盟“Unicode标准，版本3.2.0”由“Unicode标准，版本3.0”（雷丁，马萨诸塞州，Addison-Wesley，2000.ISBN 0-201-61633-5）定义，并由“Unicode标准附录27:Unicode 3.1”修订(http://www.unicode.org/reports/tr27/)根据“Unicode标准附录28:Unicode 3.2”(http://www.unicode.org/reports/tr28/).
[X.680] International Telecommunication Union - Telecommunication Standardization Sector, "Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
[X.680]国际电信联盟-电信标准化部门，“抽象语法符号1（ASN.1）-基本符号规范”，X.680（2002）（也称ISO/IEC 8824-1:2002）。
[RFC1779] Kille, S., "A String Representation of Distinguished Names", RFC 1779, March 1995.
[RFC1779]Kille，S.，“可分辨名称的字符串表示”，RFC17791995年3月。
[RFC3494] Zeilenga, K.,"Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status", RFC 3494, March 2003.
[RFC3494]Zeilenga，K.，“轻型目录访问协议版本2（LDAPv2）到历史状态”，RFC 34942003年3月。
[RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006.
[RFC4514]Zeilenga，K.，Ed.“轻量级目录访问协议（LDAP）：可分辨名称的字符串表示”，RFC4514，2006年6月。
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422]Melnikov，A.，Ed.和K.Zeilenga，Ed.，“简单身份验证和安全层（SASL）”，RFC 4422，2006年6月。
[IANADSN] IANA, "Directory Systems Names", http://www.iana.org/assignments/directory-system-names.
[IANADSN]IANA，“目录系统名称”，http://www.iana.org/assignments/directory-system-names.
This appendix provides registration templates for registering new LDAP values. Note that more than one value may be requested by extending the template by listing multiple values, or through use of tables.
本附录提供了注册新LDAP值的注册模板。请注意，通过列出多个值来扩展模板，或者通过使用表来请求多个值。
Subject: Request for LDAP OID Registration
主题：请求LDAP OID注册
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Specification: (I-D)
规格：（I-D）
Author/Change Controller:
作者/变更控制员：
Comments:
评论：
(Any comments that the requester deems relevant to the request.)
（请求人认为与请求相关的任何评论。）
Subject: Request for LDAP Protocol Mechanism Registration
主题：请求LDAP协议机制注册
Object Identifier:
对象标识符：
Description:
说明：
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Usage: (One of Control or Extension or Feature or other)
用法：（控件、扩展、特性或其他）
Specification: (RFC, I-D, URI)
规范：（RFC、I-D、URI）
Author/Change Controller:
作者/变更控制员：
Comments:
评论：
(Any comments that the requester deems relevant to the request.)
（请求人认为与请求相关的任何评论。）
Subject: Request for LDAP Syntax Registration
主题：请求LDAP语法注册
Object Identifier:
对象标识符：
Description:
说明：
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Specification: (RFC, I-D, URI)
规范：（RFC、I-D、URI）
Author/Change Controller:
作者/变更控制员：
Comments:
评论：
(Any comments that the requester deems relevant to the request.)
（请求人认为与请求相关的任何评论。）
Subject: Request for LDAP Descriptor Registration
主题：请求LDAP描述符注册
Descriptor (short name):
描述符（简称）：
Object Identifier:
对象标识符：
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Usage: (One of administrative role, attribute type, matching rule, name form, object class, URL extension, or other)
用法：（管理角色、属性类型、匹配规则、名称表单、对象类、URL扩展或其他）
Specification: (RFC, I-D, URI)
规范：（RFC、I-D、URI）
Author/Change Controller:
作者/变更控制员：
Comments:
评论：
(Any comments that the requester deems relevant to the request.)
（请求人认为与请求相关的任何评论。）
Subject: Request for LDAP Attribute Description Option Registration Option Name:
主题：请求LDAP属性描述选项注册选项名称：
Family of Options: (YES or NO)
选项系列：（是或否）
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Specification: (RFC, I-D, URI)
规范：（RFC、I-D、URI）
Author/Change Controller:
作者/变更控制员：
Comments:
评论：
(Any comments that the requester deems relevant to the request.)
（请求人认为与请求相关的任何评论。）
Subject: Request for LDAP Message Type Registration
主题：请求LDAP消息类型注册
LDAP Message Name:
LDAP消息名称：
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Specification: (Approved I-D)
规格：（经批准的I-D）
Comments:
评论：
(Any comments that the requester deems relevant to the request.)
（请求人认为与请求相关的任何评论。）
Subject: Request for LDAP Authentication Method Registration
主题：请求LDAP身份验证方法注册
Authentication Method Name:
身份验证方法名称：
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Specification: (RFC, I-D, URI)
规范：（RFC、I-D、URI）
Intended Usage: (One of COMMON, LIMITED-USE, OBSOLETE)
预期用途：（常用、限用、过时）
Author/Change Controller:
作者/变更控制员：
Comments:
评论：
(Any comments that the requester deems relevant to the request.)
（请求人认为与请求相关的任何评论。）
Subject: Request for LDAP Result Code Registration
主题：请求LDAP结果代码注册
Result Code Name:
结果代码名称：
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Specification: (RFC, I-D, URI)
规范：（RFC、I-D、URI）
Author/Change Controller:
作者/变更控制员：
Comments:
评论：
(Any comments that the requester deems relevant to the request.)
（请求人认为与请求相关的任何评论。）
Subject: Request for LDAP Search Scope Registration
主题：请求LDAP搜索范围注册
Search Scope Name:
搜索范围名称：
Filter Scope String:
筛选范围字符串：
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Specification: (RFC, I-D, URI)
规范：（RFC、I-D、URI）
Author/Change Controller:
作者/变更控制员：
Comments:
评论：
(Any comments that the requester deems relevant to the request.)
（请求人认为与请求相关的任何评论。）
Subject: Request for LDAP Filter Choice Registration
主题：请求LDAP筛选器选择注册
Filter Choice Name:
筛选器选项名称：
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Specification: (RFC, I-D, URI)
规范：（RFC、I-D、URI）
Author/Change Controller:
作者/变更控制员：
Comments:
评论：
(Any comments that the requester deems relevant to the request.)
（请求人认为与请求相关的任何评论。）
Subject: Request for LDAP ModifyRequest Operation Registration
主题：请求LDAP修改请求操作注册
ModifyRequest Operation Name:
ModifyRequest操作名称：
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Specification: (RFC, I-D, URI)
规范：（RFC、I-D、URI）
Author/Change Controller:
作者/变更控制员：
Comments:
评论：
(Any comments that the requester deems relevant to the request.)
（请求人认为与请求相关的任何评论。）
This informative appendix provides a summary of changes made since RFC 3383.
本资料性附录总结了自RFC 3383以来所做的更改。
- Object Identifier Descriptors practices were updated to require all descriptors defined in RFCs to be registered and recommending all other descriptors (excepting those in private-use name space) be registered. Additionally, all requests for multiple registrations of the same descriptor are now subject to Expert Review.
- 更新了对象标识符描述符实践，要求注册RFCs中定义的所有描述符，并建议注册所有其他描述符（专用名称空间中的描述符除外）。此外，对同一描述符的多个注册的所有请求现在都要接受专家审查。
- Protocol Mechanisms practices were updated to include values of the 'supportedFeatures' attribute type.
- 已更新协议机制实践，以包括“supportedFeatures”属性类型的值。
- LDAP Syntax, Search Scope, Filter Choice, ModifyRequest operation, and authzId prefixes registries were added.
- 添加了LDAP语法、搜索范围、筛选器选择、ModifyRequest操作和authzId前缀注册表。
- References to RFCs comprising the LDAP technical specifications have been updated to latest revisions.
- 包含LDAP技术规范的RFC参考已更新至最新版本。
- References to ISO 10646 have been replaced with [Unicode].
- 对ISO10646的引用已替换为[Unicode]。
- The "Assigned Values" appendix providing initial registry values was removed.
- 删除了提供初始注册表值的“赋值”附录。
- Numerous editorial changes were made.
- 进行了许多编辑上的修改。
Author's Address
作者地址
Kurt D. Zeilenga OpenLDAP Foundation
库尔特D.Zeeliga OpenLDAP基金会
EMail: Kurt@OpenLDAP.org
EMail: Kurt@OpenLDAP.org
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。