Network Working Group A. Melnikov
Request for Comments: 4731 Isode Ltd
Category: Standards Track D. Cridland
Inventure Systems Ltd
November 2006
IMAP4 Extension to SEARCH Command for Controlling
What Kind of Information Is Returned
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）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（2006）。
Abstract
抽象
This document extends IMAP (RFC 3501) SEARCH and UID SEARCH commands with several result options, which can control what kind of information is returned. The following result options are defined: minimal value, maximal value, all found messages, and number of found messages.
この文書は、IMAP（RFC 3501）は、検索を拡張し、UID検索は、情報の種類が返されるかを制御することができ、いくつかの結果オプションとコマンド。次の結果オプションが定義されています：最小限値、最大値、見つかったすべてのメッセージ、および見つかったメッセージの数を。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. IMAP Protocol Changes ...........................................2
3.1. New SEARCH/UID SEARCH Result Options .......................2
3.2. Interaction with CONDSTORE extension .......................4
4. Formal Syntax ...................................................5
5. Security Considerations .........................................6
6. IANA Considerations .............................................6
7. Normative References ............................................6
8. Acknowledgments .................................................6
[IMAPABNF] extended SEARCH and UID SEARCH commands with result specifiers (also known as result options), which can control what kind of information is returned.
【IMAPABNF]返される情報の種類を制御することができる結果指定子（また結果オプションとしても知られている）で検索し、UID検索コマンドを拡張しました。
A server advertising the ESEARCH capability supports the following result options: minimal value, maximal value, all found messages, and number of found messages. These result options allow clients to get SEARCH results in more convenient forms, while also saving bandwidth required to transport the results, for example, by finding the first unseen message or returning the number of unseen or deleted messages. Also, when a single MIN or a single MAX result option is specified, servers can optimize execution of SEARCHes.
最小限値、最大値、見つかったすべてのメッセージ、および見つかったメッセージの数：ESEARCH機能を広告するサーバーは、次の結果オプションをサポートしています。これらの結果オプションも最初に目に見えないメッセージを見つけたり、目に見えないか、削除されたメッセージの数を返すことによって、例えば、結果を輸送するために必要な帯域幅を節約しながら、クライアントは、より便利な形で検索結果を取得することができます。単一MINまたは単一MAX結果オプションが指定された場合も、サーバは、検索の実行を最適化することができます。
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively.
実施例において、「C：」および「S：」は、それぞれ、クライアントとサーバによって送信されたラインを示します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [KEYWORDS]で説明されるように解釈されます。
The SEARCH/UID SEARCH commands are extended to allow for the following result options:
SEARCH / UIDの検索コマンドは、次の結果オプションを可能にするように拡張されています。
MIN Return the lowest message number/UID that satisfies the SEARCH criteria.
MINは、検索基準を満たす最小のメッセージ番号/ UIDを返します。
If the SEARCH results in no matches, the server MUST NOT include the MIN result option in the ESEARCH response; however, it still MUST send the ESEARCH response.
ノー試合で検索結果場合は、サーバーはESEARCH応答でMIN結果オプションを含んではいけません。しかし、それはまだESEARCH応答を送らなければなりません。
MAX Return the highest message number/UID that satisfies the SEARCH criteria.
MAX戻り、検索条件を満たす最高のメッセージ番号/ UID。
If the SEARCH results in no matches, the server MUST NOT include the MAX result option in the ESEARCH response; however, it still MUST send the ESEARCH response.
ノー試合で検索結果場合は、サーバーはESEARCH応答でMAXの結果オプションを含んではいけません。しかし、それはまだESEARCH応答を送らなければなりません。
ALL Return all message numbers/UIDs that satisfy the SEARCH criteria. Unlike regular (unextended) SEARCH, the messages are always returned using the sequence-set syntax. A sequence-set representation may be more compact and can be used as is in a subsequent command that accepts sequence-set. Note, the client MUST NOT assume that messages/UIDs will be listed in any particular order.
ALLは、検索基準を満たすすべてのメッセージ番号/ UIDを返します。通常の（未伸長）検索とは異なり、メッセージは常にシーケンスセットの構文を使用して返されます。シーケンスセット表現をよりコンパクトにすることができ、シーケンスセットを受け入れ、後続のコマンドであるとして使用することができます。クライアントは、メッセージ/ UIDのは、特定の順序でリストされると仮定してはいけません、注意してください。
If the SEARCH results in no matches, the server MUST NOT include the ALL result option in the ESEARCH response; however, it still MUST send the ESEARCH response.
ノー試合で検索結果場合は、サーバーはESEARCH応答でALL結果オプションを含んではいけません。しかし、それはまだESEARCH応答を送らなければなりません。
COUNT Return number of the messages that satisfy the SEARCH criteria. This result option MUST always be included in the ESEARCH response.
検索基準を満たすメッセージの戻り数を数えます。この結果オプションは、常にESEARCH応答に含まれなければなりません。
If one or more result options described above are specified, the extended SEARCH command MUST return a single ESEARCH response [IMAPABNF], instead of the SEARCH response.
上記1つ以上の結果オプションが指定されている場合、拡張検索コマンドは、代わりにSEARCH応答の、単一ESEARCH応答[IMAPABNF]を返さなければなりません。
An extended UID SEARCH command MUST cause an ESEARCH response with the UID indicator present.
拡張UID SEARCHコマンドは、UIDインジケーターの存在とESEARCH応答を引き起こす必要があります。
Note that future extensions to this document can allow servers to return multiple ESEARCH responses for a single extended SEARCH command. These extensions will have to describe how results from multiple ESEARCH responses are to be amalgamated.
このドキュメントへの将来の拡張は、サーバーが単一の拡張SEARCHコマンドに対して複数のESEARCH応答を返すできるようにすることができますことに注意してください。これらの拡張機能は、複数のESEARCH応答の結果が合併される方法を説明する必要があります。
If the list of result options is empty, that requests the server to return an ESEARCH response instead of the SEARCH response. This is equivalent to "(ALL)".
結果オプションのリストが空の場合、それは代わりに、検索応答のESEARCH応答を返すようにサーバに要求します。これは、「（ALL）」に相当します。
Example: C: A282 SEARCH RETURN (MIN COUNT) FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith" S: * ESEARCH (TAG "A282") MIN 2 COUNT 3 S: A282 OK SEARCH completed
例：C：1 - 2月 - 1994年以降NOT "スミス" SからFLAGGED A282の検索RETURN（MINのCOUNT）：* ESEARCH（TAG "A282"）MIN 2 COUNT 3 S：完成A282 OK検索
Example: C: A283 SEARCH RETURN () FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith" S: * ESEARCH (TAG "A283") ALL 2,10:11 S: A283 OK SEARCH completed
例：C：A283の検索RETURN（）1 - 2月 - 1994年以降NOT "スミス" SからFLAGGED：* ESEARCH（TAG "A283"）ALL 2,10：11 S：完成A283 OK検索
The following example demonstrates finding the first unseen message as returned in the UNSEEN response code on a successful SELECT command:
次の例では、成功したSELECTコマンドでUNSEEN応答コードに返される最初の目に見えないメッセージを見つけることを示しています。
Example: C: A284 SEARCH RETURN (MIN) UNSEEN S: * ESEARCH (TAG "A284") MIN 4 S: A284 OK SEARCH completed
例：C：A284の検索RETURN（MIN）UNSEEN S：* ESEARCH（TAG "A284"）MIN 4 S：A284 OK SEARCHが完成します
The following example demonstrates that if the ESEARCH UID indicator is present, all data in the ESEARCH response is referring to UIDs; for example, the MIN result specifier will be followed by a UID.
次の例では、ESEARCH UIDインジケータが存在する場合、ESEARCH応答のすべてのデータがUIDを参照していることを示しています。例えば、MIN結果指定子は、UIDが続きます。
Example: C: A285 UID SEARCH RETURN (MIN MAX) 1:5000 S: * ESEARCH (TAG "A285") UID MIN 7 MAX 3800 S: A285 OK SEARCH completed
例：C：A285 UIDを検索RETURN（MIN MAX）1：5000 S：* ESEARCH（TAG "A285"）UID MIN 7 MAX 3800 S：終了A285 OK SEARCH
The following example demonstrates returning the number of deleted messages:
次の例では、削除されたメッセージの数を返す示しています。
Example: C: A286 SEARCH RETURN (COUNT) DELETED S: * ESEARCH (TAG "A286") COUNT 15 S: A286 OK SEARCH completed
例：C：A286の検索RETURN（COUNT）DELETED S：* ESEARCH（TAG "A286"）COUNT 15 S：完成A286 OK検索
When the server supports both the ESEARCH and the CONDSTORE [CONDSTORE] extension, and the client requests one or more result option described in section 3.1 together with the MODSEQ search criterion in the same SEARCH/UID SEARCH command, then the server MUST return the ESEARCH response containing the MODSEQ result option (described in the following paragraph) instead of the extended SEARCH response described in section 3.5 of [CONDSTORE].
サーバがESEARCHとCONDSTORE [CONDSTORE]拡張機能の両方をサポートし、クライアントが同じSEARCH / UID SEARCHコマンドでMODSEQ検索条件と一緒にセクション3.1で説明した1つ以上の結果オプションを要求すると、サーバはESEARCHを返さなければなりません（次の段落で説明）MODSEQ結果オプションの代わりに[CONDSTORE]のセクション3.5に記載の拡張された検索応答を含む応答。
If the SEARCH/UID SEARCH command contained a single MIN or MAX result option, the MODSEQ result option contains the mod-sequence for the found message. If the SEARCH/UID SEARCH command contained both MIN and MAX result options and no ALL/COUNT option, the MODSEQ result option contains the highest mod-sequence for the two returned messages. Otherwise the MODSEQ result option contains the highest mod-sequence for all messages being returned.
SEARCH / UID SEARCHコマンドは、単一のMINまたはMAXの結果オプションが含まれていた場合、MODSEQ結果オプションが見つかりました。メッセージのMOD-配列を含みます。 SEARCH / UID SEARCHコマンドは、両方のMINとMAXの結果オプションなしALL / COUNTオプションが含まれていた場合、MODSEQ結果オプションは、2つのメッセージを返したため、最高のmod-配列を含みます。それ以外の場合はMODSEQ結果オプションは、返されるすべてのメッセージのための最高のmod-配列を含みます。
Example: The following example demonstrates how Example 15 from [CONDSTORE] would look in the presence of one or more result option:
例：以下の例では、例15 [CONDSTORE]からすると、1つ以上の結果オプションの存在下でどのように見えるかを示しています。
C: a1 SEARCH RETURN (MIN) MODSEQ "/flags/\\draft"
all 620162338
S: * ESEARCH (TAG "a1") MIN 2 MODSEQ 917162488
S: a1 OK Search complete
C: a2 SEARCH RETURN (MAX) MODSEQ "/flags/\\draft" all 620162338 S: * ESEARCH (TAG "a2") MAX 23 MODSEQ 907162321
C：A2検索RETURN（MAX）MODSEQ "/旗/ \\草案" すべて620162338 S：* ESEARCH（TAG "A2"）MAX 23 MODSEQ 907162321
S: a2 OK Search complete
S：完全A2 OK検索
C: a3 SEARCH RETURN (MIN MAX) MODSEQ "/flags/\\draft" all 620162338 S: * ESEARCH (TAG "a3") MIN 2 MAX 23 MODSEQ 917162488 S: a3 OK Search complete
C：A3検索RETURN（MIN MAX）MODSEQ "/旗/ \\草案" すべて620162338 S：* ESEARCH（TAG "A3"）MIN 2 MAX 23 MODSEQ 917162488 S：A3 OK完全な検索
C: a4 SEARCH RETURN (MIN COUNT) MODSEQ "/flags/\\draft" all 620162338 S: * ESEARCH (TAG "a4") MIN 2 COUNT 10 MODSEQ 917162500 S: a4 OK Search complete
C：A4検索RETURN（MINのCOUNT）MODSEQ "/旗/ \\草案" すべて620162338 S：* ESEARCH（TAG "A4"）MIN 2 COUNT 10 MODSEQ 917162500 S：A4 OK完全な検索
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF].
以下の構文仕様は、[ABNF]で指定された拡張バッカス・ナウアフォーム（ABNF）の表記を使用します。
Non-terminals referenced but not defined below are as defined by [IMAP4], [CONDSTORE], or [IMAPABNF].
非端末は、参照が、以下に定義されていない[IMAPABNF] [IMAP4]で定義されるように[CONDSTORE]、であるか、または。
Except as noted otherwise, all alphabetic characters are case-insensitive. The use of upper or lowercase characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion.
特記しないものを除いて、すべての英字は大文字と小文字を区別しません。トークン文字列を定義するには、上または小文字の使用は、編集上明確にするためです。実装は大文字と小文字を区別しないやり方で、これらの文字列を受け入れなければなりません。
capability =/ "ESEARCH"
機能= / "ESEARCH"
search-return-data = "MIN" SP nz-number / "MAX" SP nz-number / "ALL" SP sequence-set / "COUNT" SP number ;; conforms to the generic ;; search-return-data syntax defined ;; in [IMAPABNF]
検索リターンデータ= "MIN" SPのNZ-番号/ "MAX" SP NZ-番号/ "ALL" SPシーケンスセット/ "COUNT" SP番号;;ジェネリックに準拠;;検索・リターン・データの構文定義された;; [IMAPABNF]で
search-return-opt = "MIN" / "MAX" / "ALL" / "COUNT" ;; conforms to generic search-return-opt ;; syntax defined in [IMAPABNF]
検索リターン-OPT = "MIN" / "MAX" / "ALL" / "COUNT" ;;一般的な検索リターン-OPTに準拠;; [IMAPABNF]で定義された構文
When the CONDSTORE [CONDSTORE] IMAP extension is also supported, the ABNF is updated as follows:
CONDSTORE [CONDSTORE] IMAP拡張もサポートされている場合、次のように、ABNFが更新されます。
search-return-data =/ "MODSEQ" SP mod-sequence-value ;; mod-sequence-value is defined ;; in [CONDSTORE]
検索リターンデータ= /「MODSEQ」SP modのシーケンス値;; MOD-シーケンス値が定義されている;; [CONDSTORE]で
In the general case, the IMAP SEARCH/UID SEARCH commands can be CPU and/or IO intensive, and are seen by some as a potential attack point for denial of service attacks, so some sites/implementations even disable them entirely. This is quite unfortunate, as SEARCH command is one of the best examples demonstrating IMAP advantage over POP3.
一般的なケースでは、IMAP SEARCH / UIDの検索コマンドは、CPUおよび/またはIO集中する可能性があり、サービス拒否攻撃のための潜在的な攻撃点としていくつかによって見られているので、いくつかのサイト/実装でもそれらを完全に無効にします。 SEARCHコマンドは、POP3の上にIMAPの利点を実証する最も良い例の一つであるとして、これは、非常に残念なことです。
The ALL and COUNT return options don't change how SEARCH is working internally; they only change how information about found messages is returned. MIN and MAX SEARCH result options described in this document can lighten the load on IMAP servers that choose to optimize SEARCHes containing only one or both of them.
ALLとCOUNTリターンオプションは、検索が内部的に取り組んでいる方法を変更しないでください。彼らは唯一見つかったメッセージに関する情報が返される方法を変更します。この文書で説明MINとMAXの検索結果のオプションは、1つまたはそれらの両方を含む検索を最適化することを選択したIMAPサーバーの負荷を軽減することができます。
It is believed that this extension doesn't raise any additional security concerns not already discussed in [IMAP4].
この拡張機能は、すでに[IMAP4]で議論されていない任意の追加的な安全保障上の懸念を提起しないと考えられています。
IMAP4 capabilities are registered by publishing a standards track RFC or an IESG-approved experimental RFC. The registry is currently located at <http://www.iana.org/assignments/imap4-capabilities>.
IMAP4機能は標準トラックRFCまたはIESGが承認した実験的RFCを公開することにより、登録されています。レジストリは、現在、<http://www.iana.org/assignments/imap4-capabilities>に位置しています。
This document defines the ESEARCH IMAP capability, which IANA added to the registry.
このドキュメントは、IANAレジストリに追加ESEARCHのIMAP機能を定義します。
[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月。
[IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP4]クリスピン、M.、 "インターネットメッセージアクセスプロトコル - バージョン4rev1"、RFC 3501、2003年3月。
[ABNF] Crocker, D. (Ed.) and P. Overell , "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
"構文仕様のための増大しているBNF：ABNF" [ABNF]クロッカー、D.（エド。）及びP. Overell、RFC 4234、2005年10月。
[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への拡張を集めました" ..
[CONDSTORE] Melnikov, A. and S. Hole, "IMAP Extension for Conditional STORE", RFC 4551, June 2006.
[CONDSTORE]メルニコフ、A.とS.ホール、 "条件付きSTOREためのIMAP拡張"、RFC 4551、2006年6月。
Thanks to Michael Wener, Arnt Gulbrandsen, Cyrus Daboo, Mark Crispin, and Pete Maclean for comments and corrections.
コメントと修正のためにマイケルWener、ARNT Gulbrandsenの、サイラスDaboo、マーク・クリスピン、そしてピートマクリーンに感謝します。
Authors' Addresses
著者のアドレス
Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex, TW12 2BX UK
アレクセイ・メルニコフISODE限定5キャッスルビジネス村の36の駅道ハンプトン、ミドルセックス、TW12 2BX英国
EMail: Alexey.Melnikov@isode.com
メールアドレス：Alexey.Melnikov@isode.com
Dave A. Cridland Inventure Systems Limited
デイブA. Cridlandインベンチュアシステムズ株式会社
EMail: dave.cridland@inventuresystems.co.uk URL: http://invsys.co.uk/dave/
メールアドレス：dave.cridland@inventuresystems.co.uk URL：http://invsys.co.uk/dave/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（2006）。
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彼/彼女が表すOR（もしあれば）後援が「そのまま」、インターネット学会、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.
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に情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。