RFC5162 日本語訳
5162 IMAP4 Extensions for Quick Mailbox Resynchronization. A.Melnikov, D. Cridland, C. Wilson. March 2008. (Format: TXT=51620 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Melnikov
Request for Comments: 5162 D. Cridland
Category: Standards Track Isode Ltd
C. Wilson
Nokia
March 2008
コメントを求めるワーキンググループA.メリニコフの要求をネットワークでつないでください: 5162年のD.Cridlandカテゴリ: 2008年の標準化過程Isode Ltd C.ウィルソンのノキアの行進
IMAP4 Extensions for Quick Mailbox Resynchronization
迅速なメールボックスResynchronizationのためのIMAP4拡張子
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document defines an IMAP4 extension, which gives an IMAP client the ability to quickly resynchronize any previously opened mailbox as part of the SELECT command, without the need for server-side state or additional client round-trips. This extension also introduces a new response that allows for a more compact representation of a list of expunged messages (and always includes the Unique Identifiers (UIDs) expunged).
このドキュメントはIMAP4拡張子を定義します、サーバサイド州か追加クライアント周遊旅行の必要性なしで。(拡張子はSELECTコマンドの一部としてどんな以前に開かれたメールボックスもすぐに再連動させる能力をIMAPクライアントに与えます)。 また、この拡大は梢消されたメッセージ(そして、いつも(UIDs)が梢消したUnique Identifiersを含んでいる)のリストの、よりコンパクトな表現を考慮する新しい応答を導入します。
Melnikov, et al. Standards Track [Page 1] RFC 5162 IMAP Quick Mailbox Resync March 2008
メリニコフ、他 規格は2008年のIMAPの迅速なメールボックスResync行進のときにRFC5162を追跡します[1ページ]。
Table of Contents
目次
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 4
3.1. QRESYNC Parameter to SELECT/EXAMINE . . . . . . . . . . . 4
3.2. VANISHED UID FETCH Modifier . . . . . . . . . . . . . . . 8
3.3. EXPUNGE Command . . . . . . . . . . . . . . . . . . . . . 10
3.4. CLOSE Command . . . . . . . . . . . . . . . . . . . . . . 11
3.5. UID EXPUNGE Command . . . . . . . . . . . . . . . . . . . 11
3.6. VANISHED Response . . . . . . . . . . . . . . . . . . . . 12
3.7. CLOSED Response Code . . . . . . . . . . . . . . . . . . . 15
4. Server Implementation Considerations . . . . . . . . . . . . . 15
4.1. Server Implementations That Don't Store Extra State . . . 15
4.2. Server Implementations Storing Minimal State . . . . . . . 16
4.3. Additional State Required on the Server . . . . . . . . . 16
5. Updated Synchronization Sequence . . . . . . . . . . . . . . . 17
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . . 22
1. 序論と概観. . . . . . . . . . . . . . . . . . 2 2。 要件記法. . . . . . . . . . . . . . . . . . . . 4 3 IMAPは変化. . . . . . . . . . . . . . . . . . . . 4 3.1について議定書の中で述べます。 .43.2を選択するか、または調べるQRESYNCパラメタ。 消えているUIDは修飾語. . . . . . . . . . . . . . . 8 3.3をとって来ます。 コマンド. . . . . . . . . . . . . . . . . . . . . 10 3.4を梢消してください。 コマンド. . . . . . . . . . . . . . . . . . . . . . 11 3.5を終えてください。 UIDはコマンド. . . . . . . . . . . . . . . . . . . 11 3.6を梢消します。 応答. . . . . . . . . . . . . . . . . . . . 12 3.7を消えさせました。 閉じている応答コード. . . . . . . . . . . . . . . . . . . 15 4。 サーバ実現問題. . . . . . . . . . . . . 15 4.1。 エキストラを格納しないサーバ実現が.154.2を述べます。 最小量の状態. . . . . . . 16 4.3を格納するサーバ実現。 追加状態がサーバ. . . . . . . . . 16 5で必要です。 同期系列. . . . . . . . . . . . . . . 17 6をアップデートしました。 正式な構文. . . . . . . . . . . . . . . . . . . . . . . . 19 7。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 20 8。 IANA問題. . . . . . . . . . . . . . . . . . . . . 21 9。 承認. . . . . . . . . . . . . . . . . . . . . . . 21 10。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 21 10.1。 引用規格. . . . . . . . . . . . . . . . . . . 21 10.2。 有益な参照. . . . . . . . . . . . . . . . . . 22
1. Introduction and Overview
1. 序論と概観
The [CONDSTORE] extension gives a disconnected client the ability to quickly resynchronize IMAP flag changes for previously seen messages. This can be done using the CHANGEDSINCE FETCH modifier once a mailbox is opened. In order for the client to discover which messages have been expunged, the client still has to issue a UID FETCH or a UID SEARCH command. This document defines an extension to [CONDSTORE] that allows a reconnecting client to perform full resynchronization, including discovery of expunged messages, in a single round-trip. This extension also introduces a new response, VANISHED, that allows for a more compact representation of a list of expunged messages.
[CONDSTORE]拡大がすばやく外されたクライアントに能力を与える、resynchronize IMAPは以前に見られたメッセージのために変化に旗を揚げさせます。 これはメールボックスがいったん開けられるとCHANGEDSINCE FETCH修飾語を使用し終わることができます。 クライアントが、どのメッセージが梢消されたかを発見するように、クライアントはまだUID FETCHかUID SEARCHコマンドを発行しなければなりません。 このドキュメントは再接続しているクライアントが完全な再同期を実行できる[CONDSTORE]と拡大を定義します、梢消されたメッセージの発見を含んでいて、ただ一つの丸い旅行で。 VANISHED、また、この拡大は新しい応答を導入します、とそれが梢消されたメッセージのリストの、よりコンパクトな表現のために許容します。
This extension can be useful for mobile clients that can experience frequent disconnects caused by environmental factors (battery life, signal strength, etc.). Such clients need a way to quickly reconnect to the IMAP server, while minimizing delay experienced by the user as well as the amount of traffic (and hence the expense) generated by resynchronization.
この拡大は環境要因(バッテリーの寿命、信号強度など)によって引き起こされた頻繁な分離を経験できる可動のクライアントの役に立つ場合があります。 そのようなクライアントは再同期によって発生した交通(そして、したがって、費用)の量と同様にユーザによって経験された遅れを最小にする間、すぐにIMAPサーバに再接続する方法を必要とします。
Melnikov, et al. Standards Track [Page 2] RFC 5162 IMAP Quick Mailbox Resync March 2008
メリニコフ、他 規格は2008年のIMAPの迅速なメールボックスResync行進のときにRFC5162を追跡します[2ページ]。
By extending the SELECT command to perform the additional resynchronization, this also allows clients to reduce concurrent connections to the IMAP server held purely for the sake of avoiding the resynchronization.
また、追加再同期を実行するSELECTコマンドを広げることによって、これで、クライアントは再同期を避けることのために純粋に保持されたIMAPサーバに同時接続を抑えることができます。
The quick resync IMAP extension is present if an IMAP4 server returns "QRESYNC" as one of the supported capabilities to the CAPABILITY command.
IMAP4サーバが支持された能力の1つとして"QRESYNC"を能力コマンドに返すなら、迅速なresync IMAP拡張子は存在しています。
Servers supporting this extension MUST implement and advertise support for the [ENABLE] IMAP extension. Also, the presence of the "QRESYNC" capability implies support for the [CONDSTORE] IMAP extension even if the CONDSTORE capability isn't advertised. A server compliant with this specification is REQUIREd to support "ENABLE QRESYNC" and "ENABLE QRESYNC CONDSTORE" (which are "CONDSTORE enabling commands", as defined in [CONDSTORE], and have identical results), but there is no requirement for a compliant server to support "ENABLE CONDSTORE" by itself. The "ENABLE QRESYNC"/"ENABLE QRESYNC CONDSTORE" command also tells the server that it SHOULD start sending VANISHED responses (see Section 3.6) instead of EXPUNGE responses. This change remains in effect until the connection is closed.
この拡大を支持するサーバは、[ENABLE]IMAP拡張子のサポートを実行して、広告を出さなければなりません。 また、CONDSTORE能力が広告に掲載されないでも、"QRESYNC"能力の存在は[CONDSTORE]IMAP拡張子のサポートを含意します。 この仕様による対応することのサーバは「QRESYNCを有効にしてください」を支持して、「QRESYNC CONDSTOREを有効にする」REQUIREd([CONDSTORE]で定義されるように「コマンドを可能にするCONDSTORE」であり、同じ結果を持っている)ですが、対応するサーバがそれ自体で「CONDSTOREを有効にしてください」を支持するという要件が全くありません。 の代わりにする、「QRESYNCを有効にしてください」という/またコマンドがそれが送り始めるべきであるサーバを言う「QRESYNC CONDSTOREを有効にしてください」が応答を消えさせた、(セクション3.6を見てください)応答を梢消してください。 接続が閉じられるまで、この変化は有効なままで残っています。
For compatibility with clients that only support the [CONDSTORE] IMAP extension, servers SHOULD advertise CONDSTORE in the CAPABILITY response as well.
[CONDSTORE]IMAP拡張子をサポートするだけであるクライアントとの互換性のために、サーバSHOULDはまた、CAPABILITY応答でCONDSTOREの広告を出します。
A client making use of this extension MUST issue "ENABLE QRESYNC" once it is authenticated. A server MUST respond with a tagged BAD response if the QRESYNC parameter to the SELECT/EXAMINE command or the VANISHED UID FETCH modifier is specified and the client hasn't issued "ENABLE QRESYNC" in the current connection.
それがいったん認証されると、この拡大を利用するクライアントは「QRESYNCを有効にしてください」を発行しなければなりません。 SELECT/EXAMINEコマンドかVANISHED UID FETCH修飾語へのQRESYNCパラメタが指定されていて、クライアントが現在の接続における「QRESYNCを有効にしてください」を発行していないなら、サーバはタグ付けをされたBAD応答で反応しなければなりません。
This document puts additional requirements on a server implementing the [CONDSTORE] extension. Each mailbox that supports persistent storage of mod-sequences, i.e., for which the server has sent a HIGHESTMODSEQ untagged OK response code on a successful SELECT/ EXAMINE, MUST increment the per-mailbox mod-sequence when one or more messages are expunged due to EXPUNGE, UID EXPUNGE or CLOSE; the server MUST associate the incremented mod-sequence with the UIDs of the expunged messages.
このドキュメントは[CONDSTORE]拡大を実行するサーバに追加要件を置きます。 1つ以上のメッセージがEXPUNGE、UID EXPUNGEまたはCLOSEのため梢消されるとき、すなわち、サーバがHIGHESTMODSEQ untagged OK応答コードをうまくいっているSELECT/ EXAMINEに送ったもののために、モッズ系列のしつこい格納を支持する各メールボックスは1メールボックスあたりのモッズ系列を増加しなければなりません。 サーバは増加しているモッズ系列を梢消されたメッセージのUIDsに関連づけなければなりません。
A client that supports CONDSTORE but not this extension might resynchronize a mailbox and discover that its HIGHESTMODSEQ has increased from the value cached by the client. If the increase is only due to messages having been expunged since the client last synchronized, the client is likely to send a FETCH ... CHANGEDSINCE command that returns no data. Thus, a client that supports CONDSTORE
この拡大ではなく、CONDSTOREを支持するクライアントは、メールボックスを再連動させて、HIGHESTMODSEQがクライアントによってキャッシュされた値から増えたと発見するかもしれません。 クライアントが最後に連動して以来メッセージに梢消されていて、増加が当然であるだけであるなら、クライアントはFETCHを送りそうです… データを全く返さないCHANGEDSINCEコマンド。 その結果、CONDSTOREを支持するクライアント
Melnikov, et al. Standards Track [Page 3] RFC 5162 IMAP Quick Mailbox Resync March 2008
メリニコフ、他 規格は2008年のIMAPの迅速なメールボックスResync行進のときにRFC5162を追跡します[3ページ]。
but not this extension might incur a penalty of an unneeded round- trip when resynchronizing some mailboxes (those that have had messages expunged but no flag changes since the last synchronization).
しかし、いくつかのメールボックス(メッセージを梢消したものにもかかわらず、最後の同期以来の旗の変化がない)を再連動させるとき、どんなこの拡大も不要な丸い旅行の刑罰を被らないかもしれません。
This extra round-trip is only incurred by clients that support CONDSTORE but not this extension, and only when a mailbox has had messages expunged but no flag changes to non-expunged messages. Since CONDSTORE is a relatively new extension, it is thought likely that clients that support it will also support this extension.
これほどエキストラ往復であることは、この拡大ではなく、CONDSTOREを支持するクライアントによって被られるだけであっていつだけメールボックスでメッセージを梢消したか、しかし、非梢消されたメッセージへの旗の変化ではありません。 CONDSTOREが比較的新しい拡大であるので、また、それを支持するクライアントがこの拡大を支持するのはありそうであると考えられます。
2. Requirements Notation
2. 要件記法
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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
In examples, "C:" and "S:" indicate lines sent by the client and server respectively. If a single "C:" or "S:" label applies to multiple lines, then the line breaks between those lines are for editorial clarity only and are not part of the actual protocol exchange. The five characters [...] means that something has been elided.
例で「C:」 そして、「S:」 クライアントとサーバによってそれぞれ送られた線を示してください。 シングルである、「C:」 または、「S:」 ラベルが複数の線に適用されて、そして、それらの線の間のラインブレイクは、編集の明快だけためにあって、実際のプロトコル交換の一部ではありません。 5つのキャラクタ[…]が、何かが削除されたことを意味します。
Understanding of the IMAP message sequence numbers and UIDs and the EXPUNGE response [RFC3501] is essential when reading this document.
このドキュメントを読むとき、IMAPメッセージ通番とUIDsの理解とEXPUNGE応答[RFC3501]は不可欠です。
3. IMAP Protocol Changes
3. IMAPプロトコル変化
3.1. QRESYNC Parameter to SELECT/EXAMINE
3.1. 選択するか、または調べるQRESYNCパラメタ
The Quick Resynchronization parameter to SELECT/EXAMINE commands has four arguments:
SELECT/EXAMINEコマンドへのクィックResynchronizationパラメタには、4つの議論があります:
o the last known UIDVALIDITY,
o 最後に知られているUIDVALIDITY
o the last known modification sequence,
o 最後に知られている変更系列
o the optional set of known UIDs, and
o そして知られているUIDsの任意のセット。
o an optional parenthesized list of known sequence ranges and their
corresponding UIDs.
o 知られている系列範囲とそれらの対応するUIDsの任意のparenthesizedリスト。
A server MUST respond with a tagged BAD response if the Quick Resynchronization parameter to SELECT/EXAMINE command is specified and the client hasn't issued "ENABLE QRESYNC" in the current connection.
SELECT/EXAMINEコマンドへのクィックResynchronizationパラメタが指定されていて、クライアントが現在の接続における「QRESYNCを有効にしてください」を発行していないなら、サーバはタグ付けをされたBAD応答で反応しなければなりません。
Melnikov, et al. Standards Track [Page 4] RFC 5162 IMAP Quick Mailbox Resync March 2008
メリニコフ、他 規格は2008年のIMAPの迅速なメールボックスResync行進のときにRFC5162を追跡します[4ページ]。
Before opening the specified mailbox, the server verifies all arguments for syntactic validity. If any parameter is not syntactically valid, the server returns the tagged BAD response, and the mailbox remains unselected. Once the check is done, the server opens the mailbox as if no SELECT/EXAMINE parameters are specified (this is subject to processing of other parameters as defined in other extensions). In particular this means that the server MUST send all untagged responses as specified in Sections 6.3.1 and 6.3.2 of [RFC3501].
指定されたメールボックスを開ける前に、サーバは構文の正当性のためのすべての議論について確かめます。 何かパラメタがシンタクス上有効でないなら、サーバはタグ付けをされたBAD応答を返します、そして、メールボックスは選ばれていないままで残っています。 チェックがいったん完了していると、まるでSELECT/EXAMINEパラメタが全く指定されないかのように(これは他の拡大で定義されるように他のパラメタの処理を受けることがあります)サーバはメールボックスを開けます。 特に、サーバがすべての非タグ付けをされた応答を送らなければならないこの手段はセクション6.3.1に6.3に.2[RFC3501]を指定しました。
After that, the server checks the UIDVALIDITY value provided by the client. If the provided UIDVALIDITY doesn't match the UIDVALIDITY for the mailbox being opened, then the server MUST ignore the remaining parameters and behave as if no dynamic message data changed. The client can discover this situation by comparing the UIDVALIDITY value returned by the server. This behavior allows the client not to synchronize the mailbox or decide on the best synchronization strategy.
その後に、サーバはクライアントによって提供されたUIDVALIDITY値をチェックします。 提供されたUIDVALIDITYが開けられるメールボックスのためのUIDVALIDITYに合っていないなら、まるでどんなダイナミックなメッセージデータも変化しないかのように、サーバは、残っているパラメタを無視して、振る舞わなければなりません。 クライアントは、サーバによって返されたUIDVALIDITY値を比較することによって、この状況を発見できます。この振舞いで、クライアントは、メールボックスを連動させないか、または最も良い同期戦略を決めません。
Example: Attempting to resynchronize INBOX, but the provided
UIDVALIDITY parameter doesn't match the current UIDVALIDITY
value.
例: 再連動するのを試みて、しかし、受信トレイ、提供されたUIDVALIDITYパラメタは現在のUIDVALIDITY値に合っていません。
C: A02 SELECT INBOX (QRESYNC (67890007 20050715194045000
41,43:211,214:541))
S: * 464 EXISTS
S: * 3 RECENT
S: * OK [UIDVALIDITY 3857529045] UIDVALIDITY
S: * OK [UIDNEXT 550] Predicted next UID
S: * OK [HIGHESTMODSEQ 90060128194045007]
S: * OK [UNSEEN 12] Message 12 is first unseen
S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft
\Deleted \Seen \*)] Permanent flags
S: A02 OK [READ-WRITE] Sorry, UIDVALIDITY mismatch
C: A02は受信トレイ(QRESYNC(67890007 20050715194045000 41、43:21万1214:541))Sを選択します: * 464が存在している、S: * 3、最近のS: * OK[UIDVALIDITY3857529045]UIDVALIDITY S: * OK[UIDNEXT550]は次のUID Sを予測しました: * OK[HIGHESTMODSEQ90060128194045007]S: * OK[UNSEEN12]メッセージ12は最初に、見えないSです: * 旗(\旗を揚げさせられた\草稿\に答えた\は見られた\を削除した)のS: * OK[PERMANENTFLAGS(\Answered\Flagged\Draft\Deleted\Seen\*)]の永久的な旗S: 残念なA02 OK[READ-WRITE]UIDVALIDITYミスマッチ
Modification Sequence and UID Parameters:
変更系列とUIDパラメタ:
A server that doesn't support the persistent storage of mod-sequences for the mailbox MUST send the OK untagged response including the NOMODSEQ response code with every successful SELECT or EXAMINE command, as described in [CONDSTORE]. Such a server doesn't need to remember mod-sequences for expunged messages in the mailbox. It MUST ignore the remaining parameters and behave as if no dynamic message data changed.
メールボックスがOKを送らなければならないので、モッズ系列のしつこい格納を支持しないサーバはあらゆるうまくいっているSELECTかEXAMINEコマンドのときにNOMODSEQ応答コードを含む応答に非タグ付けをしました、[CONDSTORE]で説明されるように。 そのようなサーバはメールボックスの中の梢消されたメッセージのためにモッズ系列を覚えている必要はありません。 まるでどんなダイナミックなメッセージデータも変化しないかのように、それは、残っているパラメタを無視して、反応しなければなりません。
If the provided UIDVALIDITY matches that of the selected mailbox, the server then checks the last known modification sequence.
提供されたUIDVALIDITYが選択されたメールボックスのものに合っているなら、サーバは最後に知られている変更系列をチェックします。
Melnikov, et al. Standards Track [Page 5] RFC 5162 IMAP Quick Mailbox Resync March 2008
メリニコフ、他 規格は2008年のIMAPの迅速なメールボックスResync行進のときにRFC5162を追跡します[5ページ]。
The server sends the client any pending flag changes (using FETCH responses that MUST contain UIDs) and expunges those that have occurred in this mailbox since the provided modification sequence.
サーバは、どんな未定の旗の変化(UIDsを含まなければならないFETCH応答を使用する)もクライアントに送って、提供された変更系列以来このメールボックスの中に起こっているものを梢消します。
If the list of known UIDs was also provided, the server should only report flag changes and expunges for the specified messages. If the client did not provide the list of UIDs, the server acts as if the client has specified "1:<maxuid>", where <maxuid> is the mailbox's UIDNEXT value minus 1. If the mailbox is empty and never had any messages in it, then lack of the list of UIDs is interpreted as an empty set of UIDs.
また、知られているUIDsのリストを提供するなら、サーバは、旗が指定されたメッセージのために変えて、梢消すると報告するだけでしょうに。 クライアントがUIDsのリストを提供しなかったなら、まるでクライアントが1を引いて「1: <は>をmaxuidします」、<maxuid>がメールボックスのUIDNEXTであるところで値を指定したかのようにサーバは行動します。 メールボックスが空であり、それに何かメッセージを決して持っていなかったなら、UIDsのリストの不足はUIDsの空集合として解釈されます。
Thus, the client can process just these pending events and need not perform a full resynchronization. Without the message sequence number matching information, the result of this step is semantically equivalent to the client issuing: tag1 UID FETCH "known-uids" (FLAGS) (CHANGEDSINCE "mod-sequence-value" VANISHED)
したがって、クライアントは、まさしくこれらの未定の出来事を処理できて、完全な再同期を実行する必要はありません。 メッセージ通番の合っている情報がなければ、このステップの結果はクライアント発行に意味的に同等です: tag1 UID FETCH「知られているuids」(FLAGS)(「モッズ系列価値」が消えさせたCHANGEDSINCE)
Example:
C: A03 SELECT INBOX (QRESYNC (67890007
90060115194045000 41,43:211,214:541))
S: * OK [CLOSED]
S: * 314 EXISTS
S: * 15 RECENT
S: * OK [UIDVALIDITY 67890007] UIDVALIDITY
S: * OK [UIDNEXT 567] Predicted next UID
S: * OK [HIGHESTMODSEQ 90060115205545359]
S: * OK [UNSEEN 7] There are some unseen messages in the mailbox
S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft
\Deleted \Seen \*)] Permanent flags
S: * VANISHED (EARLIER) 41,43:116,118,120:211,214:540
S: * 49 FETCH (UID 117 FLAGS (\Seen \Answered) MODSEQ
(90060115194045001))
S: * 50 FETCH (UID 119 FLAGS (\Draft $MDNSent) MODSEQ
(90060115194045308))
S: ...
S: * 100 FETCH (UID 541 FLAGS (\Seen $Forwarded) MODSEQ
(90060115194045001))
S: A03 OK [READ-WRITE] mailbox selected
例: C: A03は受信トレイ(QRESYNC(67890007 90060115194045000 41、43:21万1214:541))Sを選択します: * OK[閉じられる]S: * 314が存在している、S: * 15、最近のS: * OK[UIDVALIDITY67890007]UIDVALIDITY S: * OK[UIDNEXT567]は次のUID Sを予測しました: * OK[HIGHESTMODSEQ90060115205545359]S: * そこのOK[UNSEEN7]はメールボックスSの中のいくつかの見えないメッセージです: * 旗(\旗を揚げさせられた\草稿\に答えた\は見られた\を削除した)のS: * OK[PERMANENTFLAGS(\Answered\Flagged\Draft\Deleted\Seen\*)]の永久的な旗S: * 消える(以前)の41、43:1億1611万8120:21万1214:540秒間: * 49がとって来る、(UID117はMODSEQ(90060115194045001))Sに旗を揚げさせます(目にふれている\が答えた\): * 50がとって来る、(UID119は(\草稿$MDNSent)MODSEQ(90060115194045308))Sに旗を揚げさせます: ... S: * 100がとって来る、(UID541はMODSEQ(90060115194045001))Sに旗を揚げさせます(目にふれている$が進めた\): 選択されたA03 OK[READ-WRITE]メールボックス
Message sequence match data:
メッセージ系列マッチデータ:
A client MAY provide a parenthesized list of a message sequence set and the corresponding UID sets. Both MUST be provided in ascending order. The server uses this data to restrict the range for which it provides expunged message information.
クライアントはメッセージシーケンスセットのparenthesizedリストと対応するUIDセットを提供するかもしれません。 昇順に両方を提供しなければなりません。 サーバは、それが梢消されたメッセージ情報を提供する範囲を制限するのにこのデータを使用します。
Melnikov, et al. Standards Track [Page 6] RFC 5162 IMAP Quick Mailbox Resync March 2008
メリニコフ、他 規格は2008年のIMAPの迅速なメールボックスResync行進のときにRFC5162を追跡します[6ページ]。
Conceptually, the client provides a small sample of sequence numbers for which it knows the corresponding UIDs. The server then compares each sequence number and UID pair the client provides with the current state of the mailbox. If a pair matches, then the client knows of any expunges up to, and including, the message, and thus will not include that range in the VANISHED response, even if the "mod-sequence-value" provided by the client is too old for the server to have data of when those messages were expunged.
概念的に、クライアントはそれが対応するUIDsを知っている一連番号に関する小標本を提供します。 そして、サーバはクライアントがメールボックスの現状に提供するそれぞれの一連番号とUID組を比較します。 1組が合っているならクライアントがいずれも知っている、梢消、密かに企ててください。そうすれば、包含、メッセージ、およびその結果、意志はVANISHED応答にその範囲を含んでいません、クライアントによって提供された「モッズ系列価値」がサーバがそれらのメッセージが梢消された時に関するデータを持つことができないくらい古くても。
Thus, if the Nth message number in the first set in the list is 4, and the Nth UID in the second set in the list is 8, and the mailbox's fourth message has UID 8, then no UIDs equal to or less than 8 are present in the VANISHED response. If the (N+1)th message number is 12, and the (N+1)th UID is 24, and the (N+1)th message in the mailbox has UID 25, then the lowest UID included in the VANISHED response would be 9.
その結果、そして、VANISHED応答におけるUIDs同輩でない8より少ないプレゼントがありませんリストの第一セットのNthメッセージ番号が4であり、リストにおける2番目のセットにおけるNth UIDが8歳であり、メールボックスの4番目のメッセージがUID8を持っているなら。 そして、そして、(N+1)、メッセージ番号が12番目である、(N+1)、UIDが24番目である、(N+1)、メールボックスの中のメッセージにはUID25があって、そして、VANISHED応答に最も低いUIDを含むのは、9番目でしょう。
In the following two examples, the server is unable to remember expunges at all, and only UIDs with messages divisible by three are present in the mailbox. In the first example, the client does not use the fourth parameter; in the second, it provides it. This example is somewhat extreme, but shows that judicious usage of the sequence match data can save a substantial amount of bandwidth.
以下の2つの例、サーバが覚えていることができないコネはUIDsだけを梢消します。3で分割可能なメッセージと共に、メールボックスの中のプレゼントがあります。 最初の例では、クライアントは4番目のパラメタを使用しません。 2番目に、それはそれを提供します。 この例は、いくらか極端ですが、系列マッチデータの賢明な用法がかなりの量の帯域幅を救うことができるのを示します。
Example:
C: A04 SELECT INBOX (QRESYNC (67890007
90060115194045000 1:29997))
S: * 10003 EXISTS
S: * 5 RECENT
S: * OK [UIDVALIDITY 67890007] UIDVALIDITY
S: * OK [UIDNEXT 30013] Predicted next UID
S: * OK [HIGHESTMODSEQ 90060115205545359]
S: * OK [UNSEEN 7] There are some unseen messages in the mailbox
S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft
\Deleted \Seen \*)] Permanent flags
S: * VANISHED (EARLIER) 1:2,4:5,7:8,10:11,13:14 [...]
29998:29999,30001:30002,30004:30005,30007:30008
S: * 9889 FETCH (UID 29667 FLAGS (\Seen \Answered) MODSEQ
(90060115194045027))
S: * 9890 FETCH (UID 29670 FLAGS (\Draft $MDNSent) MODSEQ
(90060115194045028))
S: ...
S: * 9999 FETCH (UID 29997 FLAGS (\Seen $Forwarded) MODSEQ
(90060115194045031))
S: A04 OK [READ-WRITE] mailbox selected
例: C: A04の選んだ受信トレイ、(QRESYNC、(67890007 90060115194045000、1:29997)、S: * 10003が存在している、S: * 5、最近のS: * OK[UIDVALIDITY67890007]UIDVALIDITY S: * OK[UIDNEXT30013]は次のUID Sを予測しました: * OK[HIGHESTMODSEQ90060115205545359]S: * そこのOK[UNSEEN7]はメールボックスSの中のいくつかの見えないメッセージです: * 旗(\旗を揚げさせられた\草稿\に答えた\は見られた\を削除した)のS: * OK[PERMANENTFLAGS(\Answered\Flagged\Draft\Deleted\Seen\*)]の永久的な旗S: * (以前)の1:2、4:5、7:8、10:11、13:14[…]を消えさせます。 29998:29999 30001:30002 30004:30005 30007 : 30008秒間: * 9889がとって来る、(UID29667はMODSEQ(90060115194045027))Sに旗を揚げさせます(目にふれている\が答えた\): * 9890がとって来る、(UID29670は(\草稿$MDNSent)MODSEQ(90060115194045028))Sに旗を揚げさせます: ... S: * 9999がとって来る、(UID29997はMODSEQ(90060115194045031))Sに旗を揚げさせます(目にふれている$が進めた\): 選択されたA04 OK[READ-WRITE]メールボックス
Melnikov, et al. Standards Track [Page 7] RFC 5162 IMAP Quick Mailbox Resync March 2008
メリニコフ、他 規格は2008年のIMAPの迅速なメールボックスResync行進のときにRFC5162を追跡します[7ページ]。
Example:
C: B04 SELECT INBOX (QRESYNC (67890007
90060115194045000 1:29997 (5000,7500,9000,9990:9999 15000,
22500,27000,29970,29973,29976,29979,29982,29985,29988,29991,
29994,29997)))
S: * 10003 EXISTS
S: * 5 RECENT
S: * OK [UIDVALIDITY 67890007] UIDVALIDITY
S: * OK [UIDNEXT 30013] Predicted next UID
S: * OK [HIGHESTMODSEQ 90060115205545359]
S: * OK [UNSEEN 7] There are some unseen messages in the mailbox
S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft
\Deleted \Seen \*)] Permanent flags
S: * VANISHED (EARLIER) 29998:29999,30001:30002,30004:30005,30007:
30008
S: * 9889 FETCH (UID 29667 FLAGS (\Seen \Answered) MODSEQ
(90060115194045027))
S: * 9890 FETCH (UID 29670 FLAGS (\Draft $MDNSent) MODSEQ
(90060115194045028))
S: ...
S: * 9999 FETCH (UID 29997 FLAGS (\Seen $Forwarded) MODSEQ
(90060115194045031))
S: B04 OK [READ-WRITE] mailbox selected
例: C: B04の選んだ受信トレイ、(QRESYNC、(67890007 90060115194045000、1:29997、(5000、7500、9000、9990、: 9999 15000、22500、27000、29970、29973、29976、29979、29982、29985、29988、29991、29994、29997、)S: * 10003が存在している、S: * 5、最近のS: * OK[UIDVALIDITY67890007]UIDVALIDITY S: * OK[UIDNEXT30013]は次のUID Sを予測しました: * OK[HIGHESTMODSEQ90060115205545359]S: * そこのOK[UNSEEN7]はメールボックスSの中のいくつかの見えないメッセージです: * 旗(\旗を揚げさせられた\草稿\に答えた\は見られた\を削除した)のS: * OK[PERMANENTFLAGS(\Answered\Flagged\Draft\Deleted\Seen\*)]の永久的な旗S: * 消え失せる、(より早くに) 29998:29999 30001:30002 30004: 30005、30007: 30008秒間: * 9889がとって来る、(UID29667はMODSEQ(90060115194045027))Sに旗を揚げさせます(目にふれている\が答えた\): * 9890がとって来る、(UID29670は(\草稿$MDNSent)MODSEQ(90060115194045028))Sに旗を揚げさせます: ... S: * 9999がとって来る、(UID29997はMODSEQ(90060115194045031))Sに旗を揚げさせます(目にふれている$が進めた\): 選択されたB04 OK[READ-WRITE]メールボックス
3.2. VANISHED UID FETCH Modifier
3.2. 消えているUIDは修飾語をとって来ます。
[IMAPABNF] has extended the syntax of the FETCH and UID FETCH commands to include an optional FETCH modifier. This document defines a new UID FETCH modifier: VANISHED.
[IMAPABNF]はFETCHと任意のFETCH修飾語を含むUID FETCHコマンドの構文を広げました。 このドキュメントは新しいUID FETCH修飾語を定義します: 消える。
Note, that the VANISHED UID FETCH modifier is NOT allowed with a FETCH command. The server MUST return a tagged BAD response if this response is specified as a modifier to the FETCH command.
VANISHED UID FETCH修飾語がFETCHコマンドで許容されていないというメモ。 この応答が修飾語としてFETCHコマンドに指定されるなら、サーバはタグ付けをされたBAD応答を返さなければなりません。
A server MUST respond with a tagged BAD response if the VANISHED UID FETCH modifier is specified and the client hasn't issued "ENABLE QRESYNC" in the current connection.
VANISHED UID FETCH修飾語が指定されていて、クライアントが現在の接続における「QRESYNCを有効にしてください」を発行していないなら、サーバはタグ付けをされたBAD応答で反応しなければなりません。
The VANISHED UID FETCH modifier MUST only be specified together with the CHANGEDSINCE UID FETCH modifier.
CHANGEDSINCE UID FETCH修飾語と共にVANISHED UID FETCH修飾語を指定するだけでよいです。
The VANISHED UID FETCH modifier instructs the server to report those messages from the UID set parameter that have been expunged and whose associated mod-sequence is larger than the specified mod-sequence. That is, the client requests to be informed of messages from the specified set that were expunged since the specified mod-sequence. Note that the mod-sequence(s) associated with these messages were
VANISHED UID FETCH修飾語は、梢消されて、関連モッズ系列が指定されたモッズ系列より大きいUIDセットパラメタからそれらのメッセージを報告するようサーバに命令します。 すなわち、クライアントは、指定されたセットからのメッセージにおいて知識があるために、指定されたモッズ系列以来それが梢消されたよう要求します。 これらのメッセージに関連しているモッズ系列がそうであったことに注意してください。
Melnikov, et al. Standards Track [Page 8] RFC 5162 IMAP Quick Mailbox Resync March 2008
メリニコフ、他 規格は2008年のIMAPの迅速なメールボックスResync行進のときにRFC5162を追跡します[8ページ]。
updated when the messages were expunged (as described above). The expunged messages are reported using the VANISHED response as described in Section 3.6, which MUST contain the EARLIER tag. Any VANISHED (EARLIER) responses MUST be returned before any FETCH responses, as otherwise the client might get confused about how message numbers map to UIDs.
メッセージを梢消したとき(上で説明されるように)、アップデートします。 梢消されたメッセージは、セクション3.6(EARLIERタグを含まなければなりません)で説明されるようにVANISHED応答を使用することで報告されます。 どんなFETCH応答の前にもどんなVANISHED(EARLIER)応答も返さなければなりません、さもなければ、メッセージがどう地図に付番するかに関してクライアントがUIDsに混乱させるかもしれないとき。
Note: A server that receives a mod-sequence smaller than <minmodseq>, where <minmodseq> is the value of the smallest expunged mod-sequence it remembers minus one, MUST behave as if it was requested to report all expunged messages from the provided UID set parameter.
以下に注意してください。 まるですべてを報告するよう要求されているかのように<minmodseq>が<minmodseq>が1を引いて覚えている中で最も小さい梢消されたモッズ系列の値であるところで反応しなければならないより小さくモッズ系列を受け取るサーバは提供されたUIDセットパラメタからのメッセージを梢消しました。
Example 1: Without the VANISHED UID FETCH modifier, a CONDSTORE-aware client [CONDSTORE] needs to issue separate commands to learn of flag changes and expunged messages since the last synchronization:
例1: VANISHED UID FETCH修飾語がなければ、CONDSTORE意識しているクライアント[CONDSTORE]は、最後の同期以来の旗の変化と梢消されたメッセージを知る別々のコマンドを発行する必要があります:
C: s100 UID FETCH 300:500 (FLAGS) (CHANGEDSINCE 12345)
S: * 1 FETCH (UID 404 MODSEQ (65402) FLAGS (\Seen))
S: * 2 FETCH (UID 406 MODSEQ (75403) FLAGS (\Deleted))
S: * 4 FETCH (UID 408 MODSEQ (29738) FLAGS ($NoJunk
$AutoJunk $MDNSent))
S: s100 OK FETCH completed
C: s101 UID SEARCH 300:500
S: * SEARCH 404 406 407 408 410 412
S: s101 OK search completed
C: s100 UID FETCH300: 500 (FLAGS)(CHANGEDSINCE12345)S: * 1 フェッチ(UID404MODSEQ(65402)旗(見られた\))S: * 2は(UID406MODSEQ(75403)旗(削除された\))にSをとって来ます: * 4は(UID408MODSEQ(29738)旗($NoJunk$AutoJunk$MDNSent))にSをとって来ます: s100OK FETCHはCを完成しました: s101 UID検索300: 500秒間: * 412秒間の検索404 406 407 408 410: OK検索が完成したs101
Where 300 and 500 are the lowest and highest UIDs from client's cache. The second SEARCH response tells the client that the messages with UIDs 407, 410, and 412 are still present, but their flags haven't changed since the specified modification sequence.
300と500がクライアントのキャッシュからの最も低くて最も高いUIDsであるところ。 2番目の検索応答は、UIDs407、410、および412があるメッセージがまだ存在していますが、指定された変更系列以来彼らの旗が今まで変わっていないとクライアントに言います。
Using the VANISHED UID FETCH modifier, it is sufficient to issue only a single command:
VANISHED UID FETCH修飾語を使用して、ただ一つのコマンドだけを発行するのは十分です:
C: s100 UID FETCH 300:500 (FLAGS) (CHANGEDSINCE 12345
VANISHED)
S: * VANISHED (EARLIER) 300:310,405,411
S: * 1 FETCH (UID 404 MODSEQ (65402) FLAGS (\Seen))
S: * 2 FETCH (UID 406 MODSEQ (75403) FLAGS (\Deleted))
S: * 4 FETCH (UID 408 MODSEQ (29738) FLAGS ($NoJunk
$AutoJunk $MDNSent))
S: s100 OK FETCH completed
C: s100 UID FETCH300: 500 (FLAGS)(CHANGEDSINCE12345VANISHED)S: * : 310,405,411秒間、(以前)の300を消えさせます: * 1 フェッチ(UID404MODSEQ(65402)旗(見られた\))S: * 2は(UID406MODSEQ(75403)旗(削除された\))にSをとって来ます: * 4は(UID408MODSEQ(29738)旗($NoJunk$AutoJunk$MDNSent))にSをとって来ます: OK FETCHが完成したs100
Melnikov, et al. Standards Track [Page 9] RFC 5162 IMAP Quick Mailbox Resync March 2008
メリニコフ、他 規格は2008年のIMAPの迅速なメールボックスResync行進のときにRFC5162を追跡します[9ページ]。
3.3. EXPUNGE Command
3.3. 梢消コマンド
Arguments: none
議論: なし
Responses: untagged responses: EXPUNGE or VANISHED
応答: 非タグ付けをされた応答: 梢消するか、または消えます。
Result: OK - expunge completed
NO - expunge failure: can't expunge (e.g., permission denied)
BAD - command unknown or arguments invalid
結果: OK--完成したノーを梢消してください--失敗を梢消してください: BADを梢消できません(例えば否定された許可)--未知か議論病人を命令してください。
This section updates the definition of the EXPUNGE command described in Section 6.4.3 of [RFC3501].
このセクションは.3セクション6.4[RFC3501]で説明されたEXPUNGEコマンドの定義をアップデートします。
The EXPUNGE command permanently removes all messages that have the \Deleted flag set from the currently selected mailbox. Before returning an OK to the client, those messages that are removed are reported using a VANISHED response or EXPUNGE responses.
EXPUNGEコマンドは永久に、Deleted旗が現在選択されたメールボックスから設定した\を持っているすべてのメッセージを取り除きます。 OKをクライアントに返す前に、取り除かれるそれらのメッセージは、VANISHED応答かEXPUNGE応答を使用することで報告されます。
If the server is capable of storing modification sequences for the selected mailbox, it MUST increment the per-mailbox mod-sequence if at least one message was permanently removed due to the execution of the EXPUNGE command. For each permanently removed message, the server MUST remember the incremented mod-sequence and corresponding UID. If at least one message got expunged, the server MUST send the updated per-mailbox modification sequence using the HIGHESTMODSEQ response code (defined in [CONDSTORE]) in the tagged OK response.
サーバが選択されたメールボックスのために変更系列を格納できるなら、少なくとも1つのメッセージが永久にEXPUNGEコマンドの実行のため取り除かれたなら、それは1メールボックスあたりのモッズ系列を増加しなければなりません。 それぞれの永久に取り除かれたメッセージに関しては、サーバは増加しているモッズ系列と対応するUIDを覚えていなければなりません。 少なくとも1つのメッセージが梢消されたなら、タグ付けをされたOK応答にHIGHESTMODSEQ応答コード([CONDSTORE]では、定義される)を使用して、サーバは1メールボックスあたりのアップデートされた変更系列を送らなければなりません。
Example: C: A202 EXPUNGE
S: * 3 EXPUNGE
S: * 3 EXPUNGE
S: * 5 EXPUNGE
S: * 8 EXPUNGE
S: A202 OK [HIGHESTMODSEQ 20010715194045319] expunged
例: C: A202はSを梢消します: * 3 Sを梢消してください: * 3 Sを梢消してください: * 5 Sを梢消してください: * 8 Sを梢消してください: 梢消されたA202 OK[HIGHESTMODSEQ20010715194045319]
Note: In this example, messages 3, 4, 7, and 11 had the \Deleted flag set. The first "* 3 EXPUNGE" reports message # 3 as expunged. The second "* 3 EXPUNGE" reports message # 4 as expunged (the message number got decremented due to the previous EXPUNGE response). See the description of the EXPUNGE response in [RFC3501] for further explanation.
以下に注意してください。 この例では、メッセージ3、4、7、および11はDeleted旗が設定した\を持っていました。 「」 *3が梢消する1番目」は梢消されるようにメッセージ#3を報告します。 *3が梢消されるように」 レポートメッセージ#4を梢消する(前のため数で減少したメッセージは応答を梢消します)「秒。」 詳細な説明に関して[RFC3501]のEXPUNGE応答の記述を見てください。
Note that if the server chooses to always send VANISHED responses instead of EXPUNGE responses, the previous example might look like this:
サーバが、いつもEXPUNGE応答の代わりに応答をVANISHEDに送るのを選ぶなら、前の例がこれに似るかもしれないことに注意してください:
Example: C: B202 EXPUNGE
S: * VANISHED 405,407,410,425
S: B202 OK [HIGHESTMODSEQ 20010715194045319] expunged
例: C: B202はSを梢消します: * 消える405,407,410,425秒間: 梢消されたB202 OK[HIGHESTMODSEQ20010715194045319]
Melnikov, et al. Standards Track [Page 10] RFC 5162 IMAP Quick Mailbox Resync March 2008
メリニコフ、他 規格は2008年のIMAPの迅速なメールボックスResync行進のときにRFC5162を追跡します[10ページ]。
Here messages with message numbers 3, 4, 7, and 11 have respective UIDs 405, 407, 410, and 425.
ここに、メッセージ番号3、4、7、および11があるメッセージはそれぞれのUIDs405、407、410、および425を持っています。
3.4. CLOSE Command
3.4. 閉鎖コマンド
Arguments: none
議論: なし
Responses: no specific responses for this command
応答: このコマンドのための特定の応答がありません。
Result: OK - close completed, now in authenticated state
BAD - command unknown or arguments invalid
結果: OK--現在、認証された州のBADで完成した閉鎖--コマンド未知か議論病人
This section updates the definition of the CLOSE command described in Section 6.4.2 of [RFC3501].
このセクションは.2セクション6.4[RFC3501]で説明されたCLOSEコマンドの定義をアップデートします。
The CLOSE command permanently removes all messages that have the \Deleted flag set from the currently selected mailbox, and returns to the authenticated state from the selected state. No untagged EXPUNGE (or VANISHED) responses are sent.
CLOSEコマンドは、永久にDeleted旗が現在選択されたメールボックスから設定した\を持っているすべてのメッセージを取り除いて、選択された状態から認証された状態に戻ります。 untagged EXPUNGE(または、VANISHED)応答を全く送りません。
If the server is capable of storing modification sequences for the selected mailbox, it MUST increment the per-mailbox mod-sequence if at least one message was permanently removed due to the execution of the CLOSE command. For each permanently removed message, the server MUST remember the incremented mod-sequence and corresponding UID. If at least one message got expunged, the server MUST send the updated per-mailbox modification sequence using the HIGHESTMODSEQ response code (defined in [CONDSTORE]) in the tagged OK response.
サーバが選択されたメールボックスのために変更系列を保存できるなら、少なくとも1つのメッセージが永久にCLOSEコマンドの実行のため取り除かれたなら、それは1メールボックスあたりのモッズ系列を増加しなければなりません。 それぞれの永久に取り除かれたメッセージに関しては、サーバは増加しているモッズ系列と対応するUIDを覚えていなければなりません。 少なくとも1つのメッセージが梢消されたなら、タグ付けをされたOK応答にHIGHESTMODSEQ応答コード([CONDSTORE]では、定義される)を使用して、サーバは1メールボックスあたりのアップデートされた変更系列を送らなければなりません。
Example: C: A202 CLOSE
S: A202 OK [HIGHESTMODSEQ 20010715194045319] done
例: C: A202はSを閉じます: 行われたA202 OK[HIGHESTMODSEQ20010715194045319]
3.5. UID EXPUNGE Command
3.5. UID梢消コマンド
Arguments: message set
議論: メッセージセット
Responses: untagged responses: EXPUNGE or VANISHED
応答: 非タグ付けをされた応答: 梢消するか、または消えます。
Result: OK - expunge completed
NO - expunge failure: can't expunge (e.g., permission denied)
BAD - command unknown or arguments invalid
結果: OK--完成したノーを梢消してください--失敗を梢消してください: BADを梢消できません(例えば否定された許可)--未知か議論病人を命令してください。
This section updates the definition of the UID EXPUNGE command described in Section 2.1 of [UIDPLUS]. Servers that implement both [UIDPLUS] and QRESYNC extensions must implement UID EXPUNGE as described in this section.
このセクションは[UIDPLUS]のセクション2.1で説明されたUID EXPUNGEコマンドの定義をアップデートします。 両方[UIDPLUS]とQRESYNCが拡大であると実装するサーバはこのセクションで説明されるようにUID EXPUNGEを実装しなければなりません。
Melnikov, et al. Standards Track [Page 11] RFC 5162 IMAP Quick Mailbox Resync March 2008
メリニコフ、他 規格は2008年のIMAPの迅速なメールボックスResync行進のときにRFC5162を追跡します[11ページ]。
The UID EXPUNGE command permanently removes from the currently selected mailbox all messages that both have the \Deleted flag set and have a UID that is included in the specified message set. If a message either does not have the \Deleted flag set or has a UID that is not included in the specified message set, it is not affected.
UID EXPUNGEコマンドは永久に、現在選択されたメールボックスから両方がDeleted旗が設定した\を持っていて、指定されたメッセージセットに含まれているUIDを持っているというすべてのメッセージを取り除きます。 メッセージがDeleted旗が設定した\を持っていないか、または指定されたメッセージセットに含まれていないUIDを持っているなら、影響を受けません。
This command is particularly useful for disconnected mode clients. By using UID EXPUNGE instead of EXPUNGE when resynchronizing with the server, the client can avoid inadvertently removing any messages that have been marked as \Deleted by other clients between the time that the client was last connected and the time the client resynchronizes.
このコマンドは特に切断しているモードクライアントの役に立ちます。 サーバで再連動するときEXPUNGEの代わりにUID EXPUNGEを使用することによって、クライアントは、うっかり\Deletedとしてクライアントが最後に接された時、クライアントが再連動する時の間の他のクライアントによってマークされたどんなメッセージも取り除くのを避けることができます。
Before returning an OK to the client, those messages that are removed are reported using a VANISHED response or EXPUNGE responses.
OKをクライアントに返す前に、取り除かれるそれらのメッセージは、VANISHED応答かEXPUNGE応答を使用することで報告されます。
If the server is capable of storing modification sequences for the selected mailbox, it MUST increment the per-mailbox mod-sequence if at least one message was permanently removed due to the execution of the UID EXPUNGE command. For each permanently removed message, the server MUST remember the incremented mod-sequence and corresponding UID. If at least one message got expunged, the server MUST send the updated per-mailbox modification sequence using the HIGHESTMODSEQ response code (defined in [CONDSTORE]) in the tagged OK response.
サーバが選択されたメールボックスのために変更系列を保存できるなら、少なくとも1つのメッセージが永久にUID EXPUNGEコマンドの実行のため取り除かれたなら、それは1メールボックスあたりのモッズ系列を増加しなければなりません。 それぞれの永久に取り除かれたメッセージに関しては、サーバは増加しているモッズ系列と対応するUIDを覚えていなければなりません。 少なくとも1つのメッセージが梢消されたなら、タグ付けをされたOK応答にHIGHESTMODSEQ応答コード([CONDSTORE]では、定義される)を使用して、サーバは1メールボックスあたりのアップデートされた変更系列を送らなければなりません。
Example: C: . UID EXPUNGE 3000:3002
S: * 3 EXPUNGE
S: * 3 EXPUNGE
S: * 3 EXPUNGE
S: . OK [HIGHESTMODSEQ 20010715194045319] Ok
例: C: . UIDは: 3002秒間、3000を梢消します: * 3 Sを梢消してください: * 3 Sを梢消してください: * 3 Sを梢消してください: . OKに[HIGHESTMODSEQ20010715194045319]を承認してください。
Note: In this example, at least messages with message numbers 3, 4, and 5 (UIDs 3000 to 3002) had the \Deleted flag set. The first "* 3 EXPUNGE" reports message # 3 as expunged. The second "* 3 EXPUNGE" reports message # 4 as expunged (the message number got decremented due to the previous EXPUNGE response). See the description of the EXPUNGE response in [RFC3501] for further explanation.
以下に注意してください。 この例では、少なくともメッセージ番号3、4、および5(UIDs3000年から3002)があるメッセージはDeleted旗が設定した\を持っていました。 「」 *3が梢消する1番目」は梢消されるようにメッセージ#3を報告します。 *3が梢消されるように」 レポートメッセージ#4を梢消する(前のため数で減少したメッセージは応答を梢消します)「秒。」 詳細な説明に関して[RFC3501]のEXPUNGE応答の記述を見てください。
3.6. VANISHED Response
3.6. 消えている応答
Contents: an optional EARLIER tag
コンテンツ: 任意のEARLIERタグ
list of UIDs
UIDsのリスト
The VANISHED response reports that the specified UIDs have been permanently removed from the mailbox. This response is similar to the EXPUNGE response [RFC3501]; however, it can return information about multiple messages, and it returns UIDs instead of message
VANISHED応答は、指定されたUIDsが永久にメールボックスから取り外されたと報告します。 この応答はEXPUNGE応答[RFC3501]と同様です。 しかしながら、複数のメッセージの情報を返すことができます、そして、メッセージの代わりにUIDsを返します。
Melnikov, et al. Standards Track [Page 12] RFC 5162 IMAP Quick Mailbox Resync March 2008
メリニコフ、他 規格は2008年のIMAPの迅速なメールボックスResync行進のときにRFC5162を追跡します[12ページ]。
numbers. The first benefit saves bandwidth, while the second is more convenient for clients that only use UIDs to access the IMAP server.
数。 最初の利益は帯域幅を保存します、IMAPサーバにアクセスするのにUIDsを使用するだけであるクライアントは2番目が、より都合がよいのですが。
The VANISHED response has the same restrictions on when it can be sent as does the EXPUNGE response (see below).
VANISHED応答には、EXPUNGE応答のようにそれを送ることができる(以下を見てください)時に関する同じ制限があります。
The VANISHED response has two forms. The first form contains the EARLIER tag, which signifies that the response was caused by a UID FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) command. This response is sent if the UID set parameter to the UID FETCH (VANISHED) command includes UIDs of messages that are no longer in the mailbox. When the client sees a VANISHED EARLIER response, it MUST NOT decrement message sequence numbers for each successive message in the mailbox.
VANISHED応答には、2つのフォームがあります。最初のフォームはEARLIERタグを含んでいます。(それは、応答がUID FETCH(VANISHED)かSELECT/EXAMINE(QRESYNC)コマンドで引き起こされたのを意味します)。 UID FETCH(VANISHED)コマンドへのUIDセットパラメタがもうメールボックスの中ではなくあるメッセージのUIDsを含んでいるなら、この応答を送ります。 クライアントがVANISHED EARLIER応答を見るとき、それはメールボックスの中のそれぞれの連続したメッセージのためにメッセージ通番を減少させてはいけません。
The second form doesn't contain the EARLIER tag and is described below. Once a client has issued "ENABLE QRESYNC", the server SHOULD use the VANISHED response without the EARLIER tag instead of the EXPUNGE response. The server SHOULD continue using VANISHED in lieu of EXPUNGE for the duration of the connection. In particular, this affects the EXPUNGE [RFC3501] and UID EXPUNGE [UIDPLUS] commands, as well as messages expunged in other connections. Such a VANISHED response MUST NOT contain the EARLIER tag.
2番目のフォームは、EARLIERタグを含んでいなくて、以下で説明されます。 の代わりにする、クライアントがいったん「QRESYNCを有効にしてください」を発行する後、サーバが以前のタグなしで消えている応答を使用するべきである、応答を梢消してください。 サーバSHOULDは、接続の持続時間のためのEXPUNGEの代わりにVANISHEDを使用し続けています。 特に、これはEXPUNGE[RFC3501]とUID EXPUNGE[UIDPLUS]コマンド、および他の接続で梢消されたメッセージに影響します。 そのようなVANISHED応答はEARLIERタグを含んではいけません。
A VANISHED response sent because of an EXPUNGE or UID EXPUNGE command or because messages were expunged in other connections (i.e., the VANISHED response without the EARLIER tag) also decrements the number of messages in the mailbox; it is not necessary for the server to send an EXISTS response with the new value. It also decrements message sequence numbers for each successive message in the mailbox (see the example at the end of this section). Note that a VANISHED response caused by EXPUNGE, UID EXPUNGE, or messages expunged in other connections SHOULD only contain UIDs for messages expunged since the last VANISHED/EXPUNGE response sent for the currently opened mailbox or since the mailbox was opened. That is, servers SHOULD NOT send UIDs for previously expunged messages, unless explicitly requested to do so by the UID FETCH (VANISHED) command.
また、EXPUNGEかUID EXPUNGEコマンドのためメッセージが他の接続(すなわち、EARLIERタグのないVANISHED応答)で梢消されたことので送られたVANISHED応答はメールボックスの中のメッセージの数を減少させます。 サーバが新しい値があるEXISTS応答を送るのは必要ではありません。 また、それはメールボックスの中のそれぞれの連続したメッセージのためにメッセージ通番を減少させます(このセクションの端で例を見てください)。 最後のVANISHED/EXPUNGE応答以来梢消されたメッセージが現在開かれたメールボックスのために発信したか、またはメールボックスが開けられたので他の接続SHOULDで梢消されたEXPUNGEによって引き起こされたVANISHED応答、UID EXPUNGE、またはメッセージがUIDsを含むだけであることに注意してください。 すなわち、サーバSHOULD NOTは以前に梢消されたメッセージのためにUIDsを送ります、UID FETCH(VANISHED)コマンドでそうするよう明らかに要求されない場合。
Note that client implementors must take care to properly decrement the number of messages in the mailbox even if a server violates this last SHOULD or repeats the same UID multiple times in the returned UID set. In general, this means that a client using this extension should either avoid using message numbers entirely, or have a complete mapping of UIDs to message sequence numbers for the selected mailbox.
サーバが返されたUIDセットでこの最後のSHOULDに違反する、または同じUIDを複数の回繰り返してもクライアント作成者がメールボックスの中のメッセージの数を適切に減少させるために注意しなければならないことに注意してください。 一般に、これは、この拡張子を使用しているクライアントが選択されたメールボックスのためのメッセージ通番にメッセージ番号を完全に使用するのを避けるべきであるか、またはUIDsの完全なマッピングを持つべきであることを意味します。
Melnikov, et al. Standards Track [Page 13] RFC 5162 IMAP Quick Mailbox Resync March 2008
メリニコフ、他 規格は2008年のIMAPの迅速なメールボックスResync行進のときにRFC5162を追跡します[13ページ]。
Because clients handle the two different forms of the VANISHED response differently, servers MUST NOT report UIDs resulting from a UID FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) in the same VANISHED response as UIDs of messages expunged now (i.e., messages expunged in other connections). Instead, the server MUST send separate VANISHED responses: one with the EARLIER tag and one without.
クライアントがVANISHED応答の2つの異なったフォームを異なって扱うので、サーバは現在梢消されているメッセージ(すなわち、他の接続で梢消されたメッセージ)のUIDsと同じVANISHED応答でUID FETCH(VANISHED)かSELECT/EXAMINE(QRESYNC)から生じるUIDsを報告してはいけません。 代わりに、サーバは別々のVANISHED応答を送らなければなりません: EARLIERタグと1がある1
A VANISHED response MUST NOT be sent when no command is in progress, nor while responding to a FETCH, STORE, or SEARCH command. This rule is necessary to prevent a loss of synchronization of message sequence numbers between client and server. A command is not "in progress" until the complete command has been received; in particular, a command is not "in progress" during the negotiation of command continuation.
コマンドが全く進行していなくて、FETCH、ストア、または検索命令に応じている間、VANISHED応答を送ってはいけません。 この規則が、クライアントとサーバの間のメッセージ通番の同期の損失を防ぐのに必要です。コマンドは完全なコマンドを受け取るまで「進行中ではありません」。 コマンドはコマンド継続の交渉の間、特に、「進行中ではありません」。
Note: UID FETCH, UID STORE, and UID SEARCH are different commands from FETCH, STORE, and SEARCH. A VANISHED response MAY be sent during a UID command. However, the VANISHED response MUST NOT be sent during a UID SEARCH command that contains message numbers in the search criteria.
以下に注意してください。 UID FETCH、UID STORE、およびUID SEARCHはFETCH、ストア、および検索からの異なったコマンドです。 UIDコマンドの間、VANISHED応答を送るかもしれません。 しかしながら、検索評価基準におけるメッセージ番号を含むUID SEARCHコマンドの間、VANISHED応答を送ってはいけません。
The update from the VANISHED response MUST be recorded by the client.
クライアントはVANISHED応答からのアップデートを記録しなければなりません。
Example: Let's assume that there is the following mapping between message numbers and UIDs in the currently selected mailbox (here "X" marks messages with the \Deleted flag set, and "x" represents UIDs which are not relevant for the example):
例: 現在選択されたメールボックスの中のメッセージ番号とUIDsの間には、以下のマッピングがあると仮定しましょう(ここに、\が削除されているメッセージが旗を揚げさせる「X」マークはセットしました、そして、「x」は例において、関連していないUIDsを表します):
Message numbers: 1 2 3 4 5 6 7 8 9 10 11 UIDs: x 504 505 507 508 x 510 x x x 625 \Deleted messages: X X X X
メッセージ番号: 1 2 3 4 5 6 7 8 9、10 11UIDs: x504 505 507 508x510x x x625円削除されたメッセージ: X X X X
In the presence of the extension defined in this document:
これで定義された拡大があるとき、以下を記録してください。
C: A202 EXPUNGE S: * VANISHED 505,507,510,625 S: A202 OK EXPUNGE completed
C: A202はSを梢消します: * 消える505,507,510,625秒間: 完成したA202 OK EXPUNGE
Without the QRESYNC extension, the same example might look like:
QRESYNC拡張子がなければ、同じ例に似るかもしれません:
C: A202 EXPUNGE S: * 3 EXPUNGE S: * 3 EXPUNGE S: * 5 EXPUNGE S: * 8 EXPUNGE S: A202 OK EXPUNGE completed
C: A202はSを梢消します: * 3 Sを梢消してください: * 3 Sを梢消してください: * 5 Sを梢消してください: * 8 Sを梢消してください: 完成したA202 OK EXPUNGE
Melnikov, et al. Standards Track [Page 14] RFC 5162 IMAP Quick Mailbox Resync March 2008
メリニコフ、他 規格は2008年のIMAPの迅速なメールボックスResync行進のときにRFC5162を追跡します[14ページ]。
(Continuing previous example) If subsequently messages with UIDs 504 and 508 got marked as \Deleted:
(前の例を続けています)は次にUIDs504と508があるメッセージであるなら\Deletedとしてマークされました:
C: A210 EXPUNGE S: * VANISHED 504,508 S: A210 OK EXPUNGE completed
C: A210はSを梢消します: * 消える504,508秒間: 完成したA210 OK EXPUNGE
i.e., the last VANISHED response only contains UIDs of messages expunged since the previous VANISHED response.
すなわち、最後のVANISHED応答は前のVANISHED応答以来梢消されたメッセージのUIDsを含むだけです。
3.7. CLOSED Response Code
3.7. 閉じている応答コード
The CLOSED response code has no parameters. A server implementing the extension defined in this document MUST return the CLOSED response code when the currently selected mailbox is closed implicitly using the SELECT/EXAMINE command on another mailbox. The CLOSED response code serves as a boundary between responses for the previously opened mailbox (which was closed) and the newly selected mailbox: all responses before the CLOSED response code relate to the mailbox that was closed, and all subsequent responses relate to the newly opened mailbox.
CLOSED応答コードには、パラメタが全くありません。 現在選択されたメールボックスがそれとなく閉じられるとき、別のメールボックスの上にSELECT/EXAMINEコマンドを使用して、本書では定義された拡大を実装するサーバはCLOSED応答コードを返さなければなりません。 CLOSED応答コードは以前に開かれたメールボックス(閉じられた)と新たに選択されたメールボックスのための応答の間の境界として機能します: CLOSED応答コードの前のすべての応答が閉じられたメールボックスに関連します、そして、すべてのその後の応答が新たに開かれたメールボックスに関連します。
There is no need to return the CLOSED response code on completion of the CLOSE or the UNSELECT [UNSELECT] command (or similar) whose purpose is to close the currently selected mailbox without opening a new one.
CLOSEの完成かUNSELECT[UNSELECT]で応答コードをCLOSEDにコマンドと(同様)で返す新しいものを開かないで現在選択されたメールボックスを閉じる目的がことである必要は全くありません。
4. Server Implementation Considerations
4. サーバ実装問題
This section describes a minimalist implementation, a moderate implementation, and an example of a full implementation.
このセクションはミニマリスト実装、適度の実装、および完全な実施に関する例について説明します。
4.1. Server Implementations That Don't Store Extra State
4.1. 付加的な状態を保存しないサーバ実装
Strictly speaking, a server implementation that doesn't remember mod- sequences associated with expunged messages can be considered compliant with this specification. Such implementations return all expunged messages specified in the UID set of the UID FETCH (VANISHED) command every time, without paying attention to the specified CHANGEDSINCE mod-sequence. Such implementations are discouraged, as they can end up returning VANISHED responses that are bigger than the result of a UID SEARCH command for the same UID set.
厳密に言うと、この仕様で言いなりになると梢消されたメッセージに関連しているモッズ系列を覚えていないサーバ実装を考えることができます。 そのような実装は毎回UID FETCH(VANISHED)コマンドのUIDセットで指定されたすべての梢消されたメッセージを返します、指定されたCHANGEDSINCEモッズ系列に注意を向けないで。 そのような実装はがっかりしています、結局同じUIDのためのUID SEARCHコマンドの結果がセットしたより大きい応答をVANISHEDに返すことができるとき。
Clients that use the message sequence match data can reduce the scope of this VANISHED response substantially in the typical case where expunges have not happened, or happen only toward the end of the mailbox.
系列マッチデータが典型的でこのVANISHED応答の範囲をかなり減少させることができるというメッセージを使用するクライアントがどこをケースに入れるか、梢消、メールボックスの端だけに向かって起こらないか、または起こらないのを持っています。
Melnikov, et al. Standards Track [Page 15] RFC 5162 IMAP Quick Mailbox Resync March 2008
メリニコフ、他 規格は2008年のIMAPの迅速なメールボックスResync行進のときにRFC5162を追跡します[15ページ]。
4.2. Server Implementations Storing Minimal State
4.2. 最小量の状態を保存するサーバ実装
A server that stores the HIGHESTMODSEQ value at the time of the last EXPUNGE can omit the VANISHED response when a client provides a MODSEQ value that is equal to, or higher than, the current value of this datum, that is, when there have been no EXPUNGEs.
クライアントが、より高さ現行価値かこのデータの現行価値から等しいMODSEQ値を提供すると、最後のEXPUNGE時点でHIGHESTMODSEQ値を保存するサーバはVANISHED応答を省略できます、すなわち、EXPUNGEsが全くなかったとき。
A client providing message sequence match data can reduce the scope as above. In the case where there have been no expunges, the server can ignore this data.
メッセージ系列マッチデータを提供するクライアントは上の範囲を減少させることができます。 あったいいえが梢消する場合では、サーバはこのデータを無視できます。
4.3. Additional State Required on the Server
4.3. 追加状態がサーバで必要です。
When compared to the [CONDSTORE] extension, this extension requires servers to store additional state associated with expunged messages. Note that implementations are not required to store this state in persistent storage; however, use of persistent storage is advisable.
[CONDSTORE]拡大と比べると、この拡張子は、梢消されたメッセージに関連している追加状態を保存するためにサーバを必要とします。 実装は永続的なストレージでこの状態を保存するのに必要でないことに注意してください。 しかしながら、永続的なストレージの使用は賢明です。
One possible way to correctly implement the extension described in this document is to store a queue of <UID set, mod-sequence> pairs. <UID set> can be represented as a sequence of <min UID, max UID> pairs.
正しく本書では説明された拡大を実装する1つの可能な方法はUIDが設定する<の待ち行列を保存することです、モッズ風の系列>組。 <分UID、最大UID>組の系列として<UIDセット>を表すことができます。
When messages are expunged, one or more entries are added to the queue tail.
メッセージが梢消されるとき、1つ以上のエントリーが待ち行列テールに加えられます。
When the server receives a request to return messages expunged since a given mod-sequence, it will search the queue from the tail (i.e., going from the highest expunged mod-sequence to the lowest) until it sees the first record with a mod-sequence less than or equal to the given mod-sequence or it reaches the head of the queue.
サーバが与えられたモッズ系列以来梢消されたメッセージを返すという要求を受け取るとき、それはテール(すなわち、最も高い梢消されたモッズ系列から最も低い系列まで行く)から待ち行列を1番目がモッズ系列で与えられたモッズより系列を記録するのを見るか、または待ち行列のヘッドに届くまで捜すでしょう。
Note that indefinitely storing information about expunged messages can cause storage and related problems for an implementation. In the worst case, this could result in almost 64Gb of storage for each IMAP mailbox. For example, consider an implementation that stores <min UID, max UID, mod-sequence> triples for each range of messages expunged at the same time. Each triple requires 16 octets: 4 octets for each of the two UIDs, and 8 octets for the mod-sequence. Assume that there is a mailbox containing a single message with a UID of 2**32-1 (the maximum possible UID value), where messages had previously existed with UIDs starting at 1, and have been expunged one at a time. For this mailbox alone, storage is required for the triples <1, 1, modseq1>, <2, 2, modseq2>, ..., <2**32-2, 2**32-2, modseq4294967294>.
梢消されたメッセージの情報を無期限に保存するとストレージと関連する問題が実装のために引き起こされる場合があることに注意してください。 最悪の場合には、これはほとんどそれぞれのIMAPメールボックスのためのストレージの64Gbをもたらすかもしれません。 例えば、<分UIDを保存する実装を考えてください、最大UID、それぞれの範囲に関するメッセージのための>三重が同時に梢消したモッズ系列。 各三重は16の八重奏を必要とします: それぞれの2UIDsのための4つの八重奏、およびモッズ系列のための8つの八重奏。 UIDsが1時に始まっていてメッセージが以前に存在した2**32-1(最大の可能なUID値)のUIDがあるただ一つのメッセージを含むメールボックスがあると仮定してください、そして、一度に一つ、梢消されてください、そうした。 このメールボックスだけに関しては、ストレージが三重<1、1、modseq1>、<2、2、modseq2>に必要です…, <2**32-2、2**32-2、modseq4294967294>。
Melnikov, et al. Standards Track [Page 16] RFC 5162 IMAP Quick Mailbox Resync March 2008
メリニコフ、他 規格は2008年のIMAPの迅速なメールボックスResync行進のときにRFC5162を追跡します[16ページ]。
Hence, implementations are encouraged to adopt strategies to protect against such storage problems, such as limiting the size of the queue used to store mod-sequences for expunged messages and "expiring" older records when this limit is reached. When the selected implementation-specific queue limit is reached, the oldest record(s) are deleted from the queue (note that such records are located at the queue head). For all such "expired" records, the server needs to store a single mod-sequence, which is the highest mod-sequence for all "expired" expunged messages.
したがって、実装がそのようなストレージ問題から守るために戦略を採用するよう奨励されます、梢消されたメッセージのためにモッズ系列を保存するのに使用される待ち行列のサイズを制限して、この限界に達しているとき、より古い記録が「吐き出す」であることなどのように。 選択された実装特有の待ち行列限界に達しているとき、最も古い記録は待ち行列から削除されます(そのような記録が待ち行列ヘッドに位置していることに注意してください)。 そのようなすべての「満期」の記録のために、サーバは、ただ一つのモッズ系列を保存する必要があります。(系列はすべての梢消された「満期」のメッセージのための最も高いモッズ系列です)。
Note that if the client provides the message sequence match data, this can heavily reduce the data cost of sending a complete set of missing UIDs; thus, reducing the problems for clients if a server is unable to persist much of this queue. If the queue contains data back to the requested mod-sequence, this data can be ignored.
クライアントがメッセージ系列マッチデータを提供するなら、これが大いになくなったUIDsの完全なセットを送るデータコストを削減できることに注意してください。 その結果、サーバがこの待ち行列の多くを固持できないなら、クライアントのために問題を減少させます。 待ち行列が要求されたモッズ系列にデータを含んで戻しているなら、このデータを無視できます。
Also, note that if the UIDVALIDITY of the mailbox changes or if the mailbox is deleted, then any state associated with expunged messages doesn't need to be preserved and SHOULD be deleted.
また、メールボックスのUIDVALIDITYが変化するか、またはメールボックスが削除されるなら何か梢消されたメッセージに関連している州が保存される必要はないか、そして、SHOULDが削除されることに注意してください。
5. Updated Synchronization Sequence
5. アップデートされた同期系列
This section updates the description of optimized synchronization in Section 6.1 of the [IMAP-DISC].
このセクションは[IMAP-DISC]のセクション6.1における、最適化された同期の記述をアップデートします。
An advanced disconnected mail client should use the QRESYNC and [CONDSTORE] extensions when they are supported by the server. The client uses the value from the HIGHESTMODSEQ OK response code received on mailbox opening to determine if it needs to resynchronize. Once the synchronization is complete, it MUST cache the received value (unless the mailbox UIDVALIDITY value has changed; see below). The client MUST update its copy of the HIGHESTMODSEQ value whenever the server sends a subsequent HIGHESTMODSEQ OK response code.
それらがサーバによってサポートされるとき、高度な切断しているメールクライアントはQRESYNCと[CONDSTORE]拡張子を使用するべきです。クライアントはそれが、再連動する必要であるかどうか決定するために開きながらメールボックスの上に受け取られたHIGHESTMODSEQ OK応答コードから値を使用します。 同期がいったん完全になると容認された値をキャッシュしなければならない、(メールボックスUIDVALIDITY価値は変化しました; 以下を見てください、) サーバがその後のHIGHESTMODSEQ OK応答コードを送るときはいつも、クライアントはHIGHESTMODSEQ価値のコピーをアップデートしなければなりません。
After completing a full synchronization, the client MUST also take note of any unsolicited MODSEQ FETCH data items received from the server. Whenever the client receives a tagged response to a command, it calculates the highest value among all MODSEQ FETCH data items received since the last tagged response. If this value is bigger than the client's copy of the HIGHESTMODSEQ value, then the client MUST use this value as its new HIGHESTMODSEQ value.
また、完全な同期を終了した後に、クライアントはサーバから受け取られたどんな求められていないMODSEQ FETCHデータ項目にも注目しなければなりません。クライアントがコマンドへのタグ付けをされた応答を受けるときはいつも、それは最終が応答にタグ付けをして以来の項目が受け取ったすべてのMODSEQ FETCHデータの中の最も高い値について計算します。 この値がクライアントのHIGHESTMODSEQ価値のコピーより大きいなら、新しいHIGHESTMODSEQが評価するようにクライアントはこの値を使用しなければなりません。
Note: It is not safe to update the client's copy of the HIGHESTMODSEQ value with a MODSEQ FETCH data item value as soon as it is received because servers are not required to send MODSEQ FETCH data items in increasing modseqence order. This can lead to the client missing some changes in case of connectivity loss.
以下に注意してください。 サーバはmodseqenceオーダーを増強する際にデータ項目をMODSEQ FETCHに送るのに必要でないのでそれが受け取られているとすぐに、MODSEQ FETCHデータ項目価値でクライアントのHIGHESTMODSEQ価値のコピーをアップデートするのは安全ではありません。 これは接続性の損失の場合にいくつかの変化を逃すクライアントに通じることができます。
Melnikov, et al. Standards Track [Page 17] RFC 5162 IMAP Quick Mailbox Resync March 2008
メリニコフ、他 規格は2008年のIMAPの迅速なメールボックスResync行進のときにRFC5162を追跡します[17ページ]。
When opening the mailbox for synchronization, the client uses the QRESYNC parameter to the SELECT/EXAMINE command. The QRESYNC parameter is followed by the UIDVALIDITY and mailbox HIGHESTMODSEQ values, as known to the client. It can be optionally followed by the set of UIDs, for example, if the client is only interested in partial synchronization of the mailbox. The client may also transmit a list containing its knowledge of message numbers.
同期のためにメールボックスを開けるとき、クライアントはSELECT/EXAMINEコマンドにQRESYNCパラメタを使用します。 UIDVALIDITYとメールボックスHIGHESTMODSEQ値はクライアントにとって知られているようにQRESYNCパラメタを支えています。 例えば、クライアントはメールボックスの部分的な同期に関心があるだけであるなら、UIDsのセットが任意にそれに続くことができます。 また、クライアントはメッセージ番号に関する知識を含むリストを伝えるかもしれません。
If the SELECT/EXAMINE command is successful, the client compares UIDVALIDITY as described in step d)1) in Section 3 of the [IMAP-DISC]. If the cached UIDVALIDITY value matches the one returned by the server and the server also returns the HIGHESTMODSEQ response code, then the server reports expunged messages and returns flag changes for all messages specified by the client in the UID set parameter (or for all messages in the mailbox, if the client omitted the UID set parameter). At this point, the client is synchronized, except for maybe the new messages.
SELECT/EXAMINEコマンドがうまくいくなら、クライアントは[IMAP-DISC]のセクション3でステップd)1)で説明されるようにUIDVALIDITYを比較します。 キャッシュされたUIDVALIDITY値がサーバによって返されたものに合って、また、サーバがHIGHESTMODSEQ応答コードを返すなら、サーバレポートはメッセージを梢消しました、そして、リターンはUIDセットパラメタのクライアントによって指定されたすべてのメッセージのために変化に旗を揚げさせます(クライアントがUIDを省略したなら、メールボックスの中のすべてのメッセージに、パラメタを設定してください)。 ここに、多分新しいメッセージを除いて、クライアントは連動します。
If upon a successful SELECT/EXAMINE (QRESYNC) command the client receives a NOMODSEQ OK untagged response (instead of the HIGHESTMODSEQ response code), it MUST remove the last known HIGHESTMODSEQ value from its cache and follow the more general instructions in Section 3 of the [IMAP-DISC].
NOMODSEQ OKがクライアントが受け取るうまくいっているSELECT/EXAMINE(QRESYNC)コマンドのときに応答(HIGHESTMODSEQ応答コードの代わりに)に非タグ付けをしたなら、それは、キャッシュから最後に知られているHIGHESTMODSEQ値を取り除いて、[IMAP-DISC]のセクション3で、より一般的な指示に従わなければなりません。
At this point, the client is in sync with the server regarding old messages. This client can now fetch information about new messages (if requested by the user).
ここに、同時性にはクライアントが古いメッセージに関するサーバでいます。 このクライアントは現在、新しいメッセージの情報をとって来ることができます(ユーザによって要求されるなら)。
Step d) ("Server-to-client synchronization") in Section 4 of the
[IMAP-DISC] in the presence of the QRESYNC & CONDSTORE extensions is
amended as follows:
ステップd) (「サーバからクライアントとの同期」) セクションでは、QRESYNC&CONDSTORE拡張子があるとき4[IMAP-DISC]が以下の通り修正されます:
d) "Server-to-client synchronization" -- for each mailbox that
requires synchronization, do the following:
d) 「サーバからクライアントとの同期」--同期を必要とする各メールボックスに関しては、以下をしてください:
1a) Check the mailbox UIDVALIDITY (see Section 4.1 of the [IMAP-DISC]
for more details) after issuing SELECT/EXAMINE (QRESYNC) command.
1a) SELECT/EXAMINE(QRESYNC)にコマンドを発行した後に、メールボックスUIDVALIDITY(その他の詳細に関して[IMAP-DISC]のセクション4.1を見る)をチェックしてください。
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;
* キャッシュされたHIGHESTMODSEQは、メールボックスのために「忘れてください」と評価します。
Melnikov, et al. Standards Track [Page 18] RFC 5162 IMAP Quick Mailbox Resync March 2008
メリニコフ、他 規格は2008年のIMAPの迅速なメールボックスResync行進のときにRFC5162を追跡します[18ページ]。
* remove any pending "actions" which refer to UIDs in that
mailbox. Note, this doesn't affect actions performed on
client generated fake UIDs (see Section 5 of the
[IMAP-DISC]);
* そのメールボックスの中にUIDsを示すあらゆる未定の「動作」を取り除いてください。 これがクライアントの発生しているにせのUIDsに実行された動作に影響しないことに([IMAP-DISC]のセクション5を見てください)注意してください。
2) Fetch the current "descriptors";
2) 現在の「記述子」をとって来てください。
I) Discover new messages.
I) 新しいメッセージを発見してください。
3) Fetch the bodies of any "interesting" messages that the client
doesn't already have.
3) クライアントが既に持っていないどんな「おもしろい」メッセージのボディーもとって来てください。
Example: 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 (QRESYNC (3857529045 20010715194032001 1:198))
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: * VANISHED (EARLIER) 1:5,7:8,10:15
S: * 2 FETCH (UID 6 MODSEQ (20010715205008000)
FLAGS (\Deleted))
S: * 5 FETCH (UID 9 MODSEQ (20010715195517000)
FLAGS ($NoJunk $AutoJunk $MDNSent))
...
S: A142 OK [READ-WRITE] SELECT completed
C: A142の選んだ受信トレイ、(QRESYNC、(3857529045 20010715194032001、1:198)、S: * 172が存在している、S: * 1、最近のS: * OK[UNSEEN12]メッセージ12は最初に、見えないSです: * OK[UIDVALIDITY3857529045]のUIDs有効なS: * OK[UIDNEXT201]は次のUID Sを予測しました: * 旗(\に答えた\は\削除された\見られた\草稿に旗を揚げさせた)のS: * OK[PERMANENTFLAGS(\は\見られた\*を削除した)]はSを制限しました: * OK[HIGHESTMODSEQ20010715194045007]S: * 消えている(より初期の)1: 5 7:8 10 : 15秒間: * 2は(UID6MODSEQ(20010715205008000)旗(削除された\))にSをとって来ます: * 5 (UID9MODSEQ(20010715195517000)旗($NoJunk$AutoJunk$MDNSent))をとって来てください… S: 完成したA142 OK[READ-WRITE]SELECT
6. Formal Syntax
6. 正式な構文
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF].
以下の構文仕様は[ABNF]の指定されるとしてのAugmented BN記法(ABNF)記法を使用します。
Non-terminals referenced but not defined below are as defined by [RFC3501], [CONDSTORE], or [IMAPABNF].
[RFC3501]、[CONDSTORE]、または[IMAPABNF]によって定義されるように参照をつけられましたが、以下で定義されなかった非端末があります。
Except as noted otherwise, all alphabetic characters are case- insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion.
別の方法で注意されるのを除いて、すべての英字がケース神経が鈍いです。 トークンストリングを定義する上側の、または、下側のケースキャラクタの使用は編集の明快だけのためのものです。 実装は大文字と小文字を区別しないファッションでこれらのストリングを受け入れなければなりません。
Melnikov, et al. Standards Track [Page 19] RFC 5162 IMAP Quick Mailbox Resync March 2008
メリニコフ、他 規格は2008年のIMAPの迅速なメールボックスResync行進のときにRFC5162を追跡します[19ページ]。
capability =/ "QRESYNC"
能力=/"QRESYNC"
select-param = "QRESYNC" SP "(" uidvalidity SP
mod-sequence-value [SP known-uids]
[SP seq-match-data] ")"
;; conforms to the generic select-param
;; syntax defined in [IMAPABNF]
選んだparamは"QRESYNC"SPと等しいです「(「uidvalidity SPモッズ系列価値[SPの知られているuids][SP seqはデータに合っている]」)」という。 ジェネリックの選んだparamに従います。 中で定義された構文[IMAPABNF]
seq-match-data = "(" known-sequence-set SP known-uid-set ")"
seqマッチデータが等しい、「(「知られているシーケンスセットSP、知られているuidがセットした、」、)、」
uidvalidity = nz-number
uidvalidityはnz-数と等しいです。
known-uids = sequence-set
;; sequence of UIDs, "*" is not allowed
知られているuidsはシーケンスセットと等しいです。 UIDsの系列、「*」は許容されていません。
known-sequence-set = sequence-set
;; set of message numbers corresponding to
;; the UIDs in known-uid-set, in ascending order.
;; * is not allowed.
知られているシーケンスセットはシーケンスセットと等しいです。 メッセージ番号が対応するのがセットする、。 昇順に知られているuidセットにおけるUIDs。 ;; * 許容されていません。
known-uid-set = sequence-set
;; set of UIDs corresponding to the messages in
;; known-sequence-set, in ascending order.
;; * is not allowed.
知られているuidセットはシーケンスセットと等しいです。 中のメッセージに対応するUIDsのセット。 昇順で、知られているシーケンスセットです。 ;; * 許容されていません。
message-data =/ expunged-resp
メッセージデータの梢消された=/resp
expunged-resp = "VANISHED" [SP "(EARLIER)"] SP known-uids
梢消されたresp=は[「(より早くに)」というSP]SPの知られているuidsを「消えさせました」。
rexpunges-fetch-mod = "VANISHED"
;; VANISHED UID FETCH modifier conforms
;; to the fetch-modifier syntax
;; defined in [IMAPABNF]. It is only
;; allowed in the UID FETCH command.
rexpungesフェッチモッズ=は「消え失せました」。 VANISHED UID FETCH修飾語は従います。 フェッチ修飾語構文に。 [IMAPABNF]では、定義されます。 それがそうである、単に。 UID FETCHコマンドでは、許容されています。
resp-text-code =/ "CLOSED"
respテキストコード=/「閉じられます」。
7. Security Considerations
7. セキュリティ問題
As always, it is important to thoroughly test clients and servers implementing this extension, as it changes how the server reports expunged messages to the client.
いつものように、この拡大を実装するクライアントとサーバを徹底的に検査するのは重要です、サーバレポートがどうクライアントにメッセージを梢消したかを変えるとき。
Security considerations relevant to [CONDSTORE] are relevant to this extension.
[CONDSTORE]に関連しているセキュリティ問題はこの拡大に関連しています。
This document doesn't raise any new security concerns not already raised by [CONDSTORE] or [RFC3501].
このドキュメントは[CONDSTORE]か[RFC3501]によって既に上げられなかったどんな新しい安全上の配慮も上げません。
Melnikov, et al. Standards Track [Page 20] RFC 5162 IMAP Quick Mailbox Resync March 2008
メリニコフ、他 規格は2008年のIMAPの迅速なメールボックスResync行進のときにRFC5162を追跡します[20ページ]。
8. IANA Considerations
8. IANA問題
IMAP4 capabilities are registered by publishing a standards track or IESG approved experimental RFC. The registry is currently located at:
IMAP4能力が標準化過程を発行することによって、登録されたか、またはIESGは実験的なRFCを承認しました。 登録は現在、以下に位置しています。
http://www.iana.org/assignments/imap4-capabilities
http://www.iana.org/assignments/imap4-capabilities
This document defines the QRESYNC IMAP capability. IANA has added this capability to the registry.
このドキュメントはQRESYNC IMAP能力を定義します。 IANAは登録へのこの能力を加えました。
9. Acknowledgments
9. 承認
Thanks to Steve Hole, Cyrus Daboo, and Michael Wener for encouraging creation of this document.
スティーブHole、サイラスDaboo、およびマイケルWenerにこのドキュメントの作成を奨励してくださってありがとうございます。
Valuable comments, both in agreement and in dissent, were received from Timo Sirainen, Michael Wener, Randall Gellens, Arnt Gulbrandsen, Chris Newman, Peter Coates, Mark Crispin, Elwyn Davies, Dan Karp, Eric Rescorla, and Mike Zraly.
合意と異議で、ティモSirainen、マイケルWener、ランドルGellens、Arnt Gulbrandsen、クリス・ニューマン、ピーター・コーツ、マーク・クリスピン、Elwynデイヴィース、ダン・カープ、エリック・レスコラ、およびマイクZralyから貴重なコメントを受けました。
This document takes substantial text from [RFC3501] by Mark Crispin.
このドキュメントはマーク・クリスピンで[RFC3501]からかなりのテキストを取ります。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[ABNF] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、STD68、RFC5234、2008年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月。
[ENABLE] Gulbrandsen, A., Ed. and A. Melnikov, Ed., "The IMAP
ENABLE Extension", RFC 5161, March 2008.
エドGulbrandsen、A.、[可能にします]A.メリニコフ、エド、「IMAPは拡大を可能にする」RFC5161、3月2008日
[IMAPABNF] Melnikov, A. and C. Daboo, "Collected Extensions to
IMAP4 ABNF", RFC 4466, April 2006.
[IMAPABNF] メリニコフとA.とC.Daboo、「IMAP4 ABNFへの集まっている拡大」、RFC4466、2006年4月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[RFC3501] クリスピン、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日
Melnikov, et al. Standards Track [Page 21] RFC 5162 IMAP Quick Mailbox Resync March 2008
メリニコフ、他 規格は2008年のIMAPの迅速なメールボックスResync行進のときにRFC5162を追跡します[21ページ]。
10.2. Informative References
10.2. 有益な参照
[IMAP-DISC] Melnikov, A., Ed., "Synchronization Operations For
Disconnected Imap4 Clients", RFC 4549, June 2006.
[IMAP-ディスク] メリニコフ、A.、エド、「外されたImap4クライアントのための同期操作」、RFC4549、6月2006日
[UNSELECT] Melnikov, A., "Internet Message Access Protocol (IMAP)
UNSELECT command", RFC 3691, February 2004.
[UNSELECT] メリニコフ、A.、「インターネットMessage Accessプロトコル(IMAP)UNSELECTコマンド」、RFC3691、2004年2月。
Authors' Addresses
作者のアドレス
Alexey Melnikov Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
AlexeyメリニコフIsode Ltd5城のビジネス村の36駅のRoadハンプトン、ミドルセックスTW12 2BXイギリス
EMail: Alexey.Melnikov@isode.com
メール: Alexey.Melnikov@isode.com
Dave Cridland Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
デーヴCridland Isode Ltd5城のビジネス村の36駅のRoadハンプトン、ミドルセックスTW12 2BXイギリス
EMail: dave.cridland@isode.com
メール: dave.cridland@isode.com
Corby Wilson Nokia 5 Wayside Rd. Burlington, MA 01803 USA
コービーウィルソンノキア5の道端の通り バーリントン、MA01803米国
EMail: corby@computer.org
メール: corby@computer.org
Melnikov, et al. Standards Track [Page 22] RFC 5162 IMAP Quick Mailbox Resync March 2008
メリニコフ、他 規格は2008年のIMAPの迅速なメールボックスResync行進のときにRFC5162を追跡します[22ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Melnikov, et al. Standards Track [Page 23]
メリニコフ、他 標準化過程[23ページ]
一覧
スポンサーリンク
