RFC2177 日本語訳

Network Working Group                                           B. Leiba
Request for Comments: 2177               IBM T.J. Watson Research Center
Category: Standards Track                                      June 1997

Leibaがコメントのために要求するワーキンググループB.をネットワークでつないでください: 2177年のIBM T.J.ワトソン研究所カテゴリ: 標準化過程1997年6月

                           IMAP4 IDLE command

IMAP4 IDLEコマンド

Status of this Memo

この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)の現行版を参照してください。 このメモの分配は無制限です。

1.   Abstract

1. 要約

   The Internet Message Access Protocol [IMAP4] requires a client to
   poll the server for changes to the selected mailbox (new mail,
   deletions).  It's often more desirable to have the server transmit
   updates to the client in real time.  This allows a user to see new
   mail immediately.  It also helps some real-time applications based on
   IMAP, which might otherwise need to poll extremely often (such as
   every few seconds).  (While the spec actually does allow a server to
   push EXISTS responses aysynchronously, a client can't expect this
   behaviour and must poll.)

インターネットMessage Accessプロトコル[IMAP4]は、クライアントが選択されたメールボックス(新しいメール、削除)への変化のためにサーバに投票するのを必要とします。 サーバにリアルタイムでアップデートをクライアントに伝えさせるのは、しばしばより望ましいです。 これで、ユーザはすぐに、新しいメールを見ることができます。 また、そうでなければ非常にしばしば投票する必要があるかもしれないIMAPに基づくいくつかのリアルタイムのアプリケーションを助ける、(あらゆる数秒) (サーバは実際に仕様でEXISTS応答aysynchronouslyを押すことができますが、クライアントは、このふるまいを期待できないで、投票しなければなりません。)

   This document specifies the syntax of an IDLE command, which will
   allow a client to tell the server that it's ready to accept such
   real-time updates.

このドキュメントはIDLEコマンドの構文を指定します。(クライアントはコマンドでそれをそのようなリアルタイムのアップデートを受け入れる準備ができているとサーバに言うことができるでしょう)。

2.   Conventions Used in this Document

2. このDocumentのコンベンションUsed

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.

例で「C:」 そして、「S:」 クライアントとサーバによってそれぞれ送られた系列を示してください。

   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
   in this document are to be interpreted as described in RFC 2060
   [IMAP4].

キーワード“MUST"、「必須NOT」“SHOULD"、「」 「5月」はRFC2060[IMAP4]で説明されるように本書では解釈されることになっているべきです。

3.   Specification

3. 仕様

   IDLE Command

無駄なコマンド

   Arguments:  none

議論: なし

   Responses:  continuation data will be requested; the client sends
               the continuation data "DONE" to end the command

応答: 継続データは要求されるでしょう。 クライアントはコマンドを終わらせるために「された」継続データを送ります。

Leiba                       Standards Track                     [Page 1]

RFC 2177                   IMAP4 IDLE command                  June 1997

Leiba Standards Track[1ページ]RFC2177IMAP4 IDLEは1997年6月に命令します。

   Result:     OK - IDLE completed after client sent "DONE"
               NO - failure: the server will not allow the IDLE
                    command at this time
              BAD - command unknown or arguments invalid

結果: OK--クライアントが「された」ノーを送った後に完成したIDLE--失敗: サーバはBAD--未知を命令するか、議論を無効の状態で今回のIDLEコマンドに許容しないでしょう。

   The IDLE command may be used with any IMAP4 server implementation
   that returns "IDLE" as one of the supported capabilities to the
   CAPABILITY command.  If the server does not advertise the IDLE
   capability, the client MUST NOT use the IDLE command and must poll
   for mailbox updates.  In particular, the client MUST continue to be
   able to accept unsolicited untagged responses to ANY command, as
   specified in the base IMAP specification.

