Network Working Group A. Melnikov, Ed.
Request for Comments: 4549 Isode Ltd.
Category: Informational June 2006
Synchronization Operations for Disconnected IMAP4 Clients
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document attempts to address some of the issues involved in building a disconnected IMAP4 client. In particular, it deals with the issues of what might be called the "driver" portion of the synchronization tool: the portion of the code responsible for issuing the correct set of IMAP4 commands to synchronize the disconnected client in the way that is most likely to make the human who uses the disconnected client happy.
この文書では、切断さIMAP4クライアントの構築にかかわる問題のいくつかに対処しようとします。特に、同期ツールの「ドライバ」部分と呼ばれるかもしれないものの問題を扱う：IMAP4の正しいセットを発行するコードの部分は、最も可能性が高い方法で、切断されたクライアントを同期するためのコマンド幸せな切断されたクライアントを使用して、人間を作ります。
This note describes different strategies that can be used by disconnected clients and shows how to use IMAP protocol in order to minimize the time of the synchronization process.
このノートでは、切断されたクライアントで使用できるさまざまな戦略を説明し、同期プロセスの時間を最小限にするために、IMAPプロトコルを使用する方法を示しています。
This note also lists IMAP extensions that a server should implement in order to provide better synchronization facilities to disconnected clients.
このノートでは、サーバーが切断クライアントへのより良い同期機能を提供するために実装する必要がIMAP拡張を示しています。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Design Principles ...............................................3
3. Overall Picture of Synchronization ..............................4
4. Mailbox Synchronization Steps and Strategies ....................7
4.1. Checking UID Validity ......................................7
4.2. Synchronizing Local Changes with the Server ................8
4.2.1. Uploading Messages to the Mailbox ...................8
4.2.2. Optimizing "move" and "copy" Operations .............9
4.2.3. Replaying Local Flag Changes .......................14
4.2.4. Processing Mailbox Compression (EXPUNGE) Requests ..15
4.2.5. Closing a Mailbox ..................................17
4.3. Details of "Normal" Synchronization of a Single Mailbox ...18
4.3.1. Discovering New Messages and Changes to Old
Messages ...........................................18
4.3.2. Searching for "Interesting" Messages. ..............20
4.3.3. Populating Cache with "Interesting" Messages. ......21
4.3.4. User-Initiated Synchronization .....................22
4.4. Special Case: Descriptor-Only Synchronization .............22
4.5. Special Case: Fast New-Only Synchronization ...............23
4.6. Special Case: Blind FETCH .................................23
5. Implementation Considerations ..................................24
5.1. Error Recovery during Playback ............................26
5.2. Quality of Implementation Issues ..........................28
5.3. Optimizations .............................................28
6. IMAP Extensions That May Help ..................................30
6.1. CONDSTORE Extension .......................................30
7. Security Considerations ........................................33
8. References .....................................................33
8.1. Normative References ......................................33
8.2. Informative References ....................................34
9. Acknowledgements ...............................................34
Several recommendations presented in this document are generally applicable to all types of IMAP clients. However, this document tries to concentrate on disconnected mail clients [IMAP-MODEL]. It also suggests some IMAP extensions* that should be implemented by IMAP servers in order to make the life of disconnected clients easier. In particular, the [UIDPLUS] extension was specifically designed to streamline certain disconnected operations, like expunging, uploading, and copying messages (see Sections 4.2.1, 4.2.2.1, and 4.2.4).
この文書のいくつかの推奨事項は、一般的にIMAPクライアントのすべてのタイプに適用されます。しかし、この文書では切断メールクライアント[IMAP-MODEL]に集中しようとします。また、切断クライアントの人生を容易にするために、IMAPサーバによって実装されなければならないいくつかのIMAP拡張*を示唆しています。具体的には、[UIDPLUS]拡張は、具体的には（セクション4.2.1、4.2.2.1、及び4.2.4を参照）、抹消アップロード、およびメッセージのコピーのように、特定の切断作業を効率化するために設計されました。
Readers of this document are also strongly advised to read RFC 2683 [RFC2683].
このドキュメントの読者は強くRFC 2683 [RFC2683]を読むことをお勧めします。
* Note that the functionality provided by the base IMAP protocol [IMAP4] is sufficient to perform basic synchronization.
*ベースIMAPプロトコル[IMAP4]によって提供される機能は、基本的な同期を実行するのに十分であることに留意されたいです。
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively. Long lines in examples are broken for editorial clarity.
実施例において、「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]で説明されるように解釈されます。
Let's call an IMAP command idempotent if the result of executing the command twice sequentially is the same as the result of executing the command just once.
二回順次コマンドを実行した結果は、一度だけコマンドを実行した結果と同じである場合のは、IMAPコマンド冪等を呼ぶことにしましょう。
All mailbox state or content information stored on the disconnected client should be viewed strictly as a cache of the state of the server. The "master" state remains on the server, just as it would with an interactive IMAP4 client. The one exception to this rule is that information about the state of the disconnected client's cache (the state includes flag changes while offline and during scheduled message uploads) remains on the disconnected client: that is, the IMAP4 server is not responsible for remembering the state of the disconnected IMAP4 client.
切断されたクライアントに保存されているすべてのメールボックスの状態やコンテンツ情報は、サーバの状態のキャッシュとして厳密に考えるべきです。 「マスター」状態はちょうどそれがインタラクティブIMAP4クライアントと同じように、サーバー上に残ります。つまり、IMAP4サーバは状態を覚えるための責任を負いません。この規則の唯一の例外は、切断されたクライアントのキャッシュの状態に関する情報は（状態がしばらくオフラインおよびスケジュールメッセージのアップロード時にフラグの変更を含んで）切断されたクライアント上に残っているということです切断IMAP4クライアントの。
We assume that a disconnected client is a client that, for whatever reason, wants to minimize the length of time that it is "on the phone" to the IMAP4 server. Often this will be because the client is using a dialup connection, possibly with very low bandwidth, but sometimes it might just be that the human is in a hurry to catch an airplane, or some other event beyond our control. Whatever the reason, we assume that we must make efficient use of the network connection, both in the usual sense (not generating spurious traffic) and in the sense that we would prefer not to have the connection sitting idle while the client and/or the server is performing strictly local computation or I/O. Another, perhaps simpler way of stating this is that we assume that network connections are "expensive".
私たちは、切断されたクライアントは、何らかの理由で、それはIMAP4サーバへの「電話で」である時間の長さを最小化しようと、クライアントであることを前提としています。クライアントは、おそらく非常に低い帯域幅で、ダイヤルアップ接続を使用しているため、多くの場合、これは次のようになりますが、時にはそれはちょうど人間が飛行機、または当社のコントロールを超えた他のイベントをキャッチするために急いでいるということかもしれません。理由が何であれ、我々は両方とも通常の意味で（不正なトラフィックを生成しない）、我々はネットワーク接続の効率的な利用をしなければならないことを前提とし、ある意味で私たちがアイドル状態の接続を持ってしたくないことながら、クライアントおよび/またはサーバーは、厳密にはローカル計算やI / Oを実行しています。これを述べる別の、おそらく簡単な方法は、我々はネットワーク接続が「高価」であることを前提としていることです。
Practical experience with disconnected mail systems has shown that there is no single synchronization strategy that is appropriate for all cases. Different humans have different preferences, and the same human's preference will vary depending both on external circumstance (how much of a hurry the human is in today) and on the value that the human places on the messages being transferred. The point here is that there is no way that the synchronization program can guess exactly what the human wants to do, so the human will have to provide some guidance.
切断メールシステムと実際の経験は、すべての場合に適している単一の同期化戦略がないことを示しています。さまざまな人間は異なる嗜好を持っているし、同じ人間の好みは、外部の状況に（人間が今日であるお急ぎのどのくらい）と転送されたメッセージの人間の場所、その値の両方によって異なります。ここでのポイントは、人間が、いくつかのガイダンスを提供する必要がありますので、同期プログラムは、人間が何をしたいのかを正確に推測することができること方法がないということです。
Taken together, the preceding two principles lead to the conclusion that the synchronization program must make its decisions based on some kind of guidance provided by the human, by selecting the appropriate options in the user interface or through some sort of configuration file. Almost certainly, it should not pause for I/O with the human in the middle of the synchronization process. The human will almost certainly have several different configurations for the synchronization program, for different circumstances.
まとめると、前述の2つの原則は、同期プログラムは、ユーザーインターフェースや設定ファイルのいくつかの並べ替えて適切なオプションを選択することで、人間が提供する指針のいくつかの種類に基づいて、その決定をしなければならないという結論につながります。ほぼ確実に、それは同期プロセスの途中で人間とI / Oのために一時停止するべきではありません。人間は、ほぼ確実に異なる状況のために、同期プログラムにはいくつかの異なる構成を持つことになります。
Since a disconnected client has no way of knowing what changes might have occurred to the mailbox while it was disconnected, message numbers are not useful to a disconnected client. All disconnected client operations should be performed using UIDs, so that the client can be sure that it and the server are talking about the same messages during the synchronization process.
切断されたクライアントは、それが切断されていた間、メールボックスに発生した可能性がありますどのような変化を知る方法がありませんので、メッセージ番号は、切断されたクライアントに有用ではありません。クライアントは、サーバーが同期プロセス中に同じメッセージについて話していることを確認することができますように、すべての切断されたクライアントの操作は、UIDを使用して実行する必要があります。
The basic strategy for synchronization is outlined below. Note that the real strategy may vary from one application to another or may depend on a synchronization mode.
同期のための基本的な戦略は以下の通りです。実際の戦略は、別のアプリケーションと異なる場合があり、または同期モードに依存し得ることに留意されたいです。
a) Process any "actions" that were pending on the client that were not associated with any mailbox. (In particular sending messages composed offline with SMTP. This is not part of IMAP synchronization, but it is mentioned here for completeness.)
a）は任意のメールボックスに関連付けられていなかったクライアント上で保留されたすべての「アクション」を処理します。 （特にSMTPでオフラインで構成されるメッセージを送信する。これは、IMAP同期の一部ではありませんが、完全を期すために、ここで言及されています。）
b) Fetch the current list of "interesting" mailboxes. (The disconnected client should allow the user to skip this step completely.)
b）は、「面白い」のメールボックスの現在のリストを取得します。 （切断されたクライアントは、ユーザーが完全にこのステップをスキップできるようにする必要があります。）
c) "Client-to-server synchronization": for each IMAP "action" that was pending on the client, do the following:
C）「クライアントからサーバーへの同期」：クライアント上で保留された各IMAP、「アクション」のために、次の手順を実行します。
1) If the action implies opening a new mailbox (any operation that operates on messages), open the mailbox. Check its UID validity value (see Section 4.1 for more details) returned in the UIDVALIDITY response code. If the UIDVALIDITY value returned by the server differs, the client MUST empty the local cache of the mailbox and remove any pending "actions" that refer to UIDs in that mailbox (and consider them failed). Note that this doesn't affect actions performed on client-generated fake UIDs (see Section 5).
アクションは、新しいメールボックスのメッセージに動作します（任意のオペレーション）を開く暗示している場合1）、メールボックスを開きます。そのUIDの妥当性値を確認してください（詳細は4.1節を参照）UIDVALIDITY応答コードで返されます。 UIDVALIDITY値は、サーバーが異なるから返された場合、クライアントは、メールボックスのローカルキャッシュを空にして、そのメールボックスでのUIDを参照してください保留中の「アクション」を削除（それらが失敗考慮）しなければなりません。これは、クライアントが生成した偽のUID（第5節を参照）上で実行されるアクションには影響しないことに注意してください。
2) Perform the action. If the action is to delete a mailbox (DELETE), make sure that the mailbox is closed first (see also Section 3.4.12 of [RFC2683]).
2）アクションを実行します。アクションは（DELETE）メールボックスを削除する場合は、メールボックスが最初に閉じていることを確認します（また、[RFC2683]のセクション3.4.12を参照してください）。
d) "Server-to-client synchronization": for each mailbox that requires synchronization, do the following:
D）「サーバーからクライアントへの同期」：同期を必要とする各メールボックスの、次の操作を行います。
1) Check the mailbox UIDVALIDITY (see Section 4.1 for more details) with SELECT/EXAMINE/STATUS.
1）SELECT / EXAMINE / STATUSで（詳細はセクション4.1を参照）、メールボックスのUIDVALIDITYを確認してください。
If UIDVALIDITY value returned by the server differs, the client MUST
UIDVALIDITY値は、サーバーが異なるから返された場合は、クライアントMUST
* empty the local cache of that mailbox; * remove any pending "actions" that refer to UIDs in that mailbox and consider them failed; and * skip step 2-II.
*そのメールボックスのローカルキャッシュを空にする。 *そのメールボックスでのUIDを参照してください保留中の「アクション」を削除し、それらが失敗した考えます。そして*ステップ2-IIをスキップします。
2) Fetch the current "descriptors";
2）現在の「記述子」をフェッチ。
I) Discover new messages.
私は）新しいメッセージを発見してください。
II) Discover changes to old messages.
II）古いメッセージへの変更を検出します。
3) Fetch the bodies of any "interesting" messages that the client doesn't already have.
3）クライアントがすでに持っていない任意の「おもしろい」メッセージの本文を取得します。
e) Close all open mailboxes not required for further operations (if staying online) or disconnect all open connections (if going offline).
E）（以上の操作は必要ありません開いているすべてのメールボックスを閉じるオンライン滞在する場合）またはすべてのオープン接続（オフラインの場合）を外します。
Terms used:
使用条件：
"Actions" are queued requests that were made by the human to the client's Mail User Agent (MUA) software while the client was disconnected.
「アクション」は、クライアントが切断された一方で、クライアントのメールユーザエージェント（MUA）ソフトウェアに人間によって作られた要求をキューに入れられています。
We define "descriptors" as a set of IMAP4 FETCH data items. Conceptually, a message's descriptor is that set of information that allows the synchronization program to decide what protocol actions are necessary to bring the local cache to the desired state for this message; since this decision is really up to the human, this information probably includes at least a few header fields intended for human consumption. Exactly what will constitute a descriptor depends on the client implementation. At a minimum, the descriptor contains the message's UID and FLAGS. Other likely candidates are the RFC822.SIZE, RFC822.HEADER, BODYSTRUCTURE, or ENVELOPE data items.
IMAP4のセットは、データ項目をFETCHとして私たちは、「記述子」を定義します。概念的には、メッセージの記述は、このメッセージのために所望の状態にローカルキャッシュをもたらすために必要であるかのプロトコルの動作を決定する同期プログラムを可能にする情報の集合です。この決定は、本当に人間に任されているので、この情報はおそらく人間の消費のために意図少なくとも数ヘッダフィールドを含んでいます。まさに記述子を構成することは、クライアントの実装に依存します。最低でも、記述子は、メッセージのUIDおよびFLAGSが含まれています。他の有望な候補はRFC822.SIZE、RFC822.HEADER、BODYSTRUCTURE、またはENVELOPEデータ項目です。
Comments:
コメント：
1) The list of actions should be ordered. For example, if the human deletes message A1 in mailbox A, then expunges mailbox A, and then deletes message A2 in mailbox A, the human will expect that message A1 is gone and that message A2 is still present but is now deleted.
1）アクションのリストを注文する必要があります。人間は、メールボックスAにメッセージA1を削除した場合、その後、メールボックスAを抹消した後、メールボックスAにメッセージA2を削除し、人間は、A1がなくなっていると、そのメッセージA2がまだ存在するが、現在は削除され、そのメッセージを期待しています。
By processing all the actions before proceeding with synchronization, we avoid having to compensate for the local MUA's changes to the server's state. That is, once we have processed all the pending actions, the steps that the client must take to synchronize itself will be the same no matter where the changes to the server's state originated.
同期を実行する前に、すべてのアクションを処理することにより、我々は、サーバーの状態へのローカルMUAの変化を補償することを避けるため。それは我々がすべての保留中のアクションを処理した後、クライアントが自身を同期するために取らなければならないことの手順は、サーバーの状態に変更が発生かかわらず同じになり、です。
2) Steps a and b can be performed in parallel. Alternatively, step a can be performed after d.
2）工程及び（b）は並行して行うことができます。あるいは、Dの後に行うことができるステップ。
3) On step b, the set of "interesting" mailboxes pretty much has to be determined by the human. What mailboxes belong to this set may vary between different IMAP4 sessions with the same server, client, and human. An interesting mailbox can be a mailbox returned by LSUB command (see Section 6.3.9 of [IMAP4]). The special mailbox "INBOX" SHOULD be in the default set of mailboxes that the client considers interesting. However, providing the ability to ignore INBOX for a particular session or client may be valuable for some mail filtering strategies.
3工程b）で、「面白い」のメールボックスのセットはかなり人間によって決定されなければなりません。どのようなメールボックスは、このセットに属し、同じサーバー、クライアント、および人間と異なるIMAP4セッション間で異なる場合があります。面白いメールボックスがLSUBコマンドで返されたメールボックスことができます（[IMAP4]の6.3.9項を参照してください）。特別なメールボックス「INBOX」は、クライアントが面白いと考えて、メールボックスのデフォルトセットにする必要があります。しかし、特定のセッションやクライアントのためのINBOXを無視する機能を提供することは、いくつかのメールのフィルタリング戦略の価値があります。
4) On step d-2-II, the client also finds out about changes to the flags of messages that the client already has in its local cache, and about messages in the local cache that no longer exist on the server (i.e., messages that have been expunged).
4）ステップD-2-IIには、クライアントは、クライアントがすでにローカルキャッシュに持っていたメッセージのフラグの変更に関する見つけ出し、もはやサーバー上で（すなわち、メッセージが存在しないローカルキャッシュ内のメッセージについてそれは）抹消されています。
5) "Interesting" messages are those messages that the synchronization program thinks the human wants to have cached locally, based on the configuration and the data retrieved in step b.
5）「興味深い」のメッセージが同期プログラムは人間が設定し、ステップbで取得したデータに基づいて、ローカルにキャッシュされているしたいと考えてそれらのメッセージです。
6) A disconnected IMAP client is a special case of an IMAP client, so it MUST be able to handle any "unexpected" unsolicited responses, like EXISTS and EXPUNGE, at any time. The disconnected client MAY ignore EXPUNGE response during "client-to-server" synchronization phase (step c).
6）切断IMAPクライアントがIMAPクライアントの特殊なケースなので、いつでも、EXISTSと同様に、任意の「予期しない」未承諾応答を処理し、EXPUNGEできなければなりません。切断されたクライアントは、「クライアントからサーバーへの」同期フェーズ（段階c）の間EXPUNGE応答を無視してもよいです。
The rest of this discussion will focus primarily on the synchronization issues for a single mailbox.
この議論の残りの部分は、単一のメールボックスの同期の問題に主に焦点を当てます。
The "UID validity" of a mailbox is a number returned in an UIDVALIDITY response code in an OK untagged response at mailbox selection time. The UID validity value changes between sessions when UIDs fail to persist between sessions.
メールボックスの「UID妥当性は、」メールボックスの選択時にOKタグなし応答でUIDVALIDITY応答コードで返される数値です。 UIDは、セッション間で保持しないセッション間でUID妥当性値が変化します。
Whenever the client selects a mailbox, the client must compare the returned UID validity value with the value stored in the local cache. If the UID validity values differ, the UIDs in the client's cache are no longer valid. The client MUST then empty the local cache of that mailbox and remove any pending "actions" that refer to UIDs in that mailbox. The client MAY also issue a warning to the human. The client MUST NOT cancel any scheduled uploads (i.e., APPENDs) for the mailbox.
クライアントがメールボックスを選択するたびに、クライアントは、ローカルキャッシュに格納されている値で返さUID妥当性値を比較しなければなりません。 UIDの妥当性値が異なる場合は、クライアントのキャッシュ内のUIDは、もはや有効ではありません。次に、クライアントは、そのメールボックスのローカルキャッシュを空にして、そのメールボックスでのUIDを参照してください保留中の「アクション」を削除する必要があります。また、クライアントは、人間への警告を発行することができます。クライアントは、メールボックスの任意のスケジュールされたアップロード（すなわち、追加）をキャンセルしてはなりません。
Note that UIDVALIDITY is not only returned on a mailbox selection. The COPYUID and APPENDUID response codes defined in the [UIDPLUS] extension (see also 4.2.2) and the UIDVALIDITY STATUS response data item also contain a UIDVALIDITY value for some other mailbox. The client SHOULD behave as described in the previous paragraph (but it should act on the other mailbox's cache), no matter how it obtained the UIDVALIDITY value.
UIDVALIDITYが唯一のメールボックスの選択に返されないことに注意してください。 COPYUIDおよび[UIDPLUS]拡張で定義されたAPPENDUID応答コードは（また、4.2.2参照）、UIDVALIDITY状態応答データ項目はまた、いくつかの他のメールボックスのUIDVALIDITY値を含みます。関係なく、それはUIDVALIDITY値を取得する方法、前の段落で説明したようにクライアントが振る舞うべきではない（それは、他のメールボックスのキャッシュに行動しなければなりません）。
Two of the most common examples of operations resulting in message uploads are:
メッセージのアップロードが生じ操作の最も一般的な例の二つがあります：
1) Saving a draft message
1）ドラフト・メッセージを保存します
2) Copying a message between remote mailboxes on two different IMAP servers or a local mailbox and a remote mailbox.
2）は、2台の異なるIMAPサーバ上のリモートメールボックスまたはローカルメールボックスとリモートメールボックスとの間のメッセージのコピー。
Message upload is performed with the APPEND command. A message scheduled to be uploaded has no UID associated with it, as all UIDs are assigned by the server. The APPEND command will effectively associate a UID with the uploaded message that can be stored in the local cache for future reference. However, [IMAP4] doesn't describe a simple mechanism to discover the message UID by just performing the APPEND command. In order to discover the UID, the client can do one of the following:
メッセージのアップロードは、APPENDコマンドを使用して行われます。すべてのUIDがサーバによって割り当てられているとしてアップロードされる予定のメッセージは、それに関連付けられたUIDを持っていません。 APPENDコマンドは、効果的に今後の参考のために、ローカルキャッシュに格納することができ、アップロードメッセージと共にUIDを関連付けます。ただし、[IMAP4]はちょうどAPPENDコマンドを実行することにより、メッセージのUIDを発見するための簡単なメカニズムを説明していません。 UIDを発見するためには、クライアントは、次のいずれかを実行できます。
1) Remove the uploaded message from cache. Then, use the mechanism described in 4.3 to fetch the information about the uploaded message as if it had been uploaded by some other client.
1）キャッシュからアップロードされたメッセージを削除します。それはいくつかの他のクライアントによってアップロードされたかのように続いて、アップロードされたメッセージについての情報を取得するために4.3で説明したメカニズムを使用します。
2) Try to fetch header information as described in 4.2.2 in order to find a message that corresponds to the uploaded message. One strategy for doing this is described in 4.2.2.
2）アップロードされたメッセージに対応するメッセージを見つけるために4.2.2に記載したように、ヘッダ情報を取得してみてください。これを行うための一つの戦略は、4.2.2に記載されています。
Case 1 describes a not particularly smart client.
ケース1は、特にスマートではないクライアントを記述します。
C: A003 APPEND Drafts (\Seen $MDNSent) {310} S: + Ready for literal data C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) C: From: Fred Foobar <foobar@blt.example.COM> C: Subject: afternoon meeting C: To: mooch@owatagu.siam.edu C: Message-Id: <B27397-0100000@blt.example.COM> C: MIME-Version: 1.0 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII C: C: Hello Joe, do you think we can meet at 3:30 tomorrow? C: S: A003 OK APPEND Completed
C：A003 APPEND下書き（\ $ MDNSent見られる）{310} S：リテラルデータCの+準備：日：月、1994年2月7日午後9時52分25秒-0800（PST）C：から：フレッドfoobarの<foobarに@ BLT .example.comと> C：件名：午後の会議C：TO：mooch@owatagu.siam.eduのC：メッセージ-ID：<B27397-0100000@blt.example.COM> C：MIME-バージョン：1.0 C：のContentタイプ：TEXT / PLAIN。 CHARSET = US-ASCII C：C：こんにちはジョー、あなたは私たちが明日3時30分に会うことができると思いますか？ C：S：A003 OK APPENDが完了
Fortunately, there is a simpler way to discover the message UID in the presence of the [UIDPLUS] extension:
幸い、[UIDPLUS]拡張の存在下でのメッセージのUIDを発見するための簡単な方法があります：
C: A003 APPEND Drafts (\Seen $MDNSent) {310} S: + Ready for literal data C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) C: From: Fred Foobar <foobar@blt.example.COM> C: Subject: afternoon meeting C: To: mooch@owatagu.siam.edu C: Message-Id: <B27397-0100000@blt.example.COM> C: MIME-Version: 1.0 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII C: C: Hello Joe, do you think we can meet at 3:30 tomorrow? C: S: A003 OK [APPENDUID 1022843275 77712] APPEND completed
C：A003 APPEND下書き（\ $ MDNSent見られる）{310} S：リテラルデータCの+準備：日：月、1994年2月7日午後9時52分25秒-0800（PST）C：から：フレッドfoobarの<foobarに@ BLT .example.comと> C：件名：午後の会議C：TO：mooch@owatagu.siam.eduのC：メッセージ-ID：<B27397-0100000@blt.example.COM> C：MIME-バージョン：1.0 C：のContentタイプ：TEXT / PLAIN。 CHARSET = US-ASCII C：C：こんにちはジョー、あなたは私たちが明日3時30分に会うことができると思いますか？ C：S：完成A003 OK [APPENDUID 1022843275 77712] APPEND
The UID of the appended message is the second parameter of APPENDUID response code.
添付メッセージのUIDはAPPENDUID応答コードの2番目のパラメータです。
Practical experience with IMAP and other mailbox access protocols that support multiple mailboxes suggests that moving a message from one mailbox to another is an extremely common operation.
複数のメールボックスをサポートするIMAPおよびその他のメールボックスのアクセスプロトコルとの実務経験を別のメールボックスからメッセージを移動すると、非常に一般的な操作であることを示唆しています。
In IMAP4, a "move" operation between two mailboxes on the same server is really a combination of a COPY operation and a STORE +FLAGS (\Deleted) operation. This makes good protocol sense for IMAP, but it leaves a simple-minded disconnected client in the silly position of deleting and possibly expunging its cached copy of a message, then fetching an identical copy via the network.
IMAP4では、同じサーバー上の2つのメールボックスの間で「移動」操作は本当にCOPY操作の組み合わせとSTORE + FLAGS（\削除済み）操作です。これはIMAPのための優れたプロトコル理にかなっているが、それはネットワーク経由で同一のコピーを取得、その後、削除し、おそらくメッセージをそのキャッシュされたコピーを抹消する愚かな位置にシンプル志向の切断されたクライアントを残します。
However, the presence of the UIDPLUS extension in the server can help:
しかし、サーバ内のUIDPLUS拡張の存在が助けることができます。
C: A001 UID COPY 567,414 "Interesting Messages" S: A001 OK [COPYUID 1022843275 414,567 5:6] Completed
C：A001 UID COPY 567414 "おもしろいメッセージ" S：A001 OK [COPYUID 1022843275 414567 5：6]が完了
This tells the client that the message with UID 414 in the current mailbox was successfully copied to the mailbox "Interesting Messages" and was given the UID 5, and that the message with UID 567 was given the UID 6.
これは、UID 567とのメッセージがUID 6を与えたことが、現在のメールボックスにUID 414とのメッセージが正常にメールボックスに「興味深いメッセージ」をコピーしたとUID 5与えられた、とことをクライアントに伝えます。
In the absence of UIDPLUS extension support in the server, the following trick can be used. By including the Message-ID: header and the INTERNALDATE data item as part of the descriptor, the client can check the descriptor of a "new" message against messages that are already in its cache and avoid fetching the extra copy. Of course, it's possible that the cost of checking to see if the message is already in the local cache may exceed the cost of just fetching it, so this technique should not be used blindly. If the MUA implements a "move" command, it makes special provisions to use this technique when it knows that a copy/delete sequence is the result of a "move" command.
サーバ内のUIDPLUS拡張サポートがない場合には、以下のトリックを使用することができます。メッセージIDを含むことによって：ヘッダおよび記述子の一部としてINTERNALDATEデータ項目を、クライアントがそのキャッシュに既にあるメッセージに対して「新しい」メッセージの記述をチェックして、余分なコピーを取得避けることができます。もちろん、それはメッセージがローカルキャッシュに既に存在するかどうかをチェックするのコストはそれをフェッチするコストを上回ることが可能ですので、この技術は盲目的に使用すべきではありません。 MUAは、「移動」コマンドを実装している場合、それはコピーが/シーケンスを削除することを知っているとき、特別な規定は、このテクニックを使用できるようになり、「移動」コマンドの結果です。
Note that servers are not required (although they are strongly encouraged with "SHOULD language") to preserve INTERNALDATE when copying messages.
メッセージをコピーするときINTERNALDATEを維持するために（彼らは強く「SHOULD言語」で奨励されていますが）サーバが必要とされていないことに注意してください。
Also note that since it's theoretically possible for this algorithm to find the wrong message (given sufficiently malignant Message-ID headers), implementers should provide a way to disable this optimization, both permanently and on a message-by-message basis.
また、このアルゴリズムは、誤ったメッセージを発見することが理論的には可能だから（十分に悪性のメッセージ-IDヘッダを与えられる）ことに注意し、実装者は、両方の永久とメッセージごとに、この最適化を無効にする方法を提供する必要があります。
Example 1: Copying a message in the absence of UIDPLUS extension.
実施例1：UIDPLUS拡張が存在しない場合にメッセージをコピーします。
At some point in time the client has fetched the source message and some information was cached:
ある時点で、クライアントは、ソースメッセージをフェッチしており、いくつかの情報がキャッシュされました：
C: C021 UID FETCH <uids> (BODY.PEEK[] INTERNALDATE FLAGS) ... S: * 27 FETCH (UID 123 INTERNALDATE "31-May-2002 05:26:59 -0600" FLAGS (\Draft $MDNSent) BODY[] {1036} S: ... S: Message-Id: <20040903110856.22a127cd@chardonnay> S: ... S: ...message body... S: ) ... S: C021 OK fetch completed
C：C021 UIDはFETCH <のuid>（BODY.PEEK [] INTERNALDATEのFLAGS）... S：* 27 FETCH（UID 123 INTERNALDATE "31-月 - 2002午前5時26分59秒-0600" FLAGS（\ドラフト$ MDNSent） BODY [] {1036} S ... S：メッセージ-ID：<20040903110856.22a127cd@chardonnay> S ... S：...メッセージボディ... S：）... S：C021 OKフェッチ完了
Later on, the client decides to copy the message:
その後、クライアントはメッセージをコピーすることを決定しました。
C: C035 UID COPY 123 "Interesting Messages" S: C035 OK Completed
C：C035 UID COPY 123 "興味深いメッセージ" S：C035 OKを完了
As the server hasn't provided the COPYUID response code, the client tries the optimization described above:
サーバがCOPYUID応答コードを提供していないため、クライアントは、上記の最適化を試みます。
C: C036 SELECT "Interesting Messages" ... C: C037 UID SEARCH ON 31-May-2002 HEADER "Message-Id" "20040903110856.22a127cd@chardonnay" S: SEARCH 12368 S: C037 OK completed
C：SEARCH 12368 S：31月 - 2002年HEADER "メッセージID" "20040903110856.22a127cd@chardonnay" S ON C037 UID検索： "興味深いメッセージ" ... Cを選択C036 C037 OKを完了
Note that if the server has returned multiple UIDs in the SEARCH response, the client MUST NOT use any of the returned UID.
サーバは検索応答で複数のUIDを返した場合、クライアントは返されたUIDのいずれかを使用してはならないことに注意してください。
Moving a message from a remote mailbox to a local is done with FETCH (that includes FLAGS and INTERNALDATE) followed by UID STORE <uid> +FLAGS.SILENT (\Deleted):
ローカルに、リモートメールボックスからメッセージを移動するUID STORE <uid> + FLAGS.SILENT（\削除済み）、続いて（すなわち、FLAGSとINTERNALDATEを含む）FETCHを用いて行われます。
C: A003 UID FETCH 123 (BODY.PEEK[] INTERNALDATE FLAGS) S: * 27 FETCH (UID 123 INTERNALDATE "31-May-2002 05:26:59 -0600" FLAGS (\Seen $MDNSent) BODY[] S: ...message body... S: ) S: A003 OK UID FETCH completed C: A004 UID STORE <uid> +FLAGS.SILENT (\Deleted) S: A004 STORE completed
C：A003 UIDは123（BODY.PEEK [] INTERNALDATEのFLAGS）S FETCH：（* 27 FETCH（UID 123 INTERNALDATE "31-月 - 2002年5時26分59秒-0600" FLAGSを\見$ MDNSent）BODY [] S： ...メッセージボディ... S：）S：A003 OK UIDが完了CをFETCH：A004 UID STORE <UID> + FLAGS.SILENT（\削除済み）S：A004ストア完了します
Note that there is no reason to fetch the message during synchronization if it's already in the client's cache. Also, the client SHOULD preserve delivery date in the local cache.
それは、クライアントのキャッシュにすでにいた場合、同期時にメッセージを取得する理由はないことに注意してください。また、クライアントは、ローカルキャッシュに納期を守るべきです。
Moving a message from a local mailbox to a remote is done with APPEND:
APPENDで行われ、リモートにローカルのメールボックスからメッセージを移動します：
C: A003 APPEND Drafts (\Seen $MDNSent) "31-May-2002 05:26:59 -0600" {310} S: + Ready for literal data C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) C: From: Fred Foobar <foobar@blt.example.COM> C: Subject: afternoon meeting C: To: mooch@owatagu.siam.edu C: Message-Id: <B27397-0100000@blt.example.COM> C: MIME-Version: 1.0 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII C: C: Hello Joe, do you think we can meet at 3:30 tomorrow? C: S: A003 OK [APPENDUID 1022843275 77712] completed
C：A003 APPEND下書き（\見$ MDNSent） "31-月 - 2002年5時26分59秒-0600" {310} S：+準備リテラルデータC用：日：月、1994年2月7日21時52分25秒 - 0800（PST）C：から：フレッドfoobarの<foobar@blt.example.COM> C：件名：午後の会議C：TO：mooch@owatagu.siam.eduのC：メッセージ-ID：<B27397-0100000@blt.example .COM> C：MIME-バージョン：1.0 C：のContent-Type：text / plainの。 CHARSET = US-ASCII C：C：こんにちはジョー、あなたは私たちが明日3時30分に会うことができると思いますか？ C：S：A003 OK [APPENDUID 1022843275 77712]完成
The client SHOULD specify the delivery date from the local cache in the APPEND.
クライアントは、APPENDでローカルキャッシュから配達日を指定する必要があります。
If the [LITERAL+] extension is available, the client can save a round-trip*:
[LITERAL +]拡張機能が利用可能な場合、クライアントは、ラウンドトリップを保存することができます*：
C: A003 APPEND Drafts (\Seen $MDNSent) "31-May-2002 05:26:59 -0600" {310+} C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) C: From: Fred Foobar <foobar@blt.example.COM> C: Subject: afternoon meeting C: To: mooch@owatagu.siam.edu C: Message-Id: <B27397-0100000@blt.example.COM> C: MIME-Version: 1.0 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII C: C: Hello Joe, do you think we can meet at 3:30 tomorrow? C: S: A003 OK [APPENDUID 1022843275 77712] completed
C：A003 APPEND下書き（\ $ MDNSent見て） "31-月 - 2002年5時26分59秒-0600" {310+} C：日：月、1994年2月7日21時52分25秒-0800（PST）C：投稿者：フレッドfoobarの<foobar@blt.example.COM> C：件名：午後の会議C：TO：mooch@owatagu.siam.eduのC：メッセージ-ID：<B27397-0100000@blt.example.COM> C：MIME -version：1.0 C：のContent-Type：text / plainの。 CHARSET = US-ASCII C：C：こんにちはジョー、あなたは私たちが明日3時30分に会うことができると思いますか？ C：S：A003 OK [APPENDUID 1022843275 77712]完成
* Note that there is a risk that the server will reject the message due to its size. If this happens, the client will waste bandwidth transferring the whole message. If the client wouldn't have used the LITERAL+, this could have been avoided:
*サーバは、そのサイズにメッセージを拒否します危険性があることに注意してください。この問題が発生した場合、クライアントはメッセージ全体を転送帯域幅を浪費することになります。クライアントがLITERAL +を使用していないならば、これは回避されている可能性が：
C: A003 APPEND Drafts (\Seen $MDNSent) "31-May-2004 05:26:59 -0600" {16777215} S: A003 NO Sorry, message is too big
C：A003 APPEND下書き（\ $ MDNSent見て） "31-月-2004五時26分59秒-0600" {16777215} S：A003 NO申し訳ありませんが、メッセージが大きすぎます
Moving a message between two mailbox on two different servers is a combination of the operations described in 4.2.2.2 followed by the operations described in 4.2.2.3.
2台の異なるサーバー上の2つのメールボックス間でメッセージを移動すると、4.2.2.3で説明した動作に続く4.2.2.2で説明した動作の組み合わせです。
4.2.2.5. Uploading Multiple Messages to a Remote Mailbox with MULTIAPPEND
4.2.2.5。 MULTIAPPENDとリモートメールボックスに複数のメッセージをアップロード
When there is a need to upload multiple messages to a remote mailbox (e.g., as per 4.2.2.3), the presence of certain IMAP extensions may significantly improve performance. One of them is [MULTIAPPEND].
（4.2.2.3に従って、例えば）リモートメールボックスに複数のメッセージをアップロードする必要がある場合、特定のIMAP拡張機能の存在は、性能を大幅に改善することができます。そのうちの一つは、[MULTIAPPEND]です。
For some mail stores, opening a mailbox for appending might be expensive. [MULTIAPPEND] tells the server to open the mailbox once (instead of opening and closing it "n" times per "n" messages to be uploaded) and to keep it open while a group of messages is being uploaded to the server.
いくつかのメールストアの場合は、追加のメールボックスを開くと、高価になるかもしれません。 【MULTIAPPEND】一度メールボックスを開くためにサーバに指示する（代わりに開閉その「N」「N」メッセージ当たり回アップロードする）およびメッセージのグループがサーバにアップロードされている間にオープンそれを維持します。
Also, if the server supports both [MULTIAPPEND] and [LITERAL+] extensions, the entire upload is accomplished in a single command/response round-trip.
また、サーバがサポートしている場合、両方の[MULTIAPPEND]と[LITERAL +]拡張は、全体のアップロードが単一のコマンド/レスポンスの往復で達成されます。
Note: Client implementers should be aware that [MULTIAPPEND] performs append of multiple messages atomically. This means, for example, if there is not enough space to save "n"-th message (or the message has invalid structure and is rejected by the server) after successful upload of "n-1" messages, the whole upload operation fails, and no message will be saved in the mailbox. Although this behavior might be desirable in certain situations, it might not be what you want. Otherwise, the client should use the regular APPEND command (Section 4.2.2.3), possibly utilizing the [LITERAL+] extension. See also Section 5.1 for discussions about error recovery.
注：クライアントの実装は、[MULTIAPPEND]実行がアトミック複数のメッセージの追加ことに注意すべきです。これは、「N-1」のメッセージのアップロードが成功した後、保存するのに十分なスペースの「n」番目のメッセージがない場合、たとえば、（またはメッセージが無効な構造を持っており、サーバーによって拒否された）、を意味し、全体のアップロード操作は失敗します、そして何のメッセージがメールボックスに保存されません。この動作は、特定の状況では望ましいかもしれませんが、それはあなたが望むものではないかもしれません。そうでない場合、クライアントはおそらく[LITERAL +]拡張機能を利用し、定期的なAPPENDコマンド（セクション4.2.2.3）を使用する必要があります。また、エラー回復に関する議論については、セクション5.1を参照してください。
Note: MULTIAPPEND can be used together with the UIDPLUS extension in a way similar to what was described in Section 4.2.1. [MULTIAPPEND] extends the syntax of the APPENDUID response code to allow for multiple message UIDs in the second parameter.
注意：MULTIAPPENDは、4.2.1項で説明したものと同様の方法でUIDPLUS拡張子と一緒に使用することができます。 【MULTIAPPEND]二番目のパラメータで複数のメッセージのUIDを可能にするためにAPPENDUID応答コードの構文を拡張します。
Example 2:
例2：
This example demonstrates the use of MULTIAPPEND together with
UIDPLUS (synchronization points where the client waits for
confirmations from the server are marked with "<--->"):
C: A003 APPEND Jan-2002 (\Seen $MDNSent) "31-May-2002 05:26:59 -0600"
{310}
<--->
S: + Ready for literal data
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <foobar@blt.example.COM>
C: Subject: afternoon meeting
C: To: mooch@owatagu.siam.edu
C: Message-Id: <B27397-0100000@blt.example.COM>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: Hello Joe, do you think we can meet at 3:30 tomorrow?
C: (\Seen) " 1-Jun-2002 22:43:04 -0800" {286}
<--->
S: + Ready for literal data
C: Date: Mon, 7 Feb 1994 22:43:04 -0800 (PST)
C: From: Joe Mooch <mooch@OWaTaGu.siam.EDU>
C: Subject: Re: afternoon meeting
C: To: foobar@blt.example.com
C: Message-Id: <a0434793874930@OWaTaGu.siam.EDU>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: 3:30 is fine with me.
C:
S: A003 OK [APPENDUID 1022843275 77712,77713] completed
S：A003 OK [APPENDUID 1022843275 77712,77713]完了
The upload takes 3 round-trips.
アップロードは3ラウンドトリップを取ります。
Example 3:
例3：
In this example, Example 2 was modified for the case when the server supports MULTIAPPEND, LITERAL+, and UIDPLUS. The upload takes only 1 round-trip.
この例では、実施例2は、サーバがMULTIAPPENDリテラル+、及びUIDPLUSをサポートする場合のために修正しました。アップロードは唯一の1往復をとります。
C: A003 APPEND Jan-2002 (\Seen $MDNSent) "31-May-2002 05:26:59 -0600" {310+} C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) C: From: Fred Foobar <foobar@blt.example.COM> C: Subject: afternoon meeting C: To: mooch@owatagu.siam.edu C: Message-Id: <B27397-0100000@blt.example.COM> C: MIME-Version: 1.0 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII C: C: Hello Joe, do you think we can meet at 3:30 tomorrow? C: (\Seen) " 1-Jun-2002 22:43:04 -0800" {286+} C: Date: Mon, 7 Feb 1994 22:43:04 -0800 (PST) C: From: Joe Mooch <mooch@OWaTaGu.siam.EDU> C: Subject: Re: afternoon meeting C: To: foobar@blt.example.com C: Message-Id: <a0434793874930@OWaTaGu.siam.EDU> C: MIME-Version: 1.0 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII C: C: 3:30 is fine with me. C: S: A003 OK [APPENDUID 1022843275 77712,77713] completed
C：A003 APPEND月-2002（\ $ MDNSent見て） "31-月 - 2002年5時26分59秒-0600" {310+} C：日：月、1994年2月7日夜9時52分25秒-0800（PST） C：から：フレッドfoobarの<foobar@blt.example.COM> C：件名：午後の会議C：TO：mooch@owatagu.siam.edu C：メッセージ-ID：<B27397-0100000@blt.example.COM> C ：MIME-バージョン：1.0 C：のContent-Type：text / plainの。 CHARSET = US-ASCII C：C：こんにちはジョー、あなたは私たちが明日3時30分に会うことができると思いますか？ C：（\見て） "1ジュン-2002 22時43分04秒-0800" {286+} C：日：月、1994年2月7日22時43分04秒-0800（PST）C：から：ジョーMooch < mooch@OWaTaGu.siam.EDU> C：件名：再：午後の会議C：TO：foobar@blt.example.com C：メッセージ-ID：<a0434793874930@OWaTaGu.siam.EDU> C：MIME-バージョン：1.0 C ：コンテンツタイプ：TEXT / PLAIN。 CHARSET = US-ASCII C：C：3：30は私と一緒に罰金です。 C：S：A003 OK [APPENDUID 1022843275 77712,77713]完了
The disconnected client uses the STORE command to synchronize local flag state with the server. The disconnected client SHOULD use +FLAGS.SILENT or -FLAGS.SILENT in order to set or unset flags modified by the user while offline. The FLAGS form MUST NOT be used, as there is a risk that this will overwrite flags on the server that have been changed by some other client.
切断されたクライアントは、サーバとローカルフラグの状態を同期させるためにSTOREコマンドを使用しています。切断されたクライアントがオフラインでユーザーによって変更フラグを設定または解除するために、+ FLAGS.SILENT又は-FLAGS.SILENTを使用すべきです。これはいくつかの他のクライアントによって変更されたサーバー上のフラグを上書きするおそれがあるとしてFLAGSフォームは、使用してはいけません。
Example 4:
例4：
For the message with UID 15, the disconnected client stores the following flags \Seen and $Highest. The flags were modified on the server by some other client: \Seen, \Answered, and $Highest. While offline, the user requested that the $Highest flags be removed and that the \Deleted flag be added. The flag synchronization sequence for the message should look like:
UID 15のメッセージのために、切断されたクライアントは、\が見以下のフラグと最高$を格納します。フラグはいくつかの他のクライアントによってサーバーで変更された：\ \回答、および$最高、見ました。オフラインの間、ユーザーは$最高のフラグが削除されることと\ Deletedフラグが追加されることを要求しました。メッセージのフラグ同期シーケンスは、次のようになります。
C: A001 UID STORE 15 +FLAGS.SILENT (\Deleted) S: A001 STORE completed C: A002 UID STORE 15 -FLAGS.SILENT ($Highest) S: A002 STORE completed
C：A001のUIDストア15 + FLAGS.SILENT（\削除済み）S：A001ストアはCを完成：A002のUIDストア15 -FLAGS.SILENT（$最高）S：A002ストアが完成します
If the disconnected client is able to store an additional binary state information (or a piece of information that can take a value from a predefined set of values) in the local cache of an IMAP mailbox or in a local mailbox (e.g., message priority), and if the server supports storing of arbitrary keywords, the client MUST use keywords to store this state on the server.
切断されたクライアントは、IMAPメールボックスのローカルキャッシュまたはローカルメールボックスに（値の所定のセットからの値を取ることができ、または情報の一部）は、追加のバイナリ状態情報を格納することが可能である場合（例えば、メッセージ優先度）サーバは、任意のキーワードの保存をサポートしている場合、および、クライアントがサーバー上で、この状態を保存するために、キーワードを使用しなければなりません。
Example 5:
例5：
Imagine a speculative mail client that can mark a message as one of work-related ($Work), personal ($Personal), or spam ($Spam). In order to mark a message as personal, the client issues:
仕事関連（$作業）の一つとしてメッセージをマークすることができ投機メールクライアント、個人（$パーソナル）、または迷惑メール（スパム$）を想像してみてください。個人としてメッセージをマークするためには、クライアントの問題：
C: A001 UID STORE 15 +FLAGS.SILENT ($Personal) S: A001 STORE completed C: A002 UID STORE 15 -FLAGS.SILENT ($Work $Spam) S: A002 STORE completed
C：A001のUIDストアは、15 + FLAGS.SILENT（$パーソナル）S：A001ストア完了C：A002のUIDストア15 -FLAGS.SILENT（$作業$スパム）S：A002ストアが完成します
In order to mark the message as not work, not personal and not spam, the client issues:
動作しないように、メッセージ、個人的ではないとスパムではない、クライアントの問題をマークするために：
C: A003 UID STORE 15 -FLAGS.SILENT ($Personal $Work $Spam) S: A003 STORE completed
C：A003のUIDストア15 -FLAGS.SILENT（$パーソナル$作業$スパム）S：A003ストアが完成します
A naive disconnected client implementation that supports compressing a mailbox while offline may decide to issue an EXPUNGE command to the server in order to expunge messages marked \Deleted. The problem with this command during synchronization is that it permanently erases all messages with the \Deleted flag set, i.e., even those messages that were marked as \Deleted on the server while the user was offline. Doing this might result in an unpleasant surprise for the user.
オフライン\ [削除マークの付いたメッセージを抹消するためにサーバにEXPUNGEコマンドを発行することを決定するかもしれないが、メールボックスを圧縮サポートナイーブ切断されたクライアントの実装。同期中にこのコマンドを使用して、問題は、それが永久に、\ Deletedフラグが設定されたすべてのメッセージを消去していることである、すなわち、ユーザーがオフラインであった間、サーバー上の\削除済みとしてマークされたとしても、それらのメッセージ。これを行うと、ユーザーにとって不快な驚きになる可能性があります。
Fortunately the [UIDPLUS] extension can help in this case as well. The extension introduces UID EXPUNGE command, that, unlike EXPUNGE, takes a UID set parameter, that lists UIDs of all messages that can be expunged. When processing this command the server erases only messages with \Deleted flag listed in the UID list. Thus, messages not listed in the UID set will not be expunged even if they have the \Deleted flag set.
幸いにも[UIDPLUS]拡張は、この場合にも役立ちます。拡張子がUID EXPUNGEコマンドが導入され、それは、EXPUNGEとは異なり、抹消することができ、すべてのメッセージのUIDを示していますUID設定されたパラメータを取ります。このコマンドを処理するとき、サーバはUIDのリストに記載されて\ Deletedフラグを持つメッセージだけを消去します。このように、UIDセットに記載されていないメッセージは、彼らが\ Deletedフラグが設定されている場合でも、抹消されることはありません。
Example 6:
例6：
While the user was offline, 3 messages with UIDs 7, 27, and 65 were marked \Deleted when the user requested to compress the open mailbox. Another client marked a message \Deleted on the server (UID 34). During synchronization, the disconnected client issues:
ユーザーがオフラインであったが、UIDの7、27、および65との3つのメッセージは、ユーザーが開いているメールボックスを圧縮するために要求されたときに削除\マークしました。別のクライアントは、サーバー（UID 34）に削除されたメッセージを\マーク。同期中に、切断されたクライアントの問題：
C: A001 UID EXPUNGE 7,27,65 S: * ... EXPUNGE S: * ... EXPUNGE S: * ... EXPUNGE S: A001 UID EXPUNGE completed
C：A001 UID EXPUNGE 7,27,65 S：* ... EXPUNGE S：* ... EXPUNGE S：* ... EXPUNGE S：A001 UID EXPUNGEが完成しました
If another client issues UID SEARCH DELETED command (to find all messages with the \Deleted flag) before and after the UID EXPUNGE, it will get:
別のクライアントの問題はUID検索がUID EXPUNGE前と後（\ Deletedフラグを持つすべてのメッセージを見つけるために）コマンドを削除した場合、それが得られます：
Before:
前：
C: B001 UID SEARCH DELETED S: * SEARCH 65 34 27 7 S: B001 UID SEARCH completed
C：B001 UID SEARCH DELETED S：* SEARCH 65 34 27 7 S：完成B001 UID検索
After:
後：
C: B002 UID SEARCH DELETED S: * SEARCH 34 S: B002 UID SEARCH completed
C：B002 UID SEARCH DELETED S：* SEARCH 34 S：B002 UIDの検索が完了しました
In the absence of the [UIDPLUS] extension, the following sequence of commands can be used as an approximation. Note: It's possible for another client to mark additional messages as deleted while this sequence is being performed. In this case, these additional messages will be expunged as well.
【UIDPLUS】伸長の不在下で、次のコマンドシーケンスは、近似として使用することができます。注意：このシーケンスが実行されている間、削除されたとして、別のクライアントが追加メッセージをマークすることが可能です。この場合、これらの追加のメッセージも同様に消去されます。
1) Find all messages marked \Deleted on the server.
1）サーバー上で削除マークされたすべてのメッセージを\下さい。
C: A001 UID SEARCH DELETED S: * SEARCH 65 34 27 7 S: A001 UID SEARCH completed
C：A001 UID SEARCH DELETED S：* SEARCH 65 34 27 7 S：完成A001のUID検索
2) Find all messages that must not be erased (for the previous example the list will consist of the message with UID 34).
2）（前の例のためのリストは、UID 34のメッセージで構成されます）を消去してはいけないすべてのメッセージを検索します。
3) Temporarily remove \Deleted flag on all messages found in step 2.
3）一時的にステップ2で見つかったすべてのメッセージに、\ Deletedフラグを削除します。
C: A002 UID STORE 34 -FLAGS.SILENT (\Deleted) S: A002 UID STORE completed
C：A002のUIDストア34 -FLAGS.SILENT（\削除）S：完成A002のUIDストア
4) Expunge the mailbox.
4）メールボックスを抹消。
C: A003 EXPUNGE S: * 20 EXPUNGE S: * 7 EXPUNGE S: * 1 EXPUNGE S: A003 EXPUNGE completed
C：A003 EXPUNGE S：* 20 EXPUNGE S：* 7 EXPUNGEのS：* 1 EXPUNGE S：A003のEXPUNGEが完成
Here, the message with UID 7 has message number 1, with UID 27 has message number 7, and with UID 65 has message number 20.
ここで、UID 7のメッセージは、UID 27とメッセージ番号1は、メッセージ番号7を有し、UID 65とメッセージ番号20を有しています。
5) Restore \Deleted flag on all messages found when performing step 2.
5）ステップ2を実行するときに検出されたすべてのメッセージに、\ Deletedフラグを復元します。
C: A004 UID STORE 34 +FLAGS.SILENT (\Deleted) S: A004 UID STORE completed
C：A004のUIDストア34 + FLAGS.SILENT（\削除）S：完成A004のUIDストア
When the disconnected client has to close a mailbox, it should not use the CLOSE command, because CLOSE does a silent EXPUNGE. (Section 4.2.4 explains why EXPUNGE should not be used by a disconnected client.) It is safe to use CLOSE only if the mailbox was opened with EXAMINE.
切断されたクライアントがメールボックスを閉じる必要がある場合CLOSEサイレントEXPUNGEを行うので、それは、CLOSEコマンドを使用しないでください。 （EXPUNGEが切断されたクライアントによって使用されるべきではない理由4.2.4項は説明しています。）メールボックスがEXAMINEで開かれた場合にのみ、CLOSEを使用しても安全です。
If the mailbox was opened with SELECT, the client can use one of the following commands to implicitly close the mailbox and prevent the silent expunge:
メールボックスがSELECTで開いた場合、クライアントは、暗黙的にメールボックスを閉じて静かEXPUNGEを防ぐために、次のいずれかのコマンドを使用することができます。
1) UNSELECT - This is a command described in [UNSELECT] that works as CLOSE, but doesn't cause the silent EXPUNGE. This command is supported by the server if it reports UNSELECT in its CAPABILITY list.
1）UNSELECT - これはCLOSEとして動作しますが、サイレントEXPUNGEを起こさない[UNSELECT]で説明したコマンドです。それは能力リストにUNSELECTを報告する場合、このコマンドは、サーバーでサポートされています。
2) SELECT <another_mailbox> - SELECT causes implicit CLOSE without EXPUNGE.
2）<another_mailbox> SELECT - SELECTはEXPUNGEなし暗黙のCLOSEの原因となります。
3) If the client intends to issue LOGOUT after closing the mailbox, it may just issue LOGOUT, because LOGOUT causes implicit CLOSE without EXPUNGE as well.
クライアントがメールボックスを閉じた後にログアウトを発行する予定ならばLOGOUTが同様にEXPUNGEなし暗黙のCLOSEを引き起こすため3）、それだけで、LOGOUTを発行することができます。
4) SELECT <non_existing_mailbox> - If the client knows a mailbox that doesn't exist or can't be selected, it MAY SELECT it.
4）<non_existing_mailbox> SELECT - クライアントが存在しないメールボックスを知っているか、選択することができない場合は、それを選択することができます。
If the client opened the mailbox with SELECT and just wants to avoid implicit EXPUNGE without closing the mailbox, it may also use the following:
クライアントは、SELECTでメールボックスを開いて、ちょうどメールボックスを閉じずに暗黙のEXPUNGEを避けたい場合は、それはまた、次のように使用することができます：
5) EXAMINE <mailbox> - Reselect the same mailbox in read-only mode.
5）<メールボックス> EXAMINE - 読み取り専用モードで同じメールボックスを再選択。
The most common form of synchronization is where the human trusts the integrity of the client's copy of the state of a particular mailbox and simply wants to bring the client's cache up to date so that it accurately reflects the mailbox's current state on the server.
人間は、特定のメールボックスの状態のクライアントのコピーの整合性を信頼し、単にそれが正確にサーバー上のメールボックスの現在の状態を反映するように最新のクライアントのキャッシュを持って望んでいる場所の同期の最も一般的な形式です。
Let <lastseenuid> represent the highest UID that the client knows about in this mailbox. Since UIDs are allocated in strictly ascending order, this is simply the UID of the last message in the mailbox that the client knows about. Let <lastseenuid+1> represent <lastseenuid>'s UID plus one. Let <descriptors> represent a list consisting of all the FETCH data item items that the implementation considers part of the descriptor; at a minimum this is just the FLAGS data item, but it usually also includes BODYSTRUCTURE and RFC822.SIZE. At this step, <descriptors> SHOULD NOT include RFC822.
<lastseenuid>は、クライアントがこのメールボックスで知っている最高のUIDを表してみましょう。 UIDは、厳密に昇順に割り当てられているので、これは単に、クライアントが知っていることを、メールボックス内の最後のメッセージのUIDです。 <lastseenuid + 1>は、<lastseenuid>のUIDを加えたものを表してみましょう。 <記述子は>実装は記述の一部を考慮し、すべてのFETCHデータ項目の項目からなるリストを表してみましょう。最低でもこれだけのFLAGSデータ項目であるが、それは通常、BODYSTRUCTUREとRFC822.SIZEを含んでいます。このステップでは、<記述子は> RFC822を含めるべきではありません。
With no further information, the client can issue the following two commands:
それ以上の情報では、クライアントは次の2つのコマンドを発行できます。
tag1 UID FETCH <lastseenuid+1>:* <descriptors> tag2 UID FETCH 1:<lastseenuid> FLAGS
TAG1のUID FETCH <lastseenuid + 1>：* <記述子> TAG2のUIDは1をFETCH：<lastseenuid> FLAGSを
The first command will request some information about "new" messages (i.e., messages received by the server since the last synchronization). It will also allow the client to build a message number to UID map (only for new messages). The second command allows the client to
最初のコマンドは、「新しい」メッセージ（前回の同期以降にサーバーが受信した、すなわち、メッセージ）に関するいくつかの情報を要求します。また、クライアントが（唯一の新しいメッセージ用）UIDのマップにメッセージ番号を構築することができます。 2番目のコマンドは、クライアントにすることができます
1) update cached flags for old messages;
1）古いメッセージのためにキャッシュされたフラグを更新します。
2) find out which old messages got expunged; and
2）古いメッセージが消去されてしまった見つけます。そして
3) build a mapping between message numbers and UIDs (for old messages).
3）メッセージ番号と古いメッセージのためのUID（）との間のマッピングを構築します。
The order here is significant. We want the server to start returning the list of new message descriptors as fast as it can, so that the client can start issuing more FETCH commands, so we start out by asking for the descriptors of all the messages we know the client cannot possibly have cached yet. The second command fetches the information we need to determine what changes may have occurred to messages that the client already has cached. Note that the former command should only be issued if the UIDNEXT value cached by the client differs from the one returned by the server. Once the client has issued these two commands, there's nothing more the client can do with this mailbox until the responses to the first command start arriving. A clever synchronization program might use this time to fetch its local cache state from disk or to start the process of synchronizing another mailbox.
ここでの順序は重要です。私たちは、サーバはクライアントがコマンドをFETCHより発行開始できるように、新しいメッセージのリストは、早くそれができるようにディスクリプタを返す始めたいので、我々は、我々は、クライアントが、おそらくことはできません知っているすべてのメッセージの記述子を求めることから始めまだキャッシュされました。 2番目のコマンドは、私たちは、クライアントがすでにキャッシュされたメッセージに発生した可能性がどのような変更を決定するために必要な情報を取得します。クライアントによってキャッシュされUIDNEXT値がサーバから返されたものと異なる場合は、元のコマンドにのみ発行する必要があることに注意してください。クライアントは、これらの2つのコマンドを発行した後、最初のコマンドに応答が到着し始めるまで、クライアントは、このメールボックスで行うことができますより多くの何もありません。賢い同期プログラムがディスクからローカルキャッシュの状態を取得するか、別のメールボックスを同期するプロセスを開始するには、この時間を使用する場合があります。
The following is an example of the first FETCH:
以下は、最初のFETCHの例です。
C: A011 UID fetch 131:* (FLAGS BODYSTRUCTURE INTERNALDATE RFC822.SIZE)
C：A011のUIDフェッチ131 *（FLAGS BODYSTRUCTURE INTERNALDATE RFC822.SIZE）
Note 1: The first FETCH may result in the server's sending a huge volume of data. A smart disconnected client should use message ranges (see also Section 3.2.1.2 of [RFC2683]), so that the user is able to execute a different operation between fetching information for a group of new messages.
注1：最初のFETCHは、サーバのデータの膨大な量を送信することがあります。スマート切断されたクライアントは、メッセージを使用する必要があり、ユーザが新しいメッセージのグループの情報を取得する間に異なる動作を実行することができるように、（また、[RFC2683]のセクション3.2.1.2を参照のこと）の範囲です。
Example 7:
例7：
Knowing the new UIDNEXT returned by the server on SELECT or EXAMINE (<uidnext>), the client can split the UID range <lastseenuid+1>:<uidnext> into groups, e.g., 100 messages. After that, the client can issue:
基、例えば、100件のメッセージに<UIDNEXT>：SELECTまたはEXAMINE（<UIDNEXT>）上のサーバによって返された新しいUIDNEXTを知ることは、クライアントがUID範囲<lastseenuid + 1>を分割することができます。その後、クライアントが発行できます。
C: A011 UID fetch <lastseenuid+1>:<lastseenuid+100> (FLAGS BODYSTRUCTURE INTERNALDATE RFC822.SIZE) ... C: A012 UID fetch <lastseenuid+101>:<lastseenuid+200> (FLAGS BODYSTRUCTURE INTERNALDATE RFC822.SIZE) ... ... C: A0FF UID fetch <lastseenuid+901>:<uidnext> (FLAGS BODYSTRUCTURE INTERNALDATE RFC822.SIZE)
C：A011 UIDフェッチ<lastseenuid + 1>：<lastseenuid + 100>（FLAGS BODYSTRUCTURE INTERNALDATE RFC822.SIZE）... C：A012 UIDフェッチ<lastseenuid + 101>：<lastseenuid + 200>（FLAGS BODYSTRUCTURE INTERNALDATE RFC822.SIZE ）... C：A0FF UIDフェッチ<lastseenuid + 901>：<UIDNEXT>（FLAGS BODYSTRUCTURE INTERNALDATE RFC822.SIZE）
Note that unless a SEARCH command is issued, it is impossible to determine how many messages will fall into a subrange, as UIDs are not necessarily contiguous.
SEARCHコマンドが発行されていない限りのUIDは必ずしも連続していないとして、サブレンジに分類されますどのように多くのメッセージを決定することは不可能であることに注意してください。
Note 2: The client SHOULD ignore any unsolicited EXPUNGE responses received during the first FETCH command. EXPUNGE responses contain message numbers that are useless to a client that doesn't have the message-number-to-UID translation table.
注2：クライアントは、最初のFETCHコマンドの間に受信した迷惑EXPUNGE応答を無視します。 EXPUNGE応答は、メッセージ数ツーUID変換テーブルを持っていないクライアントに役に立たないメッセージ番号が含まれています。
The second FETCH command will result in zero or more untagged fetch responses. Each response will have a corresponding UID FETCH data item. All messages that didn't have a matching untagged FETCH response MUST be removed from the local cache.
FETCH 2番目のコマンドは、ゼロまたはフェッチよりタグなしの応答になります。各応答は、対応するUID FETCHデータ項目を持つことになります。マッチングタグなしFETCH応答を持っていなかったすべてのメッセージは、ローカルキャッシュから削除する必要があります。
For example, if the <lastseenuid> had a value 15000 and the local cache contained 3 messages with the UIDs 12, 777, and 14999, respectively, then after receiving the following responses from the server, the client must remove the message with UID 14999 from its local cache.
<lastseenuid>が値15000を持っていたし、ローカルキャッシュはそれぞれのUID 12、777、および14999、と3つのメッセージが含まれている場合たとえば、その後、サーバーから次の応答を受け取った後、クライアントは、UID 14999とのメッセージを削除する必要がありますそのローカルキャッシュから。
S: * 1 FETCH (UID 12 FLAGS (\Seen)) S: * 2 FETCH (UID 777 FLAGS (\Answered \Deleted))
S：* 1 FETCH（UIDを12のFLAGS（\みる））S：*（UID 777 FLAGS（\回答\削除されたが））FETCH 2
Note 3: If the client is not interested in flag changes (i.e., the client only wants to know which old messages are still on the server), the second FETCH command can be substituted with:
注3：クライアントが（つまり、クライアントが唯一の古いメッセージは、サーバー上に残っているどの知りたい）フラグの変化に興味を持っていない場合は、2番目のFETCHコマンドがで置換することができます。
tag2 UID SEARCH UID 1:<lastseenuid>
TAG2 UIDの検索UID 1：<lastseenuid>
This command will generate less traffic. However, an implementor should be aware that in order to build the mapping table from message numbers to UIDs, the output of the SEARCH command MUST be sorted first, because there is no requirement for a server to return UIDs in SEARCH response in any particular order.
このコマンドは、以下のトラフィックを生成します。しかし、実装者は、特定の順序で検索応答にUIDを返すようにサーバの要件がないためのUIDのメッセージ番号からマッピングテーブルを構築するために、SEARCHコマンドの出力は、最初にソートしなければならないことに注意する必要があります。
This step is performed entirely on the client (from the information received in the step described in 4.3.1), entirely on the server, or on some combination of both. The decision on what is an "interesting" message is up to the client software and the human. One easy criterion that should probably be implemented in any client is whether the message is "too big" for automatic retrieval, where "too big" is a parameter defined in the client's configuration.
このステップは、完全サーバー上の、または両方の何らかの組み合わせで、（4.3.1で説明したステップで受信した情報から）クライアント上で完全に実行されます。 「興味深い」のメッセージであるかについての決定は、クライアントソフトウェアと人間に任されています。おそらく、任意のクライアントに実装されなければならない一つの簡単な基準は、メッセージが「大きすぎる」自動検索のための「大きすぎる」であるかどうかであるクライアントの構成で定義されたパラメータです。
Another commonly used criterion is the age of a message. For example, the client may choose to download only messages received in the last week (in this case, <date> would be today's date minus 7 days):
別の一般的に使用される基準は、メッセージの年齢です。例えば、クライアントが（この場合には、<日付>は今日の日付マイナス7日になります）、最後の週に受け取ったメッセージのみをダウンロードすることもできます。
tag3 UID SEARCH UID <uidset> SINCE <date>
TAG3 UID SEARCH UID <uidset> SINCE <日付>
Keep in mind that a date search disregards time and time zone. The client can avoid doing this search if it specified INTERNALDATE in <descriptors> on the step described in 4.3.1. If the client did, it can perform the local search on its message cache.
日付の検索は時間と時間帯を無視していることに注意してください。それは4.3.1で説明したステップに<記述子>にINTERNALDATEを指定した場合、クライアントは、この検索を行うことを避けることができます。クライアントがした場合は、そのメッセージキャッシュのローカル検索を行うことができます。
At this step, the client also decides what kind of information about a particular message to fetch from the server. In particular, even for a message that is considered "too big", the client MAY choose to fetch some part(s) of it. For example, if the message is a multipart/mixed containing a text part and a MPEG attachment, there is no reason for the client not to fetch the text part. The decision of which part should or should not be fetched can be based on the information received in the BODYSTRUCTURE FETCH response data item (i.e., if BODYSTRUCTURE was included in <descriptors> on the step described in 4.3.1).
このステップでは、クライアントは、サーバから取得するために特定のメッセージに関する情報の種類を決定します。特に、でも「大きすぎる」とみなされたメッセージのために、クライアントはそれのいくつかの部分（複数可）を取得するために選ぶかもしれません。メッセージは、テキスト部分とMPEGアタッチメントを含む混合/マルチパートであれば、例えば、テキストの一部をフェッチしないクライアントのための理由はありません。一部のまたはフェッチすべきではないべきの決定は、応答データ項目をFETCH BODYSTRUCTUREにおいて受信された情報に基づくことができる（すなわち、BODYSTRUCTUREは、4.3.1で説明したステップに<記述子>に含まれていた場合）。
Once the client has found out which messages are "interesting", it can start issuing appropriate FETCH commands for "interesting" messages or parts thereof.
クライアントが「面白い」であるメッセージを発見したら、それはその「面白い」メッセージや部品のための適切なFETCHコマンドを発行開始することができます。
Note that fetching a message into the disconnected client's local cache does NOT imply that the human has (or even will) read the message. Thus, the synchronization program for a disconnected client should always be careful to use the .PEEK variants of the FETCH data items that implicitly set the \Seen flag.
切断されたクライアントのローカルキャッシュにメッセージをフェッチすると、メッセージを読む（う偶数か）人間が持っていることを意味しないことに注意してください。このように、切断されたクライアントのための同期プログラムは、常に暗黙のうちに\見フラグを設定FETCHデータ項目の.PEEKバリアントを使用するように注意する必要があります。
Once the last descriptor has arrived and the last FETCH command has been issued, the client simply needs to process the incoming fetch items and use them to update the local message cache.
最後の記述子が到着したとFETCH最後のコマンドが発行されると、クライアントは単に、着信処理アイテムを取得し、ローカルメッセージキャッシュを更新するためにそれらを使用する必要があります。
In order to avoid deadlock problems, the client must give processing of received messages priority over issuing new FETCH commands during this synchronization process. This may necessitate temporary local queuing of FETCH requests that cannot be issued without causing a deadlock. In order to achieve the best use of the "expensive" network connection, the client will almost certainly need to pay careful attention to any flow-control information that it can obtain from the underlying transport connection (usually a TCP connection).
デッドロックの問題を避けるために、クライアントは、この同期プロセス中に新しいFETCHコマンドを発行する上で受信したメッセージの優先順位の処理を与える必要があります。これは、デッドロックを発生させずに発行することができないFETCH要求の一時的なローカルキューイングを必要とするかもしれません。 「高価な」ネットワーク接続の最適な使用を達成するために、クライアントは、ほぼ確実にそれが基本的なトランスポート接続（通常はTCPコネクション）から得られることが任意のフロー制御情報に細心の注意を払う必要があります。
Note: The requirement stated in the previous paragraph might result in an unpleasant user experience, if followed blindly. For example, the user might be unwilling to wait for the client to finish synchronization before starting to process the user's requests. A smart disconnected client should allow the user to perform requested operations in between IMAP commands that are part of the synchronization process. See also Note 1 in Section 4.3.1.
注意：盲目的に従った場合、前の段落で述べた要件は、不快なユーザーエクスペリエンスにつながる可能性があります。例えば、ユーザは、ユーザの要求を処理するために開始する前に、同期を完了するためにクライアントを待つ不本意かもしれません。スマート切断されたクライアントは、ユーザーが同期プロセスの一部であるIMAPコマンドの間で要求された操作を実行できるようにする必要があります。また、4.3.1項に注1を参照してください。
Example 8:
例8：
After fetching a message BODYSTRUCTURE, the client discovers a complex MIME message. Then, it decides to fetch MIME headers of the nested MIME messages and some body parts.
メッセージのBODYSTRUCTUREを取得した後、クライアントは、複雑なMIMEメッセージを検出します。その後、それは入れ子になったMIMEメッセージのMIMEヘッダといくつかの体の部分を取得することを決定します。
C: A011 UID fetch 11 (BODYSTRUCTURE) S: ... C: A012 UID fetch 11 (BODY[HEADER] BODY[1.MIME] BODY[1.1.MIME] BODY[1.2.MIME] BODY[2.MIME] BODY[3.MIME] BODY[4.MIME] BODY[5.MIME] BODY[6.MIME] BODY[7.MIME] BODY[8.MIME] BODY[9.MIME] BODY[10.MIME] BODY[11.MIME] BODY[12.MIME] BODY[13.MIME] BODY[14.MIME] BODY[15.MIME] BODY[16.MIME] BODY[17.MIME] BODY[18.MIME] BODY[19.MIME] BODY[20.MIME] BODY[21.MIME]) S: ... C: A013 UID fetch 11 (BODY[1.1] BODY[1.2]) S: ... C: A014 UID fetch 11 (BODY[3] BODY[4] BODY[5] BODY[6] BODY[7] BODY[8] BODY[9] BODY[10] BODY[11] BODY[13] BODY[14] BODY[15] BODY[16] BODY[21]) S: ...
C：A011 UID 11（BODYSTRUCTURE）Sをフェッチ... C：A012 UID 11（BODY [HEADER] BODY [1.MIME] BODY [1.1.MIME] BODY [1.2.MIME] BODY [2.MIME] BODYフェッチ【3.MIME] BODY [4.MIME] BODY [5.MIME] BODY [6.MIME] BODY [7.MIME] BODY [8.MIME] BODY [9.MIME] BODY [10.MIME] BODY [11 .MIME] BODY [12.MIME] BODY [13.MIME] BODY [14.MIME] BODY [15.MIME] BODY [16.MIME] BODY [17.MIME] BODY [18.MIME] BODY [19.MIME ] BODY [20.MIME] BODY [21.MIME]）S：... C：A013 UID 11をフェッチ（BODY [1.1] BODY [1.2]）S：... C：A014 UID 3 [（体11をフェッチ] BODY [4] BODY [5] BODY [6] BODY [7] BODY [8] BODY [9] BODY [10] BODY [11] BODY [13] BODY [14] BODY [15] BODY [16] BODY [21]）S：...
After the client has finished the main synchronization process as described in Sections 4.3.1-4.3.3, the user may optionally request additional synchronization steps while the client is still online. This is not any different from the process described in Sections 4.3.2 and 4.3.3.
セクション4.3.1-4.3.3に記載されているように、クライアントは、主同期プロセスを完了した後、クライアントがオンラインである間、ユーザは、必要に応じて追加の同期手順を要求することができます。これは、セクション4.3.2と4.3.3で説明したプロセスからの違いはありません。
Typical examples are:
典型的な例は以下のとおりです。
1) fetch all messages selected in UI. 2) fetch all messages marked as \Flagged on the server.
1）UIで選択されたすべてのメッセージを取得します。 2）サーバー上のフラグ付き\としてマークされたすべてのメッセージを取得します。
For some mailboxes, fetching the descriptors might be the entire synchronization step. Practical experience with IMAP has shown that a certain class of mailboxes (e.g., "archival" mailboxes) are used primarily for long-term storage of important messages that the human wants to have instantly available on demand but does not want cluttering up the disconnected client's cache at any other time. Messages in this kind of mailbox would be fetched exclusively by explicit actions queued by the local MUA. Thus, the only synchronization desirable on this kind of mailbox is fetching enough descriptor information for the user to be able to identify messages for subsequent download.
一部のメールボックスの場合は、記述子をフェッチすると、全体の同期ステップであるかもしれません。 IMAPでの実際の経験は、メールボックスの特定のクラス（例えば、「アーカイブ」のメールボックスが）人間は、オンデマンドですぐに利用できる持って望んでいるが、切断されたクライアントのを乱雑にしたくないことを主に重要なメッセージの長期保存のために使用されていることを示しています他のどの時点でキャッシュ。メールボックスのこの種のメッセージは、ローカルMUAによってキューに入れられ、明示的なアクションによってのみフェッチされるだろう。このように、メールボックスのこの種の望ましい唯一の同期は、その後のダウンロードのためのメッセージを識別できるようにするには、ユーザーのための十分な記述子情報をフェッチしています。
Special mailboxes that receive messages from a high volume, low priority mailing list might also be in this category, at least when the human is in a hurry.
ハイボリュームからメッセージを受信する特殊なメールボックスは、優先度の低いメーリングリストも、人間が急いでいるとき、少なくとも、このカテゴリーにあるかもしれません。
In some cases, the human might be in such a hurry that he or she doesn't care about changes to old messages, just about new messages. In this case, the client can skip the UID FETCH command that obtains the flags and UIDs for old messages (1:<lastseenuid>).
いくつかのケースでは、人間は、彼または彼女はちょうど新しいメッセージについては、古いメッセージへの変更を気にしないように急いであるかもしれません。この場合、クライアントは、UIDが古いメッセージ（：<lastseenuid> 1）のためのフラグとUIDを取得FETCHコマンドをスキップすることができます。
In some cases, the human may know (for whatever reason) that he or she always wants to fetch any new messages in a particular mailbox, unconditionally. In this case, the client can just fetch the messages themselves, rather than just the descriptors, by using a command like:
いくつかのケースでは、人間は、彼または彼女は常に無条件に、特定のメールボックスに新しいメッセージを取得したい（何らかの理由で）知っているかもしれません。この場合、クライアントは、同じようにコマンドを使用して、メッセージ自体だけではなく、記述子を取得することができます：
tag1 UID FETCH <lastseenuid+1>:* (FLAGS BODY.PEEK[])
TAG1のUID FETCH <lastseenuid + 1>：*（FLAGS BODY.PEEK []）
Note that this example ignores the fact that the messages can be arbitrary long. The disconnected client MUST always check for message size before downloading, unless explicitly told otherwise. A well-behaved client should instead use something like the following:
この例では、メッセージは、任意の長さにすることができるという事実を無視することに注意してください。明示的にそう言われない限り、切断されたクライアントは常に、ダウンロードする前にメッセージサイズのためにチェックしなければなりません。行儀のクライアントは、代わりに次のようなものを使用する必要があります。
1) Issue "tag1 UID FETCH <lastseenuid+1>:* (FLAGS RFC822.SIZE)".
1）問題 "TAG1のUID FETCH <lastseenuid + 1>：*（FLAGSはRFC822.SIZE）"。
2) From the message sizes returned in step 1, construct UID set <required_messages>.
2）メッセージから設定されたUIDを構成する、ステップ1で返さサイズ<required_messages>。
3) Issue "tag2 UID FETCH <required_messages> (BODY.PEEK[])".
3）発行 "TAG2のUIDがFETCH <required_messages>（BODY.PEEK []）"。
or
または
1) Issue "tag1 UID FETCH <lastseenuid+1>:* (FLAGS)".
1）問題 "TAG1のUIDは、FETCH <lastseenuid + 1>：*（FLAGS）"。
2) Construct UID set <old_uids> from the responses of step 1.
2）工程1の応答からUIDセット<old_uids>を構築します。
3) Issue "tag2 SEARCH UID <old_uids> SMALLER <message_limit>". Construct UID set <required_messages> from the result of the SEARCH command.
3）問題 "TAG2検索UID <old_uids> SMALLER <のmessage_limit>"。 SEARCHコマンドの結果からUIDセット<required_messages>を構築します。
4) Issue "tag3 UID FETCH <required_messages> (BODY.PEEK[])".
4）号 "TAG3のUIDがFETCH <required_messages>（BODY.PEEK []）"。
or
または
1) Issue "tag1 UID FETCH <lastseenuid+1>:* (FLAGS BODY.PEEK[]<0.<length>>)", where <length> should be replaced with the maximal message size the client is willing to download.
1）発行 "TAG1のUIDがFETCH <lastseenuid + 1>：*（FLAGS BODY.PEEK [] <0 <長>>）" <長さ>は、クライアントがダウンロードしても構わないと思っている最大メッセージサイズに置き換える必要があり、。
Note: In response to such a command, the server will only return partial data if the message is longer than <length>. It will return the full message data for any message whose size is smaller than or equal to <length>. In the former case, the client will not be able to extract the full MIME structure of the message from the truncated data, so the client should include BODYSTRUCTURE in the UID FETCH command as well.
注：メッセージが長い<長さ>を超える場合、そのようなコマンドに応答して、サーバが部分的にしかデータを返します。それは、そのサイズの<length>以下であるすべてのメッセージの完全なメッセージデータを返します。前者の場合、クライアントは、切り捨てられたデータからのメッセージの完全なMIME構造を抽出することはできないので、クライアントは、UIDでBODYSTRUCTUREは同様にFETCHコマンドを含むべきです。
Below are listed some common implementation pitfalls that should be considered when implementing a disconnected client.
以下は、切断されたクライアントを実装する際に考慮すべきいくつかの一般的な実装の落とし穴を記載されています。
1) Implementing fake UIDs on the client.
1）クライアントに偽のUIDを実装します。
A message scheduled to be uploaded has no UID, as UIDs are selected by the server. The client may implement fake UIDs internally in order to reference not-yet-uploaded messages in further operations. (For example, a message could be scheduled to be uploaded, but subsequently marked as deleted or copied to another mailbox). Here, the client MUST NOT under any circumstances send these fake UIDs to the server. Also, client implementers should be reminded that according to [IMAP4] a UID is a 32-bit unsigned integer excluding 0. So, both 4294967295 and 2147483648 are valid UIDs, and 0 and -1 are both invalid. Some disconnected mail clients have been known to send negative numbers (e.g., "-1") as message UIDs to servers during synchronization.
UIDがサーバによって選択されているとしてアップロードされる予定のメッセージは、何のUIDを持っていません。クライアントは、さらに操作で未アップロードメッセージを参照するために内部的に偽のUIDを実施することができます。 （例えば、メッセージがアップロードされるようにスケジュールすることができますが、その後、削除済みとしてマークまたは別のメールボックスにコピー）。ここでは、クライアントがどのような状況の下でのサーバーにこれらの偽のUIDを送ってはいけません。また、クライアントの実装は、[IMAP4]に記載のUIDは0だから、両方4294967295及び2147483648が有効のUID、及び0であり、-1両方無効で除く32ビットの符号なし整数であることに留意すべきです。いくつかの切断メールクライアントが同期中に負の数（例えば、「-1」）のサーバーへのメッセージのUIDなどを送信することが知られています。
Situation 1: The user starts composing a new message, edits it, saves it, continues to edit it, and saves it again.
状況1：ユーザーは、新しいメッセージを作成開始し、それを編集し、それを保存し、それを編集し続け、再度保存します。
A disconnected client may record in its replay log (log of operations to be replayed on the server during synchronization) the sequence of operations as shown below. For the purpose of this situation, we assume that all draft messages are stored in the mailbox called Drafts on an IMAP server. We will also use the following conventions: <old_uid> is the UID of the intermediate version of the draft when it was saved for the first time. This is a fake UID generated on the client. <new_uid> is the UID of the final version of the draft. This is another fake UID generated on the client.
以下に示すように切断されたクライアントは、（動作のログが同期中に、サーバー上で再生されるように）、その再生ログの動作のシーケンスを記録することができます。このような状況のために、我々はすべての下書きメッセージは、IMAPサーバー上の下書きと呼ばれるメールボックスに格納されていることを前提としています。我々はまた、次の表記法を使用します。<old_uid>は、それが最初に保存されたドラフトの中間バージョンのUIDです。これは、クライアント上で生成された偽のUIDです。 <new_uid>ドラフトの最終版のUIDです。これは、クライアント上で生成された別の偽のUIDです。
1) APPEND Drafts (\Seen $MDNSent \Drafts) {<nnn>} ...first version of the message follows...
1）APPEND下書き（\ $ MDNSent \下書き見られる）{<NNN>} ...メッセージの最初のバージョンは、以下...
2) APPEND Drafts (\Seen $MDNSent \Drafts) {<mmm>} ...final version of the message follows...
2）APPEND下書き（\ $ MDNSent \下書き見られる）{<MMM>} ...メッセージの最終バージョンは、以下...
3) STORE <old_uid> +FLAGS (\Deleted)
3）STORE <old_uid> + FLAGS（\削除済み）
Step 1 corresponds to the first attempt to save the draft message, step 2 corresponds to the second attempt to save the draft message, and step 3 deletes the first version of the draft message saved in step 1.
ステップ1、ステップ2は、ドラフト・メッセージを保存するための第2の試みに相当し、ステップ3ステップ1で保存したドラフト・メッセージの最初のバージョンを削除し、ドラフト・メッセージを保存するための最初の試みに相当します。
A naive disconnected client may send the command in step 3 without replacing the fake client generated <old_uid> with the value returned by the server in step 1. A server will probably reject this command, which will make the client believe that the synchronization sequence has failed.
ナイーブ切断されたクライアントサーバーステップ1で、サーバから返された値で生成された偽のクライアント<old_uid>を交換することなく、ステップ3でコマンドを送信することは、おそらく、クライアントが同期シーケンスを持っていることを信じさせるであろう、このコマンドを拒否します失敗しました。
2) Section 5.1 discusses common implementation errors related to error recovery during playback.
2）5.1節では、再生中に回復をエラーに関連する一般的な実装エラーについて説明します。
3) Don't assume that the disconnected client is the only client used by the user.
3）切断されたクライアントは、ユーザが使用する唯一のクライアントであることを前提としないでください。
Situation 2: Some clients may use the \Deleted flag as an indicator that the message should not appear in the user's view. Usage of the \Deleted flag for this purpose is not safe, as other clients (e.g., online clients) might EXPUNGE the mailbox at any time.
状況2：一部のクライアントは、メッセージがユーザーのビューに表示されてはならない指標として\ Deletedフラグを使用することができます。他のクライアント（例えば、オンラインのクライアントが）いつでもメールボックスをEXPUNGE可能性があるとして、この目的のために、\ Deletedフラグの使用は、安全ではありません。
4) Beware of data dependencies between synchronization operations.
4）同期操作の間のデータの依存関係に注意してください。
It might be very tempting for a client writer to perform some optimizations on the playback log. Such optimizations might include removing redundant operations (for example, see optimization 2 in Section 5.3), or their reordering.
クライアントライターが再生ログにいくつかの最適化を実行することは非常に魅力的であるかもしれません。そのような最適化は、冗長な操作（例えば、セクション5.3で最適化2を参照）、またはそれらの並べ替えを除去することを含むかもしれません。
It is not always safe to reorder or remove redundant operations during synchronization because some operations may have dependencies (as Situation 3 demonstrates). So, if in doubt, don't do this.
一部の操作は、依存関係を持っているかもしれないので（状況3が示すように）同期中に冗長なオペレーションの順序を変更または削除することは必ずしも安全ではありません。疑問があれば、これをしません。
Situation 3: The user copies a message out of a mailbox and then deletes the mailbox.
状況3：ユーザのメールボックスのうちコピーメッセージと、メールボックスを削除します。
C: A001 SELECT Old-Mail S: ... C: A002 UID COPY 111 ToDo S: A002 OK [COPYUID 1022843345 111 94] Copy completed ... C: A015 CLOSE S: A015 OK Completed C: A016 DELETE Old-Mail S: A016 OK Mailbox deletion completed successfully
C：A001 SELECT旧メールS：... C：A002 UID COPY 111のToDo S：A015 CLOSE S：A015 OK完了C：A002 OK [COPYUID 1022843345 111 94]は完成... CをコピーA016は、古いメールを削除S：A016 OKメールボックスの削除が正常に完了します
If the client performs DELETE (tag A016) first and COPY (tag A002) second, then the COPY fails. Also, the message that the user so carefully copied into another mailbox has been lost.
クライアントが第二（タグA016）第COPY（タグA002）を削除実行する場合、そのコピーは失敗します。また、ユーザーは慎重に別のメールボックスにコピーされたメッセージが失われました。
Error recovery during synchronization is one of the trickiest parts to get right. Below, we will discuss certain error conditions and suggest possible choices for handling them.
同期中のエラーリカバリが権利を取得するトリッキーな部分の1つです。以下では、特定のエラー状態を議論し、それらを処理するための可能な選択肢を提案します。
1) Lost connection to the server.
1）サーバーへの接続が失われました。
The client MUST remember the current position in the playback (replay) log and replay it starting from the interrupted operation (the last command issued by the client, but not acknowledged by the server) the next time it successfully connects to the same server. If the connection was lost while executing a non-idempotent IMAP command (see the definition in Section 1), then when the client is reconnected, it MUST make sure that the interrupted command was indeed not executed. If it wasn't executed, the client must restart playback from the interrupted command, otherwise from the following command.
クライアントは、それが成功し、同じサーバーに接続し、次の時間を記録し、（最後のコマンドがクライアントによって発行されたが、サーバーによって認識されない）、中断操作から始めて、それを再生する再生（リプレイ）の現在の位置を覚えておく必要があります。 （第1節で定義を参照）非冪等のIMAPコマンドの実行中に接続が失われた場合、クライアントが再接続されると、その後、それが中断されたコマンドが実際に実行されなかったことを確認する必要があります。それが実行されなかった場合、クライアントは、そうでない場合は、次のコマンドから、中断されたコマンドからの再生を再起動する必要があります。
Upon reconnect, care must be taken in order to properly reapply logical operations that are represented by multiple IMAP commands, e.g., UID EXPUNGE emulation when UID EXPUNGE is not supported by the server (see Section 4.2.4).
UID EXPUNGEがサーバによってサポートされていない場合に再接続すると、ケア（セクション4.2.4参照）、例えば、適切に複数のIMAPコマンドによって表される論理演算を再適用するために、UIDのEXPUNGEエミュレーションを払わなければなりません。
Once the client detects that the connection to the server was lost, it MUST stop replaying its log. There are existing disconnected clients that, to the great annoyance of users, pop up an error dialog for each and every playback operation that fails.
クライアントがサーバーへの接続が失われたことを検出したら、それはそのログを再生するのを止めなければなりません。 、ユーザーの偉大な迷惑に、それぞれ失敗したすべての再生操作用のエラーダイアログをポップアップし、既存の切断クライアントがあります。
2) Copying/appending messages to a mailbox that doesn't exist. (The server advertises this condition by sending the TRYCREATE response code in the tagged NO response to the APPEND or COPY command.)
2）コピー/存在しないメールボックスにメッセージを追加します。 （サーバは、APPENDまたはCOPYコマンドにタグ付けされたNO応答TRYCREATE応答コードを送信することによって、この状態を通知します。）
The user should be advised about the situation and be given one of the following choices:
ユーザーは、状況について助言しなければならないと次の選択肢の1を与えられます。
a) Try to recreate a mailbox. b) Copy/upload messages to another mailbox. c) Skip copy/upload. d) Abort replay.
a）のメールボックスを再作成してください。 b）のコピー/別のメールボックスにメッセージをアップロードします。 C）コピー/アップロードをスキップします。 d）の再生を中止します。
3) Copying messages from a mailbox that doesn't exist, or renaming or getting/changing ACLs [ACL] on a mailbox that doesn't exist:
存在しないメールボックスの3）が存在しないメールボックスからメッセージをコピー、または名前変更または取得/変更するACLの[ACL]：
a) Skip operation. b) Abort replay.
a）の操作をスキップします。 b）の再生を中止します。
4) Deleting mailboxes or deleting/expunging messages that no longer exist.
4）メールボックスを削除するか、もはや存在しないメッセージを抹消/削除。
This is actually is not an error and should be ignored by the client.
これは実際にはエラーではなく、クライアントによって無視されるべきです。
5) Performing operations on messages that no longer exist.
5）もはや存在しないメッセージに対して操作を実行します。
a) Skip operation. b) Abort replay.
a）の操作をスキップします。 b）の再生を中止します。
In the case of changing flags on an expunged message, the client should silently ignore the error.
消去されたメッセージにフラグを変更する場合には、クライアントは黙って、エラーを無視すべきです。
Note 1: Several synchronization operations map to multiple IMAP commands (for example, "move" described in 4.2.2). The client must guarantee atomicity of each such multistep operation. For example, when performing a "move" between two mailboxes on the same server, if the server is unable to copy messages, the client MUST NOT attempt to set the \Deleted flag on the messages being copied, let alone expunge them. However, the client MAY consider that move operation to have succeeded even if the server was unable to set the \Deleted flag on copied messages.
注1：いくつかの同期操作は、複数のIMAPコマンドにマッピングする（例えば、4.2.2で説明した「移動」）。クライアントは、それぞれのそのような多段階の操作のアトミック性を保証しなければなりません。同じサーバ上の2つのメールボックスの間で「移動」を実行するときに、サーバーがメッセージをコピーすることができない場合、例えば、クライアントは、コピーされたメッセージに、\ Deletedフラグを設定し、ましてやそれらを抹消することを試みてはいけません。ただし、クライアントは、その移動操作は、サーバーがコピーされたメッセージに、\ Deletedフラグを設定することができませんでした場合でも、成功したと考えることができます。
Note 2: Many synchronization operations have data dependencies. A failed operation must cause all dependent operations to fail as well. The client should check this and MUST NOT try to perform all dependent operations blindly (unless the user corrected the original problem). For example, a message may be scheduled to be appended to a mailbox on the server and later on the appended message may be copied to another mailbox. If the APPEND operation fails, the client must not attempt to COPY the failed message later on. (See also Section 5, Situation 3).
注2：多くの同期操作は、データの依存関係を持っています。失敗した操作は、すべての依存の操作が同様に失敗する可能性がなければなりません。クライアントはこれを確認する必要がありますし、（ユーザーが元の問題を修正しない限り）盲目的に依存するすべての操作を実行しようとしてはなりません。例えば、メッセージは、サーバ上のメールボックスに追加されるようにスケジュールされてもよいし、後で添付メッセージ上の別のメールボックスにコピーされてもよいです。 APPEND操作が失敗した場合、クライアントは、後に失敗したメッセージをコピーしようとしない必要があります。 （また、第5節、状況3を参照してください）。
Below, some quality of implementation issues are listed for disconnected clients. They will help to write a disconnected client that works correctly, performs synchronization as quickly as possible (and thus can make the user happier as well as save her some money), and minimizes the server load:
以下は、実装上の問題のいくつかの品質が切断クライアントのために記載されています。彼らは、正常に動作する切断されたクライアントを書くために役立つ可能な限り迅速に同期を実行（したがって、ユーザは幸せだけでなく、彼女のいくつかのお金を節約することができます）、およびサーバーの負荷を最小限に抑えます。
1) Don't lose information.
1）情報を失うことはありません。
No matter how smart your client is in other areas, if it loses information, users will get very upset.
どんなにスマートどのようにあなたのクライアントは、情報が失われた場合、ユーザーは非常に怒るだろう、他の地域ではありません。
2) Don't do work unless explicitly asked. Be flexible. Ask all questions BEFORE starting synchronization, if possible.
明示的に求められない限り、2）仕事をしないでください。柔軟です。可能な場合は、同期を開始する前に、すべての質問をします。
3) Minimize traffic.
3）トラフィックを最小限に抑えます。
The client MUST NOT issue a command if the client already received the required information from the server.
クライアントがすでにサーバーから必要な情報を受け取った場合、クライアントは、コマンドを発行してはいけません。
The client MUST make use of UIDPLUS extension if it is supported by the server.
それはサーバによってサポートされている場合、クライアントはUIDPLUS拡張子を使用する必要があります。
See also optimization 1 in Section 5.3.
5.3節でも最適化1を参照してください。
4) Minimize the number of round-trips.
4）ラウンドトリップの数を最小限に抑えます。
Round-trips kill performance, especially on links with high latency. Sections 4.2.2.5 and 5.2 give some advice on how to minimize the number of round-trips.
ラウンドトリップは、特に高遅延とのリンクの上に、パフォーマンスを殺します。セクション4.2.2.5および5.2は、ラウンドトリップの数を最小限にする方法についていくつかのアドバイスを与えます。
See also optimization 1 in Section 5.3.
5.3節でも最適化1を参照してください。
Some useful optimizations are described in this section. A disconnected client that supports the recommendations listed below will give the user a more pleasant experience.
いくつかの有用な最適化は、このセクションで説明されています。以下に示す勧告をサポートして切断されたクライアントは、ユーザーに、より快適な経験を提供します。
1) The initial OK or PREAUTH responses may contain the CAPABILITY response code as described in Section 7.1 of [IMAP4]. This response code gives the same information as returned by the CAPABILITY command*. A disconnected client that pays attention to this response code can avoid sending CAPABILITY command and will save a round-trip.
[IMAP4]のセクション7.1に記載したように1）初期OK又はPREAUTH応答はCAPABILITY応答コードを含んでいてもよいです。この応答コードは* CAPABILITYコマンドによって返されるのと同じ情報を提供します。このレスポンスコードに注意を払って切断されたクライアントはCAPABILITYコマンドを送るのを避けることができ、ラウンドトリップを保存します。
* Note: Some servers report in the CAPABILITY response code extensions that are only relevant in unauthenticated state or in all states. Such servers usually send another CAPABILITY response code upon successful authentication using LOGIN or AUTHENTICATE command (that negotiates no security layer; see Section 6.2.2 of [IMAP4]). The CAPABILITY response code sent upon successful LOGIN/AUTHENTICATE might be different from the CAPABILITY response code in the initial OK response, as extensions only relevant for unauthenticated state will not be advertised, and some additional extensions available only in authenticated and/or selected state will be.
*注：一部のサーバが認証されていない状態またはすべての状態にのみ関連する能力応答コード拡張で報告しています。このようなサーバは通常、LOGINを使用して認証が成功すると、別の能力応答コードを送信したり、コマンドを認証（つまり、何のセキュリティ層を交渉していない。[IMAP4]のセクション6.2.2を参照してください）。ログインに成功すると送信された能力応答コード/認証されていない状態にのみ関連の拡張機能がアドバタイズされませんとして認証は、初期OK応答で能力応答コードと異なる場合があります、とのみ認証さおよび/または選択された状態でいくつかの追加の拡張機能が利用できますこと。
Example 9:
例9：
S: * OK [CAPABILITY IMAP4REV1 LOGIN-REFERRALS STARTTLS AUTH=DIGEST-MD5 AUTH=SRP] imap.example.com ready C: 2 authenticate DIGEST-MD5 S: 2 OK [CAPABILITY IMAP4REV1 IDLE NAMESPACE MAILBOX-REFERRALS SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND] User authenticated (no layer)
S：* OK [CAPABILITYののIMAP4rev1 LOGIN-REFERRALS STARTTLS AUTH = DIGEST-MD5 AUTH = SRP] imap.example.com準備C：2認証DIGEST-MD5 S：2 OK [CAPABILITYのIMAP4rev1のアイドルNAMESPACEのMAILBOX-REFERRALS SCAN SORTのTHREAD = REFERENCES THREAD = ORDEREDSUBJECT MULTIAPPEND]ユーザ認証（NO層）
2) An advanced disconnected client may choose to optimize its replay log. For example, there might be some operations that are redundant (the list is not complete):
2）先進的な切断されたクライアントは、その再生ログを最適化することもできます。例えば、（リストは完全ではありません）冗長でいくつかの操作があるかもしれません。
a) an EXPUNGE followed by another EXPUNGE or CLOSE;
b) changing flags (other than the \Deleted flag) on a message that
gets immediately expunged;
c) opening and closing the same mailbox.
When optimizing, be careful about data dependencies between commands. For example, if the client is wishing to optimize (see case b, above)
最適化する場合、コマンド間のデータの依存関係に注意してください。例えば、クライアントが最適化するように希望された場合（上記、ケースBを参照）
tag1 UID STORE <uid1> +FLAGS (\Deleted) ... tag2 UID STORE <uid1> +FLAGS (\Flagged) ... tag3 UID COPY <uid1> "Backup" ... tag4 UID EXPUNGE <uid1>
TAG1のUIDストア<UID1> + FLAGS（\削除済み）... TAG2のUIDストア<UID1> + FLAGS（\フラグ付き）... TAG3 UID COPY <UID1> "バックアップ" ... TAG4 UID EXPUNGE <UID1>
it can't remove the second UID STORE command because the message is being copied before it gets expunged.
それが消去される前に、メッセージがコピーされるので、それは、第二のUID STOREコマンドを削除することはできません。
In general, it might be a good idea to keep mailboxes open during synchronization (see case c above), if possible. This can be more easily achieved in conjunction with optimization 3 described below.
一般的には、可能ならば、（上記Cの場合を参照）同期中に開いているメールボックスを維持するためには良い考えかもしれません。これは、より簡単に以下の最適化3と併せて実現することができます。
3) Perform some synchronization steps in parallel, if possible.
可能であれば3）、並行していくつかの同期手順を実行します。
Several synchronization steps don't depend on each other and thus can be performed in parallel. Because the server machine is usually more powerful than the client machine and can perform some operations in parallel, this may speed up the total time of synchronization.
いくつかの同期手順は互いに依存せず、従って並列に実行することができます。サーバマシンがクライアントマシンよりも通常より強力であると並行して、いくつかの操作を行うことができますので、これは同期の総時間をスピードアップすることがあります。
In order to achieve such parallelization, the client will have to open more than one connection to the same server. Client writers should not forget about non-trivial cost associated with establishing a TCP connection and performing an authentication. The disconnected client MUST NOT use one connection per mailbox. In most cases, it is sufficient to have two connections. The disconnected client SHOULD avoid selecting the same mailbox in more than one connection; see Section 3.1.1 of [RFC2683] for more details.
そのような並列化を達成するために、クライアントが同じサーバーに複数の接続を開く必要があります。クライアントの作家はTCP接続を確立し、認証の実行に関連する非自明なコストを忘れてはなりません。切断されたクライアントは、メールボックスごとに1つの接続を使用してはなりません。ほとんどの場合、2つの接続を持つのに十分です。切断されたクライアントは、複数の接続で同じメールボックスを選択することは避けてください。詳細については、[RFC2683]のセクション3.1.1を参照してください。
Any mailbox synchronization MUST start with checking the UIDVALIDITY as described in Section 4.1 of this document. The client MAY use STATUS command to check UID Validity of a non-selected mailbox. This is preferable to opening many connections to the same server to perform synchronization of multiple mailboxes simultaneously. As described in Section 5.3.10 of [IMAP4], this SHOULD NOT be used on the selected mailbox.
任意のメールボックスの同期は、このドキュメントのセクション4.1で説明したようにUIDVALIDITYをチェックして起動する必要があります。クライアントは、非選択されたメールボックスのUIDの妥当性を確認するためにSTATUSコマンドを使用するかもしれません。これは、同時に複数のメールボックスの同期を実行する同じサーバーに多くの接続を開放することが好ましいです。 [IMAP4]のセクション5.3.10に記載されているように、これは選択されたメールボックスで使用されるべきではありません。
The following extensions can save traffic and/or the number of round-trips:
次の拡張子は、トラフィックおよび/またはラウンドトリップの数を節約することができます。
1) The use of [UIDPLUS] is discussed in Sections 4.1, 4.2.1, 4.2.2.1 and 4.2.4.
1）[UIDPLUS]の使用はセクション4.1、4.2.1、4.2.2.1および4.2.4に記載されています。
2) The use of the MULTIAPPEND and LITERAL+ extensions for uploading messages is discussed in Section 4.2.2.5.
2）メッセージをアップロードするためMULTIAPPENDリテラル+拡張の使用はセクション4.2.2.5で論じられています。
3) Use the CONDSTORE extension (see Section 6.1) for quick flag resynchronization.
3）迅速なフラグの再同期化のために（セクション6.1を参照）CONDSTORE拡張子を使用してください。
An advanced disconnected mail client should use the [CONDSTORE] extension when it is supported by the server. The client must cache the value from HIGHESTMODSEQ OK response code received on mailbox opening and update it whenever the server sends MODSEQ FETCH data items.
それはサーバによってサポートされている場合、高度な切断メールクライアントが[CONDSTORE]拡張を使用する必要があります。クライアントは、メールボックスの開口部で受信したHIGHESTMODSEQ OKレスポンスコードから値をキャッシュし、サーバがMODSEQは、データ項目をFETCH送信したときに、それを更新する必要があります。
If the client receives NOMODSEQ OK untagged response instead of HIGHESTMODSEQ, it MUST remove the last known HIGHESTMODSEQ value from its cache and follow the more general instructions in Section 3.
クライアントではなくHIGHESTMODSEQのNOMODSEQ OKタグなし応答を受信した場合、それはそのキャッシュから最後の既知のHIGHESTMODSEQ値を削除し、第3節では、より一般的な手順に従わなければなりません。
When the client opens the mailbox for synchronization, it first compares UIDVALIDITY as described in step d-1 in Section 3. If the cached UIDVALIDITY value matches the one returned by the server, the client MUST compare the cached value of HIGHESTMODSEQ with the one returned by the server. If the cached HIGHESTMODSEQ value also matches the one returned by the server, then the client MUST NOT fetch flags for cached messages, as they hasn't changed. If the value on the server is higher than the cached one, the client MAY use "SEARCH MODSEQ <cached-value>" to find all messages with flags changed since the last time the client was online and had the mailbox opened. Alternatively, the client MAY use "FETCH 1:* (FLAGS) (CHANGEDSINCE <cached-value>)". The latter operation combines searching for changed messages and fetching new information.
クライアントが同期のためのメールボックスを開くと第3節では、工程d-1で説明したように、キャッシュされたUIDVALIDITY値がサーバから返されたものと一致した場合、それは最初のUIDVALIDITYとを比較し、クライアントが返されたものとHIGHESTMODSEQのキャッシュされた値を比較しなければなりませんサーバーによって。キャッシュされたHIGHESTMODSEQ値は、サーバから返されたものと一致した場合、彼らは変更されていないとして、クライアントは、キャッシュされたメッセージのフラグを取得してはなりません。サーバー上の値がキャッシュされたものよりも高い場合、クライアントが使用するかもしれ「MODSEQを検索<キャッシュされた値は、>」クライアントがオンラインだったとメールボックスが開かれていた最後の時間以降に変更フラグを持つすべてのメッセージを検索します。また、クライアントは、 "：*（FLAGS）（CHANGEDSINCE <キャッシュされた値>）1をFETCH" を使用してもよい（MAY）。後者の動作は、変更メッセージを検索し、新しい情報をフェッチ組み合わせ。
In all cases, the client still needs to fetch information about new messages (if requested by the user) as well as discover which messages have been expunged.
すべての場合において、クライアントはまだ（ユーザーによって要求された場合）は、新しいメッセージに関する情報を取得するだけでなく、抹消されたメッセージを発見する必要があります。
Step d ("Server-to-client synchronization") in Section 4 in the presence of the CONDSTORE extension is amended as follows:
次のようにCONDSTORE拡張の存在下での第4のステップD（「サーバーからクライアントへの同期」）が改正されています。
d) "Server-to-client synchronization" - For each mailbox that requires synchronization, do the following:
D）「サーバーからクライアントへの同期」 - 同期を必要とする各メールボックスの場合は、次の手順を実行します。
1a) Check the mailbox UIDVALIDITY (see section 4.1 for more details) with SELECT/EXAMINE/STATUS.
図1a）SELECT / EXAMINE / STATUSで（詳細はセクション4.1を参照）、メールボックスのUIDVALIDITYを確認してください。
If the UIDVALIDITY value returned by the server differs, the
client MUST
* empty the local cache of that mailbox;
* "forget" the cached HIGHESTMODSEQ value for the mailbox;
* remove any pending "actions" that refer to UIDs in that
mailbox (note that this doesn't affect actions performed on
client-generated fake UIDs; see Section 5); and
* skip steps 1b and 2-II;
1b) Check the mailbox HIGHESTMODSEQ. If the cached value is the same as the one returned by the server, skip fetching message flags on step 2-II, i.e., the client only has to find out which messages got expunged.
図1b）、メールボックスHIGHESTMODSEQを確認してください。キャッシュされた値がサーバから返されたものと同じである場合は、ステップ2-IIにフェッチメッセージフラグをスキップし、すなわち、クライアントは、メッセージだけが消去されてしまって見つける必要があります。
2) Fetch the current "descriptors".
2）現在の「記述子」を取得します。
I) Discover new messages.
私は）新しいメッセージを発見してください。
II) Discover changes to old messages and flags for new messages using "FETCH 1:* (FLAGS) (CHANGEDSINCE <cached-value>)" or "SEARCH MODSEQ <cached-value>".
または "MODSEQ <キャッシュされた値>を検索"：II） "（FLAGS）（CHANGEDSINCE <キャッシュされた値>）* 1をFETCH" を使用して新しいメッセージの古いメッセージとフラグへの変更を検出します。
Discover expunged messages; for example, using
"UID SEARCH 1:<lastseenuid>". (All messages not returned
in this command are expunged.)
3) Fetch the bodies of any "interesting" messages that the client doesn't already have.
3）クライアントがすでに持っていない任意の「おもしろい」メッセージの本文を取得します。
Example 10:
例10：
The UIDVALIDITY value is the same, but the HIGHESTMODSEQ value has changed on the server while the client was offline.
UIDVALIDITY値は同じですが、クライアントがオフラインであったHIGHESTMODSEQ値は、サーバー上で変更されました。
C: A142 SELECT INBOX S: * 172 EXISTS S: * 1 RECENT S: * OK [UNSEEN 12] Message 12 is first unseen S: * OK [UIDVALIDITY 3857529045] UIDs valid S: * OK [UIDNEXT 201] Predicted next UID S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited S: * OK [HIGHESTMODSEQ 20010715194045007] S: A142 OK [READ-WRITE] SELECT completed
C：A142 SELECT INBOX S * 172 SをEXISTS：* 1 RECENT S：* OK [UNSEEN 12]メッセージ12最初の目に見えないSである：* OK [UIDVALIDITY 3857529045]のUID有効S：* OK [UIDNEXT 201]次のUID S予測：* FLAGS（\回答\フラグ付き\削除された\見\案）S：* OKリミテッドS [PERMANENTFLAGS（\削除された\ * \見られる）]：* OK [HIGHESTMODSEQ 20010715194045007] S：A142 OK [READ-WRITE]が完了SELECT
After that, either:
その後、次のいずれか
C: A143 UID FETCH 1:* (FLAGS) (CHANGEDSINCE 20010715194032001) S: * 2 FETCH (UID 6 MODSEQ (20010715205008000) FLAGS (\Deleted)) S: * 5 FETCH (UID 9 MODSEQ (20010715195517000) FLAGS ($NoJunk $AutoJunk $MDNSent)) ... S: A143 OK FETCH completed
C：A143のUID FETCH 1：*（FLAGS）（CHANGEDSINCE 20010715194032001）S *（UID 6 MODSEQ（20010715205008000）FLAGS（\削除））SをFETCH 2 *（UID 9 MODSEQ（20010715195517000）FLAGS（$をFETCH 5 NoJunk $ AutoJunk $ MDNSent））... S：A143 OK FETCH完成
or:
または：
C: A143 UID SEARCH MODSEQ 20010715194032001 UID 1:20 S: * SEARCH 6 9 11 12 18 19 20 23 (MODSEQ 20010917162500) S: A143 OK Search complete C: A144 UID SEARCH 1:20 S: * SEARCH 6 9 ... S: A144 OK FETCH completed
C：A143のUIDを検索MODSEQ 20010715194032001 UID 1：20 S：* SEARCH 6 9 11 12 18 19 20 23（MODSEQ 20010917162500）S：A143 OK検索完了C：A144のUID検索1：20 S：* SEARCH 6 9 ... S：A144 OK完成FETCH
It is believed that this document does not raise any new security concerns that are not already present in the base [IMAP4] protocol, and these issues are discussed in [IMAP4]. Additional security considerations may be found in different extensions mentioned in this document; in particular, in [UIDPLUS], [LITERAL+], [CONDSTORE], [MULTIAPPEND], and [UNSELECT].
この文書は、すでにベース[IMAP4]プロトコルには存在しない新たな安全保障上の懸念を提起しないと考えられている、これらの問題は、[IMAP4]で議論されています。追加のセキュリティ上の考慮事項は、この文書に記載されたさまざまな拡張で見つけることができます。特に、[UIDPLUS]において、[LITERAL +]、[CONDSTORE]、[MULTIAPPEND]、および[UNSELECT]。
Implementers are also reminded about the importance of thorough testing.
実装者はまた、徹底的なテストの重要性について通知されます。
[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月。
[UIDPLUS] Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS extension", RFC 4315, December 2005.
[UIDPLUS]クリスピン、M.、 "インターネットメッセージアクセスプロトコル（IMAP） - UIDPLUS延長"、RFC 4315、2005年12月。
[LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088, January 1997.
[LITERAL +]マイヤーズ、J.、 "IMAP4非同期リテラル"、RFC 2088、1997年1月。
[CONDSTORE] Melnikov, A. and S. Hole, "IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization", RFC 4551, June 2006.
[CONDSTORE]メルニコフ、A.とS.ホール、 "条件付きSTORE操作やクイックフラグの変更を再同期化のためのIMAP拡張"、RFC 4551、2006年6月。
[MULTIAPPEND] Crispin, M., "Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension", RFC 3502, March 2003.
[MULTIAPPEND]クリスピン、M.、 "インターネットメッセージアクセスプロトコル（IMAP） - MULTIAPPEND拡張"、RFC 3502、2003年3月。
[UNSELECT] Melnikov, A., "Internet Message Access Protocol (IMAP) UNSELECT command", RFC 3691, February 2004.
[UNSELECT]メルニコフ、A.、 "インターネットメッセージアクセスプロトコル（IMAP）UNSELECTコマンド"、RFC 3691、2004年2月。
[RFC2683] Leiba, B., "IMAP4 Implementation Recommendations", RFC 2683, September 1999.
[RFC2683] Leiba、B.、 "IMAP4の実装に関する推奨事項"、RFC 2683、1999年9月。
[ACL] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", RFC 4314, December 2005.
[ACL]メルニコフ、A.、 "IMAP4アクセス制御リスト（ACL）拡張"、RFC 4314、2005年12月。
[IMAP-MODEL] Crispin, M., "Distributed Electronic Mail Models in IMAP4", RFC 1733, December 1994.
[IMAP-MODEL]クリスピン、M.、 "IMAP4に分散電子メールモデル"、RFC 1733、1994年12月。
This document is based on version 01 of the text written by Rob Austein in November 1994.
この文書は、1994年11月ロブAusteinとによって書かれたテキストのバージョン01に基づいています。
The editor appreciates comments posted by Mark Crispin to the IMAP mailing list and the comments/corrections/ideas received from Grant Baillie, Cyrus Daboo, John G. Myers, Chris Newman, and Timo Sirainen.
エディタは、IMAPメーリングリストにマーク・クリスピンによって投稿されたコメントやグラントベイリー、サイラスDaboo、ジョン・G.マイヤーズ、クリス・ニューマン、そしてティモ・シレーヌンから寄せられたコメント/修正/アイデアを高く評価しています。
The editor would also like to thank the developers of Netscape Messenger and Mozilla mail clients for providing examples of disconnected mail clients that served as a base for many recommendations in this document.
エディタはまた、この文書に記載されている多くの勧告のためのベースを務め切断メールクライアントの例を提供するためのNetscape MessengerおよびMozillaのメールクライアントの開発者に感謝したいと思います。
Editor's Address
編集者の住所
Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX United Kingdom
アレクセイ・メルニコフISODE限定5キャッスルビジネス村の36の駅道ハンプトン、ミドルTW12 2BXイギリス
Phone: +44 77 53759732 EMail: alexey.melnikov@isode.com
電話：+44 77 53759732 Eメール：alexey.melnikov@isode.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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 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が表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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 provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。