Network Working Group A. Melnikov
Request for Comments: 5162 D. Cridland
Category: Standards Track Isode Ltd
C. Wilson
Nokia
March 2008
IMAP4 Extensions for Quick Mailbox Resynchronization
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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
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).
この文書では、サーバー側の状態や追加のクライアントのラウンドトリップを必要とせずに、IMAPクライアントに迅速SELECTコマンドの一部として以前に開かれたメールボックスを再同期することができますIMAP4拡張を定義します。この拡張はまた、消去されたメッセージのリストのよりコンパクトな表現が可能になります（と常に一意識別子（UIDを）抹消が含まれる）、新たな応答を導入しています。
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
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]拡張子が切断されたクライアントに迅速以前に見られたメッセージのIMAPフラグの変更を再同期することができます。これは、メールボックスが開かれるとCHANGEDSINCEは修飾子をFETCH使用して行うことができます。メッセージが抹消された発見するクライアントためには、クライアントはまだUID FETCHまたはUID SEARCHコマンドを発行する必要があります。この文書では、1回のラウンドトリップで消去されたメッセージの発見を含め、再接続するクライアントは、完全な再同期を実行することができます[CONDSTORE]への拡張を定義します。この拡張はまた、消去されたメッセージのリストのよりコンパクトな表現を可能にし、新たな応答、消えたが、導入されています。
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サーバーに再接続する方法が必要です。
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サーバは、CAPABILITYコマンドでサポートしている能力の一つとして「QRESYNC」を返した場合、迅速再同期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.
この拡張機能をサポートするサーバは実装して、[有効] IMAP拡張をサポートすることを通知しなければなりません。また、「QRESYNC」機能の存在がCONDSTORE機能がアドバタイズされていない場合でも、[CONDSTORE] IMAP拡張機能のサポートを意味します。この仕様に準拠したサーバが「QRESYNCを有効にする」と（これ[CONDSTORE]で定義されるように「コマンドを有効CONDSTORE」であり、同一の結果を有する）「QRESYNC CONDSTOREを有効にする」サポートするために必要な、しかし対応するため必要はないれていますそれ自体で「ENABLE CONDSTORE」をサポートするためのサーバー。 「QRESYNCを有効にする」/「QRESYNC CONDSTOREを有効にする」コマンドは、代わりにEXPUNGE応答の（セクション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拡張をサポートするクライアントとの互換性のために、サーバは、同様に能力応答で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に/コマンドを調べQRESYNCパラメータ場合はタグ付きBAD応答で応答しなければならないか、消えたUIDは、修飾子をFETCH指定され、クライアントが現在の接続に「QRESYNCを有効にする」発行しておりません。
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つ以上のメッセージがのために消去されたときに、サーバーがSELECT / EXAMINE成功にHIGHESTMODSEQタグなしOKのレスポンスコードを送信しているためMOD-系列、すなわち、の永続ストレージをサポートし、各メールボックスは、メールボックスごとのMOD-シーケンスを増加しなければなりません。 、UID EXPUNGEまたはCLOSEをEXPUNGE。サーバーは、消去されたメッセージのUIDを持つインクリメントMOD-シーケンスを関連付ける必要があります。
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 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).
CONDSTOREをサポートするクライアントではなく、この拡張機能は、メールボックスを再同期化し、そのHIGHESTMODSEQは、クライアントによってキャッシュされた値から増加していることを発見するかもしれません。増加は、クライアントが最後に同期以来抹消されたメッセージにのみある場合、クライアントはデータを返しません... FETCH CHANGEDSINCEコマンドを送信する可能性があります。したがって、CONDSTOREをサポートしていますが、一部のメールボックス（抹消メッセージを持っていたものが、最後の同期以降なしフラグの変更）を再同期するときに、この拡張機能が不要な往復のペナルティを被る可能性がないクライアント。
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は比較的新しい拡張であるので、それをサポートするクライアントもこの拡張をサポートする可能性が高いと考えられています。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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メッセージのシーケンス番号とUIDとEXPUNGE応答[RFC3501]の理解が不可欠です。
The Quick Resynchronization parameter to SELECT/EXAMINE commands has four arguments:
EXAMINE /コマンドを選択するために、クイック再同期パラメータは、次の4つの引数があります。
o the last known UIDVALIDITY,
最後の既知のUIDVALIDITY O、
o the last known modification sequence,
最後の既知の修正シーケンスO、
o the optional set of known UIDs, and
既知のUIDの任意の組O、及び
o an optional parenthesized list of known sequence ranges and their corresponding UIDs.
O既知の配列のオプションのリストを丸括弧は範囲とそれに対応するのUID。
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.
サーバはクイック再同期パラメータを選択する場合は/タグ付きBAD応答で応答調べる必要がありますコマンドが指定され、クライアントが現在の接続に「QRESYNCを有効にする」発行しておりません。
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と[RFC3501]の6.3.2に指定されているサーバーは、すべてのタグなし応答を送信しなければならないことを意味します。
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.
例：INBOXを再同期しようとするが、提供さ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のSELECT INBOX（QRESYNC（67890007 20050715194045000 41,43：211,214：541））S * 464はSをEXISTS：* 3 RECENT S：* OK [UIDVALIDITY 3857529045] UIDVALIDITY S：* OK [UIDNEXT 550]次UID S予測しました* OK [HIGHESTMODSEQ 90060128194045007] S：* OK [UNSEEN 12]メッセージ12である第一見えないS：* FLAGS（\答える\フラグ付き\ドラフト\削除\見て）S：* OK [PERMANENTFLAGS（\答える\フラグ付き\ドラフト\削除された\見\ *）]永久フラグ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.
[CONDSTORE]に記載されたメールボックスのMOD-系列の永続ストレージをサポートしていないサーバは、成功するたびにSELECTまたはEXAMINEコマンドでNOMODSEQ応答コードを含むOKタグなし応答を送らなければなりません。このようなサーバーは、メールボックス内の消去されたメッセージのためのmod-シーケンスを覚えておく必要はありません。これは、残りのパラメータを無視して、動的なメッセージデータが変化しないかのように動作しなければなりません。
If the provided UIDVALIDITY matches that of the selected mailbox, the server then checks the last known modification sequence.
提供UIDVALIDITYが選択されたメールボックスのそれと一致した場合、サーバーは、最後の既知の修正手順を確認します。
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.
サーバーはクライアントに（UIDを含まなければならない応答を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.
既知のUIDのリストも提供されていた場合、サーバーは、専用フラグの変更を報告し、指定されたメッセージのために抹消すべきです。クライアントがのUIDのリストを提供しなかった場合は、クライアントが指定しているかのように、サーバが動作し、「1：<maxuid>」、ここで<maxuid>メールボックスが空で、すべてのメッセージがあったことがない場合は、メールボックスのUIDNEXT値マイナス1です。それには、その後のUIDのリストの欠如がのUIDの空のセットとして解釈されます。
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「は既知のUIDを」FETCH（FLAGS）（CHANGEDSINCE「MOD-シーケンス値が」消滅）
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のSELECT INBOX（QRESYNC（67890007 90060115194045000 41,43：211,214：541））S：* OK [CLOSED] S：* 314 SをEXISTS：* 15 RECENT S：* OK [UIDVALIDITY 67890007] UIDVALIDITY S：* OK [HIGHESTMODSEQ 90060115205545359] S *：* OK [7 UNSEEN]メールボックスSでいくつか見えないメッセージがあります：OK [UIDNEXT 567]は次のUID Sを予測* FLAGS（\回答が\ \ドラフト\削除された\見フラグ付き）S： * OK [PERMANENTFLAGS（\は\ \ドラフト\削除された\ \ *見フラグを立て答え）]永久フラグS：*消えた（以前）41,43：116118120：211214：540 S：* 49 FETCH（UID 117のFLAGS（\は見\回答）MODSEQ（90060115194045001））S：* 50 FETCH（UID 119 FLAGS（\ドラフトの$ MDNSent）MODSEQ（90060115194045308））S：... S：* 100（UID 541のFLAGS（\見$転送された）MODSEQをFETCH（90060115194045001 ））S：A03 OK [読み書き]を選択したメールボックス
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.
クライアントは、設定されたメッセージ・シーケンスの括弧で囲まれたリストと、対応するUIDのセットを提供することができます。どちらも、昇順に提供しなければなりません。サーバは、それが消去されたメッセージ情報を提供するための範囲を制限するためにこのデータを使用します。
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.
概念的には、クライアントは、対応するUIDを知っているシーケンス番号の小さなサンプルを提供します。その後、サーバーは、クライアントがメールボックスの現在の状態で提供し、各シーケンス番号とUIDのペアを比較します。ペア一致した場合、クライアントは、までの任意の抹消を知っている、とを含む、メッセージ、したがって、クライアントが提供する「MOD-シーケンス値が」古すぎる場合でも、消え応答で、その範囲は含まれませんサーバー用にこれらのメッセージが消去されたときのデータを持っています。
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.
したがって、リスト内の最初のセット内のN番目のメッセージの数が4である場合、リスト内の第二の組のN番目のUIDは8であり、メールボックスの第4のメッセージは、UID 8は、その後何のUIDに等しいていないか、8未満である有し消えたレスポンスに存在します。 （N + 1）番目のメッセージ番号は12であり、UID第（N + 1）は24であり、メールボックス内の（N + 1）番目のメッセージは、UID 25は、次いで、最も低い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つの例では、サーバはすべての抹消を思い出すことができず、3で割り切れるメッセージを持つ唯一のUIDは、メールボックス内に存在しています。最初の例では、クライアントは、第四パラメータを使用しません。第二に、それを提供します。この例では、やや極端ですが、シーケンス・マッチ・データの賢明な利用が帯域幅のかなりの量を節約することができることを示しています。
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のSELECT INBOX（QRESYNC（67890007 90060115194045000 1：29997））S：* 10003はSをEXISTS：* 5 RECENT S：* OK [UIDVALIDITY 67890007] UIDVALIDITY S：* OK [UIDNEXT 30013]次のUID S予測しました* OK [HIGHESTMODSEQ 90060115205545359] S：* OK [UNSEEN 7]メールボックスSでいくつか見えないメッセージがあります：* FLAGS（\回答\フラグ付き\ドラフト\削除された\見た）S：* OK [PERMANENTFLAGS（\回答\フラグ付き\ドラフト\削除さ\見\ *）永久フラグS：*消えた（以前）1：2,4：5,7：8,10：11,13：14 [...] 29998：29999,30001：30002,30004 ：30005,30007：30008 S：* 9890 FETCH（UID 29670のFLAGS（\ドラフト$ MDNSent）MODSEQ（90060115194045028））S：* 9889 FETCH S（UIDを29667のFLAGSは（\見\）がMODSEQ（90060115194045027）の回答しました）.. 。S：* 9999 FETCH（UIDを29997のFLAGS（\ $転送された見て）MODSEQ（90060115194045031））S：A04 OK [読み書き]を選択し、メールボックス
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の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はSをEXISTS：* 5最近のS：* OK [UIDVALIDITY 67890007] UIDVALIDITY S：* OK [UIDNEXT 30013]は次のUID Sを予測：* OK [HIGHESTMODSEQ 90060115205545359] S：* OK [7 UNSEEN]ありメールボックスSでいくつか目に見えないメッセージがされています。* FLAGS S（\回答は\ \ドラフト\削除された\見フラグ付き）：* OK [PERMANENTFLAGS（\回答\ \ドラフト\削除された\ * \見フラグ付き）]永久フラグS：*消えました（以前）29998：29999,30001：30002,30004：30005,30007：30008 S：* 9889 FETCH（\が回答見UIDを29667のFLAGS（\）MODSEQ（90060115194045027））S：* 9890（UIDをFETCH 29670のFLAGS（\ドラフト$ MDNSent）MODSEQ（90060115194045028））S：... S：* 9999（UIDをFETCH 29997のFLAGS（\ $転送された見て）MODSEQ（90060115194045031））S：B04 OK [読み書き]を選択したメールボックス
[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 FETCHおよびUIDコマンドの構文を拡張しました。この文書は、新しい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.
消えた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.
消えUIDが修飾子が指定され、クライアントが現在の接続に「QRESYNCを有効にする」発行しておりませんFETCH場合、サーバはタグ付きBAD応答で応じなければなりません。
The VANISHED UID FETCH modifier MUST only be specified together with the CHANGEDSINCE UID FETCH modifier.
消えたUIDはCHANGEDSINCE UIDは修飾子をFETCHと修飾子は唯一一緒に指定する必要があり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 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.
消えたUIDは、修飾子は抹消とその関連するMOD-シーケンス指定MOD-シーケンスよりも大きくなっているされているUIDの設定パラメータからこれらのメッセージを報告するようサーバーに指示FETCH。これは、クライアントの要求は、指定されたMOD-シーケンスので、消去された指定されたセットからのメッセージが通知されるべきです。メッセージが消去されたときに（上記のように）これらのメッセージに関連付けられたMOD-配列（単数または複数）が更新されたことに留意されたいです。抹消メッセージは、以前にタグを含まなければならないセクション3.6に記載の消失応答を使用して報告されています。いずれかの応答をFETCHする前に、それ以外の場合は、クライアントがどのようにのUIDのメッセージ番号は、マップに関する混乱かもしれないとして任意の消えた（以前）の応答は、返さなければなりません。
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.
注：それは提供からすべて抹消メッセージを報告するよう要求されたかのように覚えている最小の抹消MOD-シーケンスの値マイナス1である<minmodseq> <minmodseq>よりMOD-シーケンス小さい受信サーバは、振る舞わなければならない（MUST） 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：消えた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：500（FLAGS）（CHANGEDSINCE 12345）S：* 1 FETCH（UID 404 MODSEQ（65402）FLAGS（\見られる））S：S100 UID 300をFETCH * FETCH 2（UID 406 MODSEQ（75403）FLAGS（\削除済み） ）S：* FETCH図4（UID 408 MODSEQ（29738）FLAGS（$ NoJunk $ AutoJunk $ MDNSent））S：S100 OK完了CをFETCH：S101 UID検索300：500 S：* SEARCH 404 406 407 408 410 412 S：S101 OK検索が完了します
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は、クライアントのキャッシュから最低と最高のUIDです。 2回目の探索応答はUIDを407、410、および412とのメッセージがまだ存在しているが、そのフラグが指定された修正シーケンス以降に変更されていないことをクライアントに伝えます。
Using the VANISHED UID FETCH modifier, it is sufficient to issue only a single command:
消えた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：500（FLAGS）（CHANGEDSINCE 12345消滅）S：*消えた（以前）300：310405411 S：S100 UID 300をFETCH * 1 FETCH（UID 404 MODSEQ（65402）FLAGS（\見られる））S：*はFETCH 2（ UID 406 MODSEQ（75403）FLAGS（\削除済み））S：* FETCH 4（UIDは408 MODSEQ（29738）FLAGS（$ NoJunk $ AutoJunk $ MDNSent））S：S100 OK FETCH完成
Arguments: none
引数：なし
Responses: untagged responses: EXPUNGE or VANISHED
回答：タグなし応答：EXPUNGEまたは消えました
Result: OK - expunge completed NO - expunge failure: can't expunge (e.g., permission denied) BAD - command unknown or arguments invalid
結果：OK - 完了NOを抹消 - 失敗を抹消：抹消することはできません（例えば、許可が拒否された）BAD - コマンド不明または引数無効
This section updates the definition of the EXPUNGE command described in Section 6.4.3 of [RFC3501].
このセクションでは、[RFC3501]のセクション6.4.3に記載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を返す前に、削除されているそれらのメッセージは消えた応答を使用して報告または応答が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コマンドの実行のために除去された場合には、メールボックスごとのMOD-シーケンスを増加しなければなりません。各永久に削除メッセージの場合、サーバーはインクリメントMOD-シーケンスおよび対応するUIDを覚えておく必要があります。少なくとも1件のメッセージが消去さしまった場合、サーバは、タグ付けされたOK応答（[CONDSTORE]で定義される）HIGHESTMODSEQ応答コードを使用して更新ごとのメールボックス変更シーケンスを送信しなければなりません。
Example: C: A202 EXPUNGE S: * 3 EXPUNGE S: * 3 EXPUNGE S: * 5 EXPUNGE S: * 8 EXPUNGE S: A202 OK [HIGHESTMODSEQ 20010715194045319] expunged
例：C：A202 EXPUNGE S：* 3 EXPUNGE S：* 3 EXPUNGE S：* 5 EXPUNGE S：* 8 EXPUNGE S：A202 OKは[HIGHESTMODSEQ 20010715194045319]抹消
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 EXPUNGEは、」メッセージ＃3を報告します。抹消ように、第2の「* 3 EXPUNGEは」（メッセージ番号が原因前回のEXPUNGE応答に減らさしまった）メッセージ＃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応答の消えた応答を送信することを選択した場合、前述の例は次のようになりますことに注意してください。
Example: C: B202 EXPUNGE S: * VANISHED 405,407,410,425 S: B202 OK [HIGHESTMODSEQ 20010715194045319] expunged
例：C：B202 EXPUNGE S：B202 OK [HIGHESTMODSEQが20010715194045319]抹消：*が405407410425のSを消滅しました
Here messages with message numbers 3, 4, 7, and 11 have respective UIDs 405, 407, 410, and 425.
ここで、メッセージ番号3、4とメッセージ、7、および11は、それぞれのUID 405、407、410、及び425を有します。
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].
このセクションでは、[RFC3501]のセクション6.4.2に記載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フラグを持っているすべてのメッセージを削除し、選択された状態から認証された状態に戻ります。いいえタグなし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 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コマンドの実行のために除去された場合には、メールボックスごとのMOD-シーケンスを増加しなければなりません。各永久に削除メッセージの場合、サーバーはインクリメントMOD-シーケンスおよび対応するUIDを覚えておく必要があります。少なくとも1件のメッセージが消去さしまった場合、サーバは、タグ付けされたOK応答（[CONDSTORE]で定義される）HIGHESTMODSEQ応答コードを使用して更新ごとのメールボックス変更シーケンスを送信しなければなりません。
Example: C: A202 CLOSE S: A202 OK [HIGHESTMODSEQ 20010715194045319] done
例：C：A202 CLOSE S：A202がOK [HIGHESTMODSEQ 20010715194045319]行わ
Arguments: message set
引数：メッセージ・セット
Responses: untagged responses: EXPUNGE or VANISHED
回答：タグなし応答：EXPUNGEまたは消えました
Result: OK - expunge completed NO - expunge failure: can't expunge (e.g., permission denied) BAD - command unknown or arguments invalid
結果：OK - 完了NOを抹消 - 失敗を抹消：抹消することはできません（例えば、許可が拒否された）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を実装しなければなりません。
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を使用することにより、クライアントは、クライアントが最後に接続された時間とクライアントが再同期化時間の間、他のクライアントによって削除\としてマークされたすべてのメッセージを削除し、誤って回避することができます。
Before returning an OK to the client, those messages that are removed are reported using a VANISHED response or EXPUNGE responses.
クライアントにOKを返す前に、削除されているそれらのメッセージは消えた応答を使用して報告または応答が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コマンドの実行に削除された場合には、メールボックスごとのMOD-シーケンスを増加しなければなりません。各永久に削除メッセージの場合、サーバーはインクリメントMOD-シーケンスおよび対応するUIDを覚えておく必要があります。少なくとも1件のメッセージが消去さしまった場合、サーバは、タグ付けされたOK応答（[CONDSTORE]で定義される）HIGHESTMODSEQ応答コードを使用して更新ごとのメールボックス変更シーケンスを送信しなければなりません。
Example: C: . UID EXPUNGE 3000:3002 S: * 3 EXPUNGE S: * 3 EXPUNGE S: * 3 EXPUNGE S: . OK [HIGHESTMODSEQ 20010715194045319] Ok
例：C：。 UID EXPUNGE 3000：3002 S：* 3 EXPUNGE S：* 3 EXPUNGEのS：* 3 EXPUNGE S：。 [OK]を[HIGHESTMODSEQ 20010715194045319] OK
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（UIDを3002から3000）を有する少なくともメッセージで\ Deletedフラグのセットを有していました。抹消として最初の「* 3 EXPUNGEは、」メッセージ＃3を報告します。抹消ように、第2の「* 3 EXPUNGEは」（メッセージ番号が原因前回のEXPUNGE応答に減らさしまった）メッセージ＃4を報告します。さらに説明のために[RFC3501]でEXPUNGE応答の説明を参照してください。
Contents: an optional EARLIER tag
内容：オプションEARLIERタグ
list of UIDs
UIDのリスト
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 numbers. The first benefit saves bandwidth, while the second is more convenient for clients that only use UIDs to access the IMAP server.
消えた応答が指定されたUIDが永久にメールボックスから削除されていることを報告します。この応答はEXPUNGE応答[RFC3501]と同様です。しかし、それは、複数のメッセージに関する情報を返すことができ、それが代わりにメッセージ番号のUIDを返します。第二は、唯一のIMAPサーバーにアクセスするためのUIDを使用するクライアントにとってより便利である一方、第一の利点は、帯域幅を節約できます。
The VANISHED response has the same restrictions on when it can be sent as does the EXPUNGE response (see below).
消え応答は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.
消えた応答は、2つの形式があります。最初の形式は、応答がFETCH UIDによって引き起こされたことを意味EARLIERタグ、（消滅）またはSELECT / EXAMINE（QRESYNC）コマンドを含みます。 UIDは、UID FETCH（消えた）コマンドにパラメータを設定した場合、この応答が送信されたメールボックスにしなくなったメッセージのUIDを含んでいます。クライアントは消え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.
第二の形態は、以前のタグを含まず、以下に説明します。クライアントが「QRESYNCをENABLE」を発行した後は、サーバーではなく、EXPUNGE応答の以前のタグなしで消えた応答を使用すべきです。サーバーは接続の間EXPUNGEの代わりに消えたの使用を継続すべきです。特に、これはEXPUNGE [RFC3501]とUID EXPUNGE [UIDPLUS]コマンド、ならびに他の接続に抹消メッセージに影響を与えます。このような消え応答は、以前のタグを含めることはできません。
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コマンドまたはメッセージが（先タグ無し即ち、消失応答）も、メールボックス内のメッセージの数をデクリメントする他の接続に消去されたので、送信された消失応答。サーバが新しい値でEXISTS応答を送信する必要はありません。それはまた、（このセクションの最後の例を参照）、メールボックス内の連続する各メッセージのメッセージシーケンス番号をデクリメントします。 EXPUNGE、UID EXPUNGE、または他の接続に抹消メッセージによって引き起こさ消え応答が唯一の現在開いているメールボックスまたはメールボックスが開かれてから送信された最後の消えた/ EXPUNGE応答以降に消去メッセージのためのUIDを含むべきであることに注意してください。これは、明示的にUID FETCH（消えた）コマンドによってそうするように要求されない限り、サーバは、以前に消去メッセージのためのUIDを送るべきではありません。
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.
クライアントの実装者が適切にサーバがこの最後のSHOULDに違反するか、返されたUIDのセットで同じUIDを複数回繰り返される場合でも、メールボックス内のメッセージの数を減少するために注意しなければならないことに注意してください。一般的に、これは、この拡張機能を使用して、クライアントが完全にメッセージ番号を使用しないよう、または選択したメールボックスのメッセージシーケンス番号へのUIDの完全なマッピングを持つべきであるのいずれかを意味します。
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.
クライアントが異なっ消え応答の2つの異なる形式を処理するので、サーバはUID FETCH（消えた）、または今抹消されたメッセージのUIDを同じ消え応じてSELECT / EXAMINE（QRESYNC）から生じたUIDを報告してはならない（つまり、メッセージが消去さ他の接続で）。 EARLIERタグと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、STORE、またはSEARCHコマンドに対応しながら、してはなりません。このルールは、クライアントとサーバの間のメッセージのシーケンス番号の同期の損失を防止する必要があります。コマンドは、完全なコマンドが受信されるまで、「進行中」ではありません。具体的には、コマンドはコマンド継続の交渉の際に、「進行中」ではありません。
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.
注：FETCH UID、UIDのSTORE、およびUID検索は、STORE、および検索をFETCH異なるコマンドです。消えた応答は、UIDコマンド中に送信されるかもしれません。しかし、消え応答は、検索基準にメッセージ番号が含まれているUID SEARCHコマンドの間に送ってはいけません。
The update from the VANISHED response MUST be recorded by the client.
消えたの応答の更新はクライアントによって記録されなければなりません。
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):
例：のは、現在選択されているメールボックスにメッセージ番号とUIDの（ここでは「X」は、\ Deletedフラグが設定されたメッセージをマークし、「x」は例えば関連していないUIDを表します）との間に、次のマッピングがあると仮定しましょう：
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 11のUID：X 504 505 507 508 X 510 X X X 625件の\削除済みメッセージ：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 EXPUNGE S：* 505507510625のSを消えた：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 (Continuing previous example) If subsequently messages with UIDs 504 and 508 got marked as \Deleted:
C：A202 EXPUNGE S：* 3 EXPUNGE S：* 3 EXPUNGEのS：* 5 EXPUNGE S：* 8 EXPUNGE S：UIDの504と508とのその後のメッセージは\削除済みとしてマークされてしまった場合はA202 OK EXPUNGEは（継続前の例を）完了しました：
C: A210 EXPUNGE S: * VANISHED 504,508 S: A210 OK EXPUNGE completed
C：A210 EXPUNGE S：* 504508のSを消えた：A210 OK EXPUNGEが完成
i.e., the last VANISHED response only contains UIDs of messages expunged since the previous VANISHED response.
すなわち、最後の消えた応答は、前の消え応答ので、消去されたメッセージのUIDを含んでいます。
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を使用して暗黙的に閉じているときに/別のメールボックスにコマンドを調べ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レスポンスコードを返す必要がありません。
This section describes a minimalist implementation, a moderate implementation, and an example of a full implementation.
このセクションでは、ミニマリストの実装、適度な実装、および完全な実装の一例を説明します。
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.
厳密に言えば、消去されたメッセージに関連付けられているMOD-シーケンスを覚えていないサーバーの実装は、この仕様に準拠して考えることができます。このような実装は、指定されたCHANGEDSINCE modのシーケンスに注意を払うことなく、UID FETCH（消えた）毎回コマンドのUIDセットで指定されたすべての抹消のメッセージを返します。彼らは同じUIDセットのためのUID SEARCHコマンドの結果よりも大きくしている姿を消した応答を返すまで終了することができますように、このような実装は、落胆しています。
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.
シーケンスの一致データがこの範囲を減らすことができ、メッセージを使用するクライアントは抹消が起こった、またはメールボックスの端に向かってのみ発生していない典型的な場合には、実質的応答を消えました。
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値を格納するサーバが消え応答を省略することができ抹消。
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.
メッセージシーケンスの一致データを提供するクライアントは、上記範囲を減少させることができます。何の抹消がなかった場合、サーバは、このデータを無視することができます。
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セット、MOD-シーケンス>ペアのキューを格納することです。 <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.
サーバーが指定されたMOD-シーケンスので、抹消メッセージを返すように要求を受信すると、それが尾からキューを検索します（つまり、最低に最高抹消MOD-シーケンスから行く）それはmod-との最初のレコードを見るまで所与MOD-配列以下の配列は、またはそれがキューの先頭に到達します。
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、MOD-シーケンス>が同時に消去されるメッセージの各範囲に対してトリプルこと実装を考えます。 MOD-シーケンスのための2つのUIDの各々について4つのオクテット、及び8つのオクテット：各トリプル16個のオクテットを必要とします。メッセージは、以前に1から始まるUIDを持つ存在していた、そして一度に消去された2 ** 32-1（最大可能なUID値）のUIDを有する単一のメッセージを含むメールボックスが存在すると仮定する。一人でこのメールボックスのために、ストレージはトリプル<1、1、modseq1>、要求される<2、2、modseq2>、...、<2 ** 32-2、2 ** 32-2、modseq4294967294>。
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.
したがって、実装は、そのような消去されたメッセージのためのmod-シーケンスを格納するために使用されるキューのサイズを制限し、この制限に達すると、古いレコードを「期限切れ」などのストレージの問題から保護するための戦略を採用することを奨励されています。選択された実装固有のキュー制限に達した場合、最も古いレコード（複数可）は、キューから削除される（このようなレコードは、キューの先頭に配置されていることに注意）。そのようなすべての「期限切れの」レコードの場合、サーバはすべてのための最高のmod-シーケンスである単一のmod-シーケンスを、格納する必要が消去されたメッセージを「期限切れ」。
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.
クライアントは、メッセージシーケンスのマッチデータを提供する場合、これは大きく不足しているのUIDの完全なセットを送信するデータコストを削減できることに注意してください。サーバーは、このキューの多くを持続することができない場合ので、クライアントのための問題を低減することができます。キューがバック要求されたMOD-シーケンスにデータが含まれている場合、このデータは無視することができます。
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が保存されるように、削除すべきかどうかということに注意してください。
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.
完全同期を完了した後、クライアントは、サーバから受信したデータ項目をFETCH任意の迷惑MODSEQのノートを取る必要があります。クライアントは、コマンドにタグ付けされた応答を受信するたびに、データ項目が、最後のタグ付けされた応答以降に受信されたFETCHすべてMODSEQの中で最も高い値を計算します。この値は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.
注：サーバーがMODSEQがmodseqenceの昇順にデータ項目をFETCH送信するために必要とされていないので、それが受信されるとすぐにMODSEQ FETCHデータ項目の値を持つHIGHESTMODSEQ値のクライアントのコピーを更新するのは安全ではありません。これは、接続損失の場合のいくつかの変更を逃しクライアントにつながることができます。
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パラメータを使用しています。クライアントに知られているようにQRESYNCパラメータは、UIDVALIDITYとメールボックスHIGHESTMODSEQ値が続いています。クライアントがメールボックスの部分的な同期のみに関心がある場合は、必要に応じて、例えば、のUIDのセットを続けることができます。また、クライアントは、メッセージ番号の知識を含むリストを送信してもよいです。
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.
工程dに記載されるように選択した場合/コマンドが成功したEXAMINE、クライアントは1）[IMAP-DISC]のセクション3）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].
成功したSELECT時/（QRESYNC）を調べると、クライアントが（代わりにHIGHESTMODSEQ応答コードの）NOMODSEQ OKタグなし応答を受信すると、そのキャッシュから最後の既知のHIGHESTMODSEQ値を削除して、第3節では、より一般的な手順に従わなければならないコマンド[IMAP-DISC]。
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:
次のようにQRESYNC＆CONDSTORE拡張の存在下で、[IMAP-DISC]のセクション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 of the [IMAP-DISC] for more details) after issuing SELECT/EXAMINE (QRESYNC) command.
図1a）SELECT / EXAMINE（QRESYNC）コマンドを発行した後（詳細は[IMAP-DISC]のセクション4.1を参照）、メールボックスのUIDVALIDITYを確認してください。
If the UIDVALIDITY value returned by the server differs, the
client MUST
* empty the local cache of that mailbox;
*そのメールボックスのローカルキャッシュを空にする。
* "forget" the cached HIGHESTMODSEQ value for the mailbox;
*メールボックスのキャッシュされたHIGHESTMODSEQ値を「忘れます」。
* 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]);
*そのメールボックスでのUIDを参照してください保留中の「アクション」を削除します。これは、クライアント上で実行されるアクションは、（[IMAP-DISC]のセクション5を参照）偽のUIDを生成した影響はありません、注意してください。
2) Fetch the current "descriptors";
2）現在の「記述子」をフェッチ。
I) Discover new messages.
私は）新しいメッセージを発見してください。
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 SELECTトレイ（QRESYNC（3857529045 20010715194032001 1：198））S * 172 SをEXISTS：* 1 RECENT S：* OK [UNSEEN 12]メッセージ12は、第1見えないSである：* OK [UIDVALIDITY 3857529045]のUID有効S。 * OK [UIDNEXT 201]予測された次のUIDのS：* FLAGS（\答える\フラグ付き\削除\見\ドラフト）S：* OK [PERMANENTFLAGS（\削除\見\ *）]リミテッドS：* OK [HIGHESTMODSEQ 20010715194045007] S *消失（以前）1：5,7：8,10：15 S：*（UID 6 MODSEQ（20010715205008000）FLAGS（\削除））SをFETCH 2：* FETCH 5（UID 9 MODSEQ（20010715195517000）FLAGS（$ NoJunk $ AutoJunk $ MDNSent））... S：A142 OK [READ-WRITE]を完了を選択
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF].
以下の構文仕様は、[ABNF]で指定された拡張バッカス・ナウアフォーム（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.
特記しないものを除いて、すべての英字は大文字と小文字を区別しません。トークン文字列を定義するための、大・小文字の使用は、編集上明確にするためです。実装は大文字と小文字を区別しないやり方で、これらの文字列を受け入れなければなりません。
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 MOD-シーケンス値[SP既知のUID] [SP配列マッチ・データ] "）" ;;一般的な選択-のparamに準拠;; [IMAPABNF]で定義された構文
seq-match-data = "(" known-sequence-set SP known-uid-set ")"
配列一致データ=「（」既知配列セットSP既知UIDセット「）」
uidvalidity = nz-number
UIDVALIDITY = NZ-数
known-uids = sequence-set ;; sequence of UIDs, "*" is not allowed
既知のUID =シーケンスセット;; UIDのシーケンスは、「*」は許可されていません
known-sequence-set = sequence-set ;; set of message numbers corresponding to ;; the UIDs in known-uid-set, in ascending order. ;; * is not allowed.
既知配列セット=シーケンスセット;; ;;に対応するメッセージ番号の組昇順に知ら-uidのセットでのUID、。 ;; *許可されていません。
known-uid-set = sequence-set ;; set of UIDs corresponding to the messages in ;; known-sequence-set, in ascending order. ;; * is not allowed.
既知のUID-セット=シーケンスセット;;内のメッセージに対応するのUIDのセット;;昇順で、既知配列を設定します。 ;; *許可されていません。
message-data =/ expunged-resp
メッセージデータ= /抹消-RESP
expunged-resp = "VANISHED" [SP "(EARLIER)"] SP known-uids
抹消-RESPは= "消失" [SP "（以前）"] SP既知のUID
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フェッチ-MOD = "消えた" ;; UIDは、修飾子が準拠FETCH消えた;;フェッチ修飾子を構文;; 【IMAPABNF]で定義されます。それだけです ;; UIDにFETCHコマンドを許可。
resp-text-code =/ "CLOSED"
RESP-テキストコード= / "CLOSED"
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]で上がっていない任意の新しいセキュリティ上の懸念を提起しません。
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
ｈっｔｐ：／／ｗっｗ。いあな。おｒｇ／あっしｇんめんｔｓ／いまｐ４ーかぱびぃちえｓ
This document defines the QRESYNC IMAP capability. IANA has added this capability to the registry.
この文書では、QRESYNC IMAP機能を定義します。 IANAは、レジストリにこの機能を追加しました。
Thanks to Steve Hole, Cyrus Daboo, and Michael Wener for encouraging creation of this document.
このドキュメントの作成を奨励するためのスティーブホール、サイラス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.
貴重なコメント、合意にと反対意見の両方で、ティモ・シレーヌン、マイケルWener、ランドールGellens、ARNT Gulbrandsenの、クリス・ニューマン、ピーター・コーツ、マーク・クリスピン、エルウィン・デイヴィス、ダン・カープ、エリックレスコラ、およびマイクZralyから受け取りました。
This document takes substantial text from [RFC3501] by Mark Crispin.
この文書では、マーク・クリスピンで[RFC3501]からかなりのテキストを取ります。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
、STD 68、RFC 5234、2008年1月： "ABNF構文仕様のための増大しているBNF" [ABNF]クロッカー、D.、およびP. Overell、。
[CONDSTORE] Melnikov, A. and S. Hole, "IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization", RFC 4551, June 2006.
[CONDSTORE]メルニコフ、A.とS.ホール、 "条件付きSTORE操作やクイックフラグの変更を再同期化のためのIMAP拡張"、RFC 4551、2006年6月。
[ENABLE] Gulbrandsen, A., Ed. and A. Melnikov, Ed., "The IMAP ENABLE Extension", RFC 5161, March 2008.
Gulbrandsenの、A.編を[有効]。そして、A.メルニコフ、エド。、2008年3月、RFC 5161 "IMAPエクステンションを有効にします"。
[IMAPABNF] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006.
[IMAPABNF]メルニコフ、A.およびC. Dabooは、RFC 4466、2006年4月 "IMAP4 ABNFへの拡張を集めました"。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501]のCrispin、M.、 "インターネットメッセージアクセスプロトコル - VERSION 4rev1"、RFC 3501、2003年3月。
[UIDPLUS] Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS extension", RFC 4315, December 2005.
[UIDPLUS]クリスピン、M.、 "インターネットメッセージアクセスプロトコル（IMAP） - UIDPLUS延長"、RFC 4315、2005年12月。
[IMAP-DISC] Melnikov, A., Ed., "Synchronization Operations For Disconnected Imap4 Clients", RFC 4549, June 2006.
[IMAP-DISC]メルニコフ、A.編、RFC 4549、2006年6月 "同期オペレーション切断IMAP4クライアントのために"。
[UNSELECT] Melnikov, A., "Internet Message Access Protocol (IMAP) UNSELECT command", RFC 3691, February 2004.
[UNSELECT]メルニコフ、A.、 "インターネットメッセージアクセスプロトコル（IMAP）UNSELECTコマンド"、RFC 3691、2004年2月。
Authors' Addresses
著者のアドレス
Alexey Melnikov Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
アレクセイ・メルニコフISODE株式会社5キャッスルビジネス村の36の駅道ハンプトン、ミドル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株式会社5キャッスルビジネス村の36の駅道ハンプトン、ミドルTW12 2BX英国
EMail: dave.cridland@isode.com
メールアドレス：dave.cridland@isode.com
Corby Wilson Nokia 5 Wayside Rd. Burlington, MA 01803 USA
コービー・ウィルソンノキア5ウェイサイドRdを。バーリントン、MA 01803 USA
EMail: corby@computer.org
メールアドレス：corby@computer.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。