Network Working Group A. Melnikov
Request for Comments: 5182 Isode Ltd.
Updates: 3501 March 2008
Category: Standards Track
IMAP Extension for Referencing the Last SEARCH Result
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
Many IMAP clients use the result of a SEARCH command as the input to perform another operation, for example, fetching the found messages, deleting them, or copying them to another mailbox.
多くのIMAPクライアントは、それらを削除、見つかったメッセージを取得、例えば、別の操作を実行するための入力として検索コマンドの結果を使用するか、別のメールボックスにコピー。
This can be achieved using standard IMAP operations described in RFC 3501; however, this would be suboptimal. The server will send the list of found messages to the client; after that, the client will have to parse the list, reformat it, and send it back to the server. The client can't pipeline the SEARCH command with the subsequent command, and, as a result, the server might not be able to perform some optimizations.
これは、RFC 3501に記載されている標準的なIMAP操作を使用して達成することができます。しかし、これは次善のだろう。サーバーは、クライアントに見つかったメッセージのリストをお送りします。その後、クライアントは、リストを解析する必要があり、それを再フォーマットし、それをサーバに送り返すます。クライアントは、後続のコマンドを使用して、パイプラインSEARCHコマンドをすることはできません、と、その結果として、サーバーは、いくつかの最適化を実行できない場合があります。
This document proposes an IMAP extension that allows a client to tell a server to use the result of a SEARCH (or Unique Identifier (UID) SEARCH) command as an input to any subsequent command.
この文書では、クライアントは、後続のコマンドへの入力として、SEARCH（または一意識別子（UID）SEARCH）コマンドの結果を使用するようにサーバに指示することができますIMAP拡張を提案しています。
Many IMAP clients use the result of a SEARCH command as the input to perform another operation, for example, fetching the found messages, deleting them, or copying them to another mailbox.
多くのIMAPクライアントは、それらを削除、見つかったメッセージを取得、例えば、別の操作を実行するための入力として検索コマンドの結果を使用するか、別のメールボックスにコピー。
This document proposes an IMAP extension that allows a client to tell a server to use the result of a SEARCH (or UID SEARCH) command as an input to any subsequent command.
この文書では、クライアントは、後続のコマンドの入力としてSEARCH（またはUID検索）コマンドの結果を使用するようにサーバに指示することができますIMAP拡張を提案しています。
The SEARCH result reference extension defines a new SEARCH result option [IMAPABNF] "SAVE" that tells the server to remember the result of the SEARCH or UID SEARCH command (as well as any command based on SEARCH, e.g., SORT and THREAD [SORT]) and store it in an internal
検索結果の参照拡張子が新しい検索結果オプション検索またはUID SEARCHコマンド（だけでなく、検索に基づいて任意のコマンドの結果を覚えて、サーバーに指示します[IMAPABNF]「SAVE」、例えば、SORTとTHREAD [SORT]を定義します）内部に格納
variable that we will reference as the "search result variable". The client can use the "$" marker to reference the content of this internal variable. The "$" marker can be used instead of message sequence or UID sequence in order to indicate that the server should substitute it with the list of messages from the search result variable. Thus, the client can use the result of the latest remembered SEARCH command as a parameter to another command. The search result marker has several advantages:
私たちは、「検索結果変数」として参照する変数。クライアントは、この内部変数の内容を参照するために「$」マーカーを使用することができます。 「$」マーカーは、サーバが検索結果変数からのメッセージのリストでそれを置き換える必要があることを示すために、代わりにメッセージシーケンスまたはUID配列を使用することができます。したがって、クライアントは、別のコマンドのパラメータとして、最新思い出しSEARCHコマンドの結果を使用することができます。検索結果マーカーには、いくつかの利点があります。
* it avoids wasted bandwidth and associated delay;
*それは無駄な帯域幅と関連する遅延を回避し、
* it allows the client to pipeline a SEARCH [IMAP4] command with a subsequent FETCH/STORE/COPY/SEARCH [IMAP4] or UID EXPUNGE [UIDPLUS] command;
*これは、後続のFETCH / STORE / COPY / SEARCH [IMAP4]又はUID EXPUNGE [UIDPLUS]コマンドを使用して、SEARCH [IMAP4]コマンドパイプラインにクライアントを可能にします。
* the client doesn't need to spend time reformatting the result of a SEARCH command into a message set used in the subsequent command;
*クライアントは、後続のコマンドで使用されるメッセージセットにSEARCHコマンドの結果を再フォーマットの時間を費やす必要はありません。
* it allows the server to perform optimizations. For example, if the server can execute several pipelined commands in parallel (or out of order), presence of the search result marker can allow the server to decide which commands may or may not be executed out of order.
*これは、サーバーが最適化を行うことができます。例えば、サーバ（または順不同）、検索結果マーカーの存在は、サーバが、または順不同で実行してもしなくてもよいコマンドかを決定できるようにすることができ、並列にいくつかのパイプライン化されたコマンドを実行できるかどうか。
In absence of any other SEARCH result option, the SAVE result option also suppresses any SEARCH response that would have been otherwise returned by the SEARCH command.
他の検索結果のオプションがない場合には、SAVE結果オプションもそうでないSEARCHコマンドによって返されたであろう任意の検索応答を抑制する。
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 [KEYWORDS].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[キーワード]に記載されているように解釈されます。
Explanatory comments in examples start with // and are not part of the protocol.
例の説明のコメントは//で始まり、プロトコルの一部ではありません。
The SEARCH result reference extension described in this document is present in any IMAP4 server implementation that returns "SEARCHRES" as one of the supported capabilities in the CAPABILITY command response. Any such server MUST also implement the [ESEARCH] extension.
この文書に記載された検索結果リファレンス拡張は、CAPABILITYコマンド応答でサポートされる機能の一つとして「SEARCHRES」を返す任意のIMAP4サーバの実装に存在します。そのような任意のサーバーは、[ESEARCH]拡張機能を実装しなければなりません。
Upon successful completion of a SELECT or an EXAMINE command (after the tagged OK response), the current search result variable is reset to the empty sequence.
（タグ付きOK応答の後）SELECTまたはEXAMINEコマンドが正常に完了すると、現在の検索結果変数が空のシーケンスにリセットされます。
A successful SEARCH command with the SAVE result option sets the value of the search result variable to the list of messages found in the SEARCH command. For example, if no messages were found, the search result variable will contain the empty list.
SAVE結果オプションを使用して成功したSEARCHコマンドは、検索コマンドで見つかったメッセージのリストに検索結果変数の値を設定します。何もメッセージが見つからなかった場合たとえば、検索結果変数は空のリストが含まれます。
Any of the following SEARCH commands MUST NOT change the search result variable:
次の検索コマンドのいずれかが、検索結果の変数を変更してはいけません。
o a SEARCH command that caused the server to return the BAD tagged response,
OサーバはBADタグ付けされた応答を返すために引き起こしたSEARCHコマンド、
o a SEARCH command with no SAVE result option that caused the server to return NO tagged response,
OサーバはNOタグ付けされた応答を返さないために発生していないSAVE結果オプション付きのSEARCHコマンド、
o a successful SEARCH command with no SAVE result option.
無SAVE結果オプションを使用して成功したSEARCHコマンドO。
A SEARCH command with the SAVE result option that caused the server to return the NO tagged response sets the value of the search result variable to the empty sequence.
サーバはNOを返すために引き起こしたSAVE結果オプション付きのSEARCHコマンドは、応答が空のシーケンスに検索結果変数の値を設定しますタグ付き。
When a message listed in the search result variable is EXPUNGEd, it is automatically removed from the list. Implementors are reminded that if the server stores the list as a list of message numbers, it MUST automatically adjust them when notifying the client about expunged messages, as described in Section 7.4.1 of [IMAP4].
検索結果変数にリストされたメッセージが消去された場合は、自動的にリストから削除されます。実装者は、サーバーがメッセージ番号のリストとしてリストを保存する場合は抹消メッセージについてクライアントに通知する際に、[IMAP4]のセクション7.4.1で説明したように、それは自動的に、それらを調整しなければならないことを思い出しています。
If the server decides to send a new UIDVALIDITY value while the mailbox is opened, this causes resetting of the search variable to the empty list.
サーバーは、メールボックスが開いている間に、新しいUIDVALIDITY値を送信することを決定した場合、これは空のリストに検索変数のリセットが発生します。
Note that even if the "$" marker contains the empty list of messages, it must be treated by all commands accepting message sets as parameters as a valid, but non-matching list of messages. For example, the "FETCH $" command would return a tagged OK response and no FETCH responses. See also the Example 5 below.
「$」マーカーがメッセージの空のリストが含まれている場合でも、それはメッセージ受付が有効などのパラメータが、メッセージの非マッチングリストとして設定し、すべてのコマンドによって処理されなければならないことに注意してください。たとえば、「$をFETCH」コマンドは、タグ付きOK応答を返さないし、何の応答をFETCHでしょう。また、実施例5下記を参照してください。
Note that even if the "$" marker contains the empty list of messages, it must be treated as a valid but non-matching list of messages, by all commands that accept message sets as parameters.
「$」マーカーがメッセージの空のリストが含まれている場合でも、それはメッセージがパラメータとして設定されます受け入れるすべてのコマンドにより、メッセージの有効だが非マッチングリストとして扱われなければならないことに注意してください。
Implementation note: server implementors should note that "$" can reference IMAP message sequences or UID sequences, depending on the context where it is used. For example, the "$" marker can be set as a result of a SEARCH (SAVE) command and used as a parameter to a UID FETCH command (which accepts a UID sequence, not a message sequence), or the "$" marker can be set as a result of a UID SEARCH (SAVE) command and used as a parameter to a FETCH command (which accepts a message sequence, not a UID sequence).
実装上の注意：サーバーの実装は、「$」は、それが使用されるコンテキストに応じて、IMAPメッセージ・シーケンスまたはUIDシーケンスを参照できることに注意してください。例えば、「$」マーカーはSEARCH（SAVE）コマンドの結果として設定することができ、（UIDシーケンスではなく、メッセージシーケンスを受け入れる）UID FETCHコマンドのパラメータとして使用される、または「$」マーカーUID検索（SAVE）コマンドの結果として設定され、（メッセージ・シーケンスではなく、UIDシーケンスを受け入れる）FETCHコマンドのパラメータとして使用することができます。
1) The following example demonstrates how the client can use the result of a SEARCH command to FETCH headers of interesting messages:
1）次の例では、クライアントが面白いメッセージのヘッダを取得するために、検索コマンドの結果をどのように使用できるかを示しています。
Example 1: C: A282 SEARCH RETURN (SAVE) FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith" S: A282 OK SEARCH completed, result saved C: A283 FETCH $ (UID INTERNALDATE FLAGS RFC822.HEADER) S: * 2 FETCH (UID 14 ... S: * 84 FETCH (UID 100 ... S: * 882 FETCH (UID 1115 ... S: A283 OK completed
例1：C：A282の検索RETURN 1 - 2月 - 1994年は "スミス" SからではないSINCE FLAGGED（SAVE）：A282 OK SEARCH完了し、保存されたCの結果：A283 $ FETCH（UID INTERNALDATEのFLAGSをRFC822.HEADER）Sを：* FETCH 2 （UID 14 ... S：* 84（UID 100をFETCH ... S：* 882 ... UID 1115（SをFETCH：A283はOK完成します
The client can also pipeline the two commands:
また、クライアントは、パイプラインの二つのコマンドことができます：
Example 2: C: A282 SEARCH RETURN (SAVE) FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith" C: A283 FETCH $ (UID INTERNALDATE FLAGS RFC822.HEADER) S: A282 OK SEARCH completed S: * 2 FETCH (UID 14 ... S: * 84 FETCH (UID 100 ... S: * 882 FETCH (UID 1115 ... S: A283 OK completed
例2：C：1 - 2月 - 1994年以降NOT "スミス" CからのFLAGGED A282の検索RETURN（SAVE）：A283は、$（UID INTERNALDATEのFLAGSのRFC822.HEADER）SをFETCH：S完成A282 OK SEARCH：*（UID 14をFETCH 2 ... S：* 84 FETCH（UID 100 ... S：* 882 FETCH（UID 1115 ... S：A283はOK完成します
2) The following example demonstrates that the result of one SEARCH command can be used as input to another SEARCH command:
2）次の例は、1つの検索コマンドの結果は、別の検索コマンドへの入力として使用することができることを実証します。
Example 3: C: A300 SEARCH RETURN (SAVE) SINCE 1-Jan-2004 NOT FROM "Smith" S: A300 OK SEARCH completed C: A301 UID SEARCH UID $ SMALLER 4096 S: * SEARCH 17 900 901 S: A301 OK completed
例3：C：1月1日 - 2004年からNOT "スミス" S FROM A300の検索RETURN（SAVE）：A300 OK SEARCH完了C：A301 UID SEARCH UID SMALLER 4096 Sを$：* SEARCH 17 900 901 S：A301はOK完成
Note that the second command in Example 3 can be replaced with: C: A301 UID SEARCH $ SMALLER 4096 and the result of the command would be the same.
C：4096 A301 UIDの検索$小さく、コマンドの結果は同じになり、実施例3の2番目のコマンドはと交換することができることに注意してください。
3) The following example shows that the "$" marker can be combined with other message numbers using the OR SEARCH criterion.
3）次の例は、「$」マーカーがOR検索基準を使用して、他のメッセージ番号と組み合わせることができることを示しています。
Example 4: C: P282 SEARCH RETURN (SAVE) SINCE 1-Feb-1994 NOT FROM "Smith" S: P282 OK SEARCH completed C: P283 SEARCH CHARSET UTF-8 (OR $ 1,3000:3021) TEXT {8} C: YYYYYYYY S: * SEARCH 882 1102 3003 3005 3006 S: P283 OK completed
実施例4：C：P282を検索RETURN（SAVE）SINCE 1 - 02月1994 NOT FROM "スミス" S：P283 SEARCH CHARSET UTF-8（OR $ 1,3000：3021）TEXT {8} C P282 OK SEARCHはCを完了：YYYYYYYY S：* SEARCH 882 1102 3003 3005 3006 S：完成P283 OK
Note: Since this document format is restricted to 7-bit ASCII text, it is not possible to show actual UTF-8 data. The "YYYYYYYY" is a placeholder for what would be 8 octets of 8-bit data in an actual transaction.
注意：この文書フォーマットは7ビットのASCIIテキストに制限されているので、実際のUTF-8のデータを表示することはできません。 「YYYYYYYYは、」実際の取引では8ビットデータの8つのオクテットであるもののプレースホルダです。
4) The following example demonstrates that a failed SEARCH sets the search result variable to the empty list.
4）次の例では、失敗した検索は、空のリストへの変数の検索結果を設定することを実証します。
Example 5: C: B282 SEARCH RETURN (SAVE) SINCE 1-Feb-1994 NOT FROM "Smith" S: B282 OK SEARCH completed C: B283 SEARCH CHARSET KOI8-R (OR $ 1,3000:3021) TEXT {4} C: XXXX S: B283 NO [BADCHARSET UTF-8] KOI8-R is not supported //After this command the saved result variable contains //no messages. A client that wants to reissue the B283 //SEARCH command with another CHARSET would have to reissue //the B282 command as well. One possible workaround for //this is to include the desired CHARSET parameter //in the earliest SEARCH RETURN (SAVE) command in a //sequence of related SEARCH commands. //A better approach might be to always use CHARSET UTF-8 //instead.
実施例5：C：1 - 02月1994年NOT "スミス" SからB282を検索RETURN（SAVE）：B282 OK SEARCHがCを完了：B283 SEARCH CHARSET KOI8-R（OR $ 1,3000：3021）TEXT {4} C ：XXXX S：B283 NO [BADCHARSETのUTF-8] KOI8-Rがサポートされていませんが、//このコマンドの後保存された結果変数は//何もメッセージが含まれていません。別のCHARSETとB283 // SEARCHコマンドを再発行したいクライアントは、同様に// B282コマンドを再発行する必要があります。この//のための一つの可能な回避策は、関連する検索コマンドの//シーケンスの早い検索RETURN（SAVE）コマンドで//希望charsetパラメータを含めることです。 //より良いアプローチは常に//代わりにCHARSETのUTF-8を使用するのが良いかもしれません。
Note: Since this document format is restricted to 7-bit ASCII text, it is not possible to show actual KOI8-R data. The "XXXX" is a placeholder for what would be 4 octets of 8-bit data in an actual transaction.
注意：この文書フォーマットは7ビットのASCIIテキストに制限されているので、実際のKOI8-Rのデータを表示することはできません。 「XXXX」は、実際の取引の8ビットデータの4つのオクテットであるもののためのプレースホルダです。
5) The following example demonstrates that it is not an error to use the "$" marker when it contains no messages.
5）次の例では、それは何のメッセージが含まれていない場合、「$」マーカーを使用するとエラーではないことを示しています。
Example 6: C: E282 SEARCH RETURN (SAVE) SINCE 28-Oct-2006 NOT FROM "Eric" C: E283 COPY $ "Other Messages" //The "$" contains no messages S: E282 OK SEARCH completed S: E283 OK COPY completed, nothing copied
例6：C：28 10月 - 2006年以来E282検索RETURN（SAVE）NOT "エリック" C FROM：E283 COPY $ "その他のメッセージ" // "$" は何もメッセージのSが含まれていません：E283 OK：E282 OK SEARCHはSを完了COPY完了し、何もコピーされません
Use of a SEARCH RETURN (SAVE) command followed by a command using the "$" marker creates direct dependency between the two commands. As directed by Section 5.5 of [IMAP4], a server MUST execute the two commands in the order they were received. (A server capable of out-of-order execution can in some cases execute the two commands in parallel, for example, if a SEARCH RETURN (SAVE) is followed by "SEARCH $", the search criteria from the first command can be directly substituted into the second command.)
「$」マーカーを使用して、コマンドに続い検索RETURN（SAVE）コマンドを使用すると、二つのコマンド間の直接の依存関係を作成します。 [IMAP4]のセクション5.5の指示に従って、サーバは、それらが受信された順序で2つのコマンドを実行しなければなりません。 （アウトオブオーダー実行可能なサーバーがある場合には、並列に2つのコマンドを実行できる検索RETURN（SAVE）「を検索$」が続いている場合、例えば、最初のコマンドからの検索条件を直接することができ2番目のコマンドに置換されています。）
A client supporting this extension MAY pipeline a SEARCH RETURN (SAVE) command with one or more command using the "$" marker, as long as this doesn't create an ambiguity, as described in Section 5.5 of [IMAP4].
限り、[IMAP4]のセクション5.5で説明したように、これは、あいまいさを作成しないよう、「$」マーカーを使用して、1つの以上のコマンドで、この拡張MAYパイプライン検索RETURN（SAVE）コマンドをサポートするクライアント。
Example 7: C: F282 SEARCH RETURN (SAVE) KEYWORD $Junk C: F283 COPY $ "Junk" C: F284 STORE $ +FLAGS.Silent (\Deleted) S: F282 OK SEARCH completed S: F283 OK COPY completed S: F284 OK STORE completed
例7：C：F282の検索RETURN（SAVE）KEYWORD $ジャンクC：F283 COPY $ "ジャンク" C：F284ストア$ + FLAGS.SILENT（\削除済み）S：F283 OK COPYはSを完成：F284 Sを完成F282 OK検索OK STORE完成
Example 8: C: G282 SEARCH RETURN (SAVE) KEYWORD $Junk C: G283 SEARCH RETURN (ALL) SINCE 28-Oct-2006 FROM "Eric" //The server can execute the two SEARCH commands //in any order, as they don't have any dependency. //Note that the second command is making use of //the [ESEARCH] extension. S: * ESEARCH (TAG "G283") ALL 3:15,27,29:103 S: G283 OK SEARCH completed S: G282 OK SEARCH completed
例8：C：G282の検索RETURN（SAVE）KEYWORDの$ジャンクC： "エリック" // FROM 28 - 10月 - 2006年以来G283の検索RETURN（ALL）サーバは、彼らのように、任意の順序で// 2つの検索コマンドを実行することができますすべての依存関係を持っていません。 // 2番目のコマンドは、// [ESEARCH]拡張を利用していることに留意されたいです。 S：* ESEARCH（TAG "G283"）ALL 3：15,27,29：103 S：S完成G283 OK SEARCH：完成G282 OK検索
The following example demonstrates that the result of the second SEARCH always overrides the result of the first.
次の例では、2回目の検索の結果は常に最初の結果をオーバーライドすることを示しています。
Example 9: C: H282 SEARCH RETURN (SAVE) KEYWORD $Junk C: H283 SEARCH RETURN (SAVE) SINCE 28-Oct-2006 FROM "Eric" S: H282 OK SEARCH completed S: H283 OK SEARCH completed
例9：C：H282の検索RETURN（SAVE）KEYWORDの$ジャンクC：H283の検索RETURN（SAVE）28 - 10月 - 2006年から "エリック" S FROM：H283 OK検索が完了した：H282 OK検索がS完成
Servers that implement the extension defined in this document MUST implement [ESEARCH] and conform to additional requirements listed in this section.
この文書で定義された拡張を実装するサーバは、[ESEARCH]を実装し、このセクションに記載されている追加の要件に従わなければなりません。
The SAVE result option doesn't change whether the server would return items corresponding to MIN, MAX, ALL, or COUNT [ESEARCH] result options.
SAVE結果オプションは、サーバがMIN、MAX、ALLに対応するアイテムを返す、または[ESEARCH]結果のオプションをCOUNTかどうかは変更されません。
When the SAVE result option is combined with the MIN or MAX [ESEARCH] result option, and none of the other ESEARCH result options are present, the corresponding MIN/MAX is returned (if the search result is not empty), but the "$" marker would contain a single message as returned in the MIN/MAX return item.
SAVE結果オプションは、minまたはmax [ESEARCH]結果オプションと組み合わされ、そして他のESEARCH結果オプションのいずれも存在しない（検索結果が空でない場合）、対応するMIN / MAXが返されるが、「$場合「マーカーは、MIN / MAXの戻り項目に戻されるように、単一のメッセージが含まれます。
If the SAVE result option is combined with both MIN and MAX result options, and none of the other ESEARCH result options are present, the "$" marker would contain one or two messages as returned in the MIN/MAX return items.
SAVE結果オプションが両方MINとMAXの結果のオプションと組み合わせると、他のESEARCH結果のオプションのいずれも存在していない場合はMIN / MAXの戻り項目に戻されるように、「$」マーカーは、1つのまたは2つのメッセージが含まれます。
If the SAVE result option is combined with the ALL and/or COUNT result option(s), the "$" marker would always contain all messages found by the SEARCH or UID SEARCH command. (Note that the last rule might affect ESEARCH implementations that optimize how the COUNT result is constructed.)
SAVE結果オプションはALLおよび/またはCOUNT結果オプション（複数可）と組み合わされた場合は、「$」マーカーは、検索またはUID SEARCHコマンドによって検出されたすべてのメッセージを常に含んでいるでしょう。 （最後のルールは、COUNT結果が構築される方法を最適化するESEARCHの実装に影響を与える可能性があることに注意してください。）
The following table summarizes the additional requirement on ESEARCH server implementations described in this section.
次の表は、このセクションで説明ESEARCHサーバの実装上の追加要件をまとめたものです。
+----------------+-------------------+
| Combination of | "$" marker value |
| Result option | |
+----------------+-------------------+
| SAVE MIN | MIN |
+----------------+-------------------+
| SAVE MAX | MAX |
+----------------+-------------------+
| SAVE MIN MAX | MIN & MAX |
+----------------+-------------------+
| SAVE * [m] | all found messages|
+----------------+-------------------+
where '*' means "ALL" and/or "COUNT" '[m]' means optional "MIN" and/or "MAX"
'*'、 "ALL" を意味し、および/または "COUNT" '[m]は' オプションの "MIN" 及び/又は "MAX" を意味します
The following example demonstrates behavioral difference for different combinations of ESEARCH result options. Explanatory comments start with // and are not part of the protocol:
次の例では、ESEARCH結果オプションのさまざまな組み合わせのための行動の違いを示しています。説明のコメントは//で始まり、プロトコルの一部ではありません。
Example 10: C: C282 SEARCH RETURN (ALL) SINCE 12-Feb-2006 NOT FROM "Smith" S: * ESEARCH (TAG "C283") ALL 2,10:15,21 //$ value hasn't changed S: C282 OK SEARCH completed
例10：C：12年02月 - 2006年以来NOT "スミス" S FROM C282検索RETURN（ALL）：* ESEARCH（TAG "C283"）ALL 2,10：15,21 // $ valueがSを変更していません。 C282 OK SEARCHが完成します
C: C283 SEARCH RETURN (ALL SAVE) SINCE 12-Feb-2006
NOT FROM "Smith"
S: * ESEARCH (TAG "C283") ALL 2,10:15,21
//$ value is 2,10:15,21
S: C283 OK SEARCH completed
C: C284 SEARCH RETURN (SAVE MIN) SINCE 12-Feb-2006 NOT FROM "Smith" S: * ESEARCH (TAG "C284") MIN 2 //$ value is 2 S: C284 OK SEARCH completed
C：12年02月 - 2006年以来NOT "スミス" S FROM C284検索RETURN（MINを保存）：完成C284 OK SEARCH：* ESEARCH（TAG "C284"）MIN 2 // $値は2つのSです
C: C285 SEARCH RETURN (MAX SAVE MIN) SINCE 12-Feb-2006 NOT FROM "Smith" S: * ESEARCH (TAG "C285") MIN 2 MAX 21 //$ value is 2,21 S: C285 OK SEARCH completed
C：C285検索RETURN（MAX SAVE MIN）12 - 2月 - 2006年以来NOT "スミス" S FROM：完成C285 OK SEARCH：* ESEARCH（TAG "C285"）MIN 2 MAX 21 // $値は2,21 Sです
C: C286 SEARCH RETURN (MAX SAVE MIN COUNT) SINCE 12-Feb-2006 NOT FROM "Smith" S: * ESEARCH (TAG "C286") MIN 2 MAX 21 COUNT 8 //$ value is 2,10:15,21 S: C286 OK SEARCH completed
C：12年02月 - 2006年以来NOT "スミス" S FROM C286検索RETURN（MAX SAVE MINのCOUNT）：* ESEARCH（TAG "C286"）MIN 2 MAX 21 COUNT 8 // $値は2,10です：15,21 S：完成C286 OK検索
C: C286 SEARCH RETURN (ALL SAVE MIN) SINCE 12-Feb-2006 NOT FROM "Smith" S: * ESEARCH (TAG "C286") MIN 2 ALL 2,10:15,21 //$ value is 2,10:15,21 S: C286 OK SEARCH completed
C：12年02月 - 2006年以来NOT "スミス" S FROM C286検索RETURN（ALL SAVE MIN）：* ESEARCH（TAG "C286"）MIN 2 ALL 2,10：15,21 // $値は2,10です。 15,21 S：完成C286 OK検索
In some cases, the server MAY refuse to save a SEARCH (SAVE) result, for example, if an internal limit on the number of saved results is reached.
いくつかのケースでは、サーバーは、保存された結果の数の内部制限に達した場合、例えば、SEARCH（SAVE）の結果を保存するために拒否することができます。
In this case, the server MUST return a tagged NO response containing the NOTSAVED response code and set the search result variable to the empty sequence, as described in Section 2.1.
この場合、サーバはNOTSAVED応答コードを含む応答なしをタグ付けしていない、セクション2.1で説明したように、空の配列に検索結果変数のセットを返さなければなりません。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF]. Non-terminals referenced but not defined below are as defined in [IMAP4] or [IMAPABNF].
以下の構文仕様は、[ABNF]で指定された拡張バッカス・ナウアフォーム（ABNF）の表記を使用します。非端末は、参照ではなく、以下に定義される[IMAPABNF] [IMAP4]で定義または通りです。
Except as noted otherwise, all alphabetic characters are case-insensitive. The use of upper- or lower-case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion.
特記しないものを除いて、すべての英字は大文字と小文字を区別しません。トークン文字列を定義するための大文字または小文字の文字の使用は、編集上明確にするためです。実装は大文字と小文字を区別しないやり方で、これらの文字列を受け入れなければなりません。
capability =/ "SEARCHRES"
;; capability is defined in [IMAP4]
sequence-set =/ seq-last-command ;; extends sequence-set to allow for ;; "result of the last command" indicator.
シーケンスセット= /配列-最後のコマンド;;シーケンスセットを可能にするために拡張;;インジケータ「最後のコマンドの結果」。
seq-last-command = "$"
SEQ-最後のコマンド= "$"
search-return-opt = "SAVE" ;; conforms to generic search-return-opt ;; syntax defined in [IMAPABNF]
検索リターン-OPT = "SAVE" ;;一般的な検索リターン-OPTに準拠;; [IMAPABNF]で定義された構文
resp-text-code =/ "NOTSAVED" ;; <resp-text-code> from [IMAP4]
RESP-テキストコード= / "NOTSAVED" ;; <RESPテキストコード> [IMAP4]から
This extension requires the server to keep additional state, that may be used to simplify Denial of Service attacks. In order to minimize damage from such attacks, server implementations MAY limit the number of saved searches they allow across all connections at any given time and return the tagged NO response containing the NOTSAVED response code (see Section 2.5) to a SEARCH RETURN (SAVE) command when this limit is exceeded.
この拡張は、サービス妨害攻撃を簡素化するために使用することができる追加の状態を、維持するためにサーバを必要とします。このような攻撃による損傷を最小限にするために、サーバの実装は、任意の時点で、彼らはすべての接続で許可保存した検索の数を制限し、検索RETURNにNOTSAVED応答コードを含むタグ付けされた応答がない（セクション2.5を参照）（SAVE）を返さなくてもよいですコマンドこの制限を超えたとき。
Apart from that, it is believed that this extension doesn't raise any additional security concerns not already discussed in [IMAP4].
それとは別に、この拡張は、すでに[IMAP4]で議論されていない任意の追加的な安全保障上の懸念を提起しないと考えられています。
This document defines the "SEARCHRES" IMAP capability. IANA has added it to the IMAP4 Capabilities Registry, which is currently located at:
この文書では、「SEARCHRES」IMAP機能を定義します。 IANAは現在に配置されてIMAP4の機能のレジストリにこれを追加しました：
http://www.iana.org/assignments/imap4-capabilities
ｈっｔｐ：／／ｗっｗ。いあな。おｒｇ／あっしｇんめんｔｓ／いまｐ４ーかぱびぃちえｓ
The author would like to thank Mark Crispin, Cyrus Daboo, and Curtis King for remembering that this document had to be written, as well as for comments and corrections received.
著者は、この文書が書かなければならなかったことを覚えているため、だけでなく、コメントや訂正受信のためにマーク・クリスピン、サイラスDaboo、およびカーティス王に感謝したいと思います。
The author would also like to thank Dave Cridland, Mark Crispin, Chris Newman, Dan Karp, and Spencer Dawkins for comments and corrections received.
著者はまた、受け取ったコメントと修正のためにデーブCridland、マーク・クリスピン、クリス・ニューマン、ダン・カープ、およびスペンサードーキンスに感謝したいと思います。
Valuable comments, both in agreement and in dissent, were received from Arnt Gulbrandsen.
契約のと反対意見の両方の貴重なコメントは、ARNT Gulbrandsenのから受け取りました。
[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月。
[ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
、STD 68、RFC 5234、2008年1月： "ABNF構文仕様のための増大しているBNF" [ABNF]クロッカー、D.、エド、およびP. Overell、。。
[IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP4]クリスピン、M.、 "インターネットメッセージアクセスプロトコル - バージョン4rev1"、RFC 3501、2003年3月。
[IMAPABNF] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006.
[IMAPABNF]メルニコフ、A.およびC. Dabooは、RFC 4466、2006年4月 "IMAP4 ABNFへの拡張を集めました"。
[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拡張は、情報の種類が返されるどのような制御するためのコマンドを検索するために」。
[UIDPLUS] Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS extension", RFC 4315, December 2005.
[UIDPLUS]クリスピン、M.、 "インターネットメッセージアクセスプロトコル（IMAP） - UIDPLUS延長"、RFC 4315、2005年12月。
[SORT] Crispin, M. and K. Murchison, "INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS", Work in Progress, Septemeber 2007.
[SORT]クリスピン、M.とK.マーチソン、 "インターネットメッセージアクセスプロトコル - SORTとTHREAD拡張機能"、進歩、Septemeber 2007での作業。
Author's Address
著者のアドレス
Alexey Melnikov Isode Ltd. 5 Castle Business Village, 36 Station Road, Hampton, Middlesex, TW12 2BX, United Kingdom
アレクセイ・メルニコフISODE株式会社5つのキャッスルビジネス村、36の駅の道、ハンプトン、ミドルセックス、TW12 2BX、イギリス
EMail: Alexey.Melnikov@isode.com
メールアドレス：Alexey.Melnikov@isode.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。