IDLEコマンドは能力コマンドにサポートしている能力の1つとして「活動していません、な」状態で戻るどんなIMAP4サーバ実装と共にも使用されるかもしれません。 サーバがIDLE能力の広告を出さないなら、クライアントは、IDLEコマンドを使用してはいけなくて、メールボックスアップデートに投票しなければなりません。 特に、クライアントはずっとどんなコマンドへの求められていない非タグ付けをされた応答も受け入れることができなければなりません、ベースIMAP仕様で指定されるように。

   The IDLE command is sent from the client to the server when the
   client is ready to accept unsolicited mailbox update messages.  The
   server requests a response to the IDLE command using the continuation
   ("+") response.  The IDLE command remains active until the client
   responds to the continuation, and as long as an IDLE command is
   active, the server is now free to send untagged EXISTS, EXPUNGE, and
   other messages at any time.

クライアントが求められていないメールボックスアップデートメッセージを受け入れる準備ができているとき、IDLEコマンドをクライアントからサーバに送ります。 サーバは、継続(「+」)応答を使用することでIDLEコマンドへの応答を要求します。 クライアントが継続に応じるまで、IDLEコマンドはアクティブなままで残っています、そして、IDLEコマンドが活発である限り、サーバはいつでも、現在、無料でuntagged EXISTS、EXPUNGE、および他のメッセージを送ることができます。

   The IDLE command is terminated by the receipt of a "DONE"
   continuation from the client; such response satisfies the server's
   continuation request.  At that point, the server MAY send any
   remaining queued untagged responses and then MUST immediately send
   the tagged response to the IDLE command and prepare to process other
   commands. As in the base specification, the processing of any new
   command may cause the sending of unsolicited untagged responses,
   subject to the ambiguity limitations.  The client MUST NOT send a
   command while the server is waiting for the DONE, since the server
   will not be able to distinguish a command from a continuation.

IDLEコマンドはクライアントからの「された」継続の領収書で終えられます。 そのような応答はサーバの継続要求を満たします。 その時、次に、サーバは、どんな残っている列に並ばせられた非タグ付けをされた応答も送るかもしれなくて、すぐに、タグ付けをされた応答をIDLEコマンドに送って、他のコマンドを処理するのを準備しなければなりません。 基礎仕様のように、どんな新しいコマンドの処理もあいまいさ制限を条件として求められていない非タグ付けをされた応答の発信を引き起こすかもしれません。 サーバがDONEを待っている間、クライアントはコマンドを送ってはいけません、サーバが継続とコマンドを区別できないので。

   The server MAY consider a client inactive if it has an IDLE command
   running, and if such a server has an inactivity timeout it MAY log
   the client off implicitly at the end of its timeout period.  Because
   of that, clients using IDLE are advised to terminate the IDLE and
   re-issue it at least every 29 minutes to avoid being logged off.
   This still allows a client to receive immediate mailbox updates even
   though it need only "poll" at half hour intervals.

IDLEがそれで稼働を命令するなら、サーバは、クライアントが不活発であると考えるかもしれません、そして、そのようなサーバに不活発タイムアウトがあるなら、それはタイムアウト時間の終わりにそれとなくクライアントからログオフするかもしれません。 それのために、IDLEを使用しているクライアントは、ログオフされるのを避けるためにIDLEを終えて、少なくともあらゆる29分単位でそれを再発行するようにアドバイスされます。 これで、30分の間隔で、「投票するだけでよいのです」が、クライアントはまだ即座のメールボックスアップデートを受け取ることができます。

Leiba                       Standards Track                     [Page 2]

RFC 2177                   IMAP4 IDLE command                  June 1997

