RFC 7377 - IMAP4 Multimailbox SEARCH Extension 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7377
タイトル : RFC 7377 - IMAP4マルチメールボックス検索拡張機能
翻訳編集 : 自動生成

[要約] RFC 7377はIMAP4の拡張機能であり、複数のメールボックスでの検索を可能にする。目的は、効率的なメール検索を実現し、クライアントのパフォーマンスを向上させること。

Internet Engineering Task Force (IETF)                          B. Leiba
Request for Comments: 7377                           Huawei Technologies
Obsoletes: 6237                                              A. Melnikov
Updates: 4466                                              Isode Limited
Category: Standards Track                                   October 2014
ISSN: 2070-1721

IMAP4 Multimailbox SEARCH Extension

IMAP4マルチメールボックス検索拡張機能

Abstract

概要

The IMAP4 specification allows the searching of only the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT and SEARCH commands, waiting for each to complete before moving on to the next. This extension allows a client to search multiple mailboxes with one command, limiting the delays caused by many round trips and not requiring disruption of the currently selected mailbox. This extension also uses MAILBOX, UIDVALIDITY, and TAG fields in ESEARCH responses, allowing a client to pipeline the searches if it chooses. This document updates RFC 4466 and obsoletes RFC 6237.

IMAP4仕様では、選択したメールボックスのみを検索できます。ユーザーは複数のメールボックスを検索したい場合が多く、これをサポートしたいクライアントは一連のSELECTコマンドとSEARCHコマンドを発行し、それぞれが完了するのを待ってから次のコマンドに進む必要があります。この拡張機能により、クライアントは1つのコマンドで複数のメールボックスを検索できるため、多くの往復による遅延が制限され、現在選択されているメールボックスを中断する必要がありません。この拡張機能は、ESEARCH応答のMAILBOX、UIDVALIDITY、およびTAGフィールドも使用するため、クライアントは、選択した検索をパイプライン処理できます。このドキュメントはRFC 4466を更新し、RFC 6237を廃止します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

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（Internet Engineering Task Force）の製品です。これは、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/rfc7377.

このドキュメントの現在のステータス、正誤表、およびそれに関するフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7377で入手できます。

著作権表示

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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   1.1.  Conventions Used in This Document . . . . . . . . . . . . .   3
   2.  New ESEARCH Command . . . . . . . . . . . . . . . . . . . . .   3
   2.1.  The ESEARCH Response  . . . . . . . . . . . . . . . . . . .   4
   2.2.  Source Options: Specifying Mailboxes to Search  . . . . . .   5
   2.3.  Strictness in Search Matches  . . . . . . . . . . . . . . .   7
   2.4.  Server-Side Limitations on Search Volume  . . . . . . . . .   7
   3.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   4.  Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . .   8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   7.  Changes since RFC 6237  . . . . . . . . . . . . . . . . . . .  10
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
   8.1.  Normative References  . . . . . . . . . . . . . . . . . . .  10
   8.2.  Informative References  . . . . . . . . . . . . . . . . . .  11
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1. Introduction

1. はじめに

IMAP4仕様では、選択したメールボックスのみを検索できます。ユーザーは複数のメールボックスを検索したい場合が多く、これをサポートしたいクライアントは一連のSELECTコマンドとSEARCHコマンドを発行し、それぞれが完了するのを待ってから次のコマンドに進む必要があります。サーバーがコマンドを並行して実行する可能性があり、タグ付けされていないSEARCH応答を互いに区別できないため、コマンドをパイプライン処理することはできません。

This extension allows a client to search multiple mailboxes with one command and includes MAILBOX and TAG fields in the ESEARCH response, yielding the following advantages:

この拡張機能により、クライアントは1つのコマンドで複数のメールボックスを検索でき、ESEARCH応答にMAILBOXフィールドとTAGフィールドが含まれるため、次の利点があります。

o A single command limits the number of round trips needed to search a set of mailboxes.

o 1つのコマンドで、メールボックスのセットを検索するために必要なラウンドトリップの数を制限します。

o A single command eliminates the need to wait for one search to complete before starting the next.

o 1つのコマンドで、1つの検索が完了するのを待ってから次の検索を開始する必要がなくなります。

o A single command allows the server to optimize the search if it can.

o 単一のコマンドにより、サーバーは検索を最適化できます（可能な場合）。

o A command that is not dependent upon the selected mailbox eliminates the need to disrupt the selection state or to open another IMAP connection.

o 選択したメールボックスに依存しないコマンドを使用すると、選択状態を中断したり、別のIMAP接続を開いたりする必要がなくなります。

