Network Working Group M. Smith, Ed.
Request for Comments: 4515 Pearl Crescent, LLC
Obsoletes: 2254 T. Howes
Category: Standards Track Opsware, Inc.
June 2006
Network Working Group M. Smith, Ed.
Request for Comments: 4515 Pearl Crescent, LLC
Obsoletes: 2254 T. Howes
Category: Standards Track Opsware, Inc.
June 2006
Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters
轻量级目录访问协议（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
摘要
Lightweight Directory Access Protocol (LDAP) search filters are transmitted in the LDAP protocol using a binary representation that is appropriate for use on the network. This document defines a human-readable string representation of LDAP search filters that is appropriate for use in LDAP URLs (RFC 4516) and in other applications.
轻量级目录访问协议（LDAP）搜索筛选器在LDAP协议中使用适合在网络上使用的二进制表示进行传输。本文档定义了LDAP搜索筛选器的可读字符串表示形式，适合在LDAP URL（RFC 4516）和其他应用程序中使用。
Table of Contents
目录
1. Introduction ....................................................2
2. LDAP Search Filter Definition ...................................2
3. String Search Filter Definition .................................3
4. Examples ........................................................5
5. Security Considerations .........................................7
6. Normative References ............................................7
7. Informative References ..........................................8
8. Acknowledgements ................................................8
Appendix A: Changes Since RFC 2254 .................................9
A.1. Technical Changes ..........................................9
A.2. Editorial Changes ..........................................9
1. Introduction ....................................................2
2. LDAP Search Filter Definition ...................................2
3. String Search Filter Definition .................................3
4. Examples ........................................................5
5. Security Considerations .........................................7
6. Normative References ............................................7
7. Informative References ..........................................8
8. Acknowledgements ................................................8
Appendix A: Changes Since RFC 2254 .................................9
A.1. Technical Changes ..........................................9
A.2. Editorial Changes ..........................................9
The Lightweight Directory Access Protocol (LDAP) [RFC4510] defines a network representation of a search filter transmitted to an LDAP server. Some applications may find it useful to have a common way of representing these search filters in a human-readable form; LDAP URLs [RFC4516] are an example of one such application. This document defines a human-readable string format for representing the full range of possible LDAP version 3 search filters, including extended match filters.
轻量级目录访问协议（LDAP）[RFC4510]定义了传输到LDAP服务器的搜索过滤器的网络表示形式。一些应用程序可能会发现，有一种以人类可读的形式表示这些搜索过滤器的通用方法是有用的；LDAP URL[RFC4516]就是这样一个应用程序的示例。本文档定义了一种人类可读的字符串格式，用于表示所有可能的LDAP版本3搜索筛选器，包括扩展匹配筛选器。
This document is a 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 2254. Changes to RFC 2254 are summarized in Appendix A.
本文件取代RFC 2254。RFC 2254的变更汇总在附录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 search filter is defined in Section 4.5.1 of [RFC4511] as follows:
[RFC4511]第4.5.1节中定义了LDAP搜索筛选器，如下所示：
Filter ::= CHOICE {
and [0] SET SIZE (1..MAX) OF filter Filter,
or [1] SET SIZE (1..MAX) OF filter Filter,
not [2] Filter,
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter,
greaterOrEqual [5] AttributeValueAssertion,
lessOrEqual [6] AttributeValueAssertion,
present [7] AttributeDescription,
approxMatch [8] AttributeValueAssertion,
extensibleMatch [9] MatchingRuleAssertion }
Filter ::= CHOICE {
and [0] SET SIZE (1..MAX) OF filter Filter,
or [1] SET SIZE (1..MAX) OF filter Filter,
not [2] Filter,
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter,
greaterOrEqual [5] AttributeValueAssertion,
lessOrEqual [6] AttributeValueAssertion,
present [7] AttributeDescription,
approxMatch [8] AttributeValueAssertion,
extensibleMatch [9] MatchingRuleAssertion }
SubstringFilter ::= SEQUENCE {
type AttributeDescription,
-- initial and final can occur at most once
substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
initial [0] AssertionValue,
any [1] AssertionValue,
final [2] AssertionValue } }
SubstringFilter ::= SEQUENCE {
type AttributeDescription,
-- initial and final can occur at most once
substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
initial [0] AssertionValue,
any [1] AssertionValue,
final [2] AssertionValue } }
AttributeValueAssertion ::= SEQUENCE {
attributeDesc AttributeDescription,
assertionValue AssertionValue }
AttributeValueAssertion ::= SEQUENCE {
attributeDesc AttributeDescription,
assertionValue AssertionValue }
MatchingRuleAssertion ::= SEQUENCE {
matchingRule [1] MatchingRuleId OPTIONAL,
type [2] AttributeDescription OPTIONAL,
matchValue [3] AssertionValue,
dnAttributes [4] BOOLEAN DEFAULT FALSE }
MatchingRuleAssertion ::= SEQUENCE {
matchingRule [1] MatchingRuleId OPTIONAL,
type [2] AttributeDescription OPTIONAL,
matchValue [3] AssertionValue,
dnAttributes [4] BOOLEAN DEFAULT FALSE }
AttributeDescription ::= LDAPString
-- Constrained to <attributedescription>
-- [RFC4512]
AttributeDescription ::= LDAPString
-- Constrained to <attributedescription>
-- [RFC4512]
AttributeValue ::= OCTET STRING
AttributeValue ::= OCTET STRING
MatchingRuleId ::= LDAPString
MatchingRuleId ::= LDAPString
AssertionValue ::= OCTET STRING
AssertionValue ::= OCTET STRING
LDAPString ::= OCTET STRING -- UTF-8 encoded,
-- [Unicode] characters
LDAPString ::= OCTET STRING -- UTF-8 encoded,
-- [Unicode] characters
The AttributeDescription, as defined in [RFC4511], is a string representation of the attribute description that is discussed in [RFC4512]. The AttributeValue and AssertionValue OCTET STRING have the form defined in [RFC4517]. The Filter is encoded for transmission over a network using the Basic Encoding Rules (BER) defined in [X.690], with simplifications described in [RFC4511].
[RFC4511]中定义的AttributeDescription是[RFC4512]中讨论的属性描述的字符串表示形式。AttributeValue和AssertionValue八位字节字符串的格式在[RFC4517]中定义。使用[X.690]中定义的基本编码规则（BER）以及[RFC4511]中描述的简化，对滤波器进行编码，以便在网络上传输。
The string representation of an LDAP search filter is a string of UTF-8 [RFC3629] encoded Unicode characters [Unicode] that is defined by the following grammar, following the ABNF notation defined in [RFC4234]. The productions used that are not defined here are defined in Section 1.4 (Common ABNF Productions) of [RFC4512] unless otherwise noted. The filter format uses a prefix notation.
LDAP搜索筛选器的字符串表示是UTF-8[RFC3629]编码的Unicode字符[Unicode]字符串，该字符串由以下语法定义，遵循[RFC4234]中定义的ABNF符号。除非另有说明，此处未定义的产品在[RFC4512]第1.4节（通用ABNF产品）中定义。过滤器格式使用前缀表示法。
filter = LPAREN filtercomp RPAREN
filtercomp = and / or / not / item
and = AMPERSAND filterlist
or = VERTBAR filterlist
not = EXCLAMATION filter
filterlist = 1*filter
item = simple / present / substring / extensible
simple = attr filtertype assertionvalue
filtertype = equal / approx / greaterorequal / lessorequal
filter = LPAREN filtercomp RPAREN
filtercomp = and / or / not / item
and = AMPERSAND filterlist
or = VERTBAR filterlist
not = EXCLAMATION filter
filterlist = 1*filter
item = simple / present / substring / extensible
simple = attr filtertype assertionvalue
filtertype = equal / approx / greaterorequal / lessorequal
equal = EQUALS
approx = TILDE EQUALS
greaterorequal = RANGLE EQUALS
lessorequal = LANGLE EQUALS
extensible = ( attr [dnattrs]
[matchingrule] COLON EQUALS assertionvalue )
/ ( [dnattrs]
matchingrule COLON EQUALS assertionvalue )
present = attr EQUALS ASTERISK
substring = attr EQUALS [initial] any [final]
initial = assertionvalue
any = ASTERISK *(assertionvalue ASTERISK)
final = assertionvalue
attr = attributedescription
; The attributedescription rule is defined in
; Section 2.5 of [RFC4512].
dnattrs = COLON "dn"
matchingrule = COLON oid
assertionvalue = valueencoding
; The <valueencoding> rule is used to encode an <AssertionValue>
; from Section 4.1.6 of [RFC4511].
valueencoding = 0*(normal / escaped)
normal = UTF1SUBSET / UTFMB
escaped = ESC HEX HEX
UTF1SUBSET = %x01-27 / %x2B-5B / %x5D-7F
; UTF1SUBSET excludes 0x00 (NUL), LPAREN,
; RPAREN, ASTERISK, and ESC.
EXCLAMATION = %x21 ; exclamation mark ("!")
AMPERSAND = %x26 ; ampersand (or AND symbol) ("&")
ASTERISK = %x2A ; asterisk ("*")
COLON = %x3A ; colon (":")
VERTBAR = %x7C ; vertical bar (or pipe) ("|")
TILDE = %x7E ; tilde ("~")
equal = EQUALS
approx = TILDE EQUALS
greaterorequal = RANGLE EQUALS
lessorequal = LANGLE EQUALS
extensible = ( attr [dnattrs]
[matchingrule] COLON EQUALS assertionvalue )
/ ( [dnattrs]
matchingrule COLON EQUALS assertionvalue )
present = attr EQUALS ASTERISK
substring = attr EQUALS [initial] any [final]
initial = assertionvalue
any = ASTERISK *(assertionvalue ASTERISK)
final = assertionvalue
attr = attributedescription
; The attributedescription rule is defined in
; Section 2.5 of [RFC4512].
dnattrs = COLON "dn"
matchingrule = COLON oid
assertionvalue = valueencoding
; The <valueencoding> rule is used to encode an <AssertionValue>
; from Section 4.1.6 of [RFC4511].
valueencoding = 0*(normal / escaped)
normal = UTF1SUBSET / UTFMB
escaped = ESC HEX HEX
UTF1SUBSET = %x01-27 / %x2B-5B / %x5D-7F
; UTF1SUBSET excludes 0x00 (NUL), LPAREN,
; RPAREN, ASTERISK, and ESC.
EXCLAMATION = %x21 ; exclamation mark ("!")
AMPERSAND = %x26 ; ampersand (or AND symbol) ("&")
ASTERISK = %x2A ; asterisk ("*")
COLON = %x3A ; colon (":")
VERTBAR = %x7C ; vertical bar (or pipe) ("|")
TILDE = %x7E ; tilde ("~")
Note that although both the <substring> and <present> productions in the grammar above can produce the "attr=*" construct, this construct is used only to denote a presence filter.
请注意，尽管上述语法中的<substring>和<present>结果都可以生成“attr=*”构造，但此构造仅用于表示存在筛选器。
The <valueencoding> rule ensures that the entire filter string is a valid UTF-8 string and provides that the octets that represent the ASCII characters "*" (ASCII 0x2a), "(" (ASCII 0x28), ")" (ASCII 0x29), "\" (ASCII 0x5c), and NUL (ASCII 0x00) are represented as a backslash "\" (ASCII 0x5c) followed by the two hexadecimal digits representing the value of the encoded octet.
<valueencoding>规则确保整个筛选器字符串是有效的UTF-8字符串，并提供表示ASCII字符“*”（ASCII 0x2a）、“（“（ASCII 0x28）、”）（ASCII 0x29）、“\”（ASCII 0x5c）和NUL（ASCII 0x00）的八位字节表示为反斜杠“\”（ASCII 0x5c）后跟表示编码八位字节值的两个十六进制数字。
This simple escaping mechanism eliminates filter-parsing ambiguities and allows any filter that can be represented in LDAP to be represented as a NUL-terminated string. Other octets that are part of the <normal> set may be escaped using this mechanism, for example, non-printing ASCII characters.
这个简单的转义机制消除了过滤器解析的歧义，并允许在LDAP中表示的任何过滤器都表示为以NUL结尾的字符串。属于<normal>集的其他八位字节可以使用此机制进行转义，例如，非打印ASCII字符。
For AssertionValues that contain UTF-8 character data, each octet of the character to be escaped is replaced by a backslash and two hex digits, which form a single octet in the code of the character. For example, the filter checking whether the "cn" attribute contained a value with the character "*" anywhere in it would be represented as "(cn=*\2a*)".
对于包含UTF-8字符数据的AssertionValues，要转义的字符的每个八位字节都将替换为反斜杠和两个十六进制数字，它们在字符代码中形成一个八位字节。例如，检查“cn”属性是否包含在其中任何位置带有“*”字符的值的筛选器将表示为“（cn=*\2a*）”。
As indicated by the <valueencoding> rule, implementations MUST escape all octets greater than 0x7F that are not part of a valid UTF-8 encoding sequence when they generate a string representation of a search filter. Implementations SHOULD accept as input strings that are not valid UTF-8 strings. This is necessary because RFC 2254 did not clearly define the term "string representation" (and in particular did not mention that the string representation of an LDAP search filter is a string of UTF-8-encoded Unicode characters).
如<valueencoding>规则所示，当实现生成搜索筛选器的字符串表示形式时，必须转义所有大于0x7F且不属于有效UTF-8编码序列的八位字节。实现应接受无效UTF-8字符串作为输入字符串。这是必要的，因为RFC 2254没有明确定义术语“字符串表示”（尤其没有提到LDAP搜索筛选器的字符串表示是UTF-8编码的Unicode字符字符串）。
This section gives a few examples of search filters written using this notation.
本节给出了几个使用此符号编写的搜索过滤器示例。
(cn=Babs Jensen)
(!(cn=Tim Howes))
(&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))
(o=univ*of*mich*)
(seeAlso=)
(cn=Babs Jensen)
(!(cn=Tim Howes))
(&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))
(o=univ*of*mich*)
(seeAlso=)
The following examples illustrate the use of extensible matching.
以下示例说明了可扩展匹配的使用。
(cn:caseExactMatch:=Fred Flintstone)
(cn:=Betty Rubble)
(sn:dn:2.4.6.8.10:=Barney Rubble)
(o:dn:=Ace Industry)
(:1.2.3:=Wilma Flintstone)
(:DN:2.4.6.8.10:=Dino)
(cn:caseExactMatch:=Fred Flintstone)
(cn:=Betty Rubble)
(sn:dn:2.4.6.8.10:=Barney Rubble)
(o:dn:=Ace Industry)
(:1.2.3:=Wilma Flintstone)
(:DN:2.4.6.8.10:=Dino)
The first example shows use of the matching rule "caseExactMatch."
第一个示例显示了匹配规则“caseExactMatch”的使用
The second example demonstrates use of a MatchingRuleAssertion form without a matchingRule.
第二个示例演示了在没有matchingRule的情况下使用MatchingRuleAssertion表单。
The third example illustrates the use of the ":oid" notation to indicate that the matching rule identified by the OID "2.4.6.8.10" should be used when making comparisons, and that the attributes of an entry's distinguished name should be considered part of the entry when evaluating the match (indicated by the use of ":dn").
第三个示例说明了使用“：oid”表示法来表示在进行比较时应使用oid“2.4.6.8.10”标识的匹配规则，并且在评估匹配时应将条目的可分辨名称属性视为条目的一部分（使用“：dn”表示）。
The fourth example denotes an equality match, except that DN components should be considered part of the entry when doing the match.
第四个示例表示相等匹配，但进行匹配时应将DN组件视为条目的一部分。
The fifth example is a filter that should be applied to any attribute supporting the matching rule given (since the <attr> has been omitted).
第五个示例是一个过滤器，它应该应用于支持给定匹配规则的任何属性（因为省略了<attr>）。
The sixth and final example is also a filter that should be applied to any attribute supporting the matching rule given. Attributes supporting the matching rule contained in the DN should also be considered.
第六个也是最后一个示例是一个过滤器，它应该应用于支持给定匹配规则的任何属性。还应考虑支持DN中包含的匹配规则的属性。
The following examples illustrate the use of the escaping mechanism.
以下示例说明了转义机制的使用。
(o=Parens R Us \28for all your parenthetical needs\29)
(cn=*\2A*)
(filename=C:\5cMyFile)
(bin=\00\00\00\04)
(sn=Lu\c4\8di\c4\87)
(1.3.6.1.4.1.1466.0=\04\02\48\69)
(o=Parens R Us \28for all your parenthetical needs\29)
(cn=*\2A*)
(filename=C:\5cMyFile)
(bin=\00\00\00\04)
(sn=Lu\c4\8di\c4\87)
(1.3.6.1.4.1.1466.0=\04\02\48\69)
The first example shows the use of the escaping mechanism to represent parenthesis characters. The second shows how to represent a "*" in an assertion value, preventing it from being interpreted as a substring indicator. The third illustrates the escaping of the backslash character.
第一个示例演示如何使用转义机制来表示括号字符。第二个示例演示如何在断言值中表示“*”，以防止将其解释为子字符串指示符。第三个示例说明了反斜杠字符的转义。
The fourth example shows a filter searching for the four-octet value 00 00 00 04 (hex), illustrating the use of the escaping mechanism to represent arbitrary data, including NUL characters.
第四个示例显示了搜索四个八位字节值0004（十六进制）的过滤器，说明了如何使用转义机制来表示任意数据，包括NUL字符。
The fifth example illustrates the use of the escaping mechanism to represent various non-ASCII UTF-8 characters. Specifically, there are 5 characters in the <assertionvalue> portion of this example: LATIN CAPITAL LETTER L (U+004C), LATIN SMALL LETTER U (U+0075), LATIN SMALL LETTER C WITH CARON (U+010D), LATIN SMALL LETTER I (U+0069), and LATIN SMALL LETTER C WITH ACUTE (U+0107).
第五个示例说明如何使用转义机制来表示各种非ASCII UTF-8字符。具体来说，本例的<assertionvalue>部分中有5个字符：拉丁文大写字母L（U+004C）、拉丁文小写字母U（U+0075）、带卡隆的拉丁文小写字母C（U+010D）、带锐音符的拉丁文小写字母I（U+0069）和带锐音符的拉丁文小写字母C（U+0107）。
The sixth and final example demonstrates assertion of a BER-encoded value.
第六个也是最后一个示例演示了BER编码值的断言。
This memo describes a string representation of LDAP search filters. While the representation itself has no known security implications, LDAP search filters do. They are interpreted by LDAP servers to select entries from which data is retrieved. LDAP servers should take care to protect the data they maintain from unauthorized access.
此备忘录描述LDAP搜索筛选器的字符串表示形式。虽然表示本身没有已知的安全含义，但LDAP搜索筛选器有。LDAP服务器对它们进行解释，以选择从中检索数据的条目。LDAP服务器应注意保护其维护的数据，防止未经授权的访问。
Please refer to the Security Considerations sections of [RFC4511] and [RFC4513] for more information.
有关更多信息，请参阅[RFC4511]和[RFC4513]的安全注意事项部分。
[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月。
[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月。
[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
[RFC4517]Legg，S.，Ed.，“轻量级目录访问协议（LDAP）：语法和匹配规则”，RFC4517，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."
[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."
[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月。
[X.690] Specification of ASN.1 encoding rules: Basic, Canonical, and Distinguished Encoding Rules, ITU-T Recommendation X.690, 1994.
[X.690]ASN.1编码规则规范：基本、规范和区分编码规则，ITU-T建议X.690，1994。
This document replaces RFC 2254 by Tim Howes. RFC 2254 was a product of the IETF ASID Working Group.
本文件由Tim Howes取代RFC 2254。RFC 2254是IETF ASID工作组的产品。
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.
本修订规范中包含的变更基于作者之间的讨论、LDAP（v3）修订工作组（ldapbis）内的讨论以及其他IETF工作组内的讨论。我们衷心感谢这些工作组中的个人所作的贡献。
Appendix A: Changes Since RFC 2254
附录A：自RFC 2254以来的变化
Replaced [ISO 10646] reference with [Unicode].
将[ISO 10646]参考替换为[Unicode]。
The following technical changes were made to the contents of the "String Search Filter Definition" section:
对“字符串搜索筛选器定义”部分的内容进行了以下技术更改：
Added statement that the string representation is a string of UTF-8- encoded Unicode characters.
添加了以下语句：字符串表示是UTF-8编码的Unicode字符字符串。
Revised all of the ABNF to use common productions from [RFC4512].
修改了所有ABNF以使用[RFC4512]中的通用产品。
Replaced the "value" rule with a new "assertionvalue" rule within the "simple", "extensible", and "substring" ("initial", "any", and "final") rules. This matches a change made in [RFC4517].
在“简单”、“可扩展”和“子字符串”（“初始”、“任意”和“最终”）规则中，将“值”规则替换为新的“断言值”规则。这与[RFC4517]中所做的更改相匹配。
Added "(" and ")" around the components of the <extensible> subproductions for clarity.
为清晰起见，在<extensible>子产品的组件周围添加了“（“and”）”。
Revised the "attr", "matchingrule", and "assertionvalue" ABNF to more precisely reference productions from the [RFC4512] and [RFC4511] documents.
修改了“attr”、“matchingrule”和“assertionvalue”ABNF，以更精确地引用[RFC4512]和[RFC4511]文档中的产品。
"String Search Filter Definition" section: replaced "greater" and "less" with "greaterorequal" and "lessorequal" to avoid confusion.
“字符串搜索筛选器定义”部分：将“较大”和“较小”替换为“较大或相等”和“较小”以避免混淆。
Introduced the "valueencoding" and associated "normal" and "escaped" rules to reduce the dependence on descriptive text. The "normal" production restricts filter strings to valid UTF-8 sequences.
引入了“valueencoding”和相关的“正常”和“转义”规则，以减少对描述性文本的依赖。“正常”生产将筛选器字符串限制为有效的UTF-8序列。
Added a statement about expected behavior in light of RFC 2254's lack of a clear definition of "string representation."
针对RFC2254缺少“字符串表示”的明确定义，添加了一个关于预期行为的声明
Changed document title to include "LDAP:" prefix.
将文档标题更改为包含“LDAP:”前缀。
IESG Note: removed note about lack of satisfactory mandatory authentication mechanisms.
IESG注释：删除了关于缺少令人满意的强制身份验证机制的注释。
Header and "Authors' Addresses" sections: added Mark Smith as the document editor and updated affiliation and contact information.
标题和“作者地址”部分：添加Mark Smith作为文档编辑器，并更新从属关系和联系信息。
"Table of Contents" and "Intellectual Property" sections: added.
“目录”和“知识产权”部分：增加。
Copyright: updated per latest IETF guidelines.
版权：根据最新IETF指南更新。
"Abstract" section: separated from introductory material.
“摘要”部分：与介绍性材料分开。
"Introduction" section: new section; separated from the Abstract. Updated second paragraph to indicate that RFC 2254 is replaced by this document (instead of RFC 1960). Added reference to the [RFC4510] document.
“导言”部分：新的部分；与抽象分开。更新第二段，表明RFC 2254由本文件取代（而非RFC 1960）。增加了对[RFC4510]文件的参考。
"LDAP Search Filter Definition" section: made corrections to the LDAP search filter ABNF so it matches that used in [RFC4511].
“LDAP搜索筛选器定义”部分：对LDAP搜索筛选器ABNF进行了更正，使其与[RFC4511]中使用的筛选器匹配。
Clarified the definition of 'value' (now 'assertionvalue') to take into account the fact that it is not precisely an AttributeAssertion from [RFC4511] Section 4.1.6 (special handling is required for some characters). Added a note that each octet of a character to be escaped is replaced by a backslash and two hex digits, which represent a single octet.
澄清了“值”的定义（现为“断言值”），以考虑到它并非[RFC4511]第4.1.6节中的AttributesSertion（某些字符需要特殊处理）。添加了一个注释，即要转义的字符的每个八位字节都将替换为反斜杠和两个十六进制数字，它们表示单个八位字节。
"Examples" section: added four additional examples: (seeAlso=), (cn:=Betty Rubble), (:1.2.3:=Wilma Flintstone), and (1.3.6.1.4.1.1466.0=\04\02\48\69). Replaced one occurrence of "a value" with "an assertion value". Corrected the description of this example: (sn:dn:2.4.6.8.10:=Barney Rubble). Replaced the numeric OID in the first extensible match example with "caseExactMatch" to demonstrate use of the descriptive form. Used "DN" (uppercase) in the last extensible match example to remind the reader to treat the <dnattrs> production as case insensitive. Reworded the description of the fourth escaping mechanism example to avoid making assumptions about byte order. Added text to the fifth escaping mechanism example to spell out what the non-ASCII characters are in Unicode terms.
“示例”部分：增加了四个示例：（参见另一个=），（cn:=贝蒂·瓦砾），（：1.2.3:=威尔玛·弗林斯通）和（1.3.6.1.4.1.1466.0=\04\02\48\69）。将一次出现的“值”替换为“断言值”。更正了此示例的描述：（sn:dn:2.4.6.8.10:=巴尼碎石）。将第一个可扩展匹配示例中的数字OID替换为“caseExactMatch”，以演示描述性表单的使用。在上一个可扩展匹配示例中使用了“DN”（大写），以提醒读者将<dnattrs>产品视为不区分大小写。重写了第四个转义机制示例的描述，以避免对字节顺序进行假设。在第五个转义机制示例中添加了文本，以说明Unicode术语中的非ASCII字符。
"Security Considerations" section: added references to [RFC4511] and [RFC4513].
“安全注意事项”部分：增加了对[RFC4511]和[RFC4513]的引用。
"Normative References" section: renamed from "References" per new RFC guidelines. Changed from [1] style to [RFC4511] style throughout the document. Added entries for [Unicode], [RFC2119], [RFC4513], [RFC4512], and [RFC4510] and updated the UTF-8 reference. Replaced RFC 822 reference with a reference to RFC 4234.
“规范性参考文件”部分：根据新的RFC指南从“参考文件”重命名。在整个文档中从[1]样式更改为[RFC4511]样式。增加了[Unicode]、[RFC2119]、[RFC4513]、[RFC4512]和[RFC4510]的条目，并更新了UTF-8参考。将RFC 822参考替换为RFC 4234参考。
"Informative References" section: (new section) moved [X.690] to this section. Added a reference to [RFC4516].
“参考资料”章节：（新章节）将[X.690]移至本章节。增加了对[RFC4516]的引用。
"Acknowledgements" section: added.
“确认”部分：已添加。
"Appendix A: Changes Since RFC 2254" section: added.
“附录A：自RFC 2254以来的变更”章节：增加。
Surrounded the names of all ABNF productions with "<" and ">" where they are used in descriptive text.
将所有ABNF产品的名称用“<”和“>”括起来，用于描述性文本。
Replaced all occurrences of "LDAPv3" with "LDAP."
将所有出现的“LDAPv3”替换为“LDAP”
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）提供。