[要約] RFC 4515は、LDAPの検索フィルタの文字列表現に関する仕様です。このRFCの目的は、LDAPクライアントとサーバー間で検索フィルタを効果的に交換するための標準化を提供することです。
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
LightWeight Directory Access Protocol（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).
Copyright（c）The Internet Society（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 URL（RFC 4516）および他のアプリケーションでの使用に適したLDAP検索フィルターの人間が読み取る文字列表現を定義します。
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
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.
LightWeight Directory Access Protocol（LDAP）[RFC4510]は、LDAPサーバーに送信された検索フィルターのネットワーク表現を定義します。一部のアプリケーションは、これらの検索フィルターを人間が読みやすい形式で表現する共通の方法を持つことが有用であると思われる場合があります。LDAP URLS [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に取って代わります。RFC2254の変更は、付録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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14 [RFC2119]に記載されているように解釈される。
An LDAP search filter is defined in Section 4.5.1 of [RFC4511] as follows:
LDAP検索フィルターは、[RFC4511]のセクション4.5.1で次のように定義されています。
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 } }
AttributeValueAssertion ::= SEQUENCE {
attributeDesc AttributeDescription,
assertionValue AssertionValue }
MatchingRuleAssertion ::= SEQUENCE {
matchingRule [1] MatchingRuleId OPTIONAL,
type [2] AttributeDescription OPTIONAL,
matchValue [3] AssertionValue,
dnAttributes [4] BOOLEAN DEFAULT FALSE }
AttributeDescription ::= LDAPString
-- Constrained to <attributedescription>
-- [RFC4512]
AttributeValue ::= OCTET STRING
MatchingRuleId ::= LDAPString
AssertionValue ::= OCTET STRING
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]で定義されているように、属性が説明したものは、[RFC4512]で説明されている属性説明の文字列表現です。属性valueおよびassertionValueのオクテット文字列には、[rfc4517]で形式が定義されています。[RFC4511]で説明されている単純化を伴う[X.690]で定義された基本エンコードルール（BER）を使用して、ネットワーク上の伝送用にフィルターがエンコードされています。
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検索フィルターの文字列表現は、[RFC4234]で定義されているABNF表記に従って、次の文法によって定義されるUTF-8 [RFC3629]エンコードされたUnicode文字[Unicode]の文字列です。ここで定義されていないプロダクションは、特に明記しない限り、[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
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.
<valueConding>ルールは、フィルター文字列全体が有効なUTF-8文字列であることを保証し、ASCII文字「*」（ASCII 0x2a）を表すオクテットを提供します。）、 "\"（ASCII 0x5C）、およびNUL（ASCII 0x00）は、バックスラッシュ「\」（ASCII 0x5C）として表され、その後、エンコードされたオクテットの値を表す2つの16進数桁が続きます。
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で表現できるフィルターをヌル終端の文字列として表現できるようにします。<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文字データを含むアサーション値の場合、逃げるキャラクターの各オクテットは、バックスラッシュと2ヘクスの数字に置き換えられ、文字のコードに単一のオクテットを形成します。たとえば、「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>ルールで示されているように、実装は、検索フィルターの文字列表現を生成するときに有効なUTF-8エンコーディングシーケンスの一部ではない0x7Fを超えるすべてのオクテットをエスケートする必要があります。実装は、有効なUTF-8文字列ではない入力文字列として受け入れる必要があります。これは、RFC 2254が「文字列表現」という用語を明確に定義しなかったためです（特に、LDAP検索フィルターの文字列表現がUTF-8エンコードされたユニコード文字の文字列であることを言及していませんでした）。
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=)
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)
The first example shows use of the matching rule "caseExactMatch."
最初の例は、一致するルール「CaseexActMatch」の使用を示しています。
The second example demonstrates use of a MatchingRuleAssertion form without a matchingRule.
2番目の例は、マッチングルールなしで一致する誤症の使用を使用することを示しています。
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").
3番目の例は、「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.
4番目の例は、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).
5番目の例は、指定された一致するルールをサポートする任意の属性に適用する必要があるフィルターです（<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.
6番目の最後の例は、与えられた一致するルールをサポートする任意の属性に適用する必要があるフィルターでもあります。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)
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.
最初の例は、括弧文字を表すための脱出メカニズムの使用を示しています。2番目は、アサーション値で「*」を表現する方法を示しており、それがサブストリングインジケーターとして解釈されるのを防ぎます。3番目は、バックスラッシュのキャラクターの逃亡を示しています。
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.
4番目の例は、nul文字を含む任意のデータを表すために逃げるメカニズムの使用を示す、4オクテット値00 00 00 00 00 00 04（16進体）を検索するフィルターを示しています。
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).
5番目の例は、さまざまな非ASCII UTF-8文字を表すための脱出メカニズムの使用を示しています。具体的には、この例の<AssertionValue>部分には5文字があります。ラテン語の大文字L（U 004C）、ラテンの小文字U（U 0075）、ラテンの小文字C with Caron（U 010D）、ラテン語の小文字i（U 0069）、およびラテン語の小文字Cが急性（U 0107）。
The sixth and final example demonstrates assertion of a BER-encoded value.
6番目の最後の例は、ベルコードされた値のアサーションを示しています。
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。、「Lightweight Directory Access Protocol（LDAP）：技術仕様ロードマップ」、RFC 4510、2006年6月。
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511] Sermersheim、J.、ed。、「Lightweight Directory Access Protocol（LDAP）：The Protocol」、RFC 4511、2006年6月。
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006.
[RFC4512] Zeilenga、K。、「Lightweight Directory Access Protocol（LDAP）：ディレクトリ情報モデル」、RFC 4512、2006年6月。
[RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006.
[RFC4513] Harrison、R.、ed。、「Lightweight Directory Access Protocol（LDAP）：認証方法とセキュリティメカニズム」、RFC 4513、2006年6月。
[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
[RFC4517] Legg、S.、ed。、「Lightweight Directory Access Protocol（LDAP）：構文と一致するルール」、RFC 4517、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] Unicode Consortium、「Unicode Standard、バージョン3.2.0」は、「Unicode Standard、バージョン3.0」（Reading、MA、Addison-Wesley、2000。ISBN0-201-61633-5）で定義されています。「Unicode Standard Annex＃27：Unicode 3.1」（http://www.unicode.org/reports/tr27/）および「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]スミス、M。、編およびT. Howes、「Lightweight Directory Access Protocol（LDAP）：ユニフォームリソースロケーター」、RFC 4516、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.
このドキュメントは、RFC 2254をTim Howesに置き換えます。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].
[RFC4512]の一般的なプロダクションを使用するために、すべてのABNFを修正しました。
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.
[rfc4512]および[rfc4511]ドキュメントからのより正確に参照するために、「attr」、「matchingrule」、および「assertionvalue」abnfを修正しました。
"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.
記述テキストへの依存を減らすために、「バリューエンコード」および関連する「通常」および「逃げた」ルールを導入しました。「通常の」生産は、フィルター文字列を有効なUTF-8シーケンスに制限します。
Added a statement about expected behavior in light of RFC 2254's lack of a clear definition of "string representation."
RFC 2254が「文字列表現」の明確な定義の欠如に照らして、予想される行動に関する声明を追加しました。
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.
ヘッダーと「著者のアドレス」セクション：マークスミスをドキュメントエディターとして追加し、提携と連絡先情報を更新しました。
"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の代わりに）このドキュメントに置き換えられていることを示すために、2番目の段落を更新しました。[RFC4510]ドキュメントへの参照を追加しました。
"LDAP Search Filter Definition" section: made corrections to the LDAP search filter ABNF so it matches that used in [RFC4511].
「LDAP検索フィルター定義」セクション：[RFC4511]で使用されるものと一致するように、LDAP検索フィルターABNFを修正しました。
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.
「Value」の定義（現在「AssertionValue」）の定義を明確にして、[RFC4511]セクション4.1.6（一部の文字には特別な取り扱いが必要です）の原因ではないという事実を考慮に入れています。逃げるキャラクターの各オクテットは、単一のオクテットを表すバックスラッシュと2ヘクスの数字に置き換えられるというメモを追加しました。
"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.
「例」セクション：（seealso =）、（cn：= betty rubble）、（：1.2.3：= wilma flintstone）、および（1.3.6.1.4.1.1466.0 = \ 04 \ 02 \ 48\ 69）。「値」の1つの発生を「アサーション値」に置き換えました。この例の説明を修正しました：（SN：DN：2.4.6.8.10：=バーニーの瓦ble）。記述形式の使用を示すために、最初の拡張可能な一致例で「CaseexActmatch」に数値OIDを置き換えました。最後の拡張可能な一致例で「DN」（大文字）を使用して、<dnattrs>生産を症例の鈍感として扱うよう読者に思い出させます。バイト順序に関する仮定を避けるために、4番目の逃亡メカニズムの例の説明を言い換えました。5番目の脱出メカニズムの例にテキストを追加して、非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 4234への参照でRFC 822リファレンスを置き換えました。
"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
マーク・スミス、編集者パール・クレセント、LLC 447 Marlpool Dr. Saline、MI 48176 USA
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 N. Mathilda Ave. Sunnyvale、CA 94085 USA
Phone: +1 408 744-7509
EMail: howes@opsware.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。