RFC5032 日本語訳

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

エド、ワーキンググループE.バーガーをネットワークでつないでください。コメントのために以下を要求してください。 5032のBEAシステムInc.アップデート: 3501 2007年9月のカテゴリ: 標準化過程

              WITHIN Search Extension to the IMAP Protocol

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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

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.

このドキュメントはWITHIN拡張子についてIMAP SEARCHに説明します。 IMAP SEARCHは間隔以内か指定された間隔の外に、内部の期日があるメッセージを返します。 ここで説明されたメカニズム(オールダーとYOUNGER)は、クライアントが日付よりむしろ間隔を指定するという点においてBEFOREと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.

この拡大は2個の新しい検索キー、オールダー、およびYOUNGERをさらします。それはそれぞれ秒で時間間隔に対応する非ゼロ整数議論を取ります。 サーバは、クライアントがサーバの現在の日時から提示する時間間隔を引き算することによって、興味がある時間について計算します。次に、サーバは使用される検索キーによる結果の時間と期日よりさらに古いか若いメッセージを返します。

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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?

Burger                      Standards Track                     [Page 1]

RFC 5032                     Search Within                September 2007

2007年9月中にバーガー標準化過程[1ページ]RFC5032検索

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

一般的な構文について説明するとき、RFC3501[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.

サーバの1つが能力コマンドにおける能力をサポートしたので、ここで説明された能力をサポートするIMAP4サーバは“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.

オールダーとYOUNGER検索キーの両方に関しては、サーバはサーバの現在の日時から間隔を引き算するのによる秒指定された目標期日と時間について計算します。次に、サーバはメッセージのINTERNALDATEと目標時間を比べます、IMAP[RFC3501]で指定されるように。 オールダーに関しては、INTERNALDATEが目標時間と最近でないのも、またはあまり等しくないなら、メッセージは合っています。 YOUNGERに関しては、INTERNALDATEが目標時間と最近である、または等しいなら、メッセージは合っています。

   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.

オールダーとYOUNGER検索の両方がいつも1秒の解決への正確なマッチングをもたらします。 しかしながら、例えば、1つが文脈[CONTEXT]で動的評価法をしているなら、人は、サーバが定期的に評価を実行するかもしれないのを意識している必要があります。 したがって、サーバはアップデートを遅らせるかもしれません。 クライアントはダイナミックな検索結果がメールボックスの現状を反映しないかもしれないのを意識しているに違いありません。 クライアントが検索結果を必要とするなら、それはメールボックスの現状を反映して、私たちはクライアントが新しい検索を発行するRECOMMENDです。

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

以下の構文仕様はAugmented BN記法(ABNF)記法を使用します。 ABNF[RFC4234]とIMAP[RFC3501]の正式な構文でここで定義されなかった要素は見つけることができます。

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

このドキュメントは2個の新しい検索キーでRFC3501[RFC3501]を広げています: より古い<間隔>と、より若い<間隔>。

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

検索主要な=/(「より古い」か「より若い」)のSP nz-数。 RFC3501で定義された検索キー

4.  Example

4. 例

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

C: 259200秒間のa1SEARCH UNSEEN YOUNGER: a1*検索4 8 15 16 23 42

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

サーバの現在の時間に従って、すべての見えないメッセージを過去3日以内か259200秒検索してください。

Burger                      Standards Track                     [Page 2]

RFC 5032                     Search Within                September 2007

2007年9月中にバーガー標準化過程[2ページ]RFC5032検索

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 Capability登録での新しいIMAP能力の登録は道のRFCかIESGが承認した規格の実験的なRFCの公表を必要とします。 登録は現在、<imap4http://www.iana.org/課題/能力>に位置しています。 この標準化過程文書はWITHIN IMAP能力を定義します。 IANAはIANA IMAP Capability登録にこの拡大を加えました。

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.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、RFC2119、BCP14、1997年3月。

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

[RFC3501] クリスピン、M.、「バージョン4rev1"、RFC3501、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"、2005年10月のRFC4234。

7.2.  Informative References

7.2. 有益な参照

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

キング、「IMAP4"のための文脈、処理中の作業、2006年5月」という[文脈。]メリニコフ、D.、およびC.

Burger                      Standards Track                     [Page 3]

RFC 5032                     Search Within                September 2007

2007年9月中にバーガー標準化過程[3ページ]RFC5032検索

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.

ステファーヌMaesとレイ・クロムウェルは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と提案を大部分に与えたいと思います。 特別番組はありがとうございます。彼のテキストの選択提出にAlexeyメリニコフに行きます。

Author's Address

作者のアドレス

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

エリックW.バーガー(エディタ)BEAシステムInc.米国

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

メール: eric.burger@bea.com ユリ: http://www.standardstrack.com

Burger                      Standards Track                     [Page 4]

RFC 5032                     Search Within                September 2007

2007年9月中にバーガー標準化過程[4ページ]RFC5032検索

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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に情報を扱ってください。

Burger                      Standards Track                     [Page 5]

バーガー標準化過程[5ページ]