Network Working Group T. Howes
Request for Comments: 2255 M. Smith
Category: Standards Track Netscape Communications Corp.
December 1997
Network Working Group T. Howes
Request for Comments: 2255 M. Smith
Category: Standards Track Netscape Communications Corp.
December 1997
The LDAP URL Format
LDAP URL格式
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 (1997). All Rights Reserved.
版权所有（C）互联网协会（1997年）。版权所有。
IESG NOTE
IESG注释
This document describes a directory access protocol that provides both read and update access. Update access requires secure authentication, but this document does not mandate implementation of any satisfactory authentication mechanisms.
本文档描述了一个目录访问协议，该协议提供读取和更新访问。更新访问需要安全身份验证，但本文档并不要求实现任何令人满意的身份验证机制。
In accordance with RFC 2026, section 4.4.1, this specification is being approved by IESG as a Proposed Standard despite this limitation, for the following reasons:
根据RFC 2026第4.4.1节，IESG批准本规范作为拟定标准，尽管存在此限制，原因如下：
a. to encourage implementation and interoperability testing of these protocols (with or without update access) before they are deployed, and
a. 鼓励在部署这些协议之前实施和互操作性测试（有或没有更新访问），以及
b. to encourage deployment and use of these protocols in read-only applications. (e.g. applications where LDAPv3 is used as a query language for directories which are updated by some secure mechanism other than LDAP), and
b. 鼓励在只读应用程序中部署和使用这些协议。（例如，使用LDAPv3作为目录查询语言的应用程序，这些目录由LDAP以外的安全机制更新），以及
c. to avoid delaying the advancement and deployment of other Internet standards-track protocols which require the ability to query, but not update, LDAPv3 directory servers.
c. 为避免延迟其他Internet标准的推进和部署，跟踪协议需要能够查询但不更新LDAPv3目录服务器。
Readers are hereby warned that until mandatory authentication mechanisms are standardized, clients and servers written according to this specification which make use of update functionality are UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
在此警告读者，在强制性身份验证机制标准化之前，根据本规范编写的使用更新功能的客户端和服务器不太可能互操作，或者只有在身份验证降低到不可接受的弱级别时才可能互操作。
Implementors are hereby discouraged from deploying LDAPv3 clients or servers which implement the update functionality, until a Proposed Standard for mandatory authentication in LDAPv3 has been approved and published as an RFC.
在此不鼓励实施者部署实现更新功能的LDAPv3客户端或服务器，直到LDAPv3中的强制性身份验证建议标准获得批准并作为RFC发布。
LDAP is the Lightweight Directory Access Protocol, defined in [1], [2] and [3]. This document describes a format for an LDAP Uniform Resource Locator. The format describes an LDAP search operation to perform to retrieve information from an LDAP directory. This document replaces RFC 1959. It updates 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, so that future documents can extend their functionality, for example, to provide access to new LDAPv3 extensions as they are defined.
LDAP是轻量级目录访问协议，定义见[1]、[2]和[3]。本文档描述LDAP统一资源定位器的格式。该格式描述要执行的LDAP搜索操作，以从LDAP目录检索信息。本文件取代RFC 1959。它更新了LDAP版本3的LDAP URL格式，并阐明了如何解析LDAP URL。本文档还定义了LDAP URL的扩展机制，以便将来的文档可以扩展其功能，例如，在定义新的LDAPv3扩展时提供对它们的访问。
The key words "MUST", "MAY", and "SHOULD" used in this document are to be interpreted as described in [6].
本文件中使用的关键词“必须”、“可以”和“应该”应按照[6]中所述进行解释。
An LDAP URL begins with the protocol prefix "ldap" and is defined by the following grammar.
LDAP URL以协议前缀“LDAP”开头，由以下语法定义。
ldapurl = scheme "://" [hostport] ["/"
[dn ["?" [attributes] ["?" [scope]
["?" [filter] ["?" extensions]]]]]]
scheme = "ldap"
attributes = attrdesc *("," attrdesc)
scope = "base" / "one" / "sub"
dn = distinguishedName from Section 3 of [1]
hostport = hostport from Section 5 of RFC 1738 [5]
attrdesc = AttributeDescription from Section 4.1.5 of [2]
filter = filter from Section 4 of [4]
extensions = extension *("," extension)
extension = ["!"] extype ["=" exvalue]
extype = token / xtoken
exvalue = LDAPString from section 4.1.2 of [2]
token = oid from section 4.1 of [3]
xtoken = ("X-" / "x-") token
ldapurl = scheme "://" [hostport] ["/"
[dn ["?" [attributes] ["?" [scope]
["?" [filter] ["?" extensions]]]]]]
scheme = "ldap"
attributes = attrdesc *("," attrdesc)
scope = "base" / "one" / "sub"
dn = distinguishedName from Section 3 of [1]
hostport = hostport from Section 5 of RFC 1738 [5]
attrdesc = AttributeDescription from Section 4.1.5 of [2]
filter = filter from Section 4 of [4]
extensions = extension *("," extension)
extension = ["!"] extype ["=" exvalue]
extype = token / xtoken
exvalue = LDAPString from section 4.1.2 of [2]
token = oid from section 4.1 of [3]
xtoken = ("X-" / "x-") token
The "ldap" prefix indicates an entry or entries residing in the LDAP server running on the given hostname at the given portnumber. The default LDAP port is TCP port 389. If no hostport is given, the client must have some apriori knowledge of an appropriate LDAP server to contact.
“ldap”前缀表示驻留在ldap服务器中的一个或多个条目，这些条目在给定端口号的给定主机名上运行。默认的LDAP端口是TCP端口389。如果未提供hostport，则客户机必须对要联系的适当LDAP服务器有一些先验知识。
The dn is an LDAP Distinguished Name using the string format described in [1]. It identifies the base object of the LDAP search.
dn是使用[1]中描述的字符串格式的LDAP可分辨名称。它标识LDAP搜索的基本对象。
ldapurl = scheme "://" [hostport] ["/"
[dn ["?" [attributes] ["?" [scope]
["?" [filter] ["?" extensions]]]]]]
scheme = "ldap"
attributes = attrdesc *("," attrdesc)
scope = "base" / "one" / "sub"
dn = distinguishedName from Section 3 of [1]
hostport = hostport from Section 5 of RFC 1738 [5]
attrdesc = AttributeDescription from Section 4.1.5 of [2]
filter = filter from Section 4 of [4]
extensions = extension *("," extension)
extension = ["!"] extype ["=" exvalue]
extype = token / xtoken
exvalue = LDAPString from section 4.1.2 of [2]
token = oid from section 4.1 of [3]
xtoken = ("X-" / "x-") token
ldapurl = scheme "://" [hostport] ["/"
[dn ["?" [attributes] ["?" [scope]
["?" [filter] ["?" extensions]]]]]]
scheme = "ldap"
attributes = attrdesc *("," attrdesc)
scope = "base" / "one" / "sub"
dn = distinguishedName from Section 3 of [1]
hostport = hostport from Section 5 of RFC 1738 [5]
attrdesc = AttributeDescription from Section 4.1.5 of [2]
filter = filter from Section 4 of [4]
extensions = extension *("," extension)
extension = ["!"] extype ["=" exvalue]
extype = token / xtoken
exvalue = LDAPString from section 4.1.2 of [2]
token = oid from section 4.1 of [3]
xtoken = ("X-" / "x-") token
The "ldap" prefix indicates an entry or entries residing in the LDAP server running on the given hostname at the given portnumber. The default LDAP port is TCP port 389. If no hostport is given, the client must have some apriori knowledge of an appropriate LDAP server to contact.
“ldap”前缀表示驻留在ldap服务器中的一个或多个条目，这些条目在给定端口号的给定主机名上运行。默认的LDAP端口是TCP端口389。如果未提供hostport，则客户机必须对要联系的适当LDAP服务器有一些先验知识。
The dn is an LDAP Distinguished Name using the string format described in [1]. It identifies the base object of the LDAP search.
dn是使用[1]中描述的字符串格式的LDAP可分辨名称。它标识LDAP搜索的基本对象。
The attributes construct is used to indicate which attributes should be returned from the entry or entries. Individual attrdesc names are as defined for AttributeDescription in [2]. 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 (in LDAPv3) by requesting the special attribute name "*").
attributes构造用于指示应该从一个或多个条目返回哪些属性。单个attrdesc名称的定义与[2]中的AttributeDescription相同。如果省略属性部分，则应请求条目的所有用户属性（例如，通过将LDAP搜索请求中的属性字段AttributeDescriptionList设置为空列表，或（在LDAPv3中）通过请求特殊属性名称“*”）。
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. If scope is omitted, a scope of "base" is assumed.
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 [4]. If filter is omitted, a filter of "(objectClass=*)" is assumed.
筛选器用于指定搜索期间应用于指定范围内的条目的搜索筛选器。它具有[4]中指定的格式。如果省略过滤器，则假定过滤器为“（objectClass=*）”。
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 LDAPv3 extension mechanisms. Extensions may be supported or unsupported by the client resolving the URL. An extension prefixed with a '!' character (ASCII 33) is critical. An extension not prefixed with a ' !' character is non-critical.
extensions构造为LDAP URL提供了可扩展性机制，允许将来扩展URL的功能。扩展是一个简单的逗号分隔的type=value对列表，对于不需要它的选项，=value部分可以省略。每个type=value对都是一个单独的扩展。这些LDAP URL扩展不一定与任何LDAPv3扩展机制相关。解析URL的客户端可能支持或不支持扩展。前缀为“！”的扩展名字符（ASCII 33）至关重要。扩展名没有前缀“！”性格是不挑剔的。
If an extension is supported by the client, the client MUST obey the extension if the extension is critical. The client SHOULD obey supported extensions that are non-critical.
如果客户机支持扩展，那么如果扩展是关键的，客户机必须遵守扩展。客户端应该遵守支持的非关键扩展。
If an extension is unsupported by the client, the client MUST NOT process the URL if the extension is critical. If an unsupported extension is non-critical, the client MUST ignore the extension.
如果客户端不支持某个扩展，则如果该扩展是关键的，客户端不得处理该URL。如果不受支持的扩展是非关键扩展，则客户端必须忽略该扩展。
If a critical extension cannot be processed successfully by the client, the client MUST NOT process the URL. If a non-critical extension cannot be processed successfully by the client, the client SHOULD ignore the extension.
如果客户端无法成功处理关键扩展，则客户端不得处理URL。如果客户端无法成功处理非关键扩展，则客户端应忽略该扩展。
Extension types prefixed by "X-" or "x-" are reserved for use in bilateral agreements between communicating parties. Other extension types MUST be defined in this document, or in other standards-track documents.
前缀为“X-”或“X-”的扩展类型保留在通信方之间的双边协议中使用。其他扩展类型必须在本文档或其他标准跟踪文档中定义。
One LDAP URL extension is defined in this document in the next section. Other documents or a future version of this document MAY define other extensions.
下一节将在本文档中定义一个LDAP URL扩展。其他文档或本文档的未来版本可能会定义其他扩展。
Note that any URL-illegal characters (e.g., spaces), URL special characters (as defined in section 2.2 of RFC 1738) and the reserved character '?' (ASCII 63) occurring inside a dn, filter, or other element of an LDAP URL MUST be escaped using the % method described in RFC 1738 [5]. If a comma character ',' occurs inside an extension value, the character MUST also be escaped using the % method.
请注意，在LDAP URL的dn、筛选器或其他元素中出现的任何URL非法字符（例如空格）、URL特殊字符（如RFC 1738第2.2节中的定义）和保留字符“？”（ASCII 63）必须使用RFC 1738[5]中描述的%方法进行转义。如果扩展值中出现逗号字符“”，则还必须使用%方法对该字符进行转义。
This section defines an LDAP URL extension for representing the distinguished name for a client to use when authenticating to an LDAP directory during resolution of an LDAP URL. Clients MAY implement this extension.
本节定义LDAP URL扩展，用于表示在解析LDAP URL期间对LDAP目录进行身份验证时客户端要使用的可分辨名称。客户端可以实现此扩展。
The extension type is "bindname". The extension value is the distinguished name of the directory entry to authenticate as, in the same form as described for dn in the grammar above. The dn may be the NULL string to specify unauthenticated access. The extension may be either critical (prefixed with a '!' character) or non-critical (not prefixed with a '!' character).
扩展类型为“bindname”。扩展名值是要进行身份验证的目录项的可分辨名称，其形式与上面语法中描述的dn相同。dn可以是空字符串，用于指定未经验证的访问。扩展名可以是关键扩展名（前缀为“！”字符）或非关键扩展名（前缀为“！”字符）。
If the bindname extension is critical, the client resolving the URL MUST authenticate to the directory using the given distinguished name and an appropriate authentication method. Note that for a NULL distinguished name, no bind MAY be required to obtain anonymous access to the directory. If the extension is non-critical, the client MAY bind to the directory using the given distinguished name.
如果bindname扩展是关键的，则解析URL的客户端必须使用给定的可分辨名称和适当的身份验证方法对目录进行身份验证。请注意，对于空可分辨名称，无需绑定即可获得对目录的匿名访问。如果扩展是非关键的，客户端可以使用给定的可分辨名称绑定到目录。
This section describes how an LDAP URL SHOULD be resolved by a client.
本节介绍客户端应如何解析LDAP URL。
First, the client obtains a connection to the LDAP server referenced in the URL, or an LDAP server of the client's choice if no LDAP server is explicitly referenced. This connection MAY be opened specifically for the purpose of resolving the URL or the client MAY reuse an already open connection. The connection MAY provide confidentiality, integrity, or other services, e.g., using TLS. Use of security services is at the client's discretion if not specified in the URL.
首先，客户机获得到URL中引用的LDAP服务器的连接，或者如果没有显式引用LDAP服务器，则获得客户机选择的LDAP服务器的连接。此连接可以专门为解析URL而打开，或者客户端可以重用已打开的连接。连接可以提供机密性、完整性或其他服务，例如使用TLS。如果URL中未指定，则客户可自行决定是否使用安全服务。
Next, the client authenticates itself to the LDAP server. This step is optional, unless the URL contains a critical bindname extension with a non-NULL value. If a bindname extension is given, the client proceeds according to the section above.
接下来，客户机向LDAP服务器进行身份验证。此步骤是可选的，除非URL包含具有非空值的关键bindname扩展名。如果给定bindname扩展名，客户机将按照上面的部分进行操作。
If a bindname extension is not specified, the client MAY bind to the directory using a appropriate dn and authentication method of its own choosing (including NULL authentication).
如果未指定bindname扩展名，则客户端可以使用自己选择的适当dn和身份验证方法（包括空身份验证）绑定到目录。
Next, the client performs the LDAP search operation specified in the URL. Additional fields in the LDAP protocol search request, such as sizelimit, timelimit, deref, and anything else not specified or defaulted in the URL specification, MAY be set at the client's discretion.
接下来，客户端执行URL中指定的LDAP搜索操作。LDAP协议搜索请求中的其他字段，如sizelimit、timelimit、deref以及URL规范中未指定或默认的任何其他字段，可由客户端自行设置。
Once the search has completed, the client MAY close the connection to the LDAP server, or the client MAY keep the connection open for future use.
搜索完成后，客户端可能会关闭与LDAP服务器的连接，或者客户端可能会保持连接打开以供将来使用。
The following are some example LDAP URLs using 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://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US
ldap://ldap.itd.umich.edu/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://ldap.itd.umich.edu/o=University%20of%20Michigan,
c=US?postalAddress
ldap://ldap.itd.umich.edu/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://host.com:6666/o=University%20of%20Michigan,
c=US??sub?(cn=Babs%20Jensen)
ldap://host.com: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://ldap.itd.umich.edu/c=GB?objectClass?one
ldap://ldap.itd.umich.edu/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" is given below, illustrating the use of the escaping mechanism on the reserved character '?'.
下一个示例是一个LDAP URL，用于检索名为“o=Question？，c=US”的LDAP条目的邮件属性，如下所示，说明了在保留字符“？”上使用转义机制。
ldap://ldap.question.com/o=Question%3f,c=US?mail
ldap://ldap.question.com/o=Question%3f,c=US?mail
The next example illustrates the interaction between LDAP and URL quoting mechanisms.
下一个示例演示了LDAP和URL引用机制之间的交互。
ldap://ldap.netscape.com/o=Babsco,c=US??(int=%5c00%5c00%5c00%5c04)
ldap://ldap.netscape.com/o=Babsco,c=US??(int=%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 (int=\00\00\00\04). Because the \ character must be escaped in a URL, the \'s are escaped as %5c in the URL encoding.
本例中的筛选器使用LDAP转义机制\对值中的三个零字节或空字节进行编码。在LDAP中，过滤器将被写入（int=\00\00\00\04）。因为\字符必须在URL中转义，所以在URL编码中，'转义为%5c。
The final example shows the use of the bindname extension to specify the dn a client should use for authentication when resolving the URL.
最后一个示例显示了如何使用bindname扩展来指定客户端在解析URL时用于身份验证的dn。
ldap:///??sub??bindname=cn=Manager%2co=Foo
ldap:///??sub??!bindname=cn=Manager%2co=Foo
ldap:///??sub??bindname=cn=Manager%2co=Foo
ldap:///??sub??!bindname=cn=Manager%2co=Foo
The two URLs are the same, except that the second one marks the bindname extension as critical. Notice the use of the % encoding method to encode the comma in the distinguished name value in the
这两个URL相同，只是第二个URL将bindname扩展标记为关键。请注意，使用%encoding方法对中的可分辨名称值中的逗号进行编码
bindname extension.
bindname扩展名。
General URL security considerations discussed in [5] are relevant for LDAP URLs.
[5]中讨论的一般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 about which servers to connect to using which security mechanisms, and SHOULD NOT make connections that are inconsistent with this policy.
在处理LDAP URL时使用安全机制需要特别小心，因为客户端可能会通过URL遇到许多不同的服务器，并且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 connection. (Note that clients conforming to previous LDAP URL specifications, where all connections are anonymous and unprotected, are consistent with this specification; they simply have the default security policy.)
无论采用何种机制，发送身份验证信息都可能违反用户的隐私要求。在没有允许将身份验证信息发送到服务器的特定策略的情况下，客户端应该使用匿名连接。（请注意，符合以前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 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.
某些身份验证方法，特别是发送到服务器的可重用密码，可能会向远程服务器或传输过程中的窃听者泄露容易被滥用的信息，除非策略明确允许，否则不应在URL处理中使用。在许多情况下，由人类用户确认身份验证信息的使用是合适的。最好使用不泄露敏感信息的强身份验证方法。
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, the initiation of a long-lived search, etc. The security implications of resolving an LDAP URL are the same as those of resolving an LDAP search query.
LDAP URL格式允许在评估LDAP URL时执行任意LDAP搜索操作的规范。遵循LDAP URL可能会导致意外结果，例如检索大量数据、启动长期搜索等。解析LDAP URL的安全含义与解析LDAP搜索查询的安全含义相同。
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号的工作。感谢密歇根大学和国家科学基金会的支持。
Several people have made valuable comments on this document. In particular RL "Bob" Morgan and Mark Wahl deserve special thanks for their contributions.
有几个人对这份文件提出了宝贵的意见。特别是RL“Bob”Morgan和Mark Wahl值得特别感谢他们的贡献。
[1] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997.
[1] Wahl，M.，Kille，S.，和T.Howes，“轻量级目录访问协议（v3）：可分辨名称的UTF-8字符串表示”，RFC 2253，1997年12月。
[2] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[2] Wahl，M.，Howes，T.，和S.Kille，“轻量级目录访问协议（v3）”，RFC 2251，1997年12月。
[3] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997.
[3] Wahl，M.，Coulbeck，A.，Howes，T.和S.Kille，“轻量级目录访问协议（v3）：属性语法定义”，RFC2252，1997年12月。
[4] Howes, T., "A String Representation of LDAP Search Filters", RFC 2254, December 1997.
[4] Howes，T.，“LDAP搜索过滤器的字符串表示”，RFC 2254，1997年12月。
[5] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)," RFC 1738, December 1994.
[5] Berners Lee，T.，Masinter，L.和M.McCahill，“统一资源定位器（URL）”，RFC 17381994年12月。
[6] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels," RFC 2119, March 1997.
[6] Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 211997年3月。
Authors' Addresses
作者地址
Tim Howes Netscape Communications Corp. 501 E. Middlefield Rd. Mountain View, CA 94043 USA
Tim Howes Netscape Communications Corp.美国加利福尼亚州山景城米德菲尔德东路501号，邮编94043
Phone: +1 415 937-3419
EMail: howes@netscape.com
Phone: +1 415 937-3419
EMail: howes@netscape.com
Mark Smith Netscape Communications Corp. 501 E. Middlefield Rd. Mountain View, CA 94043 USA
马克·史密斯网景通信公司，美国加利福尼亚州山景城米德菲尔德东路501号，邮编94043
Phone: +1 415 937-3477
EMail: mcs@netscape.com
Phone: +1 415 937-3477
EMail: mcs@netscape.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1997). All Rights Reserved.
版权所有（C）互联网协会（1997年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。