[要約] RFC 5182は、IMAP拡張機能である「Referencing the Last SEARCH Result」についての規格です。このRFCの目的は、IMAPクライアントが直前のSEARCH操作の結果を参照できるようにすることです。
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
最後の検索結果を参照するためのIMAP拡張
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操作を使用して実現できます。ただし、これは次第にです。サーバーは、見つかったメッセージのリストをクライアントに送信します。その後、クライアントはリストを解析し、それを再フォーマットし、サーバーに送り返す必要があります。クライアントは、後続のコマンドで検索コマンドをパイプラインできず、その結果、サーバーはいくつかの最適化を実行できない可能性があります。
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.
このドキュメントでは、クライアントがサーバーに検索（または一意の識別子（UID）検索）コマンドの使用を使用するように指示できる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.
このドキュメントでは、クライアントがサーバーに検索（または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 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検索コマンドの結果を覚えているようにサーバーに指示する新しい検索結果オプション[IMAPABNF]「保存」を定義します（および検索に基づくコマンド、例えば、ソートとスレッド[ソート]）そして、それを「検索結果変数」として参照する内部変数に保存します。クライアントは、「$」マーカーを使用して、この内部変数のコンテンツを参照できます。「$」マーカーは、メッセージシーケンスまたはUIDシーケンスの代わりに使用できます。これは、サーバーが検索結果変数からのメッセージのリストに置き換える必要があることを示すためです。したがって、クライアントは、最新の記憶された検索コマンドの結果を別のコマンドのパラメーターとして使用できます。検索結果マーカーにはいくつかの利点があります。
* 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/search [imap4]またはuid expunge [uidplus]コマンドを使用して、[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;
* クライアントは、検索コマンドの結果を後続のコマンドで使用されるメッセージセットに再フォーマットする時間を費やす必要はありません。
* 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.
他の検索結果オプションがない場合、保存結果オプションは、検索コマンドによって返されたであろう検索応答も抑制します。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[キーワード]で説明されていると解釈されます。
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.
このドキュメントに記載されている検索結果参照拡張機能は、「検索」を機能させる機能コマンド応答の1つとして「検索」を返す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応答の後]または[検査]コマンドが正常に完了すると、現在の検索結果変数は空のシーケンスにリセットされます。
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 resultオプションを使用した成功した検索コマンドは、検索結果変数の値を検索コマンドにあるメッセージのリストに設定します。たとえば、メッセージが見つからなかった場合、検索結果変数には空のリストが含まれます。
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 サーバーが悪いタグ付き応答を返すようにした検索コマンド、
o a SEARCH command with no SAVE result option that caused the server to return NO tagged response,
o サーバーがタグ付き応答を返さないようにした[結果も保存されていない[結果]オプションのない検索コマンド、
o a successful SEARCH command with no SAVE result option.
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タグ付き応答を返す原因となった[結果も表示された[結果]オプションを使用した検索コマンドは、検索結果変数の値を空のシーケンスに設定します。
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.
メールボックスが開かれている間にサーバーが新しいuidialidity値を送信することを決定した場合、これにより検索変数が空のリストにリセットされます。
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応答を返し、フェッチ応答はありません。以下の例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シーケンスを参照できることに注意する必要があります。たとえば、「$」マーカーは、検索（保存）コマンドの結果として設定し、UID Fetchコマンド（メッセージシーケンスではなくUIDシーケンスを受け入れる）または「$」マーカーのパラメーターとして使用できます。UID検索（保存）コマンドの結果として設定し、Fetchコマンドのパラメーターとして使用できます（UIDシーケンスではなく、メッセージシーケンスを受け入れます）。
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
The client can also pipeline the two commands:
クライアントは、2つのコマンドをパイプラインすることもできます。
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) 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
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.
例3の2番目のコマンドは、c：a301 uid search $ small 4096に置き換えることができ、コマンドの結果は同じであることに注意してください。
3) The following example shows that the "$" marker can be combined with other message numbers using the OR SEARCH criterion.
3) 次の例は、「$」マーカーを、または検索基準を使用して他のメッセージ番号と組み合わせることができることを示しています。
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
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.
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
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.) 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].
「$」マーカーを使用するコマンドが続く検索リターン（SAVE）コマンドの使用は、2つのコマンド間に直接依存関係を作成します。[IMAP4]のセクション5.5が指示したように、サーバーは受信した順序で2つのコマンドを実行する必要があります。（順序外の実行が可能なサーバーは、場合によっては2つのコマンドを並行して実行できます。たとえば、検索リターン（保存）の後に「検索$」が続く場合、最初のコマンドからの検索基準は直接可能になります2番目のコマンドに置き換えます。）この拡張機能をサポートするクライアントは、「$」マーカーを使用して1つ以上のコマンドを使用して検索リターン（保存）コマンドをパイプラインすることができます。[IMAP4]。
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
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
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
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 resultオプションは、サーバーがmin、max、all、またはcount [esearch] resultオプションに対応するアイテムを返すかどうかを変更しません。
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.
保存結果オプションがMINまたはMAX [ESEarch]結果オプションと組み合わされ、他のESEACH結果オプションが存在しない場合、対応するMIN/MAXが返されます（検索結果が空でない場合）が、 "$「マーカーには、Min/Max Returnアイテムに返されるメッセージが含まれます。
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.
保存結果オプションが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.)
保存結果オプションがすべておよび/またはカウント結果オプションと組み合わされている場合、「$」マーカーには、検索またはUID検索コマンドによって見つかったすべてのメッセージが常に含まれます。（最後のルールは、カウント結果の構築方法を最適化するESEarchの実装に影響を与える可能性があることに注意してください。）
The following table summarizes the additional requirement on ESEARCH server implementations described in this section.
次の表は、このセクションで説明するESEarch Serverの実装に関する追加要件をまとめたものです。
+----------------+-------------------+
| 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"
ここで、「*」は「すべて」および/または「count」を意味します。
The following example demonstrates behavioral difference for different combinations of ESEARCH result options. Explanatory comments start with // and are not part of the protocol:
次の例は、検索結果オプションのさまざまな組み合わせの行動の違いを示しています。説明的なコメントは//で始まり、プロトコルの一部ではありません。
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
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: 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: 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: 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
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.
場合によっては、たとえば、保存された結果の数に内部制限に達した場合、サーバーは検索（保存）結果を保存することを拒否する場合があります。
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応答コードを含むタグ付きNO応答を返し、セクション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]で指定されているように、拡張されたBackus-Naurフォーム（ABNF）表記を使用します。参照されていないが、以下では定義されていない非末端は、[IMAP4]または[IMAPABNF]で定義されています。
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-last-command = "$"
search-return-opt = "SAVE"
;; conforms to generic search-return-opt
;; syntax defined in [IMAPABNF]
resp-text-code =/ "NOTSAVED"
;; <resp-text-code> from [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.
この拡張機能では、サーバーが追加の状態を維持する必要があります。これは、サービス拒否攻撃を簡素化するために使用される場合があります。このような攻撃からの損傷を最小限に抑えるために、サーバーの実装は、すべての接続で許可された保存された検索の数を任意の時間に制限し、NotSaved応答コード（セクション2.5を参照）を含むタグ付きNO応答を検索リターン（保存）に戻す場合があります（保存）この制限を超えた場合のコマンド。
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:
このドキュメントは、「検索」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.
著者は、マーククリスピン、サイラスダブー、カーティスキングに感謝し、この文書を書いただけでなく、コメントや修正を受けたことを思い出してくれたことに感謝します。
The author would also like to thank Dave Cridland, Mark Crispin, Chris Newman, Dan Karp, and Spencer Dawkins for comments and corrections received.
著者はまた、コメントと修正について、デイブ・クリッドランド、マーク・クリスピン、クリス・ニューマン、ダン・カープ、スペンサー・ドーキンスに感謝したいと思います。
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.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.
[ABNF] Crocker、D.、ed。、およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、STD 68、RFC 5234、2008年1月。
[IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP4] Crispin、M。、「インターネットメッセージアクセスプロトコル -バージョン4REV1」、RFC 3501、2003年3月。
[IMAPABNF] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006.
[Imapabnf] Melnikov、A。and C. daboo、「拡張機能をIMAP4 ABNFに収集しました」、RFC 4466、2006年4月。
[ESEARCH] Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned", RFC 4731, November 2006.
[Esearch] Melnikov、A。、およびD. Cridland、「IMAP4拡張は、どのような種類の情報が返されるかを制御するための検索コマンドへ」、RFC 4731、2006年11月。
[UIDPLUS] Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS extension", RFC 4315, December 2005.
[uidplus] Crispin、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] Crispin、M。and K. Murchison、「インターネットメッセージアクセスプロトコル - ソートおよびスレッド拡張機能」、Work in Progress、Peptemeber 2007。
Author's Address
著者の連絡先
Alexey Melnikov Isode Ltd. 5 Castle Business Village, 36 Station Road, Hampton, Middlesex, TW12 2BX, United Kingdom
Alexey Melnikov Isode Ltd. 5 Castle Business Village、36 Station Road、Hampton、Middlesex、TW12 2BX、英国
EMail: Alexey.Melnikov@isode.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。