RFC 6203 - IMAP4 Extension for Fuzzy Search 日本語訳

URL : https://tools.ietf.org/html/rfc6203
タイトル : 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

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.

このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6203で取得することができます。

著作権表示

著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。

1. Introduction

1. はじめに

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サーバは、彼らが内部的に検索がメッセージを一致させるべきかを決定する自由だときに最も効率的な方法でこれを行うことができます。この文書では、このような機能を提供する新しいSEARCH = FUZZY拡張について説明します。

2. Conventions Used in This Document

この文書で使用される2.表記

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].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [KEYWORDS]で説明されるように解釈されます。

3. The FUZZY Search Key

3.あいまい検索キー

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:

FUZZY検索キーは、その引数として別の検索キーを取ります。サーバは、[RFC5255]で定義されるような活性比較を無視するなど、この検索キーに実装定義の方法ですべてのマッチングを実行することができます。通常、これは文字列を検索するために使用されます。例えば：

C: A1 SEARCH FUZZY (SUBJECT "IMAP break") S: * SEARCH 1 5 10 S: A1 OK Search completed.

C：A1 SEARCH FUZZY（SUBJECT "IMAPブレイク"）S：* SEARCH 1 5 10 S：A1 OK検索が完了しました。

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ブレイク」の件名とメッセージをマッチングに加えて、上記の検索では、サーバはそれは良い試合になるかもしれないことを決定科目「壊れた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.

C：user@example.com SからA2検索FUZZY SUBJECT作業：* SEARCH 1 4 S：A2 OK検索が完了しました。

How the server handles multiple separate FUZZY search keys is implementation-defined.

サーバーは、複数の独立したFUZZY検索キーを処理する方法実装定義です。

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）異なるユーザ（異なる時間に実行される検索）。たとえば、ファジー検索は、（「学習」のように）、より関連性の高い結果を与えるための試みで、ユーザーの検索習慣に適応することがあります。このような違いもあるため、このような負荷分散などの運用の意思決定の発生する可能性があります。「ファジー」を求めるクライアントが本当に-必ずしも決定的ではない方法で、検索結果を要求し、ユーザーにそのことについて適切な警告を与える必要があります。

4. Relevancy Scores for Search Results

検索結果4.関連性スコア

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.

FUZZY検索キーが与えられたとき、サーバは、一致した各メッセージの検索関連性スコアを割り当てる必要があります。関連性スコアは、100が最も高い関連性範囲1-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.

名前がすでに示しているように、関連性スコアは、一致したメッセージがどのように検索に関連する指定します。それは必ずしもメッセージがマッチしたか正確に同じではありません。例えば、その対象fuzzily検索文字列に一致するメッセージは、身体の文章の途中で正確な文字列を持っていたメッセージよりも高い関連性スコアを取得する可能性があります。複数の検索キーがfuzzily一致している場合は、関連性スコアを計算する方法をサーバーに依存しています。

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.

C：B1の検索RETURN（関連性ALL）FUZZY TEXT "HELOコマンド" S：* ESEARCH（TAG "B1"）ALL 1,5,10関連性（4 99 42）S：完成B1 OK検索。

In the example above, the server would treat "hello", "help", and other similar strings as fuzzily matching the misspelled "Helo".

上記の例では、サーバーは、「こんにちは」、「ヘルプ」を扱っていました、そしてfuzzilyスペルミス「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検索キーも指定されない限り、関連性の復帰オプションを使用してはいけません。検索結果は関連性によってソートされていないことに注意してください。 SORTそのために必要とされています。

5. Fuzzy Matching with Non-String Search Keys

非文字列検索キー5.ファジー・マッチング

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.

ファジーマッチングは、単に文字列マッチングに限定されるものではありません。ファジーマッチングは、特定のキーのために無意味であると判断し、正確なマッチングにフォールバックを含む - それは、サーバーの実装が決定するために残されている別の検索キーの意味を正確に何が、すべての検索キーは、fuzzily一致させる必要があります。いくつかの提案は以下の通りです。

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.

日付：ユーザが「一週間ほど前にデーブから」メッセージを見つけたいときの典型的な例がある可能性があります。クライアントは、（24-JAN-2009前の21-Jan-2009 SINCE "デーブ" FROM）あいまい検索を使用して、この検索を行うことができます。サーバーは、指定した日付の範囲外のメッセージを返しますが、さらに離れたメッセージは、下の関連性スコアである可能性があります。

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の添付ファイル」を検索したい場合は、クライアントは（1100000 SMALLER 900000以上）のあいまい検索を送信することにより、これを行うことができます。再び、さらに離れたメッセージのサイズが指定された範囲、より低い関連性スコアです。

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、例えば、役に立つかもしれません。

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の）、シーケンス、修正シーケンス：これらは、正確なマッチングはおそらく理にかなっているキーの例です。代替的に、サーバは、それぞれの側に5％UID範囲を拡大するために、例えば、選択したかもしれません。

6. Extensions to SORT and SEARCH

6.拡張機能は、ソートおよび検索します

If the server also advertises the SORT capability as defined by [SORT], the results can be sorted by the new RELEVANCY sort criteria:

[SORT]で定義されているサーバもSORT機能をアドバタイズした場合、その結果は、新たな関連性ソート基準によってソートすることができます。

C: C1 SORT (RELEVANCY) UTF-8 FUZZY SUBJECT "Helo" S: * SORT 5 10 1 S: C1 OK Sort completed.