Leiba Standards Track[2ページ]RFC2177IMAP4 IDLEは1997年6月に命令します。

   Example:    C: A001 SELECT INBOX
               S: * FLAGS (Deleted Seen)
               S: * 3 EXISTS
               S: * 0 RECENT
               S: * OK [UIDVALIDITY 1]
               S: A001 OK SELECT completed
               C: A002 IDLE
               S: + idling
               ...time passes; new mail arrives...
               S: * 4 EXISTS
               C: DONE
               S: A002 OK IDLE terminated
               ...another client expunges message 2 now...
               C: A003 FETCH 4 ALL
               S: * 4 FETCH (...)
               S: A003 OK FETCH completed
               C: A004 IDLE
               S: * 2 EXPUNGE
               S: * 3 EXISTS
               S: + idling
               ...time passes; another client expunges message 3...
               S: * 3 EXPUNGE
               S: * 2 EXISTS
               ...time passes; new mail arrives...
               S: * 3 EXISTS
               C: DONE
               S: A004 OK IDLE terminated
               C: A005 FETCH 3 ALL
               S: * 3 FETCH (...)
               S: A005 OK FETCH completed
               C: A006 IDLE

例: C: A001は受信トレイSを選択します: * 旗(見られた状態で、削除される)のS: * 3が存在している、S: * 0、最近のS: * OK[UIDVALIDITY1]S: A001 OK SELECTはCを完成しました: A002はSを空費します: + アイドリング…時間は経過します。 新しいメールは到着します… S: * 4が存在している、C: Sをします: A002 OK IDLEは終わりました…別のクライアントは現在、メッセージ2を梢消します… C: A003がとって来る、4 すべてのS: * 4は(…)をとって来ます。 S: A003 OK FETCHはCを完成しました: A004はSを空費します: * 2 Sを梢消してください: * 3が存在している、S: + アイドリング…時間は経過します。 別のクライアントはメッセージ3を梢消します… S: * 3 Sを梢消してください: * 2 存在しています…時間は経過します。 新しいメールは到着します… S: * 3が存在している、C: Sをします: A004 OK IDLEはCを終えました: A005がとって来る、3 すべてのS: * 3は(…)をとって来ます。 S: A005 OK FETCHはCを完成しました: A006は怠けます。

4.   Formal Syntax

4. 正式な構文

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4].
   Non-terminals referenced but not defined below are as defined by
   [IMAP4].

以下の構文仕様は変更されるとしての[RFC-822]ごとの指定されるとしての増大しているBN記法(BNF)記法を使用します。 [IMAP4]によって定義されるように参照をつけられましたが、以下で定義されなかった非端末があります。

   command_auth    ::= append / create / delete / examine / list / lsub /
                       rename / select / status / subscribe / unsubscribe
                       / idle
                       ;; Valid only in Authenticated or Selected state

_authに以下を命令してください:= / lsub /が選んだ/状態/が申し込むか、外す、または空費する/に改名する/リストを追加するか、作成する、削除する、または調べてください。 AuthenticatedかSelected状態だけでは、有効です。

   idle            ::= "IDLE" CRLF "DONE"

以下を空費してください:= 「された」「活動していません、な」CRLF

Leiba                       Standards Track                     [Page 3]

RFC 2177                   IMAP4 IDLE command                  June 1997

Leiba Standards Track[3ページ]RFC2177IMAP4 IDLEは1997年6月に命令します。

5.   References

5. 参照

   [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
   4rev1", RFC 2060, December 1996.

[IMAP4] クリスピン、M.、「バージョン4rev1"、RFC2060、1996年インターネットメッセージアクセス・プロトコル--12月。」

6.   Security Considerations

6. セキュリティ問題

   There are no known security issues with this extension.

この拡大の安全保障問題は知られていません。

7.   Author's Address

7. 作者のアドレス

   Barry Leiba
   IBM T.J. Watson Research Center
   30 Saw Mill River Road
   Hawthorne, NY  10532

バリーLeiba IBM T.J.ワトソン研究所30の製材機械の川のRoadホーソーン、ニューヨーク 10532

   Email: leiba@watson.ibm.com

メール: leiba@watson.ibm.com

Leiba                       Standards Track                     [Page 4]

Leiba標準化過程[4ページ]