o The MAILBOX, UIDVALIDITY, and TAG fields in the responses allow a client to distinguish which responses go with which search (and which mailbox). A client can safely pipeline these search commands without danger of confusion. The addition of the MAILBOX and UIDVALIDITY fields updates the search-correlator item defined in [RFC4466].

o 応答のMAILBOX、UIDVALIDITY、およびTAGフィールドにより、クライアントは、どの応答がどの検索（およびどのメールボックス）で行われるかを区別できます。クライアントは混乱の危険なしにこれらの検索コマンドを安全にパイプライン処理できます。 MAILBOXとUIDVALIDITYフィールドの追加は、[RFC4466]で定義された検索相関項目を更新します。

This extension was previously published in an Experimental RFC. There is now implementation experience, giving confidence in the protocol, so this document puts the extension on the Standards Track, with some minor updates that were informed by the implementation experience. A brief summary of changes is in Section 7.

この拡張機能は、以前は実験的RFCで公開されていました。現在、実装の経験があり、プロトコルに自信を持っているため、このドキュメントは拡張を標準化トラックに置き、実装の経験によって通知されたいくつかのマイナーな更新を行います。変更の概要はセクション7にあります。

1.1. Conventions Used in This Document

1.1. このドキュメントで使用される規則

In examples, "C:" indicates lines sent by a client that is connected to a server, and "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 [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。

2. New ESEARCH Command

2. 新しいESEARCHコマンド

Arguments: OPTIONAL source options OPTIONAL result options OPTIONAL charset specification (see [RFC2978]) searching criteria (one or more)

引数：OPTIONALソースオプションOPTIONAL結果オプションOPTIONAL文字セット仕様（[RFC2978]を参照）検索基準（1つ以上）

   Responses:  REQUIRED untagged response: ESEARCH
   Result:     OK -- search completed
               NO -- error: cannot search that charset or criteria
               BAD -- command unknown or arguments invalid

This section defines a new ESEARCH command, which works similarly to the UID SEARCH command described in Section 2.6.1 of [RFC4466] (initially described in Section 6.4.4 of [RFC3501] and extended by [RFC4731]).

このセクションでは、新しいESEARCHコマンドを定義します。これは、[RFC4466]のセクション2.6.1で説明されているUID SEARCHコマンドと同様に機能します（最初は[RFC3501]のセクション6.4.4で説明され、[RFC4731]で拡張されています）。

The ESEARCH command further extends searching by allowing for optional source and result options. This document does not define any new result options (see Section 3.1 of [RFC4731]). A server that supports this extension includes "MULTISEARCH" in its IMAP capability string.

ESEARCHコマンドは、オプションのソースおよび結果オプションを許可することにより、検索をさらに拡張します。このドキュメントでは、新しい結果オプションは定義していません（[RFC4731]のセクション3.1を参照）。この拡張機能をサポートするサーバーでは、IMAP機能文字列に「MULTISEARCH」が含まれています。

Because there has been confusion about this, it is worth pointing out that with ESEARCH, as with any SEARCH or UID SEARCH command, it MUST NOT be considered an error if the search terms include a range of message numbers that extends (or, in fact, starts) beyond the end of the mailbox. For example, a client might want to establish a rolling window through the search results this way:

これについては混乱があったため、SEARCHまたはUID SEARCHコマンドと同様に、ESEARCHでも、検索語句に拡張するメッセージ番号の範囲が含まれている場合、エラーと見なしてはなりません（または、実際には、開始）メールボックスの終わりを超えています。たとえば、クライアントは次のようにして検索結果にローリングウィンドウを設定することができます。

C: tag1 UID ESEARCH FROM "frobozz" 1:100

C：tag1 UID ESEARCH FROM "frobozz" 1：100

... followed later by this:

...後にこれが続きます：

C: tag1 UID ESEARCH FROM "frobozz" 101:200

C：tag1 UID ESEARCH FROM "frobozz" 101：200

... and so on.

... 等々。

This tells the server to match only the first hundred messages in the mailbox the first time, the second hundred the second time, etc. In fact, it might likely allow the server to optimize the search significantly. In the above example, whether the mailbox contains 50, 150, or 250 messages, neither of the search commands shown will result in an error. It is up to the client to know when to stop moving its search window.

