Network Working Group M. Smith, Ed.
Request for Comments: 4516 Pearl Crescent, LLC
Obsoletes: 2255 T. Howes
Category: Standards Track Opsware, Inc.
June 2006
Network Working Group M. Smith, Ed.
Request for Comments: 4516 Pearl Crescent, LLC
Obsoletes: 2255 T. Howes
Category: Standards Track Opsware, Inc.
June 2006
Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator
轻量级目录访问协议（LDAP）：统一资源定位器
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document describes a format for a Lightweight Directory Access Protocol (LDAP) Uniform Resource Locator (URL). An LDAP URL describes an LDAP search operation that is used to retrieve information from an LDAP directory, or, in the context of an LDAP referral or reference, an LDAP URL describes a service where an LDAP operation may be progressed.
本文档描述了轻量级目录访问协议（LDAP）统一资源定位器（URL）的格式。LDAP URL描述用于从LDAP目录检索信息的LDAP搜索操作，或者，在LDAP引用或引用的上下文中，LDAP URL描述可以进行LDAP操作的服务。
Table of Contents
目录
1. Introduction ....................................................2
2. URL Definition ..................................................2
2.1. Percent-Encoding ...........................................4
3. Defaults for Fields of the LDAP URL .............................5
4. Examples ........................................................6
5. Security Considerations .........................................8
6. Normative References ............................................9
7. Informative References .........................................10
8. Acknowledgements ...............................................10
Appendix A: Changes Since RFC 2255 ................................11
A.1. Technical Changes .........................................11
A.2. Editorial Changes .........................................11
1. Introduction ....................................................2
2. URL Definition ..................................................2
2.1. Percent-Encoding ...........................................4
3. Defaults for Fields of the LDAP URL .............................5
4. Examples ........................................................6
5. Security Considerations .........................................8
6. Normative References ............................................9
7. Informative References .........................................10
8. Acknowledgements ...............................................10
Appendix A: Changes Since RFC 2255 ................................11
A.1. Technical Changes .........................................11
A.2. Editorial Changes .........................................11
LDAP is the Lightweight Directory Access Protocol [RFC4510]. This document specifies the LDAP URL format for version 3 of LDAP and clarifies how LDAP URLs are resolved. This document also defines an extension mechanism for LDAP URLs. This mechanism may be used to provide access to new LDAP extensions.
LDAP是轻量级目录访问协议[RFC4510]。本文档指定LDAP版本3的LDAP URL格式，并说明如何解析LDAP URL。本文档还定义了LDAP URL的扩展机制。此机制可用于提供对新LDAP扩展的访问。
Note that not all the parameters of the LDAP search operation described in [RFC4511] can be expressed using the format defined in this document. Note also that URLs may be used to represent reference knowledge, including that for non-search operations.
请注意，并非[RFC4511]中描述的LDAP搜索操作的所有参数都可以使用本文档中定义的格式表示。还请注意，URL可用于表示参考知识，包括用于非搜索操作的参考知识。
This document is an integral part of the LDAP technical specification [RFC4510], which obsoletes the previously defined LDAP technical specification, RFC 3377, in its entirety.
本文档是LDAP技术规范[RFC4510]不可分割的一部分，该规范完全废除了先前定义的LDAP技术规范RFC 3377。
This document replaces RFC 2255. See Appendix A for a list of changes relative to RFC 2255.
本文件取代RFC 2255。有关RFC 2255的变更列表，请参见附录A。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14[RFC2119]中所述进行解释。
An LDAP URL begins with the protocol prefix "ldap" and is defined by the following grammar, following the ABNF notation defined in [RFC4234].
LDAP URL以协议前缀“LDAP”开头，并按照[RFC4234]中定义的ABNF符号，由以下语法定义。
ldapurl = scheme COLON SLASH SLASH [host [COLON port]]
[SLASH dn [QUESTION [attributes]
[QUESTION [scope] [QUESTION [filter]
[QUESTION extensions]]]]]
; <host> and <port> are defined
; in Sections 3.2.2 and 3.2.3
; of [RFC3986].
; <filter> is from Section 3 of
; [RFC4515], subject to the
; provisions of the
; "Percent-Encoding" section
; below.
ldapurl = scheme COLON SLASH SLASH [host [COLON port]]
[SLASH dn [QUESTION [attributes]
[QUESTION [scope] [QUESTION [filter]
[QUESTION extensions]]]]]
; <host> and <port> are defined
; in Sections 3.2.2 and 3.2.3
; of [RFC3986].
; <filter> is from Section 3 of
; [RFC4515], subject to the
; provisions of the
; "Percent-Encoding" section
; below.
scheme = "ldap"
scheme = "ldap"
dn = distinguishedName ; From Section 3 of [RFC4514],
; subject to the provisions of
; the "Percent-Encoding"
; section below.
dn = distinguishedName ; From Section 3 of [RFC4514],
; subject to the provisions of
; the "Percent-Encoding"
; section below.
attributes = attrdesc *(COMMA attrdesc)
attrdesc = selector *(COMMA selector)
selector = attributeSelector ; From Section 4.5.1 of
; [RFC4511], subject to the
; provisions of the
; "Percent-Encoding" section
; below.
attributes = attrdesc *(COMMA attrdesc)
attrdesc = selector *(COMMA selector)
selector = attributeSelector ; From Section 4.5.1 of
; [RFC4511], subject to the
; provisions of the
; "Percent-Encoding" section
; below.
scope = "base" / "one" / "sub"
extensions = extension *(COMMA extension)
extension = [EXCLAMATION] extype [EQUALS exvalue]
extype = oid ; From section 1.4 of [RFC4512].
scope = "base" / "one" / "sub"
extensions = extension *(COMMA extension)
extension = [EXCLAMATION] extype [EQUALS exvalue]
extype = oid ; From section 1.4 of [RFC4512].
exvalue = LDAPString ; From section 4.1.2 of
; [RFC4511], subject to the
; provisions of the
; "Percent-Encoding" section
; below.
exvalue = LDAPString ; From section 4.1.2 of
; [RFC4511], subject to the
; provisions of the
; "Percent-Encoding" section
; below.
EXCLAMATION = %x21 ; exclamation mark ("!")
SLASH = %x2F ; forward slash ("/")
COLON = %x3A ; colon (":")
QUESTION = %x3F ; question mark ("?")
EXCLAMATION = %x21 ; exclamation mark ("!")
SLASH = %x2F ; forward slash ("/")
COLON = %x3A ; colon (":")
QUESTION = %x3F ; question mark ("?")
The "ldap" prefix indicates an entry or entries accessible from the LDAP server running on the given hostname at the given portnumber. Note that the <host> may contain literal IPv6 addresses as specified in Section 3.2.2 of [RFC3986].
“ldap”前缀表示一个或多个条目，可从运行在给定主机名和给定端口号上的ldap服务器访问。请注意，<host>可能包含[RFC3986]第3.2.2节中规定的文字IPv6地址。
The <dn> is an LDAP Distinguished Name using the string format described in [RFC4514]. It identifies the base object of the LDAP search or the target of a non-search operation.
<dn>是一个LDAP可分辨名称，使用[RFC4514]中描述的字符串格式。它标识LDAP搜索的基本对象或非搜索操作的目标。
The <attributes> construct is used to indicate which attributes should be returned from the entry or entries.
<attributes>构造用于指示应该从一个或多个条目返回哪些属性。
The <scope> construct is used to specify the scope of the search to perform in the given LDAP server. The allowable scopes are "base" for a base object search, "one" for a one-level search, or "sub" for a subtree search.
<scope>构造用于指定要在给定LDAP服务器中执行的搜索范围。允许的范围是基本对象搜索的“基本”，一级搜索的“一”，或子树搜索的“子”。
The <filter> is used to specify the search filter to apply to entries within the specified scope during the search. It has the format specified in [RFC4515].
<filter>用于指定搜索期间应用于指定范围内的条目的搜索筛选器。它具有[RFC4515]中指定的格式。
The <extensions> construct provides the LDAP URL with an extensibility mechanism, allowing the capabilities of the URL to be extended in the future. Extensions are a simple comma-separated list of type=value pairs, where the =value portion MAY be omitted for options not requiring it. Each type=value pair is a separate extension. These LDAP URL extensions are not necessarily related to any of the LDAP extension mechanisms. Extensions may be supported or unsupported by the client resolving the URL. An extension prefixed with a '!' character (ASCII 0x21) is critical. An extension not prefixed with a '!' character is non-critical.
<extensions>构造为ldapurl提供了扩展机制，允许将来扩展URL的功能。扩展是一个简单的逗号分隔的type=value对列表，对于不需要它的选项，=value部分可以省略。每个type=value对都是一个单独的扩展。这些LDAP URL扩展不一定与任何LDAP扩展机制相关。解析URL的客户端可能支持或不支持扩展。前缀为“！”的扩展名字符（ASCII 0x21）至关重要。扩展名没有前缀“！”性格是不挑剔的。
If an LDAP URL extension is implemented (that is, if the implementation understands it and is able to use it), the implementation MUST make use of it. If an extension is not implemented and is marked critical, the implementation MUST NOT process the URL. If an extension is not implemented and is not marked critical, the implementation MUST ignore the extension.
如果实现了LDAP URL扩展（即，如果实现理解并能够使用它），则实现必须使用它。如果扩展未实现且标记为关键，则实现不得处理URL。如果扩展未实现且未标记为关键，则实现必须忽略该扩展。
The extension type (<extype>) MAY be specified using the numeric OID <numericoid> form (e.g., 1.2.3.4) or the descriptor <descr> form (e.g., myLDAPURLExtension). Use of the <descr> form SHOULD be restricted to registered object identifier descriptive names. See [RFC4520] for registration details and usage guidelines for descriptive names.
扩展类型（<extype>）可以使用数值OID<numericoid>形式（例如，1.2.3.4）或描述符<descr>形式（例如，myldapurlension）指定。<descr>表单的使用应限于已注册的对象标识符描述性名称。有关描述性名称的注册详细信息和使用指南，请参见[RFC4520]。
No LDAP URL extensions are defined in this document. Other documents or a future version of this document MAY define one or more extensions.
此文档中未定义LDAP URL扩展。其他文档或本文档的未来版本可能会定义一个或多个扩展。
A generated LDAP URL MUST consist only of the restricted set of characters included in one of the following three productions defined in [RFC3986]:
生成的LDAP URL必须仅包含[RFC3986]中定义的以下三个产品之一中包含的受限字符集：
<reserved>
<unreserved>
<pct-encoded>
<reserved>
<unreserved>
<pct-encoded>
Implementations SHOULD accept other valid UTF-8 strings [RFC3629] as input. An octet MUST be encoded using the percent-encoding mechanism described in section 2.1 of [RFC3986] in any of these situations:
实现应接受其他有效的UTF-8字符串[RFC3629]作为输入。在以下任何情况下，必须使用[RFC3986]第2.1节中所述的百分比编码机制对八位字节进行编码：
The octet is not in the reserved set defined in section 2.2 of [RFC3986] or in the unreserved set defined in section 2.3 of [RFC3986].
八位字节不在[RFC3986]第2.2节定义的保留集或[RFC3986]第2.3节定义的非保留集中。
It is the single Reserved character '?' and occurs inside a <dn>, <filter>, or other element of an LDAP URL.
它是单个保留字符“？”，出现在LDAP URL的<dn>、<filter>或其他元素中。
It is a comma character ',' that occurs inside an <exvalue>.
它是出现在<exvalue>中的逗号字符“”。
Note that before the percent-encoding mechanism is applied, the extensions component of the LDAP URL may contain one or more null (zero) bytes. No other component may.
请注意，在应用百分比编码机制之前，LDAP URL的扩展组件可能包含一个或多个空（零）字节。不得使用其他组件。
Some fields of the LDAP URL are optional, as described above. In the absence of any other specification, the following general defaults SHOULD be used when a field is absent. Note that other documents MAY specify different defaulting rules; for example, section 4.1.10 of [RFC4511] specifies a different rule for determining the correct DN to use when it is absent in an LDAP URL that is returned as a referral.
LDAP URL的某些字段是可选的，如上所述。在没有任何其他规范的情况下，如果没有字段，则应使用以下一般默认值。注意，其他文件可能会指定不同的默认规则；例如，[RFC4511]的第4.1.10节指定了一个不同的规则，用于在作为引用返回的LDAP URL中不存在DN时确定要使用的正确DN。
<host> If no <host> is given, the client must have some a priori knowledge of an appropriate LDAP server to contact.
<host>如果未给出<host>，则客户端必须对要联系的适当LDAP服务器有一些先验知识。
<port> The default LDAP port is TCP port 389.
<port>默认LDAP端口是TCP端口389。
<dn> If no <dn> is given, the default is the zero-length DN, "".
<dn>如果未给出<dn>，则默认为零长度dn“”。
<attributes> If the <attributes> part is omitted, all user attributes of the entry or entries should be requested (e.g., by setting the attributes field AttributeDescriptionList in the LDAP search request to a NULL list, or by using the special <alluserattrs> selector "*").
<attributes>如果省略了<attributes>部分，则应请求条目的所有用户属性（例如，通过将LDAP搜索请求中的attributes字段AttributeDescriptionList设置为空列表，或使用特殊的<alluserattrs>选择器“*”）。
<scope> If <scope> is omitted, a <scope> of "base" is assumed.
<scope>如果省略<scope>，则假定<scope>为“base”。
<filter> If <filter> is omitted, a filter of "(objectClass=*)" is assumed.
<filter>如果省略<filter>，则假定过滤器为“（objectClass=*）”。
<extensions> If <extensions> is omitted, no extensions are assumed.
<extensions>如果省略了<extensions>，则不假定扩展。
The following are some example LDAP URLs that use the format defined above. The first example is an LDAP URL referring to the University of Michigan entry, available from an LDAP server of the client's choosing:
下面是一些使用上面定义的格式的LDAP URL示例。第一个例子是一个LDAP URL，指的是密歇根大学的条目，可从客户端选择的LDAP服务器获得：
ldap:///o=University%20of%20Michigan,c=US
ldap:///o=University%20of%20Michigan,c=US
The next example is an LDAP URL referring to the University of Michigan entry in a particular ldap server:
下一个例子是一个LDAP URL，它指的是特定LDAP服务器中的密歇根大学条目：
ldap://ldap1.example.net/o=University%20of%20Michigan,c=US
ldap://ldap1.example.net/o=University%20of%20Michigan,c=US
Both of these URLs correspond to a base object search of the "o=University of Michigan,c=US" entry using a filter of "(objectclass=*)", requesting all attributes.
这两个URL都对应于“o=University of Michigan，c=US”条目的基本对象搜索，使用过滤器“（objectclass=*）”，请求所有属性。
The next example is an LDAP URL referring to only the postalAddress attribute of the University of Michigan entry:
下一个例子是一个LDAP URL，它只引用密歇根大学条目的PASTALLATION属性：
ldap://ldap1.example.net/o=University%20of%20Michigan,
c=US?postalAddress
ldap://ldap1.example.net/o=University%20of%20Michigan,
c=US?postalAddress
The corresponding LDAP search operation is the same as in the previous example, except that only the postalAddress attribute is requested.
相应的LDAP搜索操作与上一个示例中相同，只是只请求PostLadAddress属性。
The next example is an LDAP URL referring to the set of entries found by querying the given LDAP server on port 6666 and doing a subtree search of the University of Michigan for any entry with a common name of "Babs Jensen", retrieving all attributes:
下一个例子是一个LDAP URL，它指的是查询端口6666上给定的LDAP服务器所找到的条目，并对密歇根大学的子树搜索做了一个具有“Babs Jensen”的通用名称的条目，检索所有属性：
ldap://ldap1.example.net:6666/o=University%20of%20Michigan,
c=US??sub?(cn=Babs%20Jensen)
ldap://ldap1.example.net:6666/o=University%20of%20Michigan,
c=US??sub?(cn=Babs%20Jensen)
The next example is an LDAP URL referring to all children of the c=GB entry:
下一个示例是一个LDAP URL，它引用c=GB项的所有子项：
LDAP://ldap1.example.com/c=GB?objectClass?ONE
LDAP://ldap1.example.com/c=GB?objectClass?ONE
The objectClass attribute is requested to be returned along with the entries, and the default filter of "(objectclass=*)" is used.
请求将objectClass属性与条目一起返回，并使用默认过滤器“（objectClass=*）”。
The next example is an LDAP URL to retrieve the mail attribute for the LDAP entry named "o=Question?,c=US", illustrating the use of the percent-encoding mechanism on the reserved character '?'.
下一个示例是一个LDAP URL，用于检索名为“o=Question？，c=US”的LDAP条目的邮件属性，说明了在保留字符“？”上使用百分比编码机制。
ldap://ldap2.example.com/o=Question%3f,c=US?mail
ldap://ldap2.example.com/o=Question%3f,c=US?mail
The next example (which is broken into two lines for readability) illustrates the interaction between the LDAP string representation of the filters-quoting mechanism and the URL-quoting mechanisms.
下一个示例（为了可读性分为两行）说明了过滤器引用机制的LDAP字符串表示与URL引用机制之间的交互。
ldap://ldap3.example.com/o=Babsco,c=US
???(four-octet=%5c00%5c00%5c00%5c04)
ldap://ldap3.example.com/o=Babsco,c=US
???(four-octet=%5c00%5c00%5c00%5c04)
The filter in this example uses the LDAP escaping mechanism of \ to encode three zero or null bytes in the value. In LDAP, the filter would be written as (four-octet=\00\00\00\04). Because the \ character must be escaped in a URL, the \s are percent-encoded as %5c (or %5C) in the URL encoding.
本例中的筛选器使用LDAP转义机制\对值中的三个零字节或空字节进行编码。在LDAP中，过滤器将被写入（四个八位组=\00\00\00\04）。由于\字符必须在URL中转义，因此在URL编码中\s的百分比编码为%5c（或%5c）。
The next example illustrates the interaction between the LDAP string representation of the DNs-quoting mechanism and URL-quoting mechanisms.
下一个示例演示了DNs引用机制的LDAP字符串表示与URL引用机制之间的交互。
ldap://ldap.example.com/o=An%20Example%5C2C%20Inc.,c=US
ldap://ldap.example.com/o=An%20Example%5C2C%20Inc.,c=US
The DN encoded in the above URL is:
上述URL中编码的DN为：
o=An Example\2C Inc.,c=US
o=一个例子\2C公司，c=美国
That is, the left-most RDN value is:
即，最左边的RDN值为：
An Example, Inc.
例如，公司。
The following three URLs are equivalent, assuming that the defaulting rules specified in Section 3 of this document are used:
假设使用本文件第3节中规定的默认规则，以下三个URL是等效的：
ldap://ldap.example.net
ldap://ldap.example.net/
ldap://ldap.example.net/?
ldap://ldap.example.net
ldap://ldap.example.net/
ldap://ldap.example.net/?
These three URLs point to the root DSE on the ldap.example.net server.
这三个URL指向ldap.example.net服务器上的根DSE。
The final two examples show use of a hypothetical, experimental bind name extension (the value associated with the extension is an LDAP DN).
最后两个示例展示了一个假设的、实验性的绑定名扩展（与扩展相关联的值是LDAP DN）的使用。
ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com
ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com
ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com
ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com
The two URLs are the same, except that the second one marks the e-bindname extension as critical. Notice the use of the percent-encoding mechanism to encode the commas within the distinguished name value in the e-bindname extension.
这两个URL相同，只是第二个URL将e-bindname扩展标记为关键。请注意，在e-bindname扩展中，使用百分比编码机制对可分辨名称值内的逗号进行编码。
The general URL security considerations discussed in [RFC3986] are relevant for LDAP URLs.
[RFC3986]中讨论的一般URL安全注意事项与LDAP URL相关。
The use of security mechanisms when processing LDAP URLs requires particular care, since clients may encounter many different servers via URLs, and since URLs are likely to be processed automatically, without user intervention. A client SHOULD have a user-configurable policy that controls which servers the client will establish LDAP sessions with and with which security mechanisms, and SHOULD NOT establish LDAP sessions that are inconsistent with this policy. If a client chooses to reuse an existing LDAP session when resolving one or more LDAP URLs, it MUST ensure that the session is compatible with the URL and that no security policies are violated.
在处理LDAP URL时使用安全机制需要特别小心，因为客户端可能会通过URL遇到许多不同的服务器，并且URL可能会自动处理，而无需用户干预。客户端应具有用户可配置的策略，用于控制客户端将与哪些服务器建立LDAP会话以及与哪些安全机制建立LDAP会话，并且不应建立与此策略不一致的LDAP会话。如果客户端在解析一个或多个LDAP URL时选择重用现有LDAP会话，则必须确保会话与URL兼容，并且没有违反任何安全策略。
Sending authentication information, no matter the mechanism, may violate a user's privacy requirements. In the absence of specific policy permitting authentication information to be sent to a server, a client should use an anonymous LDAP session. (Note that clients conforming to previous LDAP URL specifications, where all LDAP sessions are anonymous and unprotected, are consistent with this specification; they simply have the default security policy.) Simply opening a transport connection to another server may violate some users' privacy requirements, so clients should provide the user with a way to control URL processing.
无论采用何种机制，发送身份验证信息都可能违反用户的隐私要求。在没有允许将身份验证信息发送到服务器的特定策略的情况下，客户端应该使用匿名LDAP会话。（请注意，符合以前LDAP URL规范（其中所有LDAP会话都是匿名且不受保护的）的客户端与此规范一致；它们只是具有默认安全策略。）简单地打开到另一台服务器的传输连接可能会违反某些用户的隐私要求，因此，客户端应该为用户提供一种控制URL处理的方法。
Some authentication methods, in particular, reusable passwords sent to the server, may reveal easily-abused information to the remote server or to eavesdroppers in transit and should not be used in URL processing unless they are explicitly permitted by policy. Confirmation by the human user of the use of authentication information is appropriate in many circumstances. Use of strong authentication methods that do not reveal sensitive information is much preferred. If the URL represents a referral for an update operation, strong authentication methods SHOULD be used. Please refer to the Security Considerations section of [RFC4513] for more information.
某些身份验证方法，特别是发送到服务器的可重用密码，可能会向远程服务器或传输过程中的窃听者泄露容易被滥用的信息，除非策略明确允许，否则不应在URL处理中使用这些方法。在许多情况下，由人类用户确认身份验证信息的使用是合适的。最好使用不泄露敏感信息的强身份验证方法。如果URL表示更新操作的引用，则应使用强身份验证方法。有关更多信息，请参阅[RFC4513]的安全注意事项部分。
The LDAP URL format allows the specification of an arbitrary LDAP search operation to be performed when evaluating the LDAP URL. Following an LDAP URL may cause unexpected results, for example, the retrieval of large amounts of data or the initiation of a long-lived
LDAP URL格式允许在评估LDAP URL时执行任意LDAP搜索操作的规范。遵循LDAP URL可能会导致意外的结果，例如，检索大量数据或启动长寿命URL
search. The security implications of resolving an LDAP URL are the same as those of resolving an LDAP search query.
搜索解析LDAP URL的安全含义与解析LDAP搜索查询的安全含义相同。
[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月。
[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月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[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月。
[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月。
[RFC4515] Smith, M. Ed. and T. Howes, "Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters", RFC 4515, June 2006.
[RFC4515]Smith，M.Ed.和T.Howes，“轻量级目录访问协议（LDAP）：搜索过滤器的字符串表示”，RFC4515，2006年6月。
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC2396]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
[RFC4520]Zeilenga，K.，“轻量级目录访问协议（LDAP）的互联网分配号码管理局（IANA）注意事项”，BCP 64，RFC 4520，2006年6月。
The LDAP URL format was originally defined at the University of Michigan. This material is based upon work supported by the National Science Foundation under Grant No. NCR-9416667. The support of both the University of Michigan and the National Science Foundation is gratefully acknowledged.
LDAP URL格式最初是在密歇根大学定义的。该材料是基于国家科学基金会资助的NCR-9416667号的工作。感谢密歇根大学和国家科学基金会的支持。
This document obsoletes RFC 2255 by Tim Howes and Mark Smith. Changes included in this revised specification are based upon discussions among the authors, discussions within the LDAP (v3) Revision Working Group (ldapbis), and discussions within other IETF Working Groups. The contributions of individuals in these working groups is gratefully acknowledged. Several people in particular have made valuable comments on this document: RL "Bob" Morgan, Mark Wahl, Kurt Zeilenga, Jim Sermersheim, and Hallvard Furuseth deserve special thanks for their contributions.
本文件淘汰了Tim Howes和Mark Smith的RFC 2255。本修订规范中包含的变更基于作者之间的讨论、LDAP（v3）修订工作组（ldapbis）内的讨论以及其他IETF工作组内的讨论。我们衷心感谢这些工作组中的个人所作的贡献。特别是一些人对这份文件发表了宝贵的评论：RL“Bob”Morgan、Mark Wahl、Kurt Zeilenga、Jim Sermersheim和Hallvard Furuseth值得特别感谢他们的贡献。
Appendix A: Changes Since RFC 2255
附录A：自RFC 2255以来的变化
The following technical changes were made to the contents of the "URL Definition" section:
对“URL定义”部分的内容进行了以下技术更改：
Revised all of the ABNF to use common productions from [RFC4512].
修改了所有ABNF以使用[RFC4512]中的通用产品。
Replaced references to [RFC2396] with a reference to [RFC3986] (this allows literal IPv6 addresses to be used inside the <host> portion of the URL, and a note was added to remind the reader of this enhancement). Referencing [RFC3986] required changes to the ABNF and text so that productions that are no longer defined by [RFC3986] are not used. For example, <hostport> is not defined by [RFC3986] so it has been replaced with host [COLON port]. Note that [RFC3986] includes new definitions for the "Reserved" and "Unreserved" sets of characters, and the net result is that the following two additional characters should be percent-encoded when they appear anywhere in the data used to construct an LDAP URL: "[" and "]" (these two characters were first added to the Reserved set by RFC 2732).
将对[RFC2396]的引用替换为对[RFC3986]的引用（这允许在URL的<host>部分中使用文字IPv6地址，并且添加了一个注释以提醒读者此增强）。引用[RFC3986]需要对ABNF和文本进行更改，以便不再使用[RFC3986]定义的产品。例如，<hostport>不是由[RFC3986]定义的，因此它已替换为主机[COLON port]。请注意，[RFC3986]包含了“保留”和“未保留”字符集的新定义，最终结果是，当以下两个附加字符出现在用于构造LDAP URL的数据中的任何位置时，它们都应进行百分比编码：“[”和“]”（这两个字符是RFC 2732首先添加到保留集的）。
Changed the definition of <attrdesc> to refer to <attributeSelector> from [RFC4511]. This allows the use of "*" in the <attrdesc> part of the URL. It is believed that existing implementations of RFC 2255 already support this.
将[RFC4511]中的<attributeSelector>的定义更改为引用<attributeSelector>。这允许在URL的<attrdesc>部分使用“*”。据信，RFC2255的现有实现已经支持这一点。
Avoided use of <prose-val> (bracketed-string) productions in the <dn>, <host>, <attrdesc>, and <exvalue> rules.
避免在<dn>、<host>、<attrdesc>和<exvalue>规则中使用<pross val>（带括号的字符串）结果。
Changed the ABNF for <ldapurl> to group the <dn> component with the preceding <SLASH>.
将<ldapurl>的ABNF更改为使用前面的<SLASH>对<dn>组件进行分组。
Changed the <extype> rule to be an <oid> from [RFC4512].
将<extype>规则从[RFC4512]更改为<oid>。
Changed the text about extension types so it references [RFC4520]. Reordered rules to more closely follow the order in which the elements appear in the URL.
更改了有关扩展类型的文本，使其引用[RFC4520]。重新排序规则，以便更紧密地遵循元素在URL中的显示顺序。
"Bindname Extension": removed due to lack of known implementations.
“Bindname扩展”：由于缺少已知的实现而被删除。
Changed document title to include "LDAP:" prefix.
将文档标题更改为包含“LDAP:”前缀。
IESG Note: removed note about lack of satisfactory mandatory authentication mechanisms.
IESG注释：删除了关于缺少令人满意的强制身份验证机制的注释。
"Status of this Memo" section: updated boilerplate to match current I-D guidelines.
“本备忘录的状态”部分：更新模板，以符合当前的I-D指南。
"Abstract" section: separated from introductory material.
“摘要”部分：与介绍性材料分开。
"Table of Contents" and "Intellectual Property" sections: added.
“目录”和“知识产权”部分：增加。
"Introduction" section: new section; separated from the Abstract. Changed the text indicate that RFC 2255 is replaced by this document (instead of RFC 1959). Added text to indicate that LDAP URLs are used for references and referrals. Fixed typo (replaced the nonsense phrase "to perform to retrieve" with "used to retrieve"). Added a note to let the reader know that not all of the parameters of the LDAP search operation described in [RFC4511] can be expressed using this format.
“导言”部分：新的部分；与抽象分开。更改文本表明RFC 2255被本文件取代（而不是RFC 1959）。添加文本以指示LDAP URL用于引用和引用。修正了打字错误（将无意义的短语“执行检索”替换为“用于检索”）。添加了一个注释，让读者知道[RFC4511]中描述的LDAP搜索操作的所有参数都不能使用此格式表示。
"URL Definition" section: removed second copy of <ldapurl> grammar and following two paragraphs (editorial error in RFC 2255). Fixed line break within '!' sequence. Reformatted the ABNF to improve readability by aligning comments and adding some blank lines. Replaced "residing in the LDAP server" with "accessible from the LDAP server" in the sentence immediately following the ABNF. Removed the sentence "Individual attrdesc names are as defined for AttributeDescription in [RFC4511]." because [RFC4511]'s <attributeSelector> is now used directly in the ABNF. Reworded last paragraph to clarify which characters must be percent-encoded. Added text to indicate that LDAP URLs are used for references and referrals. Added text that refers to the ABNF from RFC 4234. Clarified and strengthened the requirements with respect to processing of URLs that contain implemented and not implemented extensions (the approach now closely matches that specified in [RFC4511] for LDAP controls).
“URL定义”部分：删除了<ldapurl>语法的第二份副本和以下两段（RFC 2255中的编辑错误）。“！”内的固定线路中断序列通过对齐注释和添加一些空行，重新格式化ABNF以提高可读性。将ABNF后面的句子中的“驻留在LDAP服务器中”替换为“可从LDAP服务器访问”。删除了“单个属性描述名称如[RFC4511]中为属性描述定义的那样”这句话，因为[RFC4511]的<attributeSelector>现在直接用于ABNF。改写了最后一段，以澄清哪些字符必须进行百分比编码。添加文本以指示LDAP URL用于引用和引用。添加了引用RFC 4234中ABNF的文本。澄清并加强了关于处理包含已实现和未实现扩展的URL的要求（该方法现在与[RFC4511]中为LDAP控件指定的方法非常匹配）。
"Defaults for Fields of the LDAP URL" section: added; formed by moving text about defaults out of the "URL Definition" section. Replaced direct reference to the attribute name "*" with a reference to the special <alluserattrs> selector "*" defined in [RFC4511].
“LDAP URL字段的默认值”部分：已添加；通过将有关默认值的文本移出“URL定义”部分而形成。将对属性名“*”的直接引用替换为对[RFC4511]中定义的特殊<alluserattrs>选择器“*”的引用。
"URL Processing" section: removed.
“URL处理”部分：已删除。
"Examples" section: Modified examples to use example.com and example.net hostnames. Added missing '?' to the LDAP URL example whose filter contains three null bytes. Removed space after one comma within a DN. Revised the bindname example to use e-bindname. Changed the name of an attribute used in one example from "int" to "four-octet" to avoid potential confusion. Added an example that demonstrates the interaction between DN escaping and URL percent-encoding. Added some examples to show URL equivalence with respect
“示例”部分：修改示例以使用example.com和example.net主机名。将缺少的“？”添加到LDAP URL示例中，该示例的筛选器包含三个空字节。删除了DN中一个逗号后的空格。修改了bindname示例以使用e-bindname。将一个示例中使用的属性的名称从“int”更改为“four octet”，以避免潜在的混淆。添加了一个示例，演示DN转义和URL百分比编码之间的交互。添加了一些示例以显示URL在这方面的等效性
to the <dn> portion of the URL. Used uppercase in some examples to remind the reader that some tokens are case-insensitive.
指向URL的<dn>部分。在一些示例中使用大写，以提醒读者某些标记不区分大小写。
"Security Considerations" section: Added a note about connection reuse. Added a note about using strong authentication methods for updates. Added a reference to [RFC4513]. Added note that simply opening a connection may violate some users' privacy requirements. Adopted the working group's revised LDAP terminology specification by replacing the word "connection" with "LDAP session" or "LDAP connection" as appropriate.
“安全注意事项”部分：添加了关于连接重用的说明。添加了关于对更新使用强身份验证方法的说明。增加了对[RFC4513]的引用。补充说明：简单地打开连接可能会违反某些用户的隐私要求。通过将“连接”一词替换为“LDAP会话”或“LDAP连接”（视情况而定），通过了工作组修订的LDAP术语规范。
"Acknowledgements" section: added statement that this document obsoletes RFC 2255. Added Kurt Zeilenga, Jim Sermersheim, and Hallvard Furuseth.
“确认”部分：增加了本文件淘汰RFC 2255的声明。Kurt Zeilenga、Jim Sermersheim和Hallvard Furuseth补充道。
"Normative References" section: renamed from "References" per new RFC guidelines. Changed from [1] style to [RFC4511] style throughout the document. Added references to RFC 4234 and RFC 3629. Updated all RFC 1738 references to point to the appropriate sections within [RFC3986]. Updated the LDAP references to refer to LDAPBis WG documents. Removed the reference to the LDAP Attribute Syntaxes document and added references to the [RFC4513], [RFC4520], and [RFC4510] documents.
“规范性参考文件”部分：根据新的RFC指南从“参考文件”重命名。在整个文档中从[1]样式更改为[RFC4511]样式。增加了对RFC 4234和RFC 3629的参考。更新了所有RFC 1738参考，以指向[RFC3986]中的适当章节。更新了LDAP参考，以参考LDAPBis WG文档。删除了对LDAP属性语法文档的引用，并添加了对[RFC4513]、[RFC4520]和[RFC4510]文档的引用。
"Informative References" section: added.
“参考资料”部分：增加。
Header and "Authors' Addresses" sections: added "editor" next to Mark Smith's name. Updated affiliation and contact information.
标题和“作者地址”部分：在马克·史密斯的名字旁边添加了“编辑”。更新了联系方式和联系方式。
Copyright: updated the year.
版权所有：本年度更新。
Throughout the document: surrounded the names of all ABNF productions with "<" and ">" where they are used in descriptive text.
在整个文档中：所有ABNF产品的名称都用“<”和“>”括起来，用于描述性文本。
Authors' Addresses
作者地址
Mark Smith, Editor Pearl Crescent, LLC 447 Marlpool Dr. Saline, MI 48176 USA
马克·史密斯，编辑珍珠新月有限责任公司447 Marlpool Dr.Saline，美国密歇根州48176
Phone: +1 734 944-2856
EMail: mcs@pearlcrescent.com
Phone: +1 734 944-2856
EMail: mcs@pearlcrescent.com
Tim Howes Opsware, Inc. 599 N. Mathilda Ave. Sunnyvale, CA 94085 USA
Tim Howes Opsware，Inc.美国加利福尼亚州桑尼维尔市马蒂尔达大道北599号，邮编94085
Phone: +1 408 744-7509
EMail: howes@opsware.com
Phone: +1 408 744-7509
EMail: howes@opsware.com
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）提供。