RFC4549 日本語訳
4549 Synchronization Operations for Disconnected IMAP4 Clients. A.Melnikov, Ed.. June 2006. (Format: TXT=75417 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Melnikov, Ed. Request for Comments: 4549 Isode Ltd. Category: Informational June 2006
ワーキンググループのA.メリニコフ、エドをネットワークでつないでください。コメントのために以下を要求してください。 4549年のIsode株式会社カテゴリ: 情報の2006年6月
Synchronization Operations for Disconnected IMAP4 Clients
外されたIMAP4クライアントのための同期操作
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).
Copyright(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拡張子を記載します。
Melnikov Informational [Page 1] RFC 4549 Synch Ops for Disconnected IMAP4 Clients June 2006
外されたIMAP4クライアント2006年6月のためのメリニコフ情報[1ページ]のRFC4549同時性オプアート
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
1. 序論…3 1.1. このドキュメントで中古のコンベンション…3 2. プリンシプルズを設計してください…3 3. 同期の全体像…4 4. メールボックス同期ステップと戦略…7 4.1. UIDの正当性をチェックします…7 4.2. 地方で連動するのはサーバを交換します…8 4.2.1. メールボックスへのアップロードメッセージ…8 4.2.2. 「移動」と「コピー」操作を最適化します…9 4.2.3. 地方であることで再演して、変化に旗を揚げさせてください…14 4.2.4. メールボックス圧縮(梢消する)要求を処理します。15 4.2.5. メールボックスを閉じます…17 4.3. 単一のメールボックスの「正常な」同期の詳細…18 4.3.1. 新しいメッセージと古いメッセージへの変化を発見します…18 4.3.2. 「おもしろい」メッセージを検索します。 ..............20 4.3.3. 「おもしろい」メッセージでキャッシュに居住します。 ......21 4.3.4. ユーザによって開始された同期…22 4.4. 特別なケース: 記述子だけ同期…22 4.5. 特別なケース: 速さ、新しく唯一の同期…23 4.6. 特別なケース: 盲目のフェッチ…23 5. 実現問題…24 5.1. 再生の間のエラー回復…26 5.2. 導入問題の品質…28 5.3. 最適化…28 6. その5月のIMAP拡張子は助けます…30 6.1. CONDSTORE拡張子…30 7. セキュリティ問題…33 8. 参照…33 8.1. 標準の参照…33 8.2. 有益な参照…34 9. 承認…34
Melnikov Informational [Page 2] RFC 4549 Synch Ops for Disconnected IMAP4 Clients June 2006
外されたIMAP4クライアント2006年6月のためのメリニコフ情報[2ページ]のRFC4549同時性オプアート
1. Introduction
1. 序論
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].
また、このドキュメントの読者がRFC2683[RFC2683]を読むように強くアドバイスされます。
* Note that the functionality provided by the base IMAP protocol
[IMAP4] is sufficient to perform basic synchronization.
* ベースIMAPプロトコル[IMAP4]によって提供された機能性が基本的な同期を実行するために十分であることに注意してください。
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[キーワード]で説明されるように本書では解釈されることであるべきですか?
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コマンドベキ等元を呼びましょう。
2. Design Principles
2. 設計原理
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クライアントと共にそうするように。 この規則への1つの例外は外されたクライアントのキャッシュ(オフラインと予定されているメッセージアップロードの間、州は旗の変化を含める)の状態の情報が外されたクライアントの上に残っているということです: すなわち、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
外されたクライアントはIMAP4サーバへの「電話」の推論することなら何でものために時間の長さを最小にしたがっているクライアントです。しかし、私たちは、ことによると非常に低い帯域幅でクライアントが電話での接続を使用しているのでしばしば、これがそうになると思います。
Melnikov Informational [Page 3] RFC 4549 Synch Ops for Disconnected IMAP4 Clients June 2006
外されたIMAP4クライアント2006年6月のためのメリニコフ情報[3ページ]のRFC4549同時性オプアート
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".
時々、まさしく人間が私たちのコントロールを超えて飛行機、またはある他の出来事を捕らえるとは急いでいるということであるかもしれません。 理由が何であっても、私たちは、ネットワーク接続(普通の意味(偽りの交通を発生させない)と私たちが、クライアント、そして/または、サーバが厳密に地方の計算か入出力を実行している間、接続にぽかんとしていさせないのを好むだろうという意味における両方)の効率的な使用をしなければならないと思います。 別のもの、恐らく、これを述べるより簡単な方法は私たちが、ネットワーク接続が「高価である」と思うということです。
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つの原則が人間が同期プログラムである種の指導に基づいた決定を提供しなければならないという結論につながります、ユーザーインタフェースかある種の構成ファイルを通した適切なオプションを選択することによって。 ほぼ確実に、それは入出力のために同期の過程の中央の人間と共に止まるべきではありません。 人間には、同期プログラム、異なった事情のためのいくつかの異なった構成がほぼ確実にあるでしょう。
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.
外されたクライアントにはそれが外されていた間、どんな変化がメールボックスの心に浮かんでいたかもしれないかを知る方法が全くないので、メッセージ番号は外されたクライアントの役に立ちません。 すべての外されたクライアント操作がUIDsを使用することで実行されるべきです、クライアントがそれとサーバが同期の過程の間ほぼ同じくらいのメッセージについて話しているのを確信するように。
3. Overall Picture of Synchronization
3. 同期の全体像
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.
同期のための基本戦略は以下に概説されています。 本当の戦略を1つのアプリケーションから別のものに異なるか、または同期モードに依存するかもしれないことに注意してください。
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同期の一部ではありませんが、それは完全性のためにここに言及されます。)
Melnikov Informational [Page 4] RFC 4549 Synch Ops for Disconnected IMAP4 Clients June 2006
外されたIMAP4クライアント2006年6月のためのメリニコフ情報[4ページ]のRFC4549同時性オプアート
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) 動作が、新しいメールボックス(メッセージを作動させるどんな操作)を開けて、メールボックスを開けるように含意するなら。 UIDVALIDITY応答コードで返されたUID正当性価値(その他の詳細に関してセクション4.1を見る)をチェックしてください。 サーバによって返されたUIDVALIDITY値が異なるなら、クライアントは、ローカルなキャッシュからメールボックスを取り出して、そのメールボックスの中にUIDsを示すどんな未定の「動作」も移さなければなりません(彼らが失敗されていると考えてください)。 これがクライアントが発生しているにせのUIDsに実行された動作に影響しないことに注意してください(セクション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)を必ず削除してください(また、.12セクション3.4[RFC2683]を見てください)ことです。
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) メールボックスUIDVALIDITY(その他の詳細に関してセクション4.1を見る)についてSELECT/EXAMINE/STATUSに問い合わせてください。
If UIDVALIDITY value returned by the server differs, the client
MUST
サーバによって返されたUIDVALIDITY値が異なるなら、クライアントは異ならなければなりません。
* 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.
* ローカルなキャッシュからそのメールボックスを取り出してください。 * そのメールボックスの中にUIDsを示すあらゆる未定の「動作」を取り除いてください、そして、彼らが失敗されていると考えてください。 *そして、2IIである状態でステップをサボってください。
2) Fetch the current "descriptors";
2) 現在の「記述子」をとって来てください。
I) Discover new messages.
I) 新しいメッセージを発見してください。
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) さらなる操作に必要でないすべての開いているメールボックスを閉じるか(オンラインのままであるなら)、またはすべてのオープンな接続を外してください(オフラインで行くなら)。
Melnikov Informational [Page 5] RFC 4549 Synch Ops for Disconnected IMAP4 Clients June 2006
外されたIMAP4クライアント2006年6月のためのメリニコフ情報[5ページ]のRFC4549同時性オプアート
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.
私たちは1セットの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) 平行でステップaと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コマンドで返されたメールボックスであるかもしれません(.9セクション6.3[IMAP4]を見てください)。 クライアントがおもしろいと考えるメールボックスのデフォルトセットに特別なメールボックス「受信トレイ」があるべきです。 しかしながら、戦略をフィルターにかける何らかのメールに、特定のセッションかクライアントのために受信トレイを無視する能力を提供するのは貴重であるかもしれません。
Melnikov Informational [Page 6] RFC 4549 Synch Ops for Disconnected IMAP4 Clients June 2006
外されたIMAP4クライアント2006年6月のためのメリニコフ情報[6ページ]のRFC4549同時性オプアート
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) d2IIは踏みます、とまた、クライアントはクライアントがローカルなキャッシュで既にメッセージの旗に持っている変化の周りと、そして、ローカルなキャッシュにおけるもうサーバ(すなわち、梢消されたメッセージ)に存在しないメッセージの周りに関してわかります。
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.
この議論の残りは単一のメールボックスのために主として同期問題に焦点を合わせるでしょう。
4. Mailbox Synchronization Steps and Strategies
4. メールボックス同期ステップと戦略
4.1. Checking UID Validity
4.1. UIDの正当性をチェックします。
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正当性価値は、セッションの間でUIDsがいつセッションの間で固執しないかを変えます。
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正当性値が異なるなら、クライアントのキャッシュにおけるUIDsはもう有効ではありません。 クライアントは、次に、ローカルなキャッシュからそのメールボックスを取り出して、そのメールボックスの中にUIDsを示すどんな未定の「動作」も移さなければなりません。 また、クライアントは人間に警報を出すかもしれません。 クライアントはメールボックスのための少しの予定されているアップロード(すなわち、APPENDs)も中止してはいけません。
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とAPPENDUID応答コードが[UIDPLUS]拡大で定義した、(参照、4.2、.2、)、また、UIDVALIDITY STATUS応答データの品目はある他のメールボックスのためのUIDVALIDITY値を含んでいます。 クライアントSHOULDは前のパラグラフで説明されるように振る舞います(それはもう片方のメールボックスのキャッシュに影響するべきです)、どのようにUIDVALIDITY値を得たとしても。
Melnikov Informational [Page 7] RFC 4549 Synch Ops for Disconnected IMAP4 Clients June 2006
外されたIMAP4クライアント2006年6月のためのメリニコフ情報[7ページ]のRFC4549同時性オプアート
4.2. Synchronizing Local Changes with the Server
4.2. サーバに地域変化を連動させます。
4.2.1. Uploading Messages to the Mailbox
4.2.1. メールボックスへのアップロードメッセージ
Two of the most common examples of operations resulting in message uploads are:
メッセージアップロードをもたらす操作の2つの最も一般的な例は以下の通りです。
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も持っていません、すべてのUIDsがサーバによって割り当てられるとき。事実上、APPENDコマンドはローカルなキャッシュに後日のために格納できるアップロードされたメッセージにUIDを関連づけるでしょう。 しかしながら、[IMAP4]は、ただAPPENDコマンドを実行することによってメッセージUIDを発見するために簡単なメカニズムについて説明しません。 UIDを発見するために、クライアントは以下の1つができます:
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をとって来るようにしてください。 これをするための1つの戦略が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は草稿(\目にふれている$MDNSent)310Sを追加します: +は文字通りのデータのためにCを準備します: 日付: 月曜日、1994年2月7日21:52:25 -0800(太平洋標準時の)のC: From: フレッド Foobar <foobar@blt.example.COM 、gt;、C: Subject: 午後のミーティングC: To: mooch@owatagu.siam.edu C: メッセージイド: <B27397-0100000@blt.example.COM>C: MIMEバージョン: 1.0C: コンテントタイプ: テキスト/平野。 CHARSETは米国のASCII Cと等しいです: C: こんにちは、ジョー、あなたは私たちが明日の3:30に会うことができると思いますか? C: S: 完成されて、A003OKは追加します。
Fortunately, there is a simpler way to discover the message UID in the presence of the [UIDPLUS] extension:
幸い、[UIDPLUS]拡大があるときメッセージUIDを発見するより簡単な方法があります:
Melnikov Informational [Page 8] RFC 4549 Synch Ops for Disconnected IMAP4 Clients June 2006
外されたIMAP4クライアント2006年6月のためのメリニコフ情報[8ページ]のRFC4549同時性オプアート
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は草稿(\目にふれている$MDNSent)310Sを追加します: +は文字通りのデータのためにCを準備します: 日付: 月曜日、1994年2月7日21:52:25 -0800(太平洋標準時の)のC: From: フレッド Foobar <foobar@blt.example.COM 、gt;、C: Subject: 午後のミーティングC: To: mooch@owatagu.siam.edu C: メッセージイド: <B27397-0100000@blt.example.COM>C: MIMEバージョン: 1.0C: コンテントタイプ: テキスト/平野。 CHARSETは米国のASCII Cと等しいです: C: こんにちは、ジョー、あなたは私たちが明日の3:30に会うことができると思いますか? C: S: 完成したA003 OK[APPENDUID1022843275 77712]APPEND
The UID of the appended message is the second parameter of APPENDUID response code.
追加されたメッセージのUIDはAPPENDUID応答コードの2番目のパラメタです。
4.2.2. Optimizing "move" and "copy" Operations
4.2.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と複数のメールボックスを支える他のメールボックスアクセス・プロトコルの実用的な経験は、1個のメールボックスから別のメールボックスまでメッセージを動かすのが、非常に一般的な操作であると示唆します。
4.2.2.1. Moving a Message between Two Mailboxes on the Same Server
4.2.2.1. 同じサーバでメッセージを2個のメールボックスの間に動かします。
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操作の組み合わせるのとストア+FLAGS(\Deleted)操作です。 これは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コピー567,414「おもしろいメッセージ」S: 完成したA001OK[COPYUID1022843275 414,567 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.
これは現在のメールボックスの中にUID414があるメッセージは首尾よくメールボックス「おもしろいメッセージ」にコピーして、UID5を与えて、UID567があるメッセージにUID6を与えたとクライアントに言います。
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,
サーバにおけるUIDPLUS拡大サポートがないとき、以下のトリックを使用できます。 Message-IDを含んでいることによって: ヘッダーと記述子の一部としてのINTERNALDATEデータ項目、クライアントはキャッシュには既にあるメッセージに対して「新しい」メッセージに関する記述子をチェックして、複本をとって来るのを避けることができます。 もちろん
Melnikov Informational [Page 9] RFC 4549 Synch Ops for Disconnected IMAP4 Clients June 2006
外されたIMAP4クライアント2006年6月のためのメリニコフ情報[9ページ]のRFC4549同時性オプアート
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.
盲目的にこのテクニックを使用するべきでなくて、ローカルなキャッシュでメッセージが既にあるかを確認するためにチェックする費用がただそれをとって来る費用を超えているのは、可能です。 MUAが「動き」コマンドを実行するなら、それで、知っているときこのテクニックを使用するaがコピーするか、または削除する特別条項はaの結果が「移動」であるというコマンドを配列します。
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.
また、このアルゴリズムが間違ったメッセージを見つけるのが、理論的に可能であるので(十分悪性のMessage-IDヘッダーを考えて)implementersがこの最適化を無効にする方法を提供するはずであることに注意してください、永久に、そして、メッセージごとのベースの上の両方。
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は<uids>(BODY.PEEK[] INTERNALDATE旗)をとって来ます… S: * 27FETCH、(UID123INTERNALDATE「2002年5月31日05:26:59 -0600」FLAGS(\Draft$MDNSent)BODY[]1036S: …S: メッセージイド: <20040903110856.22a127cd@chardonnay 、gt;、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コピー123「おもしろいメッセージ」S: 完成したC035OK
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: C036は「おもしろいメッセージ」を選択します… C: C037 UIDは2002年5月31日ヘッダー「メッセージイド」" 20040903110856.22a127cd@chardonnay "Sで探します: 12368秒間、探してください: 完成したC037 OK
Melnikov Informational [Page 10] RFC 4549 Synch Ops for Disconnected IMAP4 Clients June 2006
外されたIMAP4クライアント2006年6月のためのメリニコフ情報[10ページ]のRFC4549同時性オプアート
Note that if the server has returned multiple UIDs in the SEARCH response, the client MUST NOT use any of the returned UID.
サーバが検索応答で複数のUIDsを返したなら、クライアントが返されたUIDのどれかを使用してはいけないことに注意してください。
4.2.2.2. Moving a Message from a Remote Mailbox to a Local
4.2.2.2. リモートメールボックスからローカルまでメッセージを動かします。
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):
FETCH(それはFLAGSとINTERNALDATEを含んでいる)がUID STORE<uid>+FLAGS.SILENT(\Deleted)によって続かれている状態で、メッセージはリモートメールボックスからローカルまで動かされます:
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旗)S: * 27 FETCH(UID123INTERNALDATE「2002年5月31日05:26:59 -0600」FLAGS(\Seen$MDNSent)BODY[] S: …メッセージ本体S…:)S: A003 OK UID FETCHはCを完成しました: A004 UIDは<uid>+FLAGS.SILENT(削除された\)Sを格納します: 完成したA004 STORE
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.
クライアントのキャッシュにそれが既にあるなら同期の間にメッセージをとって来る理由が全くないことに注意してください。 また、クライアントSHOULDはローカルなキャッシュにおける納品日を保持します。
4.2.2.3. Moving a Message from a Local Mailbox to a Remote
4.2.2.3. 地方のメールボックスからaまでリモートなメッセージを動かします。
Moving a message from a local mailbox to a remote is done with APPEND:
地方のメールボックスからaまでリモートなメッセージは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は草稿(\目にふれている$MDNSent)「2002年5月31日05:26:59 -0600」310Sを追加します: +は文字通りのデータのためにCを準備します: 日付: 月曜日、1994年2月7日21:52:25 -0800(太平洋標準時の)のC: From: フレッド Foobar <foobar@blt.example.COM 、gt;、C: Subject: 午後のミーティングC: To: mooch@owatagu.siam.edu C: メッセージイド: <B27397-0100000@blt.example.COM>C: MIMEバージョン: 1.0C: コンテントタイプ: テキスト/平野。 CHARSETは米国のASCII Cと等しいです: C: こんにちは、ジョー、あなたは私たちが明日の3:30に会うことができると思いますか? C: S: 完成したA003 OK[APPENDUID1022843275 77712]
The client SHOULD specify the delivery date from the local cache in the APPEND.
クライアントSHOULDはAPPENDのローカルなキャッシュからの納品日を指定します。
If the [LITERAL+] extension is available, the client can save a round-trip*:
[LITERAL+]拡大が利用可能であるなら、クライアントは往復の*を救うことができます:
Melnikov Informational [Page 11] RFC 4549 Synch Ops for Disconnected IMAP4 Clients June 2006
外されたIMAP4クライアント2006年6月のためのメリニコフ情報[11ページ]のRFC4549同時性オプアート
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は草稿(\目にふれている$MDNSent)「2002年5月31日05:26:59 -0600」310+Cを追加します: 日付: 月曜日、1994年2月7日21:52:25 -0800(太平洋標準時の)のC: From: フレッド Foobar <foobar@blt.example.COM 、gt;、C: Subject: 午後のミーティングC: To: mooch@owatagu.siam.edu C: メッセージイド: <B27397-0100000@blt.example.COM>C: MIMEバージョン: 1.0C: コンテントタイプ: テキスト/平野。 CHARSETは米国のASCII Cと等しいです: C: こんにちは、ジョー、あなたは私たちが明日の3:30に会うことができると思いますか? C: S: 完成したA003 OK[APPENDUID1022843275 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は草稿(\目にふれている$MDNSent)「2004年5月31日05:26:59 -0600」16777215Sを追加します: A003 NO、すみません、メッセージは大き過ぎます。
4.2.2.4. Moving a Message between Two Mailboxes on Different Servers
4.2.2.4. 異なったサーバでメッセージを2個のメールボックスの間に動かします。
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が続いた.2がコネについて説明した、4.2、.2、.3
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拡張子の存在は性能をかなり向上させるかもしれません。 それらの1つは[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+]拡大の両方を支持するなら、全体のアップロードはただ一つの応答コマンド/周遊旅行で実行されます。
Melnikov Informational [Page 12] RFC 4549 Synch Ops for Disconnected IMAP4 Clients June 2006
外されたIMAP4クライアント2006年6月のためのメリニコフ情報[12ページ]のRFC4549同時性オプアート
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.
以下に注意してください。 クライアントimplementersが[MULTIAPPEND]が働くのを意識しているべきである、追加、倍数は原子論的に通信します。 例えば、これが、「n」を救うことができるくらいのスペースがないかどうかを意味する、-、「n-1インチのメッセージ、全体のアップロード操作は失敗します、そして、メッセージは全くメールボックスの中に保存されない」うまくいっているアップロードの後の第メッセージ(メッセージは、無効の構造を持って、サーバによって拒絶されます)。 この振舞いはある状況で望ましいかもしれませんが、それはあなたが欲しいものでないかもしれません。 さもなければ、クライアントが定期的なAPPENDコマンドを使用するべきである、(セクション4.2 .2 .3) ことによると、[LITERAL+]拡大を利用します。 また、エラー回復についての議論に関してセクション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.
以下に注意してください。 ある意味でセクション4.2.1で説明されたことと同様のUIDPLUS拡張子と共にMULTIAPPENDを使用できます。 [MULTIAPPEND]は、2番目のパラメタで複数のメッセージUIDsを考慮するために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 "<--->"):
この例がUIDPLUSと共にMULTIAPPENDの使用を示す、(サーバからの確認のためのクライアント待ちがマークされる同期ポイント、「<--、>、」、)、:
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:
C: A003は1月-2002(\目にふれている$MDNSent)「2002年5月31日05:26:59 -0600」310<を追加します。--->S: +は文字通りのデータのためにCを準備します: 日付: 月曜日、1994年2月7日21:52:25 -0800(太平洋標準時の)のC: From: フレッド Foobar <foobar@blt.example.COM 、gt;、C: Subject: 午後のミーティングC: To: mooch@owatagu.siam.edu C: メッセージイド: <B27397-0100000@blt.example.COM>C: MIMEバージョン: 1.0C: コンテントタイプ: テキスト/平野。 CHARSETは米国のASCII Cと等しいです: C: こんにちは、ジョー、あなたは私たちが明日の3:30に会うことができると思いますか? C: (見られた\) 「2002年6月1日22:43:04 -0800」286<。--->S: +は文字通りのデータのためにCを準備します: 日付: 月曜日、1994年2月7日22:43:04 -0800(太平洋標準時の)のC: From: ジョー Mooch <mooch@OWaTaGu.siam.EDU 、gt;、C: Subject: Re: 午後のミーティングC: To: foobar@blt.example.com C: メッセージイド: <a0434793874930@OWaTaGu.siam.EDU>C: MIMEバージョン: 1.0C: コンテントタイプ: テキスト/平野。 CHARSETは米国のASCII Cと等しいです: C: 3:30は大丈夫です。 C:
Melnikov Informational [Page 13] RFC 4549 Synch Ops for Disconnected IMAP4 Clients June 2006
外されたIMAP4クライアント2006年6月のためのメリニコフ情報[13ページ]のRFC4549同時性オプアート
S: A003 OK [APPENDUID 1022843275 77712,77713] completed
S: 完成したA003 OK[APPENDUID1022843275 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.
サーバがMULTIAPPEND、LITERAL+、およびUIDPLUSを支持するとき、この例では、Example2はケースのために変更されました。 アップロードは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は1月-2002(\目にふれている$MDNSent)「2002年5月31日05:26:59 -0600」310+Cを追加します: 日付: 月曜日、1994年2月7日21:52:25 -0800(太平洋標準時の)のC: From: フレッド Foobar <foobar@blt.example.COM 、gt;、C: Subject: 午後のミーティングC: To: mooch@owatagu.siam.edu C: メッセージイド: <B27397-0100000@blt.example.COM>C: MIMEバージョン: 1.0C: コンテントタイプ: テキスト/平野。 CHARSETは米国のASCII Cと等しいです: C: こんにちは、ジョー、あなたは私たちが明日の3:30に会うことができると思いますか? C: (見られた\) 「2002年6月1日22:43:04 -0800」286+、C: 日付: 月曜日、1994年2月7日22:43:04 -0800(太平洋標準時の)のC: From: ジョー Mooch <mooch@OWaTaGu.siam.EDU 、gt;、C: Subject: Re: 午後のミーティングC: To: foobar@blt.example.com C: メッセージイド: <a0434793874930@OWaTaGu.siam.EDU>C: MIMEバージョン: 1.0C: コンテントタイプ: テキスト/平野。 CHARSETは米国のASCII Cと等しいです: C: 3:30は大丈夫です。 C: S: 完成したA003 OK[APPENDUID1022843275 77712、77713]
4.2.3. Replaying Local Flag Changes
4.2.3. 地方の旗の変化を再演します。
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.
外されたクライアントは地方の旗国をサーバと同期させるストアコマンドを使用します。外されたクライアントSHOULDがセットするのに+ FLAGS.SILENTか-FLAGS.SILENTを使用するか、またはオフラインですが、ユーザによって変更されて、unsetは弛みます。 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
UID15があるメッセージに関しては、外されたクライアントは以下の旗\Seenと$Highestを収納します。 旗はサーバである他のクライアントによって変更されました: 見られた\、答えられた\、および最も高い$。 while
Melnikov Informational [Page 14] RFC 4549 Synch Ops for Disconnected IMAP4 Clients June 2006
外されたIMAP4クライアント2006年6月のためのメリニコフ情報[14ページ]のRFC4549同時性オプアート
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:
オフラインで、ユーザはHighestが旗を揚げさせるドルを取り除いて、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 STOREはCを完成しました: A002 UIDは15-FLAGS.SILENT(最も高い$)Sを格納します: 完成したA002 STORE
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メールボックスのローカルなキャッシュ、または、地方のメールボックス(例えば、メッセージ優先権)の中に追加2進の州の情報(または、事前に定義されたセットの値から値を取ることができる1つの情報)を格納できて、サーバが、任意のキーワードが格納されるのを支持するなら、クライアントは、この状態をサーバに格納するのにキーワードを使用しなければなりません。
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:
1としてメッセージをマークできる仕事関連の個人的な($パーソナル)投機的なメールクライアント($Work)を想像するか、または($スパム)をばらまいてください。 個人的であるとしてメッセージをマークするために、クライアントは以下を発行します。
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 STOREはCを完成しました: A002 UIDは15-FLAGS.SILENT($仕事$スパム)Sを格納します: 完成したA002 STORE
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 STORE
4.2.4. Processing Mailbox Compression (EXPUNGE) Requests
4.2.4. 処理メールボックス圧縮(梢消する)要求
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.
オフラインである間、メールボックスを圧縮するのを支持するナイーブな外されたクライアント実現は、\Deletedであるとマークされたメッセージを梢消するためにEXPUNGEコマンドをサーバに発行すると決めるかもしれません。 同期の間のこのコマンドに関する問題は永久にDeleted旗が設定した\ですべてのメッセージを消すということです、すなわち、ユーザがオフラインであった間に\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
また、幸い、[UIDPLUS]拡大はこの場合助けることができます。 拡大はUID EXPUNGEコマンドを紹介して、それはEXPUNGEと異なってUIDセットパラメタを取って、それは梢消できるすべてのメッセージのUIDsを記載します。 これを処理するときには、サーバ抹消だけを命令してください。
Melnikov Informational [Page 15] RFC 4549 Synch Ops for Disconnected IMAP4 Clients June 2006
外されたIMAP4クライアント2006年6月のためのメリニコフ情報[15ページ]のRFC4549同時性オプアート
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.
Deletedが旗を揚げさせる\があるメッセージはUIDリストにリストアップされました。 したがって、それらにDeleted旗が設定した\があっても、UIDセットでリストアップされなかったメッセージは梢消されないでしょう。
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:
ユーザがオフラインであった間、UIDs7、27、および65がある3つのメッセージが、開いているメールボックスを圧縮するためにユーザであることの\Deletedであると要求されていた状態でマークされました。 別のクライアントは、メッセージが\Deletedであるとサーバ(UID34)にマークしました。 同期の間、外されたクライアントは以下を発行します。
C: A001 UID EXPUNGE 7,27,65
S: * ... EXPUNGE
S: * ... EXPUNGE
S: * ... EXPUNGE
S: A001 UID EXPUNGE completed
C: A001 UIDは65秒間、7、27を梢消します: * ... Sを梢消してください: * ... Sを梢消してください: * ... 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 EXPUNGEの前後にコマンド(Deletedが旗を揚げさせる\ですべてのメッセージを見つける)をUID SEARCH DELETEDに発行すると、それは以下を得るでしょう。
Before:
以前:
C: B001 UID SEARCH DELETED
S: * SEARCH 65 34 27 7
S: B001 UID SEARCH completed
C: B001 UID検索はSを削除しました: * 7秒間の検索65 34 27: 完成したB001 UID SEARCH
After:
後:
C: B002 UID SEARCH DELETED
S: * SEARCH 34
S: B002 UID SEARCH completed
C: B002 UID検索はSを削除しました: * 34秒間、探してください: 完成したB002 UID SEARCH
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) すべてのメッセージが、\がDeletedであるとサーバにマークしたと確かめてください。
C: A001 UID SEARCH DELETED
S: * SEARCH 65 34 27 7
S: A001 UID SEARCH completed
C: A001 UID検索はSを削除しました: * 7秒間の検索65 34 27: 完成したA001 UID SEARCH
2) Find all messages that must not be erased (for the previous
example the list will consist of the message with UID 34).
2) 消してはいけないすべてのメッセージを見つけてください(前の例に関して、リストはUID34と共にメッセージから成るでしょう)。
Melnikov Informational [Page 16] RFC 4549 Synch Ops for Disconnected IMAP4 Clients June 2006
外されたIMAP4クライアント2006年6月のためのメリニコフ情報[16ページ]のRFC4549同時性オプアート
3) Temporarily remove \Deleted flag on all messages found in step 2.
3) 一時Deletedがステップ2で見つけられたすべてのメッセージで旗を揚げさせる\を取り除いてください。
C: A002 UID STORE 34 -FLAGS.SILENT (\Deleted)
S: A002 UID STORE completed
C: A002 UIDは34-FLAGS.SILENT(削除された\)Sを格納します: 完成したA002 UID STORE
4) Expunge the mailbox.
4) メールボックスを梢消してください。
C: A003 EXPUNGE
S: * 20 EXPUNGE
S: * 7 EXPUNGE
S: * 1 EXPUNGE
S: A003 EXPUNGE completed
C: A003はSを梢消します: * 20 Sを梢消してください: * 7 Sを梢消してください: * 1 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.
ここに、UID7があるメッセージは、メッセージ番号1を持っていて、UID27と共にメッセージ番号7を持っていて、UID65と共にメッセージ番号20を持っています。
5) Restore \Deleted flag on all messages found when performing step
2.
5) Deletedがステップ2を実行するとき見つけられたすべてのメッセージで旗を揚げさせる\を回復してください。
C: A004 UID STORE 34 +FLAGS.SILENT (\Deleted)
S: A004 UID STORE completed
C: A004 UIDは34+FLAGS.SILENT(削除された\)Sを格納します: 完成したA004 UID STORE
4.2.5. Closing a Mailbox
4.2.5. メールボックスを閉じます。
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コマンドを使用するべきではありません、CLOSEが静かなEXPUNGEをするので。 (セクション4.2 .4 EXPUNGEがなぜ外されたクライアントによって使用されるべきでないかを説明します。) メールボックスが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、缶が1つを使用するクライアントと共に、それとなくメールボックスを閉じて、静かを防ぐ以下のコマンドは以下を梢消します。
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]で説明されたコマンドです。 それがCAPABILITYリストでUNSELECTを報告するなら、このコマンドはサーバで後押しされています。
2) SELECT <another_mailbox> - SELECT causes implicit CLOSE without
EXPUNGE.
2) 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.
3) メールボックスを閉じた後にクライアントがLOGOUTを発行するつもりであるなら、ただLOGOUTを発行するかもしれません、LOGOUTがまた、EXPUNGEなしで内在しているCLOSEを引き起こすので。
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) SELECTの<の非_の存在_メールボックス>--クライアントがメールボックスを知っているなら、それは存在しないことができないか、選択できない、それ、MAY SELECT、それ。
Melnikov Informational [Page 17] RFC 4549 Synch Ops for Disconnected IMAP4 Clients June 2006
外されたIMAP4クライアント2006年6月のためのメリニコフ情報[17ページ]のRFC4549同時性オプアート
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<メールボックス>--、Reselect、読込み専用モードの同じメールボックス。
4.3. Details of "Normal" Synchronization of a Single Mailbox
4.3. 単一のメールボックスの「正常な」同期の詳細
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.
最も一般的な形式の同期は人間がクライアントの特定のメールボックスの状態のコピーの保全を信じて、単にクライアントのキャッシュを最新の状態にしたがっているのでそれが正確にサーバのメールボックスの現状を反映するところです。
4.3.1. Discovering New Messages and Changes to Old Messages
4.3.1. 新しいメッセージと古いメッセージへの変化を発見します。
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を表させてください。 厳密に昇順でUIDsを割り当てるので、これは単にクライアントが知っているメールボックスにおける最後のメッセージのUIDです。 <lastseenuid+1>に<lastseenuid>のUIDと1を表させてください。 <記述子>に実現が記述子の一部であると考えるすべてのFETCHデータ項目の品目から成るリストを表させてください。 最小限では、これはただFLAGSデータ項目ですが、また、通常、それはBODYSTRUCTUREとRFC822.SIZEを含んでいます。 このステップでは、<記述子>SHOULD NOTは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 FETCH1: *<記述子<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) メッセージ番号とUIDs(古いメッセージのための)の間のマッピングを築き上げてください。
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
ここのオーダーは重要です。 私たちは、サーバにできるだけ速く新しいメッセージ記述子のリストを返し始めて欲しいと思います、私たちが私たちがクライアントを知っているというすべてのメッセージに関する記述子を求めることによって始めてクライアントが、より多くのFETCHコマンドを発行し始めることができるように
Melnikov Informational [Page 18] RFC 4549 Synch Ops for Disconnected IMAP4 Clients June 2006
外されたIMAP4クライアント2006年6月のためのメリニコフ情報[18ページ]のRFC4549同時性オプアート
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.
まだキャッシュさせることができません。 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をとって来ます: *(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は、サーバが巨大なデータ量を送るのをもたらすかもしれません。 また、セクション3.2を見てください。賢い外されたクライアントがメッセージ範囲を使用するべきである、(.1 .2[RFC2683]) ユーザが新しいメッセージのグループのための魅惑的な情報の間の異なった操作を実行できるように。
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:
SELECTかEXAMINE(<uidnext>)でサーバによって返された新しいUIDNEXTを知っていて、クライアントはUID範囲<lastseenuid+1>を分割できます: グループ(例えば、100のメッセージ)への<uidnext>。 その後に、クライアントは以下を発行できます。
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>。(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.
検索命令が発行されない場合、いくつのメッセージがサブレンジになるかを決定するのが不可能であることに注意してください、UIDsが必ず隣接であるというわけではないときに。
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: クライアントSHOULDは最初のFETCHコマンドの間に受けられたどんな求められていないEXPUNGE応答も無視します。 EXPUNGE応答はメッセージ番号からUIDへの変換テーブルを持っていないクライアントにとって、役に立たないメッセージ番号を含んでいます。
Melnikov Informational [Page 19] RFC 4549 Synch Ops for Disconnected IMAP4 Clients June 2006
外されたIMAP4クライアント2006年6月のためのメリニコフ情報[19ページ]のRFC4549同時性オプアート
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.
2番目のFETCHコマンドはゼロかさらに非タグ付けををされたフェッチ応答をもたらすでしょう。 各応答には、対応するUID FETCHデータ項目があるでしょう。 ローカルなキャッシュから合っているuntagged 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があって、ローカルなキャッシュがそれぞれUIDs12、777、および14999がある3つのメッセージを含んだなら、サーバから以下の応答を受けた後に、クライアントはUID14999と共にローカルなキャッシュからメッセージを取り除かなければなりません。
S: * 1 FETCH (UID 12 FLAGS (\Seen))
S: * 2 FETCH (UID 777 FLAGS (\Answered \Deleted))
S: * 1 フェッチ(UID12旗(見られた\))S: * 2フェッチ(UID777旗(削除された\に答えた\))
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 SEARCH UID1: <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.
このコマンドは、より少ない交通を発生させるでしょう。 しかしながら、作成者は最初にメッセージ番号からUIDsまでマッピングテーブルを組立てるために検索命令の出力を分類しなければならないのを意識しているべきです、サーバがどんな特定のオーダーでも検索応答でUIDsを返すという要件が全くないので。
4.3.2. Searching for "Interesting" Messages.
4.3.2. 「おもしろい」メッセージを検索します。
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、)、完全なサーバ、または両方の何らかの組み合わせに関して。 「おもしろい」メッセージであることに関する決定はクライアントソフトウェアと人間次第です。 たぶんどんなクライアントでも実行されるべきである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.
日付の検索が時間と時間帯を無視するのを覚えておいてください。 クライアントが、中で説明されたステップの<記述子>でINTERNALDATEを指定したならこの検索をするのを避けることができる、4.3、.1 クライアントがそうしたなら、それはメッセージキャッシュに局所探索を実行できます。
Melnikov Informational [Page 20] RFC 4549 Synch Ops for Disconnected IMAP4 Clients June 2006
外されたIMAP4クライアント2006年6月のためのメリニコフ情報[20ページ]のRFC4549同時性オプアート
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).
また、このステップでは、クライアントは、サーバから特定のメッセージのどういう情報をとって来たらよいかを決めます。「大き過ぎる」と考えられるメッセージのためにさえ特定のIn、クライアントはそれの何らかの部分をとって来るのを選ぶかもしれません。 例えば、メッセージがテキスト部分とMPEG付属を含んでいて、混ぜられた、複合/であるなら、クライアントがテキスト部分をとって来ない理由が全くありません。 部分がとって来られるべきであるか、またはとって来られるべきでない決定がBODYSTRUCTURE FETCH応答データ項目に受け取られた情報に基づくことができる、(すなわち、BODYSTRUCTUREが中で説明されたステップの<記述子>に含まれていた、4.3、.1、)
4.3.3. Populating Cache with "Interesting" Messages.
4.3.3. 「おもしろい」メッセージでキャッシュに居住します。
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.
外されたクライアントのローカルなキャッシュにメッセージをとって来るのが、人間がメッセージを読んだのを(または、意志さえ)含意しないことに注意してください。 したがって、外されたクライアントのための同期プログラムはいつもそれとなくSeenが旗を揚げさせる\を設定する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でNote1を見てください。
Melnikov Informational [Page 21] RFC 4549 Synch Ops for Disconnected IMAP4 Clients June 2006
外されたIMAP4クライアント2006年6月のためのメリニコフ情報[21ページ]のRFC4549同時性オプアート
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: とってくる ... C: A013 UIDが11をとって来る、(BODY[1.1] BODY[1.2]) S: ... C: A014 UIDがとって来る、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: ...
4.3.4. User-Initiated Synchronization
4.3.4. ユーザによって開始された同期
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) \Flaggedとしてサーバでマークされたすべてのメッセージをとって来てください。
4.4. Special Case: Descriptor-Only Synchronization
4.4. 特別なケース: 記述子だけ同期
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によって列に並ばせられた明白な動作でとって来られるでしょう。 したがって、ユーザがその後のダウンロードへのメッセージを特定できるように、この種類のメールボックスで望ましい唯一の同期が十分な記述子に情報をとって来ています。
Melnikov Informational [Page 22] RFC 4549 Synch Ops for Disconnected IMAP4 Clients June 2006
外されたIMAP4クライアント2006年6月のためのメリニコフ情報[22ページ]のRFC4549同時性オプアート
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.
高いボリュームからメッセージを受け取る特別なメールボックス、また、少ない優先権メーリングリストがこのカテゴリにあるかもしれなくて、人間がaにいるときには少なくとも、急いでください。
4.5. Special Case: Fast New-Only Synchronization
4.5. 特別なケース: 速さ、新しく唯一の同期
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>).
いくつかの場合、人間はその人が古いメッセージへの変化を心配しないほど急ぐかもしれません、ほとんど新しいメッセージ。 この場合、クライアントは古いメッセージ(1: <lastseenuid>)に旗とUIDsを入手するUID FETCHコマンドをサボることができます。
4.6. Special Case: Blind FETCH
4.6. 特別なケース: 盲目のフェッチ
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>: *(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は<lastseenuid+1>をとって来ます: *(RFC822.SIZEに旗を揚げさせる)」を発行します。
2) From the message sizes returned in step 1, construct UID set
<required_messages>.
2) ステップ1で返されたメッセージサイズから、構造物UIDセット<は_メッセージ>を必要としました。
3) Issue "tag2 UID FETCH <required_messages> (BODY.PEEK[])".
3) 問題、「tag2 UIDフェッチ<が_メッセージ>を必要とした、(BODY.PEEK[])、」
or
または
1) Issue "tag1 UID FETCH <lastseenuid+1>:* (FLAGS)".
1) 「tag1 UIDは<lastseenuid+1>をとって来ます: *(旗)」を発行します。
2) Construct UID set <old_uids> from the responses of step 1.
2) 構造物UIDはステップ1の応答から<の古い_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検索のuids>より小さい<メッセージ_限界UID<_>」を発行してください。 構造物UIDセット<は_結果からのメッセージ>に検索命令を要求しました。
4) Issue "tag3 UID FETCH <required_messages> (BODY.PEEK[])".
4) 問題、「tag3 UIDフェッチ<が_メッセージ>を必要とした、(BODY.PEEK[])、」
Melnikov Informational [Page 23] RFC 4549 Synch Ops for Disconnected IMAP4 Clients June 2006
切断しているIMAP4クライアント2006年6月のためのメリニコフ情報[23ページ]のRFC4549同時性オプアート
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.
以下に注意してください。 そのようなコマンドに対応して、メッセージが<の長さの>より長い場合にだけ、サーバは部分的なデータを返すでしょう。 それはサイズが<の長さの、より>以下であるどんなメッセージのための完全なメッセージデータも返すでしょう。 前の場合では、クライアントが不完全なデータからメッセージの完全なMIME構造を抜粋できないので、クライアントはまた、UID FETCHコマンドでBODYSTRUCTUREを入れるべきです。
5. Implementation Considerations
5. 実装問題
Below are listed some common implementation pitfalls that should be considered when implementing a disconnected client.
以下であることは、記載されていて、aを実装するとき考えられるべきであるいくつかの一般的な実装落とし穴がクライアントから切断したということです。
1) Implementing fake UIDs on the client.
1) クライアントの上でにせのUIDsを実装します。
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を全く持っていません、UIDsがサーバによって選択されるとき。クライアントは、さらなる操作におけるまだアップロードされなかったメッセージに参照をつけるために内部的ににせのUIDsを実装するかもしれません。 (例えば、別のメールボックスに削除されるか、またはコピーされるようにメッセージをアップロードされることが予定されていましたが、次に、マークできました。) ここで、クライアントはどうあってもこれらのにせのUIDsをサーバに送ってはいけません。また、クライアントimplementersは[IMAP4]に従ってUIDが0を除いた32ビットの符号のない整数であると思い出させられるべきです。 それで、4294967295と2147483648の両方が有効なUIDsです、そして、0と-1はともに無効です。 メールクライアントであると切断された或るものが負数を送るのが知られている、(例えば、「1インチ)、同期の間のサーバへのメッセージUIDs、」
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サーバにDraftsと呼ばれるメールボックスの中に保存されると思います。また、以下のコンベンションを使用するつもりです: それが初めて保存されたとき、<の古い_uid>は草稿の中間的バージョンのUIDです。 これはクライアントの上で生成されたにせのUIDです。 <の新しい_uid>は草稿の最終版のUIDです。 これはクライアントの上で生成された別のにせのUIDです。
Melnikov Informational [Page 24] RFC 4549 Synch Ops for Disconnected IMAP4 Clients June 2006
切断しているIMAP4クライアント2006年6月のためのメリニコフ情報[24ページ]のRFC4549同時性オプアート
1) APPEND Drafts (\Seen $MDNSent \Drafts) {<nnn>}
...first version of the message follows...
1) 草稿(見られた$MDNSent\が作成する\)を追加してください。 <nnn>…メッセージの最初のバージョンは従います…
2) APPEND Drafts (\Seen $MDNSent \Drafts) {<mmm>}
...final version of the message follows...
2) 草稿(見られた$MDNSent\が作成する\)を追加してください。 <、えー、>、…メッセージの最終版は続きます…
3) STORE <old_uid> +FLAGS (\Deleted)
3) <の古い_uid>+旗を保存してください。(削除された\)
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で値がある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がメッセージがユーザの意見に現れるべきでないというインディケータとして旗を揚げさせる\を使用する人もいるかもしれません。 Deletedが旗を揚げさせる\の用法はこのためにいずれのメールボックスが調節する安全で、他のクライアント(例えば、オンラインクライアント)力のEXPUNGEではありません。
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.
それがいつも追加注文に安全であるというわけではありませんか、またはいくつかの操作には依存があるかもしれないので(Situation3が示すように)、同期の間、余分な操作を移してください。 それで、疑問でこれをしないでください。
Situation 3: The user copies a message out of a mailbox and then
deletes the mailbox.
状況3: ユーザは、メールボックスからメッセージをコピーして、次に、メールボックスを削除します。
Melnikov Informational [Page 25] RFC 4549 Synch Ops for Disconnected IMAP4 Clients June 2006
切断しているIMAP4クライアント2006年6月のためのメリニコフ情報[25ページ]のRFC4549同時性オプアート
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は古いメールSを選択します: ... C: A002 UIDコピー111ToDo S: A002 OK、[94]コピーが完成したCOPYUID1022843345 111… C: A015はSを閉じます: A015OKはCを完成しました: A016は古いメールSを削除します: 首尾よく終了するA016 OK Mailbox削除
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.
クライアントがDELETE(タグA016)1番目とCOPY(タグA002)2番目を実行するなら、COPYは失敗します。 また、ユーザがそれほど慎重に別のメールボックスの中にコピーしたというメッセージは失われました。
5.1. Error Recovery during Playback
5.1. 再生の間のエラー回復
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.
それが首尾よく同じサーバに接続する次の時に中断している操作(クライアントによって発行されますが、サーバによって承諾されなかった持続コマンド)から始めて、クライアントは、再生(再生)ログの現在の見解を覚えていて、それを再演しなければなりません。クライアントが再接続されるとき、接続が非ベキ等元のIMAPコマンドを実行している間、迷子になったなら(セクション1との定義を見てください)、それは、本当に、中断しているコマンドが実行されなかったのを確実にしなければなりません。 それが実行されなかったなら、クライアントはそうでなければ、中断しているコマンド、以下のコマンドから再生を再開しなければなりません。
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コマンドへのタグ付けをされたいいえ応答におけるTRYCREATE応答コードを送ることによって、この状態の広告を出します。)
Melnikov Informational [Page 26] RFC 4549 Synch Ops for Disconnected IMAP4 Clients June 2006
切断しているIMAP4クライアント2006年6月のためのメリニコフ情報[26ページ]のRFC4549同時性オプアート
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) 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) メールボックスからのメッセージをコピーして、それが存在していないか、またはメールボックスの上のACLs[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操作が失敗するなら、クライアントは後で失敗したメッセージをCOPYに試みてはいけません。 (Situation3、また、セクション5を見てください。)
Melnikov Informational [Page 27] RFC 4549 Synch Ops for Disconnected IMAP4 Clients June 2006
切断しているIMAP4クライアント2006年6月のためのメリニコフ情報[27ページ]のRFC4549同時性オプアート
5.2. Quality of Implementation Issues
5.2. 導入問題の品質
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) 明らかに尋ねられない場合、仕事をしないでください。 フレキシブルであってください。 できれば、BEFOREの始めの同期をすべての質問に尋ねてください。
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を見てください。
5.3. Optimizations
5.3. 最適化
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.
1) 初期のOKかPREAUTH応答が[IMAP4]のセクション7.1で説明されるようにCAPABILITY応答コードを含むかもしれません。 この応答コードはCAPABILITYコマンド*で返されるのと同じ情報を教えます。この応答コードに注意を向ける切断しているクライアントは、コマンドをCAPABILITYに送るのを避けることができて、周遊旅行を保存するでしょう。
Melnikov Informational [Page 28] RFC 4549 Synch Ops for Disconnected IMAP4 Clients June 2006
切断しているIMAP4クライアント2006年6月のためのメリニコフ情報[28ページ]のRFC4549同時性オプアート
* 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.
* 以下に注意してください。 いくつかのサーバが非認証された州かすべての州だけで関連しているCAPABILITY応答コード拡張で報告します。 通常、そのようなサーバは、LOGINかAUTHENTICATEコマンドを使用することでうまくいっている認証の別のCAPABILITY応答コードを送ります(それはセキュリティ層を全く交渉しません; .2セクション6.2[IMAP4]を見てください)。 非認証された状態が広告に掲載されないので、うまくいっているLOGIN/AUTHENTICATEに送られたCAPABILITY応答コードは拡大として初期のOK応答におけるCAPABILITY応答コードと関連していただけである状態で異なるかもしれません、そして、認証されたそして/または、選択された状態だけで利用可能ないくつかの追加拡大は異なるでしょう。
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: * [CAPABILITY IMAP4REV1 LOGIN-REFERRALS STARTTLS AUTH=DIGEST-MD5 AUTH=SRP]imap.example.comの持ち合わせのCを承認してください: 2 DIGEST-MD5 Sを認証してください: 2 OK [CAPABILITY IMAP4REV1 IDLE NAMESPACE MAILBOX-REFERRALS SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND] User authenticated (層がありません)
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.
a) EXPUNGEは別のEXPUNGEかCLOSEで続きました。 b)変化はすぐに梢消されるメッセージで弛みます(Deletedが旗を揚げさせる\を除いて)。 c) 同じメールボックスを開けて、閉じます。
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(\Deleted)… tag2 UIDストア<uid1>+FLAGS(\Flagged)… 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.
それが梢消される前にメッセージがコピーされているので、それは2番目の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に関連してこれを達成できます。
Melnikov Informational [Page 29] RFC 4549 Synch Ops for Disconnected IMAP4 Clients June 2006
切断しているIMAP4クライアント2006年6月のためのメリニコフ情報[29ページ]のRFC4549同時性オプアート
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.
そのような並列化を達成するために、クライアントは同じサーバに1つ以上の接続を開かなければならないでしょう。クライアント作家はTCP接続を確立して、認証を実行すると関連している重要な費用を忘れるべきではありません。 切断しているクライアントは1メールボックスあたり1つの接続を使用してはいけません。 多くの場合、2つの接続があるのは、十分です。 切断しているクライアントSHOULDは、1つ以上の接続で同じメールボックスを選択するのを避けます。 その他の詳細に関して.1セクション3.1[RFC2683]を見てください。
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 ValidityをチェックするSTATUSコマンドを使用するかもしれません。 これは同時に複数のメールボックスの同期を実行するために同じサーバに多くの接続を開くより望ましいです。 .10セクション5.3[IMAP4]、このSHOULD NOTで説明される、選択されたメールボックスの上に使用されてください。
6. IMAP Extensions That May Help
6. 助けるかもしれないIMAP拡張子
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) そして、セクション4.1、4.2.1、4.2で[UIDPLUS]の使用について議論する、.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) セクション4.2.2で.5にMULTIAPPENDとLITERAL+拡張子のアップロードメッセージの使用について議論します。
3) Use the CONDSTORE extension (see Section 6.1) for quick flag
resynchronization.
3) 迅速な旗の再同期に、CONDSTORE拡張子(セクション6.1を見る)を使用してください。
6.1. CONDSTORE Extension
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]拡張子を使用するべきです。サーバがデータ項目をMODSEQ FETCHに送るときはいつも、クライアントは、メールボックス始まりの上に受け取られたHIGHESTMODSEQ OK応答コードから値をキャッシュして、それをアップデートしなければなりません。
Melnikov Informational [Page 30] RFC 4549 Synch Ops for Disconnected IMAP4 Clients June 2006
切断しているIMAP4クライアント2006年6月のためのメリニコフ情報[30ページ]のRFC4549同時性オプアート
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.
クライアントが受信するならNOMODSEQ OKがHIGHESTMODSEQの代わりに応答に非タグ付けをして、それは、キャッシュから最後に知られている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値がサーバによって返されたものに合っているなら、クライアントはキャッシュされたメッセージのために旗をとって来てはいけません、変えた状態で持っていないとき。 サーバの値がキャッシュされたものより高いなら、クライアントは、クライアントが最後の時にオンラインであり、メールボックスを持って以来旗を変えているすべてのメッセージが開いたのがわかるのに「SEARCH MODSEQの<のキャッシュされた価値の>」を使用するかもしれません。 あるいはまた、クライアントは「フェッチ1: *(旗)(CHANGEDSINCEの<のキャッシュされた価値の>)」を使用するかもしれません。 後者の操作は、変えられたメッセージと魅惑的な新情報を検索しながら、結合します。
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) メールボックスUIDVALIDITY(その他の詳細に関してセクション4.1を見る)についてSELECT/EXAMINE/STATUSに問い合わせてください。
If the UIDVALIDITY value returned by the server differs, the
client MUST
サーバによって返されたUIDVALIDITY値が異なるなら、クライアントは異ならなければなりません。
* 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;
* ローカルなキャッシュからそのメールボックスを取り出してください。 * キャッシュされたHIGHESTMODSEQは、メールボックスのために「忘れてください」と評価します。 * そのメールボックスの中にUIDsを示すあらゆる未定の「動作」を取り除いてください(これがクライアントが発生しているにせのUIDsに実行された動作に影響しないことに注意してください; セクション5を見てください)。 *そして、スキップは1bと2IIを踏みます。
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をチェックしてください。 キャッシュされた値がものがサーバで戻ったのと同じであるなら、2II、すなわち、クライアントだけをステップのメッセージ旗にとって来るスキップは、どのメッセージが梢消されたかを見つけなければなりません。
Melnikov Informational [Page 31] RFC 4549 Synch Ops for Disconnected IMAP4 Clients June 2006
切断しているIMAP4クライアント2006年6月のためのメリニコフ情報[31ページ]のRFC4549同時性オプアート
2) Fetch the current "descriptors".
2) 現在の「記述子」をとって来てください。
I) Discover new messages.
I) 新しいメッセージを発見してください。
II) Discover changes to old messages and flags for new messages
using
"FETCH 1:* (FLAGS) (CHANGEDSINCE <cached-value>)" or
"SEARCH MODSEQ <cached-value>".
II) 「フェッチ1: *(旗)」を使用して、新しいメッセージに関して古いメッセージと旗への変化を発見してください。 (CHANGEDSINCEの<のキャッシュされた価値の>)「または、「MODSEQの<のキャッシュされた価値の>を捜してください」。」
Discover expunged messages; for example, using
"UID SEARCH 1:<lastseenuid>". (All messages not returned
in this command are expunged.)
梢消されたメッセージを発見してください。 例えば、「UID SEARCH1: <lastseenuid>」を使用すること。 (このコマンドで返されなかったすべてのメッセージが梢消されます。)
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は受信トレイSを選択します: * 172が存在している、S: * 1、最近のS: * OK[UNSEEN12]メッセージ12は最初に、見えないSです: * OK[UIDVALIDITY3857529045]のUIDs有効なS: * OK[UIDNEXT201]は次のUID Sを予測しました: * 旗(\に答えた\は\削除された\見られた\草稿に旗を揚げさせた)のS: * OK[PERMANENTFLAGS(\は\見られた\*を削除した)]はSを制限しました: * OK[HIGHESTMODSEQ20010715194045007]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フェッチ1: *(旗)(CHANGEDSINCE20010715194032001)S: * 2は(UID6MODSEQ(20010715205008000)旗(削除された\))にSをとって来ます: * 5 (UID9MODSEQ(20010715195517000)旗($NoJunk$AutoJunk$MDNSent))をとって来てください… S: 完成したA143 OK FETCH
or:
または、:
Melnikov Informational [Page 32] RFC 4549 Synch Ops for Disconnected IMAP4 Clients June 2006
切断しているIMAP4クライアント2006年6月のためのメリニコフ情報[32ページ]のRFC4549同時性オプアート
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検索MODSEQ20010715194032001UID1: 20秒間: * 検索6 9 11 12 18 19 20 23(MODSEQ20010917162500)S: A143 OKの検索の完全なC: A144 UID検索1: 20秒間: * 検索6 9… S: 完成したA144 OK FETCH
7. Security Considerations
7. セキュリティ問題
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.
また、Implementersは徹底的なテスト重要性に関して思い出させられています。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
VERSION 4rev1", RFC 3501, March 2003.
[IMAP4] クリスピン、M.、「バージョン4rev1"、RFC3501、2003年インターネットメッセージアクセス・プロトコル--3月。」
[UIDPLUS] Crispin, M., "Internet Message Access Protocol (IMAP) -
UIDPLUS extension", RFC 4315, December 2005.
[UIDPLUS]クリスピン、M.、「インターネットMessage Accessプロトコル(IMAP)--、UIDPLUS拡張子、」、RFC4315、12月2005日
[LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC
2088, January 1997.
[LITERAL+] マイアーズ、J.、「IMAP4非連動リテラル」、RFC2088、1997年1月。
[CONDSTORE] Melnikov, A. and S. Hole, "IMAP Extension for
Conditional STORE Operation or Quick Flag Changes
Resynchronization", RFC 4551, June 2006.
メリニコフ、A.、およびS.が掘る[CONDSTORE]、「条件付きの店舗運営か迅速な旗のためのIMAP拡張子はResynchronizationを変えます」、RFC4551、2006年6月。
[MULTIAPPEND] Crispin, M., "Internet Message Access Protocol (IMAP) -
MULTIAPPEND Extension", RFC 3502, March 2003.
[MULTIAPPEND]クリスピン、M.、「インターネットはアクセス・プロトコル(IMAP)を通信させます--MULTIAPPEND拡張子」、RFC3502、3月2003日
[UNSELECT] Melnikov, A., "Internet Message Access Protocol (IMAP)
UNSELECT command", RFC 3691, February 2004.
[UNSELECT] メリニコフ、A.、「インターネットMessage Accessプロトコル(IMAP)UNSELECTコマンド」、RFC3691、2004年2月。
[RFC2683] Leiba, B., "IMAP4 Implementation Recommendations", RFC
2683, September 1999.
[RFC2683] Leiba、B.、「IMAP4実装推薦」、RFC2683、1999年9月。
Melnikov Informational [Page 33] RFC 4549 Synch Ops for Disconnected IMAP4 Clients June 2006
切断しているIMAP4クライアント2006年6月のためのメリニコフ情報[33ページ]のRFC4549同時性オプアート
8.2. Informative References
8.2. 有益な参照
[ACL] Melnikov, A., "IMAP4 Access Control List (ACL)
Extension", RFC 4314, December 2005.
[ACL] メリニコフ、A.、「IMAP4アクセスコントロールリスト(ACL)拡大」、RFC4314、2005年12月。
[IMAP-MODEL] Crispin, M., "Distributed Electronic Mail Models in
IMAP4", RFC 1733, December 1994.
[IMAP-モデル]クリスピン(M.)は「1994年12月にIMAP4"、RFC1733で電子メールモデルを分配しました」。
9. Acknowledgements
9. 承認
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メーリングリストに掲示されたコメント、グラントBaillieから受け取られたコメント/修正/考え、サイラスDaboo、ジョン・G.マイアーズ、クリス・ニューマン、およびティモSirainenに感謝します。
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
AlexeyメリニコフIsode株式会社5城のビジネス村の36駅のRoadハンプトン、ミドルセックスTW12 2BXイギリス
Phone: +44 77 53759732 EMail: alexey.melnikov@isode.com
以下に電話をしてください。 +44 77 53759732はメールされます: alexey.melnikov@isode.com
Melnikov Informational [Page 34] RFC 4549 Synch Ops for Disconnected IMAP4 Clients June 2006
外されたIMAP4クライアント2006年6月のためのメリニコフ情報[34ページ]のRFC4549同時性オプアート
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Melnikov Informational [Page 35]
メリニコフInformationalです。[35ページ]
一覧
スポンサーリンク