これは、メールボックス内の最初の100件のメッセージのみを最初に照合し、2回目は2回目を照合するようにサーバーに指示します。実際、サーバーが検索を大幅に最適化できる可能性があります。上記の例では、メールボックスに50、150、または250のメッセージが含まれるかどうかに関係なく、表示される検索コマンドはいずれもエラーになりません。検索ウィンドウの移動をいつ停止するかを知るのはクライアントの責任です。

2.1. The ESEARCH Response

2.1. ESEARCHレスポンス

In response to an ESEARCH command, the server MUST return ESEARCH responses [RFC4731] (that is, not SEARCH responses). Because message numbers are not useful for mailboxes that are not selected, the responses MUST contain information about UIDs, not message numbers. This is true even if the source options specify that only the selected mailbox be searched.

ESEARCHコマンドに応答して、サーバーはESEARCH応答[RFC4731]を返す必要があります（つまり、SEARCH応答ではありません）。メッセージ番号は選択されていないメールボックスには役に立たないため、応答にはメッセージ番号ではなくUIDに関する情報を含める必要があります。これは、ソースオプションで、選択したメールボックスのみを検索するように指定している場合にも当てはまります。

Presence of a source option in the absence of a result option implies the "ALL" result option (see Section 3.1 of [RFC4731]). Note that this is not the same as the result from the SEARCH command described in the IMAP base protocol [RFC3501].

結果オプションがない場合のソースオプションの存在は、「すべて」の結果オプションを意味します（[RFC4731]のセクション3.1を参照）。これは、IMAPベースプロトコル[RFC3501]で説明されているSEARCHコマンドの結果とは異なることに注意してください。

Source options describe which mailboxes must be searched for messages. An ESEARCH command with source options does not affect which mailbox, if any, is currently selected, regardless of which mailboxes are searched.

ソースオプションは、メッセージを検索する必要があるメールボックスを示します。ソースオプションを指定したESEARCHコマンドは、どのメールボックスが検索されるかに関係なく、現在選択されているメールボックス（存在する場合）に影響を与えません。

For each mailbox satisfying the source options, a single ESEARCH response MUST be returned if any messages in that mailbox match the search criteria. An ESEARCH response MUST NOT be returned for mailboxes that contain no matching messages. This is true even when result options such as MIN, MAX, and COUNT are specified (see Section 3.1 of [RFC4731]), and the values returned (lowest UID matched, highest UID matched, and number of messages matched, respectively) apply to the mailbox reported in that ESEARCH response.

ソースオプションを満たすメールボックスごとに、そのメールボックス内のメッセージが検索条件に一致する場合は、1つのESEARCH応答を返す必要があります。一致するメッセージを含まないメールボックスに対しては、ESEARCH応答を返してはなりません（MUST NOT）。これは、MIN、MAX、COUNTなどの結果オプションが指定され（[RFC4731]のセクション3.1を参照）、返される値（一致する最低UID、一致する最高UID、および一致するメッセージ数）が適用される場合にも当てはまります。そのESEARCH応答で報告されたメールボックス。

Note that it is possible for an ESEARCH command to return no untagged responses (no ESEARCH responses at all) in the case that there are no matches to the search in any of the mailboxes that satisfy the source options. Clients can detect this situation by finding the tagged OK response without having received any matching untagged ESEARCH responses.

ソースオプションを満たすメールボックスのいずれかでの検索に一致するものがない場合、ESEARCHコマンドがタグなし応答を返さない（ESEARCH応答がまったく返されない）可能性があることに注意してください。クライアントは、一致するタグなしESEARCH応答を受信せずにタグ付きOK応答を見つけることにより、この状況を検出できます。

Each ESEARCH response MUST contain the MAILBOX, TAG, and UIDVALIDITY correlators. Correlators allow clients to issue several ESEARCH commands at once (pipelined). If the SEARCHRES [RFC5182] extension is used in an ESEARCH command, that ESEARCH command MUST be executed by the server after all previous SEARCH/ESEARCH commands have completed and before any subsequent SEARCH/ESEARCH commands are executed. The server MAY perform consecutive ESEARCH commands in parallel as long as none of them use the SEARCHRES extension.

各ESEARCH応答には、MAILBOX、TAG、およびUIDVALIDITYコリレーターが含まれている必要があります。コリレータにより、クライアントは複数のESEARCHコマンドを一度に発行できます（パイプライン）。 ESEARCHコマンドでSEARCHRES [RFC5182]拡張が使用されている場合、そのESEARCHコマンドは、以前のすべてのSEARCH / ESEARCHコマンドが完了した後、後続のSEARCH / ESEARCHコマンドが実行される前に、サーバーによって実行される必要があります。サーバーは、SEARCHRES拡張機能を使用しない限り、連続するESEARCHコマンドを並行して実行してもよい（MAY）。

