RFC 5032 - WITHIN Search Extension to the IMAP Protocol 日本語訳

URL : https://tools.ietf.org/html/rfc5032
タイトル : RFC 5032 - IMAPプロトコルに検索拡張WITHIN
翻訳編集 : 自動生成

Network Working Group                                     E. Burger, Ed.
Request for Comments: 5032                             BEA Systems, Inc.
Updates: 3501                                             September 2007
Category: Standards Track

              WITHIN Search Extension to the IMAP Protocol

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

抽象

This document describes the WITHIN extension to IMAP SEARCH. IMAP SEARCH returns messages whose internal date is within or outside a specified interval. The mechanism described here, OLDER and YOUNGER, differs from BEFORE and SINCE in that the client specifies an interval, rather than a date. WITHIN is useful for persistent searches where either the device does not have the capacity to perform the search at regular intervals or the network is of limited bandwidth and thus there is a desire to reduce network traffic from sending repeated requests and redundant responses.

この文書は、IMAP検索にWITHIN拡張について説明します。 IMAP検索は、その内部日付内または指定した間隔外にあるメッセージを返します。ここで説明するメカニズムは、古く、ヤンガー、以前から異なり、その中SINCEクライアントではなく、日付よりも、間隔を指定します。 WITHINデバイスは定期的に検索を実行する能力を持っていないか、ネットワークが限られた帯域幅であるため、繰り返し要求と冗長レスポンスを送信ネットワークトラフィックを削減したいがあるいずれかの持続検索するのに便利です。

1. Introduction

1. はじめに

This extension exposes two new search keys, OLDER and YOUNGER, each of which takes a non-zero integer argument corresponding to a time interval in seconds. The server calculates the time of interest by subtracting the time interval the client presents from the current date and time of the server. The server then either returns messages older or younger than the resultant time and date, depending on the search key used.

この拡張は、秒単位の時間間隔に対応する非ゼロの整数引数を取り、それぞれが古く、ヤンガー二つの新しい検索キーを、公開しています。サーバは、クライアントがサーバの現在の日付と時刻から提示時間間隔を減算することにより、関心の時間を算出します。その後、サーバは、使用される検索キーに応じて、得られる時刻と日付より古い歳以下のメッセージを返しますどちらか。

1.1. Conventions Used in This Document

1.1. このドキュメントの表記規則

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 [RFC2119].

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。

When describing the general syntax, we omit some definitions, as RFC 3501 [RFC3501] defines them.

一般的な構文を記述する場合、RFC 3501 [RFC3501]は、それらを定義するように、我々は、いくつかの定義を省略します。

2. Protocol Operation

2.プロトコル動作

An IMAP4 server that supports the capability described here MUST return "WITHIN" as one of the server supported capabilities in the CAPABILITY command.

ここで説明する機能をサポートしているIMAP4サーバは、CAPABILITYコマンドでサーバーサポート機能の一つとして「WITHIN」返さなければなりません。

For both the OLDER and YOUNGER search keys, the server calculates a target date and time by subtracting the interval, specified in seconds, from the current date and time of the server. The server then compares the target time with the INTERNALDATE of the message, as specified in IMAP [RFC3501]. For OLDER, messages match if the INTERNALDATE is less recent than or equal to the target time. For YOUNGER, messages match if the INTERNALDATE is more recent than or equal to the target time.

OLDERより若い検索キーの両方のために、サーバは、サーバの現在の日付と時刻から、秒単位で指定された間隔を減算することにより目標の日付と時間を算出します。 IMAP [RFC3501]で指定されるように、サーバは、次いで、メッセージのINTERNALDATEと目標時間とを比較します。 INTERNALDATE未満最近または目標時間と等しい場合OLDERのために、メッセージが一致します。 INTERNALDATEがより最近のまたは目標時間と等しい場合YOUNGERのために、メッセージが一致します。

Both OLDER and YOUNGER searches always result in exact matching, to the resolution of a second. However, if one is doing a dynamic evaluation, for example, in a context [CONTEXT], one needs to be aware that the server might perform the evaluation periodically. Thus, the server may delay the updates. Clients MUST be aware that dynamic search results may not reflect the current state of the mailbox. If the client needs a search result that reflects the current state of the mailbox, we RECOMMEND that the client issue a new search.

両方OLDERより若い検索は常に第二の解像度に、正確なマッチングをもたらします。しかし、1は例えば、動的な評価を行っている場合は、コンテキスト[CONTEXT]で、1は、サーバが定期的に評価を行う可能性があることを認識する必要があります。このように、サーバはアップデートを遅らせる可能性があります。クライアントは、動的な検索結果がメールボックスの現在の状態を反映していない可能性があることに注意しなければなりません。クライアントがメールボックスの現在の状態を反映した検索結果を必要とする場合、我々は、クライアントが新しい検索を発行することをお勧めします。

3. Formal Syntax

3.正式な構文

The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation. Elements not defined here can be found in the formal syntax of ABNF [RFC4234] and IMAP [RFC3501].

