[要約] RFC 6203は、IMAP4プロトコルにおけるファジー検索の拡張を定義しています。この拡張の目的は、メールボックス内のメッセージをより柔軟に検索することです。
Internet Engineering Task Force (IETF) T. Sirainen
Request for Comments: 6203 March 2011
Category: Standards Track
ISSN: 2070-1721
IMAP4 Extension for Fuzzy Search
ファジー検索用のIMAP4拡張
Abstract
概要
This document describes an IMAP protocol extension enabling a server to perform searches with inexact matching and assigning relevancy scores for matched messages.
このドキュメントでは、サーバーがマッチングされたメッセージの関連スコアを不正確に一致させ、割り当てるサーバーを実行できるIMAPプロトコル拡張機能について説明します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6203.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6203で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
When humans perform searches in IMAP clients, they typically want to see the most relevant search results first. IMAP servers are able to do this in the most efficient way when they're free to internally decide how searches should match messages. This document describes a new SEARCH=FUZZY extension that provides such functionality.
人間がIMAPクライアントで検索を行うとき、彼らは通常、最初に最も関連性の高い検索結果を見たいと思っています。IMAPサーバーは、検索がメッセージと一致する方法を内部的に決定できる場合、最も効率的な方法でこれを行うことができます。このドキュメントでは、そのような機能を提供する新しい検索=ファジー拡張機能について説明します。
In examples, "C:" indicates lines sent by a client that is connected to a server. "S:" indicates lines sent by the server to the client.
例では、「C：」は、サーバーに接続されているクライアントから送信された行を示します。「S：」は、サーバーからクライアントに送信された行を示します。
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 RFC 2119 [KEYWORDS].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [キーワード]に記載されているように解釈されます。
The FUZZY search key takes another search key as its argument. The server is allowed to perform all matching in an implementation-defined manner for this search key, including ignoring the active comparator as defined by [RFC5255]. Typically, this would be used to search for strings. For example:
ファジー検索キーは、その引数として別の検索キーを取ります。サーバーは、[RFC5255]で定義されているアクティブコンパレータを無視するなど、この検索キーに対して実装定義の方法ですべてのマッチングを実行することができます。通常、これは文字列の検索に使用されます。例えば：
C: A1 SEARCH FUZZY (SUBJECT "IMAP break")
S: * SEARCH 1 5 10
S: A1 OK Search completed.
Besides matching messages with a subject of "IMAP break", the above search may also match messages with subjects "broken IMAP", "IMAP is broken", or anything else the server decides that might be a good match.
メッセージを「IMAP Break」の件名と一致させることに加えて、上記の検索では、「IMAPの壊れた」、「IMAPは壊れている」、またはサーバーが決定する可能性のあるものとのメッセージと一致する場合があります。
This example does a fuzzy SUBJECT search, but a non-fuzzy FROM search:
この例はファジーなサブジェクト検索を行いますが、検索からはファジーではありません。
C: A2 SEARCH FUZZY SUBJECT work FROM user@example.com
S: * SEARCH 1 4
S: A2 OK Search completed.
How the server handles multiple separate FUZZY search keys is implementation-defined.
サーバーが複数の個別のファジー検索キーを処理する方法は、実装定義です。
Fuzzy search algorithms might change, or the results of the algorithms might be different from search to search, so that fuzzy searches with the same parameters might give different results for 1) the same user at different times, 2) different users (searches executed simultaneously), or 3) different users (searches executed at different times). For example, a fuzzy search might adapt to a user's search habits in an attempt to give more relevant results (in a "learning" manner). Such differences can also occur because of operational decisions, such as load balancing. Clients asking for "fuzzy" really are requesting search results in a not-necessarily-deterministic way and need to give the user appropriate warning about that.
ファジー検索アルゴリズムが変更される可能性があるか、アルゴリズムの結果が検索まで異なる場合があるため、同じパラメーターを使用したファジー検索は、1）同じユーザーが異なる時間、2）異なるユーザー（検索）に対して異なる結果をもたらす可能性があります。）、または3）異なるユーザー（異なる時間に実行される検索）。たとえば、ファジー検索は、より関連性の高い結果を（「学習」方法で）提供するために、ユーザーの検索習慣に適応する場合があります。このような違いは、負荷分散などの運用上の決定のためにも発生する可能性があります。「ファジー」を求めるクライアントは、実際には必要ではない決定的な方法で検索結果を要求しており、ユーザーにそれについて適切な警告を与える必要があります。
Servers SHOULD assign a search relevancy score for each matched message when the FUZZY search key is given. Relevancy scores are given in the range 1-100, where 100 is the highest relevancy. The relevancy scores SHOULD use the full 1-100 range, so that clients can show them to users in a meaningful way, e.g., as a percentage value.
サーバーは、ファジー検索キーが与えられたときに、一致する各メッセージの検索関連スコアを割り当てる必要があります。関連性スコアは、1〜100の範囲で与えられ、100が最も高い関連性です。関連性スコアは、1〜100の完全な範囲を使用して、クライアントが有意義な方法でユーザーに表示できるようにする必要があります。たとえば、パーセンテージ値として。
As the name already indicates, relevancy scores specify how relevant to the search the matched message is. It's not necessarily the same as how precisely the message matched. For example, a message whose subject fuzzily matches the search string might get a higher relevancy score than a message whose body had the exact string in the middle of a sentence. When multiple search keys are matched fuzzily, how the relevancy score is calculated is server-dependent.
名前がすでに示されているように、関連性スコアは、一致したメッセージの検索にどのように関連するかを指定します。メッセージがどれだけ正確に一致したかと必ずしも同じではありません。たとえば、被写体が検索文字列にファジーに一致するメッセージは、文の中央に本文が正確な文字列を持っているメッセージよりも高い関連スコアを取得する可能性があります。複数の検索キーがファジーに一致する場合、関連性スコアの計算方法はサーバー依存です。
If the server also advertises the ESEARCH capability as defined by [ESEARCH], the relevancy scores can be retrieved using the new RELEVANCY return option for SEARCH:
サーバーが[esearch]で定義されているESEarch機能も宣伝する場合、検索の新しい関連性リターンオプションを使用して関連性スコアを取得できます。
C: B1 SEARCH RETURN (RELEVANCY ALL) FUZZY TEXT "Helo"
S: * ESEARCH (TAG "B1") ALL 1,5,10 RELEVANCY (4 99 42)
S: B1 OK Search completed.
In the example above, the server would treat "hello", "help", and other similar strings as fuzzily matching the misspelled "Helo".
上記の例では、サーバーは「Hello」、「help」、およびその他の同様の文字列を、スペルミスの「Helo」をファジーに一致させるように扱います。
The RELEVANCY return option MUST NOT be used unless a FUZZY search key is also given. Note that SEARCH results aren't sorted by relevancy; SORT is needed for that.
ファジー検索キーも与えられない限り、関連する返品オプションを使用しないでください。検索結果は関連性によってソートされていないことに注意してください。そのためにソートが必要です。
Fuzzy matching is not limited to just string matching. All search keys SHOULD be matched fuzzily, although exactly what that means for different search keys is left for server implementations to decide -- including deciding that fuzzy matching is meaningless for a particular key, and falling back to exact matching. Some suggestions are given below.
ファジーマッチングは、ストリングマッチングだけに限定されません。すべての検索キーはファジーに一致する必要がありますが、それが正確に異なる検索キーを意味することは、サーバーの実装が決定するために残されています。ファジーマッチングは特定のキーでは無意味であり、正確なマッチングに戻ることを決定します。いくつかの提案を以下に示します。
Dates: A typical example could be when a user wants to find a message "from Dave about a week ago". A client could perform this search using SEARCH FUZZY (FROM "Dave" SINCE 21-Jan-2009 BEFORE 24-Jan-2009). The server could return messages outside the specified date range, but the further away the message is, the lower the relevancy score.
日付：典型的な例は、ユーザーが「約1週間前にデイブから」メッセージを見つけたいときです。クライアントは、検索ファジーを使用してこの検索を実行できます（2009年1月24日以前から2009年1月24日以降「デイブ」から）。サーバーは指定された日付範囲外にメッセージを返すことができますが、メッセージがさらに離れるほど、関連性スコアが低くなります。
Sizes: These should be handled similarly to dates. If a user wants to search for "about 1 MB attachments", the client could do this by sending SEARCH FUZZY (LARGER 900000 SMALLER 1100000). Again, the further away the message size is from the specified range, the lower the relevancy score.
サイズ：これらは日付と同様に処理する必要があります。ユーザーが「約1 MBの添付ファイル」を検索したい場合、クライアントは検索ファジーを送信することでこれを行うことができます（より大きな900000小さい1100000）。繰り返しますが、メッセージサイズが指定された範囲から遠く離れているほど、関連性スコアが低くなります。
Flags: If other search criteria match, the server could return messages that don't have the specified flags set, but with lower relevancy scores. SEARCH SUBJECT "xyz" FUZZY ANSWERED, for example, might be useful if the user thinks the message he is looking for has the ANSWERED flag set, but he isn't sure.
フラグ：他の検索条件が一致する場合、サーバーは指定されたフラグが設定されていないが、関連性スコアが低いメッセージを返すことができます。たとえば、「XYZ」Fuzzyが回答した「XYZ」の検索は、ユーザーが探しているメッセージに答えられたフラグセットがあると考えている場合に役立つかもしれませんが、彼は確信していません。
Unique Identifiers (UIDs), sequences, modification sequences: These are examples of keys for which exact matching probably makes sense. Alternatively, a server might choose, for instance, to expand a UID range by 5% on each side.
一意の識別子（UID）、シーケンス、変更シーケンス：これらは、正確な一致がおそらく理にかなっているキーの例です。あるいは、たとえば、サーバーが各側でUID範囲を5％拡張することを選択する場合があります。
If the server also advertises the SORT capability as defined by [SORT], the results can be sorted by the new RELEVANCY sort criteria:
サーバーが[sort]で定義されているソート機能も宣伝する場合、結果は新しい関連性のソート基準でソートできます。
C: C1 SORT (RELEVANCY) UTF-8 FUZZY SUBJECT "Helo"
S: * SORT 5 10 1
S: C1 OK Sort completed.
The message with the highest score is returned first. As with the RELEVANCY return option, RELEVANCY sort criteria MUST NOT be used unless a FUZZY search key is also given.
最高のスコアのメッセージが最初に返されます。関連するリターンオプションと同様に、ファジー検索キーも与えられない限り、関連性ソート基準を使用しないでください。
If the server also advertises the ESORT capability as defined by [CONTEXT], the relevancy scores can be retrieved using the new RELEVANCY return option for SORT:
サーバーが[コンテキスト]で定義されているESORT機能を宣伝する場合、並べ替えの新しい関連性リターンオプションを使用して関連性スコアを取得できます。
C: C2 SORT RETURN (RELEVANCY ALL) (RELEVANCY) UTF-8 FUZZY TEXT
"Helo"
S: * ESEARCH (TAG "C2") ALL 5,10,1 RELEVANCY (99 42 4)
S: C2 OK Sort completed.
Furthermore, if the server advertises the CONTEXT=SORT (or CONTEXT=SEARCH) capability, then the client can limit the number of returned messages to a SORT (or a SEARCH) by using the PARTIAL return option. For example, this returns the 10 most relevant messages:
さらに、サーバーがコンテキスト=ソート（またはコンテキスト=検索）機能を宣伝する場合、クライアントは、部分的な戻りオプションを使用して、返されたメッセージの数をソート（または検索）に制限できます。たとえば、これにより、最も関連性の高い10のメッセージが返されます。
C: C3 SORT RETURN (PARTIAL 1:10) (RELEVANCY) UTF-8 FUZZY TEXT
"World"
S: * ESEARCH (TAG "C3") PARTIAL (1:10 42,9,34,13,15,4,2,7,23,82)
S: C3 OK Sort completed.
The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in [ABNF]. It includes definitions from [RFC3501], [IMAP-ABNF], and [SORT].
次の構文仕様では、[ABNF]で説明されているように、拡張されたバックナウル形式（BNF）を使用します。[RFC3501]、[IMAP-ABNF]、および[sort]の定義が含まれます。
capability =/ "SEARCH=FUZZY"
score = 1*3DIGIT
;; (1 <= n <= 100)
score-list = "(" [score *(SP score)] ")"
search-key =/ "FUZZY" SP search-key
search-return-data =/ "RELEVANCY" SP score-list
;; Conforms to <search-return-data>, from [IMAP-ABNF]
search-return-opt =/ "RELEVANCY"
;; Conforms to <search-return-opt>, from [IMAP-ABNF]
sort-key =/ "RELEVANCY"
Implementation of this extension might enable denial-of-service attacks against server resources. Servers MAY limit the resources that a single search (or a single user) may use. Additionally, implementors should be aware of the following: Fuzzy search engines are often complex with non-obvious disk space, memory, and/or CPU usage patterns. Server implementors should at least test the fuzzy-search behavior with large messages that contain very long words and/or unique random strings. Also, very long search keys might cause excessive memory or CPU usage.
この拡張機能の実装により、サーバーリソースに対するサービス拒否攻撃が可能になる場合があります。サーバーは、単一の検索（または単一のユーザー）が使用できるリソースを制限する場合があります。さらに、実装者は次のことを認識する必要があります。ファジー検索エンジンは、多くの場合、非自明なディスクスペース、メモリ、および/またはCPU使用パターンと複雑です。サーバーの実装者は、非常に長い単語やユニークなランダム文字列を含む大きなメッセージで、少なくともファジー検索動作をテストする必要があります。また、非常に長い検索キーは、過度のメモリまたはCPUの使用を引き起こす可能性があります。
Invalid input may also be problematic. For example, if the search engine takes a UTF-8 stream as input, it might fail more or less badly when illegal UTF-8 sequences are fed to it from a message whose character set was claimed to be UTF-8. This could be avoided by validating all the input and, for example, replacing illegal UTF-8 sequences with the Unicode replacement character (U+FFFD).
無効な入力も問題になる可能性があります。たとえば、検索エンジンがUTF-8ストリームを入力として取得する場合、違法なUTF-8シーケンスが、キャラクターセットがUTF-8であると主張されているメッセージからそれに供給されると、多かれ少なかれ悪化する可能性があります。これは、すべての入力を検証し、たとえば、違法なUTF-8シーケンスをUnicode置換文字（U FFFD）に置き換えることで回避できます。
Search relevancy rankings might be susceptible to "poisoning" by smart attackers using certain keywords or hidden markup (e.g., HTML) in their messages to boost the rankings. This can't be fully prevented by servers, so clients should prepare for it by at least allowing users to see all the search results, rather than hiding results below a certain score.
関連するランキングの検索は、特定のキーワードまたは非表示のマークアップ（HTMLなど）を使用して、ランキングを強化するために、スマート攻撃者による「中毒」の影響を受けやすい場合があります。これはサーバーによって完全に防止されることはできないため、クライアントは、特定のスコアの下に結果を隠すのではなく、少なくともユーザーがすべての検索結果を見ることができるようにすることにより、それを準備する必要があります。
IMAP4 capabilities are registered by publishing a standards track or IESG-approved experimental RFC. The "Internet Message Access Protocol (IMAP) 4 Capabilities Registry" is available from http://www.iana.org/.
IMAP4機能は、標準トラックまたはIESGが承認した実験RFCを公開することにより登録されます。「インターネットメッセージアクセスプロトコル（IMAP）4機能レジストリ」は、http：//www.iana.org/から入手できます。
This document defines the SEARCH=FUZZY IMAP capability. IANA has added it to the registry.
このドキュメントは、検索=ファジーIMAP機能を定義します。IANAはそれをレジストリに追加しました。
Alexey Melnikov, Zoltan Ordogh, Barry Leiba, Cyrus Daboo, and Dave Cridland have helped with this document.
Alexey Melnikov、Zoltan Ordogh、Barry Leiba、Cyrus Daboo、およびDave Cridlandがこの文書を手伝ってきました。
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[ABNF] Crocker、D.、ed。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、STD 68、RFC 5234、2008年1月。
[CONTEXT] Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267, July 2008.
[コンテキスト] Cridland、D。およびC. King、「IMAP4のコンテキスト」、RFC 5267、2008年7月。
[ESEARCH] Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned", RFC 4731, November 2006.
[Esearch] Melnikov、A。、およびD. Cridland、「IMAP4拡張は、どのような種類の情報が返されるかを制御するための検索コマンドへ」、RFC 4731、2006年11月。
[IMAP-ABNF] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006.
[IMAP-ABNF] Melnikov、A。およびC. Daboo、「IMAP4 ABNFへの拡張を収集した」、RFC 4466、2006年4月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501] CRISPIN、M。、「インターネットメッセージアクセスプロトコル - バージョン4REV1」、RFC 3501、2003年3月。
[RFC5255] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet Message Access Protocol Internationalization", RFC 5255, June 2008.
[RFC5255] Newman、C.、Gulbrandsen、A。、およびA. Melnikov、「インターネットメッセージアクセスプロトコル国際化」、RFC 5255、2008年6月。
[SORT] Crispin, M. and K. Murchison, "Internet Message Access Protocol - SORT and THREAD Extensions", RFC 5256, June 2008.
[sort] Crispin、M。and K. Murchison、「インターネットメッセージアクセスプロトコル - ソートおよびスレッド拡張機能」、RFC 5256、2008年6月。
Author's Address
著者の連絡先
Timo Sirainen
ティモ・シランエン
EMail: tss@iki.fi