2.2. Source Options: Specifying Mailboxes to Search

2.2. ソースオプション：検索するメールボックスの指定

The source options, if present, MUST contain a mailbox specifier as defined in the IMAP NOTIFY extension [RFC5465], Section 6 (using the "filter-mailboxes" ABNF item), with the following differences:

ソースオプションが存在する場合は、IMAP NOTIFY拡張[RFC5465]、セクション6（「filter-mailboxes」ABNFアイテムを使用）で定義されているメールボックス指定子を含める必要がありますが、次の違いがあります。

1. The "selected-delayed" specifier is not valid here.

1. 「selected-delayed」指定子はここでは無効です。

2. A "subtree-one" specifier is added. The "subtree" specifier results in a search of the specified mailbox and all selectable mailboxes that are subordinate to it, through an indefinitely deep hierarchy. The "subtree-one" specifier results in a search of the specified mailbox and all selectable child mailboxes, one hierarchy level down.

2.「subtree-one」指定子が追加されました。「サブツリー」指定子は、指定されたメールボックスと、その下位にある選択可能なすべてのメールボックスを、無限に深い階層で検索します。 "subtree-one"指定子は、指定されたメールボックスと選択可能なすべての子メールボックスを1階層下に検索します。

If "subtree" is specified, the server MUST defend against loops in the hierarchy (for example, those caused by recursive file-system links within the message store). The server SHOULD do this by keeping track of the mailboxes that have been searched and by terminating the hierarchy traversal when a repeat is found. If it cannot do that, it MAY do it by limiting the hierarchy depth.

「サブツリー」が指定されている場合、サーバーは階層内のループ（たとえば、メッセージストア内の再帰的なファイルシステムリンクによって引き起こされるループ）を防御しなければなりません（MUST）。サーバーは、検索されたメールボックスを追跡し、繰り返しが見つかったときに階層トラバーサルを終了することにより、これを行う必要があります（SHOULD）。それができない場合は、階層の深さを制限することで可能です。

If the source options are not present, the value "selected" is assumed -- that is, only the currently selected mailbox is searched.

ソースオプションが存在しない場合は、値 "selected"が想定されます。つまり、現在選択されているメールボックスのみが検索されます。

The "personal" source option is a particularly convenient way to search all of the current user's mailboxes. Note that there is no way to use wildcard characters to search all mailboxes; the "mailboxes" source option does not do wildcard expansion.

「個人」ソースオプションは、現在のユーザーのメールボックスをすべて検索するのに特に便利な方法です。ワイルドカード文字を使用してすべてのメールボックスを検索する方法はないことに注意してください。「mailboxes」ソースオプションはワイルドカード拡張を行いません。

If the source options include (or default to) "selected", the IMAP session MUST be in "selected" state. If the source options specify other mailboxes and NOT "selected", then the IMAP session MUST be in either "selected" or "authenticated" state. If the session is not in a correct state, the ESEARCH command MUST return a "BAD" result.

ソースオプションに「選択済み」が含まれている（またはデフォルトである）場合、IMAPセッションは「選択済み」状態でなければなりません。ソースオプションが他のメールボックスを指定し、「選択」ではない場合、IMAPセッションは「選択」または「認証」状態でなければなりません。セッションが正しい状態でない場合、ESEARCHコマンドは「BAD」結果を返さなければなりません（MUST）。

The client SHOULD NOT provide source options that resolve to including the same mailbox more than once. A server can, of course, remove the duplicates before processing, but the server MAY return "BAD" to an ESEARCH command with duplicate source mailboxes.

クライアントは、同じメールボックスを複数回含めることを解決するソースオプションを提供してはなりません（SHOULD NOT）。もちろん、サーバーは処理の前に重複を削除できますが、サーバーは重複したソースメールボックスを持つESEARCHコマンドに「BAD」を返す場合があります。

If the server supports the SEARCHRES [RFC5182] extension, then the "SAVE" result option is valid only if "selected" is specified or defaulted to as the sole mailbox to be searched. If any source option other than "selected" is specified, the ESEARCH command MUST return a "BAD" result.

サーバーがSEARCHRES [RFC5182]拡張をサポートしている場合、「SAVE」結果オプションは、「選択」が指定されているか、デフォルトでデフォルトの検索対象のメールボックスとして指定されている場合にのみ有効です。 "selected"以外のソースオプションが指定されている場合、ESEARCHコマンドは "BAD"結果を返さなければなりません（MUST）。

