[要約] RFC 6237はIMAP4 Multimailbox SEARCH拡張機能に関する規格であり、複数のメールボックスでの検索をサポートする。目的は、IMAPクライアントが複数のメールボックスで一括検索を行えるようにすること。
Internet Engineering Task Force (IETF) B. Leiba
Request for Comments: 6237 Huawei Technologies
Updates: 4466 A. Melnikov
Category: Experimental Isode Limited
ISSN: 2070-1721 May 2011
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 round trips and waiting for various searches to complete, and not requiring disruption of the currently selected mailbox. This extension also uses MAILBOX and TAG fields in ESEARCH responses, allowing a client to pipeline the searches if it chooses. This document updates RFC 4466.
IMAP4仕様により、選択したメールボックスのみを検索できます。多くの場合、ユーザーは複数のメールボックスを検索したいと考えており、これをサポートしたいクライアントは、一連の選択コマンドと検索コマンドを発行する必要があります。この拡張機能により、クライアントは1つのコマンドで複数のメールボックスを検索し、ラウンドトリップを制限し、さまざまな検索が完了するのを待つことができ、現在選択されているメールボックスの混乱を必要としません。この拡張機能は、ESEarch応答でメールボックスとタグフィールドも使用しているため、クライアントが選択した場合に検索をパイプラインできます。このドキュメントは、RFC 4466を更新します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントは、インターネット標準の追跡仕様ではありません。試験、実験的実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。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/rfc6237.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6237で取得できます。
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ライセンステキストを含める必要があります。
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
3. Examples ........................................................6
4. Formal Syntax ...................................................7
5. Security Considerations .........................................8
6. IANA Considerations .............................................9
7. Acknowledgements ................................................9
8. Normative References ............................................9
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. The commands can't be pipelined, because the server might run them in parallel, and the untagged SEARCH responses could not then be distinguished from each other.
IMAP4仕様により、選択したメールボックスのみを検索できます。多くの場合、ユーザーは複数のメールボックスを検索したいと考えており、これをサポートしたいクライアントは、一連の選択コマンドと検索コマンドを発行する必要があります。サーバーが並行してそれらを実行する可能性があり、未積層の検索応答が互いに区別できなかったため、コマンドをパイプ化することはできません。
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応答にメールボックスとタグフィールドを含めて、次の利点が得られます。
o A single command limits the number of round trips needed to search a set of mailboxes.
o 単一のコマンドは、メールボックスのセットを検索するのに必要な往復の数を制限します。
o A single command eliminates the need to wait for one search to complete before starting the next.
o 単一のコマンドは、次の検索を開始する前に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 応答のメールボックス、uidvalidity、およびタグフィールドにより、クライアントはどの応答がどの検索（およびどのメールボックス）に合うかを区別できます。クライアントは、混乱の危険なくこれらの検索コマンドを安全にパイプラインできます。メールボックスとuidvalidityフィールドを追加すると、[RFC4466]で定義されている検索相関アイテムが更新されます。
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 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
Arguments: OPTIONAL source options OPTIONAL result options OPTIONAL charset specification (see [RFC2978]) searching criteria (one or more)
引数：オプションのソースオプションオプションの結果オプションオプションのチャーセット仕様（[RFC2978]を参照）検索基準（1つ以上）
Responses: REQUIRED untagged response: ESEARCH
応答：攻撃されていない応答が必要：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]).
このセクションでは、[RFC4466]のセクション2.6.1で説明されているUID検索コマンド（[RFC3501]のセクション6.4.4で最初に説明され、[RFC4731]で拡張された）と同様に機能する新しいESEarchコマンドを定義します。
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:
これには混乱があったため、 *任意の *検索またはuid検索コマンドと同様に、esearchを使用すると、検索用語が拡張されるメッセージ番号の範囲が含まれている場合はエラーと見なされないことを指摘する価値があります（または、実際、メールボックスの終わりを超えて開始します。たとえば、クライアントは、この方法で検索結果を介してローリングウィンドウを確立したい場合があります。
C: tag1 UID ESEARCH FROM "frobozz" 1:100
c： "frobozz"のtag1 uid esearch 1：100
...followed later by this:
...後でこれが続きます：
C: tag1 UID ESEARCH FROM "frobozz" 101:200
c： "frobozz"からtag1 uid esearch 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 or 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のメッセージが含まれているかどうかにかかわらず、表示されている検索コマンドのどちらもエラーになりません。検索ウィンドウの移動をいつ停止するかを知るのはクライアント次第です。
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 Responses [RFC4731]（つまり、検索応答ではありません）を返す必要があります。メッセージ番号は選択されていないメールボックスには役に立たないため、回答にはメッセージ番号ではなく、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]で説明されている検索コマンドの結果と同じではないことに注意してください。
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.
ソースオプションを満たす各メールボックスについて、そのメールボックスにあるメッセージが検索条件と一致する場合、単一のesearch応答を返す必要があります。一致するメッセージが含まれていないメールボックスの場合、esearch応答を返してはなりません。これは、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コマンドが * no * untagged応答（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応答には、メールボックス、タグ、およびuidialidityの相関器が含まれている必要があります。相関者により、クライアントは一度にいくつかのESEarchコマンドを発行できます（Pipelined）。SearchRes [RFC5182]拡張機能がESEarchコマンドで使用されている場合、そのESEACHコマンドは、以前のすべての検索/ESEARCHコマンドが完了し、その後の検索/ESEARCHコマンドが実行される前にサーバーによって実行されなければなりません。サーバーは、SearchRes拡張子を使用しない限り、連続したESEarchコマンドを並行して実行できます。
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 Extension [RFC5465]、セクション6（「フィルターメールボックス」ABNFアイテムを使用）で定義されているメールボックス仕様を含める必要があります。
1. The "selected-delayed" specifier is not valid here.
1. 「選択された」仕様は、ここでは無効です。
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 terminating the hierarchy traversal when a repeat is found. If it cannot do that, it MAY do it by limiting the hierarchy depth.
「サブツリー」が指定されている場合、サーバーは階層内のループ（たとえば、メッセージストア内の再帰ファイルシステムリンクによって引き起こされるループ）を防御する必要があります。サーバーは、検索されたメールボックスを追跡し、繰り返しが見つかったときに階層横断を終了することにより、これを行う必要があります。それができない場合、階層の深さを制限することでそれを行う可能性があります。
If the source options are not present, the value "selected" is assumed -- that is, only the currently selected mailbox is searched.
ソースオプションが存在しない場合、「選択された」値が想定されます。つまり、現在選択されているメールボックスのみが検索されます。
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.
「個人的な」ソースオプションは、現在のユーザーのすべてのメールボックスを検索するための特に便利な方法です。ワイルドカード文字を使用してすべてのメールボックスを検索する方法はないことに注意してください。「メールボックス」ソースオプションは、ワイルドカードの拡張を行いません。
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コマンドは「悪い」結果を返す必要があります。
If the server supports the SEARCHRES [RFC5182] extension, then the "SAVE" result option is valid *only* if "selected" is specified or defaulted as the sole mailbox to be searched. If any source option other than "selected" is specified, the ESEARCH command MUST return a "BAD" result.
サーバーが検索[RFC5182]拡張機能をサポートする場合、「保存」結果オプションは、「選択された」が検索する唯一のメールボックスとして「選択」が指定またはデフォルトである場合にのみ有効です。「選択された」以外のソースオプションが指定されている場合、esearchコマンドは「悪い」結果を返す必要があります。
If the server supports the CONTEXT=SEARCH and/or CONTEXT=SORT extension [RFC5267], then the following additional rules apply:
サーバーがコンテキスト=検索および/またはコンテキスト=ソート拡張子[RFC5267]をサポートする場合、次の追加ルールが適用されます。
o The CONTEXT return option (Section 4.2 of [RFC5267]) can be used with an ESEARCH command.
o コンテキストリターンオプション（[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 更新戻りオプションが使用されている場合（[RFC5267]のセクション4.3）、現在選択されているメールボックスにのみ適用する必要があります。更新が使用され、現在選択されているメールボックスがない場合、esearchコマンドは「悪い」結果を返す必要があります。
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 部分的な検索リターンオプション（[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の応答を返してはなりません。
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
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]で説明されているように、拡張されたバックスノール形式（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 on-more-mailbox）;IMAPからの定義を更新します[RFC5465]。;新しい「Subtree-One」セレクターを追加します。
filter-mailboxes-selected = "selected" ; Update definition from IMAP Notify [RFC5465]. ; We forbid the use of "selected-delayed".
Filter-Mailboxes-Selected = "Selected";IMAPからの定義を更新します[RFC5465]。;「選択された」の使用を禁止しました。
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.
scope-option = scope-option-name [sp scope-option-value];ここにはオプションが定義されていません。将来の拡張機能の構文。
scope-option-name = tagged-ext-label ; No options defined here. Syntax for future extensions.
scope-option-name = tagged-ext-label;ここにはオプションが定義されていません。将来の拡張機能の構文。
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
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-relerator *（sp one-relerator） "）";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.
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.
この新しいIMAP esearchコマンドにより、単一のコマンドが一度に多くのメールボックスを検索できます。一方で、クライアントは多くのIMAP検索コマンドを送信することでそれを行うことができます。一方、これにより、クライアントがサーバーを過剰に処理しやすくなり、数万のメールボックスを高価に検索する単一のコマンドを送信することで簡単になります。サーバーの実装はそれを認識し、クライアントが他のユーザーに悪影響を与えることを妨げるメカニズムを提供する必要があります。1つのコマンドで検索できるメールボックスの数、および/または単一のクライアントへの応答に専念するサーバーリソースの制限は、実装が課す合理的な制限です。
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 be there 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のこれについての段落を参照）。
IMAP4 capabilities are registered by publishing a Standards Track or IESG-approved Experimental RFC. The "IMAP 4 Capabilities" registry is currently located here:
IMAP4機能は、標準トラックまたはIESGが承認した実験RFCを公開することにより登録されます。「IMAP 4機能」レジストリは現在ここにあります。
http://www.iana.org/
This document defines the IMAP capability "MULTISEARCH", and IANA has added it to the registry.
このドキュメントでは、IMAP機能「MultiSearch」を定義し、IANAがレジストリに追加しました。
The authors gratefully acknowledge feedback provided by Timo Sirainen, Peter Coates, and Arnt Gulbrandsen.
著者は、Timo Sirainen、Peter Coates、およびArnt Gulbrandsenによって提供されたフィードバックに感謝しています。
[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月。
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000.
[RFC2978] Freed、N。およびJ. Postel、「Iana Charset登録手順」、BCP 19、RFC 2978、2000年10月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501] CRISPIN、M。、「インターネットメッセージアクセスプロトコル - バージョン4REV1」、RFC 3501、2003年3月。
[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", RFC 4314, December 2005.
[RFC4314] Melnikov、A。、「IMAP4アクセス制御リスト（ACL）拡張機能」、RFC 4314、2005年12月。
[RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006.
[RFC4466] Melnikov、A。およびC. Daboo、「IMAP4 ABNFへの拡張を収集した」、RFC 4466、2006年4月。
[RFC4731] Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned", RFC 4731, November 2006.
[RFC4731] Melnikov、A。およびD. Cridland、「どのような種類の情報が返されるかを制御するための検索コマンドへのIMAP4拡張」、RFC 4731、2006年11月。
[RFC5182] Melnikov, A., "IMAP Extension for Referencing the Last SEARCH Result", RFC 5182, March 2008.
[RFC5182] Melnikov、A。、「最後の検索結果を参照するためのIMAP拡張」、RFC 5182、2008年3月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D.、ed。、およびP. Overell、「構文仕様のためのBNFの増強」、STD 68、RFC 5234、2008年1月。
[RFC5267] Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267, July 2008.
[RFC5267] Cridland、D。およびC. King、「IMAP4のコンテキスト」、RFC 5267、2008年7月。
[RFC5465] Gulbrandsen, A., King, C., and A. Melnikov, "The IMAP NOTIFY Extension", RFC 5465, February 2009.
[RFC5465] Gulbrandsen、A.、King、C。、およびA. Melnikov、「IMAP Notify Extension」、RFC 5465、2009年2月。
Authors' Addresses
著者のアドレス
Barry Leiba Huawei Technologies
Barry Leiba Huawei Technologies
Phone: +1 646 827 0648
EMail: barryleiba@computer.org
URI: http://internetmessagingtechnology.org/
Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton、Middlesex TW12 2BX UK
EMail: Alexey.Melnikov@isode.com
URI: http://www.melnikov.ca/