C：C1 SORT（関連性）UTF-8 FUZZY SUBJECT "HELOコマンド" S：* SORT 5 10 1 S：ソート完了C1 OK。

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.

スコアが最も高いメッセージが最初に返されます。 FUZZY検索キーも指定されない限り、関連性リターンオプションと同様に、関連性の分類基準を使用してはいけません。

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:

[CONTEXT]で定義されているサーバもESORT機能をアドバタイズした場合は、関連性スコアは、SORTのための新たな関連性リターン・オプションを使用して取得することができます。

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.

C：C2ソートRETURN（関連性ALL）（関連性）UTF-8 FUZZY TEXT "HELOコマンド" S * ESEARCH（TAG "C2"）は、すべての5,10,1関連性（99 42 4）S：ソート完了C2 OK。

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:

サーバがCONTEXT = SORT（またはCONTEXT = SEARCH）機能をアドバタイズした場合さらに、クライアントはPARTIALリターン・オプションを使用して、SORT（またはSEARCH）に返されたメッセージの数を制限することができます。たとえば、これは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.

C：C3のSORTのRETURN（PARTIAL 1:10）（関連性）UTF-8 FUZZY TEXT "世界" S：* ESEARCH（TAG "C3"）PARTIAL（1:10 42,9,34,13,15,4,2 、7,23,82）S：C3 OKソート完成。

7. Formal Syntax

7.正式な構文

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"

機能= / "SEARCH = FUZZY"

score = 1*3DIGIT ;; (1 <= n <= 100)

スコア= 1 * 3DIGIT ;; （1 <= N <= 100）

score-list = "(" [score *(SP score)] ")"

スコアリスト= "（" [スコア*（SPスコア）] "）"

search-key =/ "FUZZY" SP search-key

検索キー= /「FUZZY」SP検索キー

search-return-data =/ "RELEVANCY" SP score-list ;; Conforms to <search-return-data>, from [IMAP-ABNF]

検索リターンデータ= /「関連性」SPスコアリスト;; [IMAP-ABNF]から、<検索・リターン・データ>に準拠

search-return-opt =/ "RELEVANCY" ;; Conforms to <search-return-opt>, from [IMAP-ABNF]

検索リターン-OPT = / "関連性" ;; [IMAP-ABNF]から、<検索リターン-OPT>に準拠

sort-key =/ "RELEVANCY"

ソート・キー= /「関連性」

8. Security Considerations

8.セキュリティの考慮事項

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.

この拡張機能の実装は、サーバーのリソースに対するサービス拒否攻撃を可能にするかもしれません。サーバーは、単一の検索（または1人のユーザーが）を使用することができ、リソースを制限することがあります。また、実装者は、次の点に注意してください：ファジー検索エンジンは、多くの場合、非自明なディスク容量、メモリ、および/または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であることが主張されたメッセージからそれに供給されたときに失敗することがあります。これは、すべての入力を検証し、例えば、Unicodeの置換文字（U + FFFD）で違法UTF-8配列を置換することによって回避することができます。

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）を使用して、スマート攻撃者により「中毒」の影響を受けやすいかもしれません。クライアントは、少なくともユーザーが、むしろ特定のスコア以下の結果を隠すよりも、すべての検索結果を表示できるようにすることで、それのために準備しなければならないので、これは完全には、サーバによって防止することができません。

9. IANA Considerations

9. IANAの考慮事項

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機能Registryは」http://www.iana.org/から入手可能です。

This document defines the SEARCH=FUZZY IMAP capability. IANA has added it to the registry.

この文書では、SEARCH = FUZZY IMAP機能を定義します。 IANAは、レジストリに追加しました。

10. Acknowledgements

10.謝辞

Alexey Melnikov, Zoltan Ordogh, Barry Leiba, Cyrus Daboo, and Dave Cridland have helped with this document.

アレクセイ・メルニコフ、ゾルタンOrdogh、バリー・レイバ、サイラスDaboo、とDave Cridlandは、この文書に役立っています。

11. Normative References

11.引用規格

[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

[ABNF]クロッカー、D.、エド。そして、P. Overell、 "構文仕様のための増大しているBNF：ABNF"、STD 68、RFC 5234、2008年1月。

[CONTEXT] Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267, July 2008.

[CONTEXT] Cridland、D.およびC.王、 "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]メルニコフ、A.とD. Cridland、2006年11月、RFC 4731「IMAP4拡張は、情報の種類が返されるどのような制御するためのコマンドを検索するために」。

[IMAP-ABNF] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006.

[IMAP-ABNF]メルニコフ、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.

[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.

[RFC3501]のCrispin、M.、 "インターネットメッセージアクセスプロトコル - VERSION 4rev1"、RFC 3501、2003年3月。

[RFC5255] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet Message Access Protocol Internationalization", RFC 5255, June 2008.

[RFC5255]ニューマン、C.、Gulbrandsenの、A.、およびA.メルニコフ、 "インターネットメッセージアクセスプロトコル国際化"、RFC 5255、2008年6月。

[SORT] Crispin, M. and K. Murchison, "Internet Message Access Protocol - SORT and THREAD Extensions", RFC 5256, June 2008.

[SORT]クリスピン、M.とK.マーチソン、 "インターネットメッセージアクセスプロトコル - SORTとTHREAD拡張機能"、RFC 5256、2008年6月。

Author's Address

著者のアドレス

Timo Sirainen

ティモ・シレーヌン

EMail: tss@iki.fi

メールアドレス：tss@iki.fi