If the server supports the CONTEXT=SEARCH and/or CONTEXT=SORT extension [RFC5267], then the following additional rules apply:

サーバーがCONTEXT = SEARCHおよび/またはCONTEXT = SORT拡張[RFC5267]をサポートしている場合、次の追加ルールが適用されます。

o The CONTEXT return option (Section 4.2 of [RFC5267]) can be used with an ESEARCH command.

o CONTEXT戻りオプション（[RFC5267]のセクション4.2）は、ESEARCHコマンドで使用できます。

o If the UPDATE return option is used (Section 4.3 of [RFC5267]), it MUST apply only to the currently selected mailbox. If UPDATE is used and there is no mailbox currently selected, the ESEARCH command MUST return a "BAD" result.

o UPDATEリターンオプションを使用する場合（[RFC5267]のセクション4.3）、現在選択されているメールボックスにのみ適用する必要があります。 UPDATEが使用され、現在選択されているメールボックスがない場合、ESEARCHコマンドは「BAD」結果を返さなければなりません（MUST）。

o The PARTIAL search return option (Section 4.4 of [RFC5267]) can be used and applies to each mailbox searched by the ESEARCH command.

o PARTIAL検索の戻りオプション（[RFC5267]のセクション4.4）を使用でき、ESEARCHコマンドで検索された各メールボックスに適用されます。

If the server supports the Access Control List (ACL) [RFC4314] extension, then the logged-in user is required to have the "r" right for each mailbox she wants to search. In addition, any mailboxes that are not explicitly named (accessed through "personal" or "subtree", for example) are required to have the "l" right. Mailboxes matching the source options for which the logged-in user lacks sufficient rights MUST be ignored by the ESEARCH command processing. In particular, ESEARCH responses MUST NOT be returned for those mailboxes.

サーバーがアクセス制御リスト（ACL）[RFC4314]拡張をサポートしている場合、ログインユーザーは、検索する各メールボックスに対して「r」権限を持っている必要があります。さらに、明示的に名前が付けられていないメールボックス（たとえば、「個人」または「サブツリー」を通じてアクセスされる）には、「l」権限が必要です。ログインユーザーに十分な権限がないソースオプションと一致するメールボックスは、ESEARCHコマンド処理で無視する必要があります。特に、それらのメールボックスに対してESEARCH応答を返してはならない（MUST NOT）。

2.3. Strictness in Search Matches

2.3. 検索マッチの厳密さ

The base IMAP SEARCH command (Section 6.4.4. of [RFC3501]) requires strict substring matching in text searches. Many servers, however, use search engines that match strings in different ways, for example, matching "swim" to both "swam" and "swum" or only doing full word matching (where "swim" will not match "swimming"). This is covered by the "Fuzzy Search" extension to IMAP [RFC6203], and that extension is compatible with this one and can be combined with it.

基本のIMAP SEARCHコマンド（[RFC3501]のセクション6.4.4。）では、テキスト検索で部分文字列を厳密に一致させる必要があります。ただし、多くのサーバーは、文字列をさまざまな方法で照合する検索エンジンを使用しています。たとえば、「swim」を「swam」と「swum」の両方に照合したり、完全な単語照合のみを行ったりします（「swim」は「swimming」と一致しません）。これは、IMAP [RFC6203]の「ファジー検索」拡張によってカバーされ、その拡張はこれと互換性があり、組み合わせることができます。

Whether or not Fuzzy Search is implemented or used, this extension explicitly allows flexible searching with respect to TEXT and BODY searches. Servers MAY use fuzzy text matching in multimailbox searches.

あいまい検索が実装または使用されているかどうかに関係なく、この拡張機能により、TEXTおよびBODY検索に関する柔軟な検索が明示的に許可されます。サーバーは、マルチメールボックス検索でファジーテキストマッチングを使用する場合があります。

2.4. Server-Side Limitations on Search Volume

2.4. 検索ボリュームに関するサーバー側の制限

To avoid having a search use more than a reasonable share of server resources, servers MAY apply limits that go beyond loop protection, such as limits on the number of mailboxes that may be searched at once and/or limits on the number or total size of messages searched. A server can apply those limits up front, responding with "NO [LIMIT]" if a limit is exceeded (see [RFC5530] for information about response codes). Alternatively, a server can process the search and terminate it when a limit is exceeded, responding with "OK [LIMIT]" and returning partial results. Note that searches that return partial results can cause complexity for client implementations and confusion to users.