次の構文仕様は、拡張バッカス・ナウアフォーム（ABNF）の表記を使用します。ここで定義されていない要素はABNF [RFC4234]とIMAP [RFC3501]の正式な構文で見つけることができます。

This document extends RFC 3501 [RFC3501] with two new search keys: OLDER <interval> and YOUNGER <interval>.

OLDER <間隔>とヤンガー<間隔>：この文書は、2つの新しい検索キーとRFC 3501 [RFC3501]を拡張します。

search-key =/ ( "OLDER" / "YOUNGER" ) SP nz-number ; search-key defined in RFC 3501

検索キー= /（ "OLDER" / "YOUNGER"）SPのNZ-番号。 RFC 3501で定義された検索キー

4. Example

4.例

C: a1 SEARCH UNSEEN YOUNGER 259200 S: a1 * SEARCH 4 8 15 16 23 42

C：A1 * SEARCH 4 8 15 16 23 42：検索がUNSEEN YOUNGER 259200のS A1

Search for all unseen messages within the past 3 days, or 259200 seconds, according to the server's current time.

サーバーの現在の時刻に応じて、過去3日間、または259200秒以内にすべての見えないメッセージを検索します。

5. Security Considerations

5.セキュリティについての考慮事項

The WITHIN extension does not raise any security considerations that are not present in the base protocol. Considerations are the same as for IMAP [RFC3501].

WITHIN拡張は基本プロトコルに存在しない任意のセキュリティ上の考慮事項は発生しません。考慮事項は、IMAP [RFC3501]と同じです。

6. IANA Considerations

6. IANAの考慮事項

Per the IMAP RFC [RFC3501], registration of a new IMAP capability in the IMAP Capability registry requires the publication of a standards-track RFC or an IESG approved experimental RFC. The registry is currently located at <http://www.iana.org/assignments/imap4-capabilities>. This standards-track document defines the WITHIN IMAP capability. IANA has added this extension to the IANA IMAP Capability registry.

IMAP RFC [RFC3501]あたり、IMAP能力レジストリに新しいIMAP機能の登録は標準トラックRFCの公表を必要とするか、またはIESGは実験的なRFCを承認しました。レジストリは、現在、<http://www.iana.org/assignments/imap4-capabilities>に位置しています。この標準化過程文書は、WITHIN IMAP機能を定義します。 IANAはIANA IMAP能力のレジストリにこの拡張機能を追加しました。

7. References

7.参考

7.1. Normative References

7.1. 引用規格

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997.

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、RFC 2119、BCP 14、1997年3月。

[RFC3501] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, March 2003.

[RFC3501]のCrispin、M.、 "インターネットメッセージアクセスプロトコル - バージョン4rev1"、RFC 3501、2003年3月。

[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.

[RFC4234]クロッカー、D.、エド。そして、P. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 4234、2005年10月。

7.2. Informative References

7.2. 参考文献

[CONTEXT] Melnikov, D. and C. King, "Contexts for IMAP4", Work in Progress, May 2006.

[CONTEXT]メルニコフ、D.およびC.王、 "IMAP4のためのコンテキスト"、進歩、2006年5月での作業。

Appendix A. Contributors

付録A.協力者

Stephane Maes and Ray Cromwell wrote the original version of this document as part of P-IMAP, as well as the first versions for the IETF. From an attribution perspective, they are clearly authors.

ステファンマースとレイ・クロムウェルは、P-IMAPの一部としてこのドキュメントのオリジナルバージョン、ならびにIETFのための最初のバージョンを書きました。帰属の観点から、彼らは明らかに作者です。

Appendix B. Acknowledgements

付録B.謝辞

The authors want to thank all who have contributed key insight and who have extensively reviewed and discussed the concepts of LPSEARCH. They also thank the authors of its early introduction in P-IMAP.

著者は、キー洞察力を貢献してきたし、誰が広範囲に検討し、LPSEARCHの概念を議論してきたすべての人に感謝したいと思います。彼らはまた、P-IMAPでの早期導入の作者に感謝します。

We also want to give a special thanks to Arnt Gilbrandsen, Ken Murchison, Zoltan Ordogh, and most especially Dave Cridland for their review and suggestions. A special thank you goes to Alexey Melnikov for his choice submission of text.

我々はまた、彼らのレビューと提案のためARNT Gilbrandsen、ケンマーチソン、ゾルタンOrdogh、最も特にデーブCridlandに特別な感謝を与えたいです。特別では、テキストの彼の選択の提出のためのアレクセイ・メルニコフに行く感謝します。

Author's Address

著者のアドレス

Eric W. Burger (editor) BEA Systems, Inc. USA

エリック・W.バーガー（編集者）BEA Systems、Inc.の米国

EMail: eric.burger@bea.com URI: http://www.standardstrack.com

電子メール：eric.burger@bea.com URI：http://www.standardstrack.com

Full Copyright Statement

完全な著作権声明

著作権（C）IETFトラスト（2007）。

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に情報を記述してください。