RFC2254 日本語訳
2254 The String Representation of LDAP Search Filters. T. Howes. December 1997. (Format: TXT=13511 bytes) (Obsoletes RFC1960) (Obsoleted by RFC4510, RFC4515) (Updated by RFC3377) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Howes Request for Comments: 2254 Netscape Communications Corp. Category: Standards Track December 1997
コメントを求めるワーキンググループT.ハウズの要求をネットワークでつないでください: 2254年のネットスケープ・コミュニケーションズカテゴリ: 標準化過程1997年12月
The String Representation of LDAP Search Filters
LDAP検索フィルタのストリング表現
1. Status of this Memo
1. この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright(C)インターネット協会(1997)。 All rights reserved。
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:
RFC2026、セクション4.4.1に従って、この制限にもかかわらず、この仕様はProposed Standardとして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. LDAPv3ディレクトリサーバを質問しますが、アップデートしない能力を必要とする他のインターネット標準化過程プロトコルの前進と展開を遅らせるのを避けるために。
Howes Standards Track [Page 1] RFC 2254 String Representation of LDAP December 1997
ハウズStandardsは1997年12月にLDAPのRFC2254ストリング表現を追跡します[1ページ]。
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.
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での義務的な認証のためのProposed StandardがRFCとして承認されて、発行されるまで。
2. Abstract
2. 要約
The Lightweight Directory Access Protocol (LDAP) [1] 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. This document defines a human-readable string format for representing LDAP search filters.
ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)[1]はLDAPサーバに送られた検索フィルタのネットワーク表現を定義します。いくつかのアプリケーションが、人間読み込み可能なフォームにこれらの検索フィルタを表す一般的な方法を持っているのが役に立つのがわかるかもしれません。 このドキュメントは、LDAP検索フィルタを表すために人間読み込み可能な記号列の書式を定義します。
This document replaces RFC 1960, extending the string LDAP filter definition to include support for LDAP version 3 extended match filters, and including support for representing the full range of possible LDAP search filters.
このドキュメントはRFC1960を取り替えます、LDAPバージョン3の拡張マッチフィルタのサポートを含むようにストリングLDAPフィルター定義を広げていて、最大限の範囲の可能なLDAP検索フィルタを表すサポートを含んでいて。
Howes Standards Track [Page 2] RFC 2254 String Representation of LDAP December 1997
ハウズStandardsは1997年12月にLDAPのRFC2254ストリング表現を追跡します[2ページ]。
3. LDAP Search Filter Definition
3. LDAP検索フィルター定義
An LDAPv3 search filter is defined in Section 4.5.1 of [1] as follows:
LDAPv3検索フィルタは以下の[1]についてセクション4.5.1で定義されます:
Filter ::= CHOICE {
and [0] SET OF Filter,
or [1] SET OF 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
}
以下をフィルターにかけてください:= 選択そして、[2]フィルタ、AttributeValueAssertion(サブストリング[4]SubstringFilter、greaterOrEqual[5]AttributeValueAssertion、lessOrEqual[6]AttributeValueAssertion)が[7]AttributeDescription、approxMatch[8]AttributeValueAssertion、extensibleMatch[9]MatchingRuleAssertionを寄贈するequalityMatch[3]ではなく、[0]SET OF Filter、または[1]SET OF Filter
SubstringFilter ::= SEQUENCE {
type AttributeDescription,
SEQUENCE OF CHOICE {
initial [0] LDAPString,
any [1] LDAPString,
final [2] LDAPString
}
}
SubstringFilter:、:= 系列AttributeDescriptionをタイプしてください、そして、SEQUENCE OF CHOICEは[0]LDAPString、どんな[1]LDAPString、決勝[2]LDAPStringにも頭文字をつけます。
AttributeValueAssertion ::= SEQUENCE {
attributeDesc AttributeDescription,
attributeValue AttributeValue
}
AttributeValueAssertion:、:= 系列attributeDesc AttributeDescription、attributeValue AttributeValue
MatchingRuleAssertion ::= SEQUENCE {
matchingRule [1] MatchingRuleID OPTIONAL,
type [2] AttributeDescription OPTIONAL,
matchValue [3] AssertionValue,
dnAttributes [4] BOOLEAN DEFAULT FALSE
}
MatchingRuleAssertion:、:= 系列matchingRule[1]MatchingRuleID OPTIONAL、タイプ[2]AttributeDescription OPTIONAL、matchValue[3]AssertionValue、dnAttributes[4]BOOLEAN DEFAULT FALSE
AttributeDescription ::= LDAPString
AttributeDescription:、:= LDAPString
AttributeValue ::= OCTET STRING
AttributeValue:、:= 八重奏ストリング
MatchingRuleID ::= LDAPString
MatchingRuleID:、:= LDAPString
AssertionValue ::= OCTET STRING
AssertionValue:、:= 八重奏ストリング
LDAPString ::= OCTET STRING
LDAPString:、:= 八重奏ストリング
Howes Standards Track [Page 3] RFC 2254 String Representation of LDAP December 1997
ハウズStandardsは1997年12月にLDAPのRFC2254ストリング表現を追跡します[3ページ]。
where the LDAPString above is limited to the UTF-8 encoding of the ISO 10646 character set [4]. The AttributeDescription is a string representation of the attribute description and is defined in [1]. The AttributeValue and AssertionValue OCTET STRING have the form defined in [2]. The Filter is encoded for transmission over a network using the Basic Encoding Rules defined in [3], with simplifications described in [1].
上のLDAPStringがISO10646文字集合[4]のUTF-8コード化に制限されるところ。 AttributeDescriptionは属性記述のストリング表現であり、[1]で定義されます。 AttributeValueとAssertionValue OCTET STRINGには、[2]で定義された書式があります。 Filterはネットワークの上のトランスミッションのために[3]で定義されたBasic Encoding Rulesを使用することでコード化されます、簡素化が[1]で説明されている状態で。
4. String Search Filter Definition
4. ストリング検索フィルター定義
The string representation of an LDAP search filter is defined by the following grammar, following the ABNF notation defined in [5]. The filter format uses a prefix notation.
LDAP検索フィルタのストリング表現は以下の文法によって定義されます、[5]で定義されたABNF記法に従って。 フィルタ形式は前置表記法を使用します。
filter = "(" filtercomp ")"
filtercomp = and / or / not / item
and = "&" filterlist
or = "|" filterlist
not = "!" filter
filterlist = 1*filter
item = simple / present / substring / extensible
simple = attr filtertype value
filtertype = equal / approx / greater / less
equal = "="
approx = "~="
greater = ">="
less = "<="
extensible = attr [":dn"] [":" matchingrule] ":=" value
/ [":dn"] ":" matchingrule ":=" value
present = attr "=*"
substring = attr "=" [initial] any [final]
initial = value
any = "*" *(value "*")
final = value
attr = AttributeDescription from Section 4.1.5 of [1]
matchingrule = MatchingRuleId from Section 4.1.9 of [1]
value = AttributeValue from Section 4.1.6 of [1]
「/項目と=“&" filterlistか=ではなく、「("filtercomp")」というフィルタ=filtercomp=と/か/」|1*フィルタの=“!"フィルタfilterlistではなく、filterlist=品目=簡単であるか現在の/サブストリング/広げることができる簡単な=attr filtertype値filtertypeは同輩/と約等しいです。「「/よりすばらしいかそれほど等しくない=「=」は」 よりすばらしい=」 ~=「>広げることができる=」 より少ない=「<=」=attr[「: dn」][「:」 matchingrule]」と約等しいです:、」 値/[「: dn」]と等しい、」、:、」 "matchingrule": = 」 値の現在の=attr「=*」サブストリング=attrは.5セクション4.1[1] matchingrule=MatchingRuleIdからセクション4.1.9からどんな[最終的]の初期の=価値のどんな=「*」*(値の「*」)最終的な=値attrも=AttributeDescriptionとも値がセクション4.1.6からのAttributeValueと等しい[1]と「等しい」[初期の]。[1]
The attr, matchingrule, and value constructs are as described in the corresponding section of [1] given above.
attr、matchingrule、および値の構造物が上に与えられた[1]の該当箇所で説明されるようにあります。
Howes Standards Track [Page 4] RFC 2254 String Representation of LDAP December 1997
ハウズStandardsは1997年12月にLDAPのRFC2254ストリング表現を追跡します[4ページ]。
If a value should contain any of the following characters
値が以下のキャラクタのどれかを含んでいるなら
Character ASCII value
---------------------------
* 0x2a
( 0x28
) 0x29
\ 0x5c
NUL 0x00
キャラクターASCII価値--------------------------- * 0x2a(0×28)0×29円の0x5c NUL0x00
the character must be encoded as the backslash '\' character (ASCII 0x5c) followed by the two hexadecimal digits representing the ASCII value of the encoded character. The case of the two hexadecimal digits is not significant.
バックスラッシュ'\'キャラクタ(ASCII0x5c)がコード化されたキャラクタのASCII値を表す2つの16進数字で後をつけて、キャラクタをコード化しなければなりません。 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 characters besides the ones listed above may be escaped using this mechanism, for example, non-printing characters.
この簡単なエスケープメカニズムは、フィルタを分析するあいまいさを排除して、LDAPに表すことができるどんなフィルタもNULによって終えられたストリングとして表されるのを許容します。 上に記載されたもの以外に他のキャラクタ、このメカニズム、例えば非表示文字を使用することで逃げられるかもしれません。
For example, the filter checking whether the "cn" attribute contained a value with the character "*" anywhere in it would be represented as "(cn=*\2a*)".
例えば、"cn"属性がそれでどこでもキャラクタ「*」がある値を含んだか否かに関係なく、フィルタの照合は「(cn=*\2a*)」として表されるでしょう。
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.
上の文法のサブストリングと現在の創作の両方が「attr=*」構造物を生産できますが、この構造物が使用されることに注意してください存在フィルタを指示する。
5. Examples
5. 例
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*)
(cnはBabsジェンセン) ((ティム・cn=ハウズ))と等しいです((objectClassは人と等しいです)(| (snはジェンセンと等しいです)(バブスcn=J*)))。(*mich*のo=univ*)
The following examples illustrate the use of extensible matching.
以下の例は広げることができるマッチングの使用を例証します。
(cn:1.2.3.4.5:=Fred Flintstone)
(sn:dn:2.4.6.8.10:=Barney Rubble)
(o:dn:=Ace Industry)
(:dn:2.4.6.8.10:=Dino)
(: 1.2に.3をcnする、.4、.5:、=フレッドFlintstone)、(sn: dn: 2.4 .6 .8 .10: =バニー瓦礫) (o: dn:、=エース産業)(:、: 2.4に.6をdnする、.8、.10:、=ディーノ)
Howes Standards Track [Page 5] RFC 2254 String Representation of LDAP December 1997
ハウズStandardsは1997年12月にLDAPのRFC2254ストリング表現を追跡します[5ページ]。
The second example illustrates the use of the ":dn" notation to indicate that matching rule "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.
「2番目の例が使用を例証する、」、:、その合っている規則を示すために」 記法をdnする、「2.4 .6 .8 比較をするとき、0.1インチが使用されるべきであり、マッチを評価するときエントリーの分類名の属性がエントリーの一部であると考えられるべきである、」
The third example denotes an equality match, except that DN components should be considered part of the entry when doing the match.
3番目の例は平等マッチを指示します、マッチをするとき、DNの部品がエントリーの一部であると考えられるべきであるのを除いて。
The fourth example is a filter that should be applied to any attribute supporting the matching rule given (since the attr has been left off). Attributes supporting the matching rule contained in the DN should also be considered.
4番目の例は与えられた合っている規則をサポートするどんな属性にも適用されるべきであるフィルタ(attrがやめられたので)です。 また、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=%%BODY%%0%%BODY%%0%%BODY%%0%%BODY%%4)
(sn=Lu\c4\8di\c4\87)
(あなたのすべての挿入語句が29円必要とするo=Parens R Us\28for) (cn=*\2A*) (ファイル名=C: \5cMyFile) (容器00=円00円00円04円)(snはLu\c4\8di\c4と87円等しいです)
The first example shows the use of the escaping mechanism to represent parenthesis characters. The second shows how to represent a "*" in a value, preventing it from being interpreted as a substring indicator. The third illustrates the escaping of the backslash character.
最初の例は、挿入句キャラクタの代理をするためにエスケープメカニズムの使用を示しています。 秒は、それがサブストリングインディケータとして解釈されるのを防いで、どのように値における「*」を表すかを示します。 3番目はバックスラッシュキャラクタのエスケープを例証します。
The fourth example shows a filter searching for the four-byte value 0x00000004, illustrating the use of the escaping mechanism to represent arbitrary data, including NUL characters.
4番目の例は、フィルタが4バイトの値0x00000004を捜し求めるのを示します、任意のデータを表すためにエスケープメカニズムの使用を例証して、NULキャラクタを含んでいて。
The final example illustrates the use of the escaping mechanism to represent various non-ASCII UTF-8 characters.
最終的な例は、様々な非ASCII UTF-8キャラクタの代理をするためにエスケープメカニズムの使用を例証します。
6. Security Considerations
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サーバは、それらが不正アクセスから保守するデータを保護するために注意されるべきです。
Howes Standards Track [Page 6] RFC 2254 String Representation of LDAP December 1997
ハウズStandardsは1997年12月にLDAPのRFC2254ストリング表現を追跡します[6ページ]。
7. References
7. 参照
[1] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[1] ウォール、M.、ハウズ、T.、およびS.Kille、「ライトウェイト・ディレクトリ・アクセス・プロトコル(v3)」、RFC2251 1997年12月。
[2] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997.
[2] ウォール、M.、Coulbeck、A.、ハウズ、T.、およびS.Kille、「軽量のディレクトリアクセスは(v3)について議定書の中で述べます」。 「属性構文定義」、RFC2252、1997年12月。
[3] Specification of ASN.1 encoding rules: Basic, Canonical, and Distinguished Encoding Rules, ITU-T Recommendation X.690, 1994.
[3] ASN.1符号化規則の仕様: 基本的で、正準で、顕著なコード化はITU-T推薦X.690、1994に統治されます。
[4] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996.
[4]Yergeau、1996年10月のF.、「UTF-8、ユニコードとISO10646の変換形式」RFC2044。
[5] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[5] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。
8. Author's Address
8. 作者のアドレス
Tim Howes Netscape Communications Corp. 501 E. Middlefield Road Mountain View, CA 94043 USA
ティムハウズネットスケープ・コミュニケーションズ501E.Middlefield Roadカリフォルニア94043マウンテンビュー(米国)
Phone: +1 415 937-3419 EMail: howes@netscape.com
以下に電話をしてください。 +1 415 937-3419 メールしてください: howes@netscape.com
Howes Standards Track [Page 7] RFC 2254 String Representation of LDAP December 1997
ハウズStandardsは1997年12月にLDAPのRFC2254ストリング表現を追跡します[7ページ]。
9. Full Copyright Statement
9. 完全な著作権宣言文
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright(C)インターネット協会(1997)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Howes Standards Track [Page 8]
ハウズ標準化過程[8ページ]
一覧
スポンサーリンク