検索でサーバーリソースの合理的な共有を超えて使用することを回避するために、サーバーは、一度に検索できるメールボックスの数の制限や、メールボックスの数や合計サイズの制限など、ループ保護を超える制限を適用できます（MAY）。検索されたメッセージ。サーバーはこれらの制限を事前に適用でき、制限を超えた場合は「NO [LIMIT]」で応答します（応答コードについては[RFC5530]を参照）。または、サーバーは検索を処理し、制限を超えたときに検索を終了し、「OK [LIMIT]」で応答して部分的な結果を返すこともできます。部分的な結果を返す検索は、クライアントの実装を複雑にし、ユーザーを混乱させる可能性があることに注意してください。

3. Examples

3. 例

In the following example, note that two ESEARCH commands are pipelined and that the server is running them in parallel, interleaving a response to the second search amid the responses to the first (watch the tags).

次の例では、2つのESEARCHコマンドがパイプライン処理され、サーバーがそれらを並行して実行しており、最初の検索への応答の間に2番目の検索への応答をインターリーブしていることに注意してください（タグを見る）。

   C: tag1 ESEARCH IN (mailboxes "folder1" subtree "folder2") unseen
   C: tag2 ESEARCH IN (mailboxes "folder1" subtree-one "folder2")
   subject "chad"
   S: * ESEARCH (TAG "tag1" MAILBOX "folder1" UIDVALIDITY 1) UID ALL
   4001,4003,4005,4007,4009
   S: * ESEARCH (TAG "tag2" MAILBOX "folder1" UIDVALIDITY 1) UID ALL
   3001:3004,3788
   S: * ESEARCH (TAG "tag1" MAILBOX "folder2/banana" UIDVALIDITY 503)
   UID ALL 3002,4004
   S: * ESEARCH (TAG "tag1" MAILBOX "folder2/peach" UIDVALIDITY 3) UID
   ALL 921691
   S: tag1 OK done
   S: * ESEARCH (TAG "tag2" MAILBOX "folder2/salmon" UIDVALIDITY
   1111111) UID ALL 50003,50006,50009,50012
   S: tag2 OK done

4. Formal Syntax

4. 正式な構文

The following syntax specification uses the Augmented Backus-Naur Form (ABNF) as described in [RFC5234]. Terms not defined here are taken from [RFC3501], [RFC5465], or [RFC4466].

次の構文仕様では、[RFC5234]で説明されているようにAugmented Backus-Naur Form（ABNF）を使用しています。ここで定義されていない用語は、[RFC3501]、[RFC5465]、または[RFC4466]から取得されます。

command-auth =/ esearch ; Update definition from IMAP base [RFC3501]. ; Add new "esearch" command.

command-auth = / esearch; IMAPベース[RFC3501]から定義を更新します。 ;新しい「esearch」コマンドを追加します。

command-select =/ esearch ; Update definition from IMAP base [RFC3501]. ; Add new "esearch" command.

command-select = / esearch; IMAPベース[RFC3501]から定義を更新します。 ;新しい「esearch」コマンドを追加します。

filter-mailboxes-other =/ ("subtree-one" SP one-or-more-mailbox) ; Update definition from IMAP Notify [RFC5465]. ; Add new "subtree-one" selector.

filter-mailboxes-other = /（ "subtree-one" SP one-or-more-mailbox）; IMAP通知からの定義の更新[RFC5465]。 ;新しい「サブツリー1」セレクターを追加します。

filter-mailboxes-selected = "selected" ; Update definition from IMAP Notify [RFC5465]. ; We forbid the use of "selected-delayed".

filter-mailboxes-selected = "selected"; IMAP通知からの定義の更新[RFC5465]。 ; 「selected-delayed」の使用を禁止します。

   one-correlator =  ("TAG" SP tag-string) / ("MAILBOX" SP astring) /
           ("UIDVALIDITY" SP nz-number)
           ; Each correlator MUST appear exactly once.

scope-option = scope-option-name [SP scope-option-value] ; No options defined here. Syntax for future extensions.

スコープオプション=スコープオプション名[SPスコープオプション値];ここではオプションは定義されていません。将来の拡張のための構文。

scope-option-name = tagged-ext-label ; No options defined here. Syntax for future extensions.

スコープオプション名=タグ付き拡張ラベル;ここではオプションは定義されていません。将来の拡張のための構文。

scope-option-value = tagged-ext-val ; No options defined here. Syntax for future extensions.

scope-option-value = tagged-ext-val;ここではオプションは定義されていません。将来の拡張のための構文。

scope-options = scope-option *(SP scope-option) ; A given option may only appear once. ; No options defined here. Syntax for future extensions.

scope-options = scope-option *（SP scope-option）;与えられたオプションは一度だけ現れるかもしれません。 ;ここではオプションは定義されていません。将来の拡張のための構文。

esearch = "ESEARCH" [SP esearch-source-opts] [SP search-return-opts] SP search-program

search-correlator = SP "(" one-correlator *(SP one-correlator) ")" ; Updates definition in IMAP4 ABNF [RFC4466].

search-correlator = SP "（" one-correlator *（SP one-correlator） "）"; IMAP4 ABNF [RFC4466]の定義を更新します。

esearch-source-opts = "IN" SP "(" source-mbox [SP "(" scope-options ")"] ")"

esearch-source-opts = "IN" SP "（" source-mbox [SP "（" scope-options "）"] "）"

   source-mbox =  filter-mailboxes *(SP filter-mailboxes)
           ; "filter-mailboxes" is defined in IMAP Notify [RFC5465].
           ; See updated definition of filter-mailboxes-other, above.
           ; See updated definition of filter-mailboxes-selected, above.

5. Security Considerations

5. セキュリティに関する考慮事項

This new IMAP ESEARCH command allows a single command to search many mailboxes at once. On the one hand, a client could do that by sending many IMAP SEARCH commands. On the other hand, this makes it easier for a client to overwork a server by sending a single command that results in an expensive search of tens of thousands of mailboxes. Server implementations need to be aware of that and provide mechanisms that prevent a client from adversely affecting other users. Limitations on the number of mailboxes that may be searched in one command and/or on the server resources that will be devoted to responding to a single client, are reasonable limitations for an implementation to impose (see also Section 2.4).

この新しいIMAP ESEARCHコマンドを使用すると、単一のコマンドで多数のメールボックスを一度に検索できます。一方では、クライアントは多くのIMAP SEARCHコマンドを送信することでそれを行うことができます。一方、これにより、クライアントが単一のコマンドを送信することでサーバーを使いすぎやすくなり、結果として数万のメールボックスの検索にコストがかかります。サーバーの実装では、それを認識し、クライアントが他のユーザーに悪影響を与えないようにするメカニズムを提供する必要があります。 1つのコマンドで検索できるメールボックスの数や単一のクライアントへの応答に充てられるサーバーリソースの制限は、実装が課す妥当な制限です（セクション2.4も参照）。

Implementations MUST, of course, apply access controls appropriately, limiting a user's access to ESEARCH in the same way its access is limited for any other IMAP commands. This extension has no data-access risks beyond what may exist in the unextended IMAP implementation.

もちろん、実装は適切にアクセス制御を適用しなければならず、他のIMAPコマンドに対するアクセスが制限されるのと同じ方法でESEARCHへのユーザーのアクセスを制限します。この拡張機能には、拡張されていないIMAP実装に存在する可能性のあるデータアクセスのリスクはありません。

Mailboxes matching the source options for which the logged-in user lacks sufficient rights MUST be ignored by the ESEARCH command processing (see the paragraph about this in Section 2.2). In particular, any attempt to distinguish insufficient access from non-existent mailboxes may expose information about the mailbox hierarchy that isn't otherwise available to the client.

ログインユーザーに十分な権限がないソースオプションと一致するメールボックスは、ESEARCHコマンド処理で無視する必要があります（セクション2.2のこれに関する段落を参照）。特に、不十分なアクセスを存在しないメールボックスと区別しようとすると、クライアントが利用できないメールボックス階層に関する情報が公開される可能性があります。

If "subtree" is specified, the server MUST defend against loops in the hierarchy (see the paragraph about this in Section 2.2).

「サブツリー」が指定されている場合、サーバーは階層内のループから防御する必要があります（セクション2.2のこれに関する段落を参照）。

6. IANA Considerations

6. IANAに関する考慮事項

The "Internet Message Access Protocol (IMAP) Capabilities Registry" is currently located at <http://www.iana.org/assignments/imap-capabilities>.

「インターネットメッセージアクセスプロトコル（IMAP）機能レジストリ」は、現在<http://www.iana.org/assignments/imap-capabilities>にあります。

IANA has changed the reference for the IMAP capability "MULTISEARCH" to point to this document.

IANAは、このドキュメントを指すようにIMAP機能「マルチサーチ」の参照を変更しました。

7. Changes since RFC 6237

7. RFC 6237以降の変更

o Change to Standards Track.

o 標準トラックに変更します。

o Added paragraph about duplicate mailboxes.

o メールボックスの重複に関する段落を追加。

o Added Section 2.3 about Fuzzy Search.

o ファジー検索に関するセクション2.3を追加しました。

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。

[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000, <http://www.rfc-editor.org/info/rfc2978>.

[RFC2978] Freed、N。およびJ. Postel、「IANA Charset Registration Procedures」、BCP 19、RFC 2978、2000年10月、<http://www.rfc-editor.org/info/rfc2978>。

[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003, <http://www.rfc-editor.org/info/rfc3501>.

[RFC3501] Crispin、M。、「インターネットメッセージアクセスプロトコル-バージョン4rev1」、RFC 3501、2003年3月、<http://www.rfc-editor.org/info/rfc3501>。

[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", RFC 4314, December 2005, <http://www.rfc-editor.org/info/rfc4314>.

[RFC4314] Melnikov、A。、「IMAP4 Access Control List（ACL）Extension」、RFC 4314、2005年12月、<http://www.rfc-editor.org/info/rfc4314>。

[RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006, <http://www.rfc-editor.org/info/rfc4466>.

[RFC4466] Melnikov、A。およびC. Daboo、「Collected Extensions to IMAP4 ABNF」、RFC 4466、2006年4月、<http://www.rfc-editor.org/info/rfc4466>。

[RFC4731] Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned", RFC 4731, November 2006, <http://www.rfc-editor.org/info/rfc4731>.

[RFC4731] Melnikov、A。およびD. Cridland、「返される情報の種類を制御するためのSEARCHコマンドのIMAP4拡張機能」、RFC 4731、2006年11月、<http://www.rfc-editor.org/info/rfc4731 >。

[RFC5182] Melnikov, A., "IMAP Extension for Referencing the Last SEARCH Result", RFC 5182, March 2008, <http://www.rfc-editor.org/info/rfc5182>.

[RFC5182] Melnikov、A。、「最後の検索結果を参照するためのIMAP拡張機能」、RFC 5182、2008年3月、<http://www.rfc-editor.org/info/rfc5182>。

[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.

[RFC5234] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月、<http://www.rfc-editor.org/info/rfc5234>。

[RFC5267] Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267, July 2008, <http://www.rfc-editor.org/info/rfc5267>.

[RFC5267] Cridland、D。およびC. King、「Contexts for IMAP4」、RFC 5267、2008年7月、<http://www.rfc-editor.org/info/rfc5267>。

[RFC5465] Gulbrandsen, A., King, C., and A. Melnikov, "The IMAP NOTIFY Extension", RFC 5465, February 2009, <http://www.rfc-editor.org/info/rfc5465>.

[RFC5465] Gulbrandsen、A.、King、C。、およびA. Melnikov、「IMAP NOTIFY Extension」、RFC 5465、2009年2月、<http://www.rfc-editor.org/info/rfc5465>。

[RFC5530] Gulbrandsen, A., "IMAP Response Codes", RFC 5530, May 2009, <http://www.rfc-editor.org/info/rfc5530>.

[RFC5530] Gulbrandsen、A。、「IMAP Response Codes」、RFC 5530、2009年5月、<http://www.rfc-editor.org/info/rfc5530>。

8.2. Informative References

8.2. 参考引用

[RFC6203] Sirainen, T., "IMAP4 Extension for Fuzzy Search", RFC 6203, March 2011, <http://www.rfc-editor.org/info/rfc6203>.

[RFC6203] Sirainen、T。、「ファジー検索のIMAP4拡張機能」、RFC 6203、2011年3月、<http://www.rfc-editor.org/info/rfc6203>。

Acknowledgments

謝辞

The authors gratefully acknowledge feedback provided by Timo Sirainen, Peter Coates, Arnt Gulbrandsen, and Chris Newman.

著者は、Timo Sirainen、Peter Coates、Arnt Gulbrandsen、およびChris Newmanから提供されたフィードバックに感謝します。

Authors' Addresses

著者のアドレス

Barry Leiba Huawei Technologies

バリーブレッドファーウェイテクノロジーズ

   Phone: +1 646 827 0648
   EMail: barryleiba@computer.org
   URI:   http://internetmessagingtechnology.org/

Alexey Melnikov Isode Limited 14 Castle Mews Hampton, Middlesex TW12 2NP United Kingdom

Alexey Melnikov Isode Limited 14 Castle Mewsハンプトン、ミドルセックスTW12 2NPイギリス

   EMail: Alexey.Melnikov@isode.com
   URI:   http://www.melnikov.ca/