[要約] RFC 7162はIMAPの拡張機能であり、Quick Flag Changes Resynchronization (CONDSTORE)とQuick Mailbox Resynchronization (QRESYNC)を提供します。目的は、効率的なフラグの変更とメールボックスの同期を実現することです。
Internet Engineering Task Force (IETF) A. Melnikov
Request for Comments: 7162 Isode Ltd
Obsoletes: 4551, 5162 D. Cridland
Updates: 2683 Surevine Ltd
Category: Standards Track May 2014
ISSN: 2070-1721
IMAP Extensions: Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC)
IMAP拡張機能：クイックフラグ変更の再同期（CONDSTORE）およびクイックメールボックスの再同期（QRESYNC）
Abstract
概要
Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user and multiple users accessing shared mailboxes. These clients need a mechanism to efficiently synchronize state changes for messages within the mailbox.
多くの場合、複数のIMAP（RFC 3501）クライアントは、共通のIMAPメールボックスへの変更を調整する必要があります。例としては、同じユーザーに代わって動作するさまざまなクライアントや、共有メールボックスにアクセスする複数のユーザーなどがあります。これらのクライアントには、メールボックス内のメッセージの状態変更を効率的に同期するメカニズムが必要です。
Initially defined in RFC 4551, the Conditional Store facility provides a protected update mechanism for message state information and a mechanism for requesting only changes to the message state. This memo updates that mechanism and obsoletes RFC 4551, based on operational experience.
RFC 4551で最初に定義された条件付きストア機能は、メッセージ状態情報の保護された更新メカニズムと、メッセージ状態の変更のみを要求するメカニズムを提供します。このメモは、そのメカニズムを更新し、運用経験に基づいてRFC 4551を廃止します。
This document additionally updates another IMAP extension, Quick Resynchronization, which builds on the Conditional STORE extension to provide an IMAP client the ability to fully resynchronize a mailbox as part of the SELECT/EXAMINE command, without the need for additional server-side state or client round trips. Hence, this memo obsoletes RFC 5162.
このドキュメントは、条件付きSTORE拡張に基づいて構築された別のIMAP拡張機能であるQuick Resynchronizationをさらに更新して、追加のサーバー側の状態またはクライアントを必要とせずにIMAPクライアントがSELECT / EXAMINEコマンドの一部としてメールボックスを完全に再同期できるようにします往復。したがって、このメモはRFC 5162を廃止します。
Finally, this document also updates the line-length recommendation in Section 3.2.1.5 of RFC 2683.
最後に、このドキュメントでは、RFC 2683のセクション3.2.1.5の推奨される行長も更新されています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7162.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7162で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。 IETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5
3. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 5
3.1. CONDSTORE Extension . . . . . . . . . . . . . . . . . . . 5
3.1.1. Advertising Support for CONDSTORE . . . . . . . . . . 8
3.1.2. New OK Untagged Responses for SELECT and EXAMINE . . 8
3.1.3. STORE and UID STORE Commands . . . . . . . . . . . . 10
3.1.4. FETCH and UID FETCH Commands . . . . . . . . . . . . 16
3.1.5. MODSEQ Search Criterion in SEARCH . . . . . . . . . . 19
3.1.6. Modified SEARCH Untagged Response . . . . . . . . . . 20
3.1.7. HIGHESTMODSEQ Status Data Items . . . . . . . . . . . 21
3.1.8. CONDSTORE Parameter to SELECT and EXAMINE . . . . . . 21
3.1.9. Interaction with IMAP SORT and THREAD Extensions . . 22
3.1.10. Interaction with IMAP ESORT and ESEARCH Extensions . 22
3.1.11. Additional Quality-of-Implementation Issues . . . . . 23
3.1.12. CONDSTORE Server Implementation Considerations . . . 23
3.2. QRESYNC Extension . . . . . . . . . . . . . . . . . . . . 24
3.2.1. Impact on CONDSTORE-only Clients . . . . . . . . . . 25
3.2.2. Advertising Support for QRESYNC . . . . . . . . . . . 25
3.2.3. Use of ENABLE . . . . . . . . . . . . . . . . . . . . 25
3.2.4. Additional Requirements on QRESYNC Servers . . . . . 26
3.2.5. QRESYNC Parameter to SELECT/EXAMINE . . . . . . . . . 26
3.2.6. VANISHED UID FETCH Modifier . . . . . . . . . . . . . 31
3.2.7. EXPUNGE Command . . . . . . . . . . . . . . . . . . . 32
3.2.8. CLOSE Command . . . . . . . . . . . . . . . . . . . . 33
3.2.9. UID EXPUNGE Command . . . . . . . . . . . . . . . . . 34
3.2.10. VANISHED Response . . . . . . . . . . . . . . . . . . 35
3.2.11. CLOSED Response Code . . . . . . . . . . . . . . . . 38
4. Long Command Lines (Update to RFC 2683) . . . . . . . . . . . 39
5. QRESYNC Server Implementation Considerations . . . . . . . . 39
5.1. Server Implementations That Don't Store Extra State . . . 39
5.2. Server Implementations Storing Minimal State . . . . . . 40
5.3. Additional State Required on the Server . . . . . . . . . 40
6. Updated Synchronization Sequence . . . . . . . . . . . . . . 41
7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 44
8. Security Considerations . . . . . . . . . . . . . . . . . . . 48
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 48
10.1. Normative References . . . . . . . . . . . . . . . . . . 48
10.2. Informative References . . . . . . . . . . . . . . . . . 49
Appendix A. Changes since RFC 4551 . . . . . . . . . . . . . . . 50
Appendix B. Changes since RFC 5162 . . . . . . . . . . . . . . . 50
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 51
Often, multiple IMAP [RFC3501] clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user and clients representing multiple users accessing shared mailboxes. These clients need a mechanism to synchronize state changes for messages within the mailbox. The Conditional Store ("CONDSTORE") facility allows a client to quickly resynchronize mailbox flag changes.
多くの場合、複数のIMAP [RFC3501]クライアントは、共通のIMAPメールボックスへの変更を調整する必要があります。たとえば、同じユーザーに代わって動作するさまざまなクライアントや、共有メールボックスにアクセスする複数のユーザーを表すクライアントが含まれます。これらのクライアントには、メールボックス内のメッセージの状態変更を同期するメカニズムが必要です。条件付きストア（「CONDSTORE」）機能により、クライアントはメールボックスフラグの変更をすばやく再同期できます。
The Conditional Store facility also provides a protected update mechanism for message state information that can detect and resolve conflicts between multiple writing mail clients. The mechanism can be used to guarantee that only one client can change the message state at any given time. For example, this can be used by multiple clients that treat a mailbox as a message queue.
条件付きストア機能は、複数の書き込みメールクライアント間の競合を検出して解決できるメッセージ状態情報の保護された更新メカニズムも提供します。このメカニズムを使用して、常に1つのクライアントのみがメッセージの状態を変更できることを保証できます。たとえば、これはメールボックスをメッセージキューとして扱う複数のクライアントで使用できます。
The Conditional Store facility is provided by associating a modification sequence (mod-sequence) with every IMAP message. This is updated whenever metadata (such as a message flag) is modified.
条件付きストア機能は、すべてのIMAPメッセージに変更シーケンス（mod-sequence）を関連付けることによって提供されます。これは、メタデータ（メッセージフラグなど）が変更されるたびに更新されます。
The CONDSTORE extension is described in more detail in Section 3.1.
CONDSTORE拡張機能については、セクション3.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. The Quick Mailbox Resynchronization (QRESYNC) IMAP extension is an extension to CONDSTORE that allows a reconnecting client to perform full resynchronization, including discovery of expunged messages, in a single round trip. QRESYNC 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コマンドを発行する必要があります。 Quick Mailbox Resynchronization（QRESYNC）IMAP拡張機能はCONDSTOREの拡張機能で、再接続しているクライアントが、消去されたメッセージの検出を含む完全な再同期を1回の往復で実行できるようにします。 QRESYNCは、削除されたメッセージのリストをよりコンパクトに表現できる新しい応答VANISHEDも導入しています。
QRESYNC can be useful for mobile clients that can experience frequent disconnects caused by environmental factors (such as 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 generated by resynchronization.
QRESYNCは、環境要因（バッテリーの寿命、信号強度など）が原因で頻繁に切断されるモバイルクライアントに役立ちます。このようなクライアントには、ユーザーが経験する遅延と再同期によって生成されるトラフィックの量を最小限に抑えながら、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 QRESYNC extension is described in more detail in Section 3.2.
QRESYNC拡張機能については、セクション3.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」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
In the examples that follow, "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文字[...]は、何かが省略されていることを意味します。
Formal syntax is defined using ABNF [RFC5234].
正式な構文は、ABNF [RFC5234]を使用して定義されます。
The term "metadata" or "metadata item" is used throughout this document. It refers to any system- or user-defined keyword. If the server supports the IMAP ANNOTATE-EXPERIMENT-1 extension [RFC5257], then metadata also includes message annotations. Future documents may extend "metadata" to include other dynamic message data.
このドキュメントでは、「メタデータ」または「メタデータアイテム」という用語を使用しています。システムまたはユーザー定義のキーワードを指します。サーバーがIMAP ANNOTATE-EXPERIMENT-1拡張[RFC5257]をサポートしている場合、メタデータにはメッセージの注釈も含まれます。今後のドキュメントでは、「メタデータ」を拡張して他の動的メッセージデータを含める可能性があります。
Some IMAP mailboxes are private, accessible only to the owning user. Other mailboxes are not, either because the owner has set an Access Control List [RFC4314] that permits access by other users or because it is a shared mailbox. Let's call a metadata item "shared" for the mailbox if any changes to the metadata items are persistent and visible to all other users accessing the mailbox. Otherwise, the metadata item is called "private". Note that private metadata items are still visible to all sessions accessing the mailbox as the same user. Also, note that different mailboxes may have different metadata items as shared.
一部のIMAPメールボックスはプライベートであり、所有ユーザーのみがアクセスできます。他のメールボックスは、所有者が他のユーザーによるアクセスを許可するアクセス制御リスト[RFC4314]を設定したか、共有メールボックスであるため、そうではありません。メタデータアイテムへの変更が永続的で、メールボックスにアクセスする他のすべてのユーザーに表示される場合は、メールボックスのメタデータアイテムを「共有」と呼びましょう。それ以外の場合、メタデータアイテムは「プライベート」と呼ばれます。プライベートメタデータアイテムは、同じユーザーとしてメールボックスにアクセスするすべてのセッションで引き続き表示されることに注意してください。また、メールボックスごとに、メタデータアイテムが共有されている場合があることに注意してください。
See Section 3.1 for the definition of a "CONDSTORE-aware client" and a "CONDSTORE enabling command".
「CONDSTORE対応クライアント」および「CONDSTORE有効化コマンド」の定義については、セクション3.1を参照してください。
Understanding of the IMAP message sequence numbers and UIDs (see Section 2.3.1 of [RFC3501]) and the EXPUNGE response (see Section 7.4.1 of [RFC3501]) is essential when reading this document.
このドキュメントを読むときは、IMAPメッセージのシーケンス番号とUID（[RFC3501]のセクション2.3.1を参照）およびEXPUNGE応答（[RFC3501]のセクション7.4.1を参照）を理解することが不可欠です。
An IMAP server that supports CONDSTORE MUST associate a positive unsigned 63-bit (*) value, called a mod-sequence, with every IMAP message. This is an opaque value updated by the server whenever a metadata item is modified. The server MUST guarantee that each STORE command performed on the same mailbox (including simultaneous stores to different metadata items from different connections) will get a different mod-sequence value. Also, for any two successful STORE operations performed in the same session on the same mailbox, the mod-sequence of the second completed operation MUST be greater than the mod-sequence of the first completed operation. Note that the latter rule disallows the direct use of the system clock as a mod-sequence because if system time changes (e.g., an NTP [NTP] client adjusting the time), the next generated value might be less than the previous one.
CONDSTOREをサポートするIMAPサーバーは、mod-sequenceと呼ばれる正の符号なし63ビット（*）値をすべてのIMAPメッセージに関連付ける必要があります。これは、メタデータアイテムが変更されるたびにサーバーによって更新される不透明な値です。サーバーは、同じメールボックス（異なる接続からの異なるメタデータアイテムへの同時ストアを含む）で実行される各STOREコマンドが異なるmod-sequence値を取得することを保証する必要があります。また、同じメールボックスの同じセッションで実行される2つの成功したSTORE操作の場合、2番目に完了した操作のmodシーケンスは、最初に完了した操作のmodシーケンスよりも大きい必要があります。後者のルールでは、システム時刻が変更されると（たとえば、NTP [NTP]クライアントが時刻を調整する場合）、次に生成される値が前の値より小さくなる可能性があるため、modシーケンスとしてシステムクロックを直接使用することはできません。
(*) Note: RFC 4551 defined mod-sequences as unsigned 64-bit values. In order to make implementations on various platforms (such as Java) easier, this version of the document redefines them as unsigned 63-bit values.
（*）注：RFC 4551は、modシーケンスを符号なし64ビット値として定義しました。さまざまなプラットフォーム（Javaなど）での実装を容易にするために、このバージョンのドキュメントでは、それらを符号なし63ビット値として再定義しています。
These rules allow a client to list all metadata changes since a well-known point in time, as well as to perform conditional metadata modifications based on an assumption that the metadata state hasn't changed for a particular message.
これらのルールにより、クライアントは、既知の時点以降のすべてのメタデータの変更を一覧表示し、特定のメッセージのメタデータの状態が変更されていないという前提に基づいて、条件付きのメタデータの変更を実行できます。
In particular, mod-sequences allow a client that supports the CONDSTORE extension to determine if a message metadata has changed since some known moment. Whenever the state of a flag changes (i.e., the flag is added where previously it wasn't set, or the flag is removed where previously it was set), the value of the modification sequence for the message MUST be updated. Setting a flag that is already set, or clearing a flag that is not set, SHOULD NOT change the mod-sequence.
特に、mod-sequencesにより、CONDSTORE拡張をサポートするクライアントは、既知の瞬間以降にメッセージメタデータが変更されたかどうかを判断できます。フラグの状態が変化するたびに（つまり、以前に設定されていなかった場所にフラグが追加されるか、以前に設定された場所にフラグが削除される）、メッセージの変更シーケンスの値を更新する必要があります。すでに設定されているフラグを設定するか、設定されていないフラグをクリアする場合は、mod-sequenceを変更してはなりません（SHOULD NOT）。
When a message is appended to a mailbox (via the IMAP APPEND command, COPY to the mailbox, or using an external mechanism), the server generates a new modification sequence that is higher than the highest modification sequence of all messages in the mailbox and assigns it to the appended message.
メッセージがメールボックスに追加されると（IMAP APPENDコマンド、メールボックスへのCOPYを介して、または外部メカニズムを使用して）、サーバーはメールボックス内のすべてのメッセージの最高の変更シーケンスよりも高い新しい変更シーケンスを生成し、割り当てます追加されたメッセージにそれを。
The server MAY store separate (per-message) modification sequence values for different metadata items. If the server does so, per-message mod-sequence is the highest mod-sequence of all metadata items accessible to the currently logged-in user for the specified message.
サーバーは、異なるメタデータアイテムに対して個別の（メッセージごとの）修正シーケンス値を格納できます（MAY）。サーバーがそうする場合、メッセージごとのmod-sequenceは、指定されたメッセージの現在ログインしているユーザーがアクセスできるすべてのメタデータ項目の最も高いmod-sequenceです。
The server that supports CONDSTORE is not required to be able to store mod-sequences for every available mailbox. Section 3.1.2.2 describes how the server may act if a particular mailbox doesn't support the persistent storage of mod-sequences.
CONDSTOREをサポートするサーバーは、使用可能なすべてのメールボックスのmodシーケンスを格納できる必要はありません。セクション3.1.2.2は、特定のメールボックスがmodシーケンスの永続的なストレージをサポートしていない場合のサーバーの動作を説明しています。
CONDSTORE makes the following changes to the IMAP4 protocol:
CONDSTOREは、IMAP4プロトコルに次の変更を加えます。
a. adds the UNCHANGEDSINCE STORE modifier.
a. UNCHANGEDSINCE STORE修飾子を追加します。
b. adds the MODIFIED response code that is used with an OK response to the STORE command. (It can also be used in a NO response.)
b. OK応答で使用されるMODIFIED応答コードをSTOREコマンドに追加します。 （NO応答でも使用できます。）
c. adds a new MODSEQ message data item for use with the FETCH command.
c. FETCHコマンドで使用する新しいMODSEQメッセージデータ項目を追加します。
d. adds the CHANGEDSINCE FETCH modifier.
d. CHANGEDSINCE FETCH修飾子を追加します。
e. adds a new MODSEQ search criterion.
e. 新しいMODSEQ検索基準を追加します。
f. extends the syntax of untagged SEARCH and ESEARCH responses to include mod-sequence.
f. タグなしのSEARCHおよびESEARCH応答の構文を拡張して、mod-sequenceを含めます。
g. adds new OK untagged responses (HIGHESTMODSEQ and NOMODSEQ) for the SELECT and EXAMINE commands.
g. SELECTおよびEXAMINEコマンドに新しいOKタグなし応答（HIGHESTMODSEQおよびNOMODSEQ）を追加します。
h. defines an additional CONDSTORE parameter to SELECT/EXAMINE commands.
h. SELECT / EXAMINEコマンドに追加のCONDSTOREパラメータを定義します。
i. adds the HIGHESTMODSEQ status data item to the STATUS command.
i. HIGHESTMODSEQステータスデータ項目をSTATUSコマンドに追加します。
A client supporting the CONDSTORE extension indicates its willingness to receive mod-sequence updates in all untagged FETCH responses by issuing one of the following, which are called "CONDSTORE enabling commands":
CONDSTORE拡張をサポートするクライアントは、「CONDSTORE有効化コマンド」と呼ばれる次のいずれかを発行することにより、タグなしのすべてのFETCH応答でmodシーケンス更新を受信する意思を示します。
o a SELECT or EXAMINE command with the CONDSTORE parameter,
o CONDSTOREパラメータを指定したSELECTまたはEXAMINEコマンド
o a STATUS (HIGHESTMODSEQ) command,
o STATUS（HIGHESTMODSEQ）コマンド
o a FETCH or SEARCH command that includes the MODSEQ message data item,
o MODSEQメッセージデータ項目を含むFETCHまたはSEARCHコマンド
o a FETCH command with the CHANGEDSINCE modifier,
o CHANGEDSINCE修飾子を含むFETCHコマンド
o a STORE command with the UNCHANGEDSINCE modifier, or
o UNCHANGEDSINCE修飾子を使用したSTOREコマンド、または
o an ENABLE command containing "CONDSTORE" as one of the parameters. (This option only applies when the client is communicating with a server that also implements the ENABLE extension [RFC5161].)
o パラメータの1つとして「CONDSTORE」を含むENABLEコマンド。 （このオプションは、クライアントがENABLE拡張[RFC5161]も実装しているサーバーと通信している場合にのみ適用されます。）
Once a client issues a CONDSTORE enabling command, it has announced itself as a "CONDSTORE-aware client". The server MUST then include mod-sequence data in all subsequent untagged FETCH responses (until the connection is closed), whether they were caused by a regular STORE, a STORE with an UNCHANGEDSINCE modifier, or an external agent.
クライアントがCONDSTORE有効化コマンドを発行すると、それ自体が「CONDSTORE対応クライアント」としてアナウンスされます。その後、サーバーは、通常のSTORE、UNCHANGEDSINCE修飾子付きのSTORE、または外部エージェントによって引き起こされたものかどうかに関係なく、（接続が閉じられるまで）後続のすべてのタグなしFETCH応答にmodシーケンスデータを含める必要があります。
A future extension to this document may extend the list of CONDSTORE enabling commands. A first CONDSTORE enabling command executed in the session with a mailbox selected MUST cause the server to return HIGHESTMODSEQ (Section 3.1.2.1) for the mailbox (if any is selected), unless the server has sent a NOMODSEQ (Section 3.1.2.2) response code when the currently selected mailbox was selected.
このドキュメントの将来の拡張により、CONDSTORE有効化コマンドのリストが拡張される可能性があります。メールボックスが選択されているセッションで最初のCONDSTORE有効化コマンドを実行すると、サーバーがNOMODSEQ（セクション3.1.2.2）応答を送信しない限り、サーバーはメールボックス（選択されている場合）に対してHIGHESTMODSEQ（セクション3.1.2.1）を返す必要があります。現在選択されているメールボックスが選択されたときのコード。
The Conditional STORE extension is present in any IMAP4 implementation that returns "CONDSTORE" as one of the supported capabilities in the CAPABILITY command response.
条件付きSTORE拡張は、CAPABILITYコマンド応答でサポートされる機能の1つとして「CONDSTORE」を返すすべてのIMAP4実装に存在します。
This document adds two new response codes: HIGHESTMODSEQ and NOMODSEQ. One of these two response codes MUST be returned in an OK untagged response for any successful SELECT/EXAMINE command issued after a CONDSTORE enabling command.
このドキュメントでは、HIGHESTMODSEQとNOMODSEQの2つの新しい応答コードを追加しています。これらの2つの応答コードの1つは、CONDSTORE有効化コマンドの後に発行されたSELECT / EXAMINEコマンドが成功した場合、タグなしのOK応答で返される必要があります。
When opening a mailbox, the server must check if the mailbox supports the persistent storage of mod-sequences. If the mailbox supports the persistent storage of mod-sequences and the mailbox open operation succeeds, the server MUST send an OK untagged response, including the HIGHESTMODSEQ response code. If the persistent storage for the mailbox is not supported, the server MUST send an OK untagged response, including the NOMODSEQ response code instead.
メールボックスを開くとき、サーバーはメールボックスがmodシーケンスの永続的なストレージをサポートしているかどうかを確認する必要があります。メールボックスがmodシーケンスの永続的なストレージをサポートし、メールボックスのオープン操作が成功した場合、サーバーはHIGHESTMODSEQ応答コードを含むOKタグなし応答を送信しなければなりません（MUST）。メールボックスの永続的なストレージがサポートされていない場合、サーバーは、NOMODSEQ応答コードを含むOKタグなし応答を送信する必要があります。
This document adds a new response code that is returned in an OK untagged response for the SELECT and EXAMINE commands. Once a CONDSTORE enabling command is issued, a server supporting the persistent storage of mod-sequences for the mailbox MUST send an OK untagged response, including the HIGHESTMODSEQ response code with every successful SELECT or EXAMINE command:
このドキュメントでは、SELECTおよびEXAMINEコマンドのタグなしOK応答で返される新しい応答コードを追加します。 CONDSTORE有効化コマンドが発行されると、メールボックスのmodシーケンスの永続的ストレージをサポートするサーバーは、成功したすべてのSELECTまたはEXAMINEコマンドでHIGHESTMODSEQ応答コードを含む、OKタグなし応答を送信する必要があります。
OK [HIGHESTMODSEQ <mod-sequence-value>]
OK [HIGHESTMODSEQ <mod-sequence-value>]
where <mod-sequence-value> is the highest mod-sequence value of all messages in the mailbox. When the server changes UIDVALIDITY for a mailbox, it doesn't have to keep the same HIGHESTMODSEQ for the mailbox.
ここで、<mod-sequence-value>は、メールボックス内のすべてのメッセージの最高のmod-sequence値です。サーバーがメールボックスのUIDVALIDITYを変更するとき、メールボックスの同じHIGHESTMODSEQを維持する必要はありません。
Note that some existing CONDSTORE servers don't start tracking mod-sequences or don't report them until after a CONDSTORE enabling command is issued. Because of that, a client wishing to receive HIGHESTMODSEQ/NOMODSEQ information must first send a CONDSTORE enabling command, for example, by using SELECT/EXAMINE with the CONDSTORE parameter (see Section 3.1.8).
一部の既存のCONDSTOREサーバーは、CONDSTORE有効化コマンドが発行されるまで、modシーケンスの追跡を開始しないか、mod-sequenceを報告しません。そのため、HIGHESTMODSEQ / NOMODSEQ情報を受信したいクライアントは、最初にCONDSTORE有効化コマンドを送信する必要があります。たとえば、SELECT / EXAMINEをCONDSTOREパラメータとともに使用します（セクション3.1.8を参照）。
A disconnected client can use the value of HIGHESTMODSEQ to check if it has to refetch metadata from the server. If the UIDVALIDITY value has changed for the selected mailbox, the client MUST delete the cached value of HIGHESTMODSEQ. If UIDVALIDITY for the mailbox is the same, and if the HIGHESTMODSEQ value stored in the client's cache is less than the value returned by the server, then some metadata items on the server have changed since the last synchronization, and the client needs to update its cache. The client MAY use SEARCH MODSEQ (Section 3.1.5) to find out exactly which metadata items have changed. Alternatively, the client MAY issue FETCH with the CHANGEDSINCE modifier (Section 3.1.4.1) in order to fetch data for all messages that have metadata items changed since some known modification sequence.
切断されたクライアントは、HIGHESTMODSEQの値を使用して、サーバーからメタデータを再フェッチする必要があるかどうかを確認できます。選択したメールボックスのUIDVALIDITY値が変更された場合、クライアントはHIGHESTMODSEQのキャッシュされた値を削除する必要があります。メールボックスのUIDVALIDITYが同じで、クライアントのキャッシュに格納されているHIGHESTMODSEQ値がサーバーから返された値よりも小さい場合、サーバー上の一部のメタデータアイテムが最後の同期以降に変更されており、クライアントはその更新を行う必要があります。キャッシュ。クライアントは、SEARCH MODSEQ（セクション3.1.5）を使用して、変更されたメタデータ項目を正確に見つけることができます（MAY）。あるいは、クライアントは、既知の変更シーケンス以降にメタデータ項目が変更されたすべてのメッセージのデータをフェッチするために、CHANGEDSINCE修飾子（セクション3.1.4.1）を使用してFETCHを発行できます（MAY）。
C: A142 SELECT INBOX
S: * 172 EXISTS
S: * 1 RECENT
S: * OK [UNSEEN 12] Message 12 is first unseen
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * OK [UIDNEXT 4392] Predicted next UID
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
S: * OK [HIGHESTMODSEQ 715194045007]
S: A142 OK [READ-WRITE] SELECT completed
Example 1
例1
Once a CONDSTORE enabling command is issued, a server that doesn't support the persistent storage of mod-sequences for the mailbox MUST send an OK untagged response, including the NOMODSEQ response code with every successful SELECT or EXAMINE command. Note that some existing CONDSTORE servers don't return NOMODSEQ until after a CONDSTORE enabling command is issued. Because of that, a client wishing to receive HIGHESTMODSEQ/NOMODSEQ information must first send a CONDSTORE enabling command, for example, by using SELECT/EXAMINE with the CONDSTORE parameter (see Section 3.1.8).
CONDSTORE有効化コマンドが発行されると、メールボックスのmodシーケンスの永続的なストレージをサポートしないサーバーは、成功したすべてのSELECTまたはEXAMINEコマンドでNOMODSEQ応答コードを含むOKタグなし応答を送信する必要があります。既存の一部のCONDSTOREサーバーは、CONDSTORE有効化コマンドが発行されるまでNOMODSEQを返さないことに注意してください。そのため、HIGHESTMODSEQ / NOMODSEQ情報を受信したいクライアントは、最初にCONDSTORE有効化コマンドを送信する必要があります。たとえば、SELECT / EXAMINEをCONDSTOREパラメータとともに使用します（セクション3.1.8を参照）。
A server that returned the NOMODSEQ response code for a mailbox MUST reject (with a tagged BAD response) any of the following commands while the mailbox remains selected:
メールボックスのNOMODSEQ応答コードを返したサーバーは、メールボックスが選択されている間、次のコマンドを（タグ付きのBAD応答で）拒否する必要があります。
o a FETCH command with the CHANGEDSINCE modifier,
o CHANGEDSINCE修飾子を含むFETCHコマンド
o a FETCH or SEARCH command that includes the MODSEQ message data item, or
o MODSEQメッセージデータ項目を含むFETCHまたはSEARCHコマンド、または
o a STORE command with the UNCHANGEDSINCE modifier.
o UNCHANGEDSINCE修飾子を指定したSTOREコマンド。
C: A142 SELECT INBOX
S: * 172 EXISTS
S: * 1 RECENT
S: * OK [UNSEEN 12] Message 12 is first unseen
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * OK [UIDNEXT 4392] Predicted next UID
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
S: * OK [NOMODSEQ] Sorry, this mailbox format doesn't support
modsequences
S: A142 OK [READ-WRITE] SELECT completed
Example 2
例2
This document defines the following STORE modifier (see Section 2.5 of [RFC4466]):
このドキュメントでは、次のSTORE修飾子を定義しています（[RFC4466]のセクション2.5を参照）。
UNCHANGEDSINCE <mod-sequence>
UNCHANGEDSINCE <mod-sequence>
For each message specified in the message set, the server performs the following. If the mod-sequence of every metadata item of the message affected by the STORE/UID STORE is equal to or less than the specified UNCHANGEDSINCE value, then the requested operation (as described by the message data item) is performed. If the operation is successful, the server MUST update the mod-sequence attribute of the message. An untagged FETCH response MUST be sent, even if the .SILENT suffix is specified, and the response MUST include the MODSEQ message data item. This is required to update the client's cache with the correct mod-sequence values. See Section 3.1.4.2 for more details.
メッセージセットで指定されたメッセージごとに、サーバーは次のことを実行します。 STORE / UID STOREの影響を受けるメッセージのすべてのメタデータアイテムのmod-sequenceが指定されたUNCHANGEDSINCE値以下の場合、要求された操作（メッセージデータアイテムで説明）が実行されます。操作が成功した場合、サーバーはメッセージのmod-sequence属性を更新する必要があります。 .SILENTサフィックスが指定されている場合でも、タグなしFETCH応答を送信する必要があり、応答にはMODSEQメッセージデータ項目を含める必要があります。これは、クライアントのキャッシュを正しいmod-sequence値で更新するために必要です。詳細については、セクション3.1.4.2を参照してください。
However, if the mod-sequence of any metadata item of the message is greater than the specified UNCHANGEDSINCE value, then the requested operation MUST NOT be performed. In this case, the mod-sequence attribute of the message is not updated, and the message number (or unique identifier in the case of the UID STORE command) is added to the list of messages that failed the UNCHANGEDSINCE test.
ただし、メッセージのメタデータ項目のmod-sequenceが指定されたUNCHANGEDSINCE値より大きい場合、要求された操作を実行してはなりません（MUST NOT）。この場合、メッセージのmod-sequence属性は更新されず、メッセージ番号（またはUID STOREコマンドの場合は一意の識別子）がUNCHANGEDSINCEテストに失敗したメッセージのリストに追加されます。
When the server finishes performing the operation on all the messages in the message set, it checks for a non-empty list of messages that failed the UNCHANGEDSINCE test. If this list is non-empty, the server MUST return in the tagged response a MODIFIED response code. The MODIFIED response code includes the message set (for STORE) or set of UIDs (for UID STORE) of all messages that failed the UNCHANGEDSINCE test.
サーバーは、メッセージセット内のすべてのメッセージに対する操作の実行を完了すると、UNCHANGEDSINCEテストに失敗したメッセージの空でないリストをチェックします。このリストが空でない場合、サーバーはタグ付き応答でMODIFIED応答コードを返さなければなりません（MUST）。 MODIFIED応答コードには、UNCHANGEDSINCEテストに失敗したすべてのメッセージのメッセージセット（STOREの場合）またはUIDのセット（UID STOREの場合）が含まれます。
All messages pass the UNCHANGEDSINCE test.
すべてのメッセージはUNCHANGEDSINCEテストに合格します。
C: a103 UID STORE 6,4,8 (UNCHANGEDSINCE 12121230045)
+FLAGS.SILENT (\Deleted)
S: * 1 FETCH (UID 4 MODSEQ (12121231000))
S: * 2 FETCH (UID 6 MODSEQ (12121230852))
S: * 4 FETCH (UID 8 MODSEQ (12121230956))
S: a103 OK Conditional Store completed
Example 3
例3
C: a104 STORE * (UNCHANGEDSINCE 12121230045) +FLAGS.SILENT
(\Deleted $Processed)
S: * 50 FETCH (MODSEQ (12111230047))
S: a104 OK Store (conditional) completed
Example 4
実施例4
C: c101 STORE 50 (UNCHANGEDSINCE 12121230045) -FLAGS.SILENT
(\Deleted)
S: * OK [HIGHESTMODSEQ 12111230047]
S: * 50 FETCH (MODSEQ (12111230048))
S: c101 OK Store (conditional) completed
The HIGHESTMODSEQ response code was sent by the server presumably because this was the first CONDSTORE enabling command.
HIGHESTMODSEQ応答コードは、おそらくこれが最初のCONDSTORE有効化コマンドだったため、サーバーによって送信されました。
Example 5
例5
The failure of the conditional STORE operation for any particular message or messages (7 in this example) does not stop the server from finding all messages that fail the UNCHANGEDSINCE test. All such messages are returned in the MODIFIED response code.
特定の1つまたは複数のメッセージ（この例では7）に対する条件付きSTORE操作が失敗しても、サーバーはUNCHANGEDSINCEテストに失敗したすべてのメッセージを見つけることができます。このようなメッセージはすべて、MODIFIED応答コードで返されます。
C: d105 STORE 7,5,9 (UNCHANGEDSINCE 320162338)
+FLAGS.SILENT (\Deleted)
S: * 5 FETCH (MODSEQ (320162350))
S: d105 OK [MODIFIED 7,9] Conditional STORE failed
Example 6
実施例6
Same as above, but the server follows the SHOULD recommendation in Section 6.4.6 of [RFC3501].
上記と同じですが、サーバーは[RFC3501]のセクション6.4.6の推奨事項に従う必要があります。
C: d105 STORE 7,5,9 (UNCHANGEDSINCE 320162338)
+FLAGS.SILENT (\Deleted)
S: * 7 FETCH (MODSEQ (320162342) FLAGS (\Seen \Deleted))
S: * 5 FETCH (MODSEQ (320162350))
S: * 9 FETCH (MODSEQ (320162349) FLAGS (\Answered))
S: d105 OK [MODIFIED 7,9] Conditional STORE failed
Use of UNCHANGEDSINCE with a modification sequence of 0 always fails if the metadata item exists. A system flag MUST always be considered existent, whether it was set or not.
メタデータアイテムが存在する場合、変更シーケンス0のUNCHANGEDSINCEの使用は常に失敗します。システムフラグは、設定されているかどうかにかかわらず、常に存在していると見なす必要があります。
Example 7
実施例7
C: a102 STORE 12 (UNCHANGEDSINCE 0)
+FLAGS.SILENT ($MDNSent)
S: a102 OK [MODIFIED 12] Conditional STORE failed
The client has tested the presence of the $MDNSent user-defined keyword.
クライアントは、$ MDNSentユーザー定義キーワードの存在をテストしました。
Example 8
実施例8
Note: A client trying to make an atomic change to the state of a particular metadata item (or a set of metadata items) MUST be prepared to deal with the case when the server returns the MODIFIED response code if the state of the metadata item being watched hasn't changed (but the state of some other metadata item has). This is necessary because some servers don't store separate mod-sequences for different metadata items. However, a server implementation SHOULD avoid generating spurious MODIFIED responses for +FLAGS/-FLAGS STORE operations, even when the server stores a single mod-sequence per message. Section 3.1.12 describes how this can be achieved.
注：特定のメタデータアイテム（またはメタデータアイテムのセット）の状態をアトミックに変更しようとするクライアントは、メタデータアイテムの状態が変更されている場合にサーバーがMODIFIED応答コードを返す場合に対処する準備が必要です。監視は変更されていません（ただし、他の一部のメタデータ項目の状態は変更されています）。一部のサーバーは、異なるメタデータアイテムに個別のmodシーケンスを格納しないため、これが必要です。ただし、サーバー実装では、サーバーがメッセージごとに単一のmodシーケンスを格納する場合でも、+ FLAGS / -FLAGS STORE操作に対して誤ったMODIFIED応答を生成しないようにする必要があります（SHOULD）。セクション3.1.12では、これを実現する方法について説明しています。
Unless the server has included an unsolicited FETCH to update the client's knowledge about messages that have failed the UNCHANGEDSINCE test, upon receipt of the MODIFIED response code, the client SHOULD try to figure out if the required metadata items have indeed changed by issuing the FETCH or NOOP command. It is RECOMMENDED that the server avoids the need for the client to do that by sending an unsolicited FETCH response (see Examples 9 and 10).
UNCHANGEDSINCEテストに失敗したメッセージに関するクライアントの知識を更新するための非送信請求FETCHがサーバーに含まれていない限り、MODIFIED応答コードを受信すると、クライアントは、必要なメタデータ項目が実際に変更されたかどうかをFETCHまたはNOOPコマンド。サーバーが非送信請求FETCH応答を送信することにより、クライアントがそれを行う必要を回避することをお勧めします（例9および10を参照）。
If the required metadata items haven't changed, the client SHOULD retry the command with the new mod-sequence. The client needs to allow for a reasonable number of retries (at least 2).
必要なメタデータアイテムが変更されていない場合、クライアントは新しいmod-sequenceでコマンドを再試行する必要があります（SHOULD）。クライアントは、妥当な数の再試行（少なくとも2回）を許可する必要があります。
In the example below, the server returns the MODIFIED response code without sending information describing why the STORE UNCHANGEDSINCE operation has failed.
以下の例では、サーバーはSTORE UNCHANGEDSINCE操作が失敗した理由を説明する情報を送信せずにMODIFIED応答コードを返します。
C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000)
+FLAGS.SILENT ($Processed)
S: * 100 FETCH (MODSEQ (303181230852))
S: * 102 FETCH (MODSEQ (303181230852))
...
S: * 150 FETCH (MODSEQ (303181230852))
S: a106 OK [MODIFIED 101] Conditional STORE failed
The flag $Processed was set on the message 101...
フラグ$ Processedがメッセージ101に設定されました...
C: a107 NOOP
S: * 101 FETCH (MODSEQ (303011130956) FLAGS ($Processed))
S: a107 OK
Example 9
実施例9
Or, the flag hasn't changed, but another has (note that this server behavior is discouraged. Server implementers should also see Section 3.1.12)...
または、フラグは変更されていませんが、別のフラグは変更されています（このサーバーの動作はお勧めしません。サーバーの実装者もセクション3.1.12を参照してください）...
C: b107 NOOP
S: * 101 FETCH (MODSEQ (303011130956) FLAGS (\Deleted \Answered))
S: b107 OK
...and the client retries the operation for the message 101 with the updated UNCHANGEDSINCE value.
...そしてクライアントは、更新されたUNCHANGEDSINCE値を使用して、メッセージ101の操作を再試行します。
C: b108 STORE 101 (UNCHANGEDSINCE 303011130956)
+FLAGS.SILENT ($Processed)
S: * 101 FETCH (MODSEQ (303181230852))
S: b108 OK Conditional Store completed
Same as above, but the server avoids the need for the client to poll for changes.
上記と同じですが、サーバーはクライアントが変更をポーリングする必要を回避します。
The flag $Processed was set on the message 101 by another client...
フラグ$ Processedが別のクライアントによってメッセージ101に設定されました...
C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000)
+FLAGS.SILENT ($Processed)
S: * 100 FETCH (MODSEQ (303181230852))
S: * 101 FETCH (MODSEQ (303011130956) FLAGS ($Processed))
S: * 102 FETCH (MODSEQ (303181230852))
...
S: * 150 FETCH (MODSEQ (303181230852))
S: a106 OK [MODIFIED 101] Conditional STORE failed
Example 10
実施例10
Or, the flag hasn't changed, but another has (note that this server behavior is discouraged. Server implementers should also see Section 3.1.12)...
または、フラグは変更されていませんが、別のフラグは変更されています（このサーバーの動作はお勧めしません。サーバーの実装者もセクション3.1.12を参照してください）...
C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000)
+FLAGS.SILENT ($Processed)
S: * 100 FETCH (MODSEQ (303181230852))
S: * 101 FETCH (MODSEQ (303011130956) FLAGS (\Deleted \Answered))
S: * 102 FETCH (MODSEQ (303181230852))
...
S: * 150 FETCH (MODSEQ (303181230852))
S: a106 OK [MODIFIED 101] Conditional STORE failed
...and the client retries the operation for the message 101 with the updated UNCHANGEDSINCE value.
...そしてクライアントは、更新されたUNCHANGEDSINCE値を使用して、メッセージ101の操作を再試行します。
C: b108 STORE 101 (UNCHANGEDSINCE 303011130956)
+FLAGS.SILENT ($Processed)
S: * 101 FETCH (MODSEQ (303181230852))
S: b108 OK Conditional Store completed
Or, the flag hasn't changed, but another has (nice server behavior. Server implementers should also see Section 3.1.12)...
または、フラグは変更されていませんが、別のフラグは変更されています（サーバーの動作が適切です。サーバーの実装者もセクション3.1.12を参照してください）...
C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000)
+FLAGS.SILENT ($Processed)
S: * 100 FETCH (MODSEQ (303181230852))
S: * 101 FETCH (MODSEQ (303011130956) FLAGS ($Processed \Deleted
\Answered))
S: * 102 FETCH (MODSEQ (303181230852))
...
S: * 150 FETCH (MODSEQ (303181230852))
S: a106 OK Conditional STORE completed
The following example is based on the example from Section 4.2.3 of
[RFC2180] and demonstrates that the MODIFIED response code MAY also
be returned in the tagged NO response.
The client tries to conditionally STORE flags on a mixture of expunged and non-expunged messages; one message fails the UNCHANGEDSINCE test.
クライアントは、消去されたメッセージと消去されていないメッセージが混在する場合に条件付きでフラグを保存しようとします。 1つのメッセージがUNCHANGEDSINCEテストに失敗しました。
C: B001 STORE 1:7 (UNCHANGEDSINCE 320172338) +FLAGS (\SEEN)
S: * 1 FETCH (MODSEQ (320172342) FLAGS (\SEEN))
S: * 3 FETCH (MODSEQ (320172342) FLAGS (\SEEN))
S: B001 NO [MODIFIED 2] Some of the messages no longer exist.
C: B002 NOOP
S: * 4 EXPUNGE
S: * 4 EXPUNGE
S: * 4 EXPUNGE
S: * 4 EXPUNGE
S: * 2 FETCH (MODSEQ (320172340) FLAGS (\Deleted \Answered))
S: B002 OK NOOP Completed.
By receiving FETCH responses for messages 1 and 3, and EXPUNGE responses that indicate that messages 4 through 7 have been expunged, the client retries the operation only for message 2. The updated UNCHANGEDSINCE value is used.
メッセージ1および3のFETCH応答と、メッセージ4〜7が消去されたことを示すEXPUNGE応答を受信すると、クライアントはメッセージ2に対してのみ操作を再試行します。更新されたUNCHANGEDSINCE値が使用されます。
C: b003 STORE 2 (UNCHANGEDSINCE 320172340) +FLAGS (\Seen)
S: * 2 FETCH (MODSEQ (320180050) FLAGS (\SEEN \Flagged))
S: b003 OK Conditional Store completed
Example 11
実施例11
Note: If a message is specified multiple times in the message set, and the server doesn't internally eliminate duplicates from the message set, it MUST NOT fail the conditional STORE operation for the second (or subsequent) occurrence of the message if the operation completed successfully for the first occurrence. For example, if the client specifies:
注：メッセージがメッセージセットで複数回指定され、サーバーがメッセージセットから重複を内部的に排除しない場合、メッセージの2番目（以降）の発生に対する条件付きSTORE操作は失敗しません最初の発生で正常に完了しました。たとえば、クライアントが次のように指定したとします。
e105 STORE 7,3:9 (UNCHANGEDSINCE 12121230045) +FLAGS.SILENT (\Deleted)
e105 STORE 7,3：9（UNCHANGEDSINCE 12121230045）+ FLAGS.SILENT（\ Deleted）
the server must not fail the operation for message 7 as part of processing "3:9" if it succeeded when message 7 was processed the first time.
サーバーは、メッセージ7が初めて処理されたときに成功した場合、「3：9」の処理の一環としてメッセージ7の操作を失敗させてはなりません。
As specified in Section 3.1, once the client specifies the UNCHANGEDSINCE modifier in a STORE command, the server starts including the MODSEQ FETCH response data items in all subsequent unsolicited FETCH responses.
セクション3.1で指定されているように、クライアントがSTOREコマンドでUNCHANGEDSINCE修飾子を指定すると、サーバーは、後続のすべての非送信請求FETCH応答にMODSEQ FETCH応答データ項目を含め始めます。
This document also changes the behavior of the server when it has performed a STORE or UID STORE command and the UNCHANGEDSINCE modifier is not specified. If the operation is successful for a message, the server MUST update the mod-sequence attribute of the message. The server is REQUIRED to include the mod-sequence value whenever it decides to send the unsolicited FETCH response to all CONDSTORE-aware clients that have opened the mailbox containing the message.
このドキュメントは、STOREまたはUID STOREコマンドを実行し、UNCHANGEDSINCE修飾子が指定されていない場合のサーバーの動作も変更します。メッセージの操作が成功した場合、サーバーはメッセージのmod-sequence属性を更新する必要があります。サーバーは、メッセージを含むメールボックスを開いたすべてのCONDSTORE対応クライアントに非送信請求FETCH応答を送信することを決定した場合は常に、mod-sequence値を含める必要があります。
Server implementers should also see Section 3.1.11 for additional quality of implementation issues related to the STORE command.
サーバーの実装者は、STOREコマンドに関連する実装品質の問題について、セクション3.1.11も参照してください。
This document defines the following FETCH modifier (see Section 2.4 of [RFC4466]):
このドキュメントでは、次のFETCH修飾子を定義しています（[RFC4466]のセクション2.4を参照）。
CHANGEDSINCE <mod-sequence>: The CHANGEDSINCE FETCH modifier allows the client to further subset the list of messages described by the sequence set. The information described by message data items is only returned for messages that have a mod-sequence bigger than <mod-sequence>.
CHANGEDSINCE <mod-sequence>：CHANGEDSINCE FETCH修飾子を使用すると、クライアントはシーケンスセットで記述されたメッセージのリストをさらにサブセット化できます。メッセージデータアイテムによって記述される情報は、<mod-sequence>よりも大きいmod-sequenceを持つメッセージに対してのみ返されます。
When the CHANGEDSINCE FETCH modifier is specified, it implicitly adds the MODSEQ FETCH message data item (Section 3.1.4.2).
CHANGEDSINCE FETCH修飾子を指定すると、MODSEQ FETCHメッセージデータ項目が暗黙的に追加されます（セクション3.1.4.2）。
C: s100 UID FETCH 1:* (FLAGS) (CHANGEDSINCE 12345)
S: * 1 FETCH (UID 4 MODSEQ (65402) FLAGS (\Seen))
S: * 2 FETCH (UID 6 MODSEQ (75403) FLAGS (\Deleted))
S: * 4 FETCH (UID 8 MODSEQ (29738) FLAGS ($NoJunk $AutoJunk
$MDNSent))
S: s100 OK FETCH completed
Example 12
実施例12
CONDSTORE adds a MODSEQ message data item to the FETCH command. The MODSEQ message data item allows clients to retrieve mod-sequence values for a range of messages in the currently selected mailbox.
CONDSTOREは、MODSEQメッセージデータ項目をFETCHコマンドに追加します。 MODSEQメッセージデータ項目により、クライアントは現在選択されているメールボックス内のメッセージの範囲のmodシーケンス値を取得できます。
As specified in Section 3.1, once the client has specified the MODSEQ message data item in a FETCH request, the server starts including the MODSEQ FETCH response data items in all subsequent unsolicited FETCH responses.
セクション3.1で指定されているように、クライアントがFETCH要求でMODSEQメッセージデータ項目を指定すると、サーバーは、後続のすべての非送信請求FETCH応答にMODSEQ FETCH応答データ項目を含めます。
Syntax: MODSEQ
構文：MODSEQ
The MODSEQ message data item causes the server to return MODSEQ FETCH response data items.
MODSEQメッセージデータ項目により、サーバーはMODSEQ FETCH応答データ項目を返します。
Syntax: MODSEQ ( <permsg-modsequence> )
MODSEQ response data items contain per-message mod-sequences.
MODSEQ応答データ項目には、メッセージごとのmodシーケンスが含まれています。
The MODSEQ response data item is returned if the client issued FETCH with the MODSEQ message data item. It also allows the server to notify the client about mod-sequence changes caused by conditional STOREs (Section 3.1.3) and/or changes caused by external sources.
クライアントがMODSEQメッセージデータ項目でFETCHを発行した場合、MODSEQ応答データ項目が返されます。また、条件付きSTORE（セクション3.1.3）によって引き起こされるmodシーケンスの変更や外部ソースによって引き起こされる変更についてサーバーがクライアントに通知することもできます。
C: a FETCH 1:3 (MODSEQ)
S: * 1 FETCH (MODSEQ (624140003))
S: * 2 FETCH (MODSEQ (624140007))
S: * 3 FETCH (MODSEQ (624140005))
S: a OK Fetch complete
In this example, the client requests per-message mod-sequences for a set of messages.
この例では、クライアントは一連のメッセージに対してメッセージごとのmodシーケンスを要求します。
Example 13
実施例13
Servers that only support the CONDSTORE extension (and not QRESYNC) SHOULD comply with requirements from Section 3.2.4.
CONDSTORE拡張のみをサポートする（QRESYNCではない）サーバーは、セクション3.2.4の要件に準拠する必要があります（SHOULD）。
When a flag for a message is modified in a different session, the server sends an unsolicited FETCH response containing the mod-sequence for the message, as demonstrated in Example 14. Note that when the server also supports the QRESYNC extension (Section 3.2.3) and a CONDSTORE enabling command has been issued, all FETCH responses in Example 14 must also include UID FETCH items as prescribed by Section 3.2.4.
例14に示すように、メッセージのフラグが別のセッションで変更されると、サーバーはメッセージのmodシーケンスを含む非送信請求FETCH応答を送信します。サーバーがQRESYNC拡張もサポートしている場合（セクション3.2.3 ）およびCONDSTORE有効化コマンドが発行された場合、例14のすべてのFETCH応答には、セクション3.2.4で規定されているUID FETCH項目も含まれている必要があります。
(Session 1, authenticated as the user "alex".) The user adds a shared flag \Deleted:
（セッション1、ユーザー「alex」として認証されます。）ユーザーは共有フラグ\ Deletedを追加します。
C: A142 SELECT INBOX
...
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Answered \Deleted \Seen \*)] Limited
...
C: A160 STORE 7 +FLAGS.SILENT (\Deleted)
S: * 7 FETCH (MODSEQ (2121231000))
S: A160 OK Store completed
(Session 2, also authenticated as the user "alex".) Any changes to flags are always reported to all sessions authenticated as the same user as in session 1.
（セッション2もユーザー「alex」として認証されます。）フラグへの変更は常に、セッション1と同じユーザーとして認証されたすべてのセッションに報告されます。
C: C180 NOOP
S: * 7 FETCH (FLAGS (\Deleted \Answered) MODSEQ (12121231000))
S: C180 OK Noop completed
(Session 3, authenticated as the user "andrew".) As \Deleted is a shared flag, changes in session 1 are also reported in session 3:
（セッション3、ユーザー "andrew"として認証されます。）\ Deletedは共有フラグなので、セッション1の変更はセッション3でも報告されます。
C: D210 NOOP
S: * 7 FETCH (FLAGS (\Deleted \Answered) MODSEQ (12121231000))
S: D210 OK Noop completed
The user modifies a private flag, \Seen, in session 1...
ユーザーはセッション1でプライベートフラグ\ Seenを変更します...
C: A240 STORE 7 +FLAGS.SILENT (\Seen)
S: * 7 FETCH (MODSEQ (12121231777))
S: A240 OK Store completed
...which is only reported in session 2...
...これはセッション2でのみ報告されます...
C: C270 NOOP
S: * 7 FETCH (FLAGS (\Deleted \Answered \Seen) MODSEQ
(12121231777))
S: C270 OK Noop completed
...but not in session 3.
...しかし、セッション3ではありません。
C: D300 NOOP
S: D300 OK Noop completed
And, finally, the user removes flags \Answered (shared) and \Seen (private) in session 1.
そして最後に、ユーザーはセッション1でフラグ\ Answered（shared）および\ Seen（private）を削除します。
C: A330 STORE 7 -FLAGS.SILENT (\Answered \Seen)
S: * 7 FETCH (MODSEQ (12121245160))
S: A330 OK Store completed
Both changes are reported in session 2...
両方の変更はセッション2で報告されます...
C: C360 NOOP
S: * 7 FETCH (FLAGS (\Deleted) MODSEQ (12121245160))
S: C360 OK Noop completed
...and only changes to shared flags are reported in session 3.
...そして共有フラグへの変更のみがセッション3で報告されます。
C: D390 NOOP
S: * 7 FETCH (FLAGS (\Deleted) MODSEQ (12121245160))
S: D390 OK Noop completed
Example 14
実施例14
Server implementers should also see Section 3.1.11 for additional quality of implementation issues related to the FETCH command.
サーバーの実装者は、FETCHコマンドに関連する実装品質の問題について、セクション3.1.11も参照してください。
The MODSEQ criterion for the SEARCH (or UID SEARCH) command allows a client to search for the metadata items that were modified since a specified moment.
SEARCH（またはUID SEARCH）コマンドのMODSEQ基準を使用すると、クライアントは、指定された瞬間以降に変更されたメタデータアイテムを検索できます。
Syntax: MODSEQ [<entry-name> <entry-type-req>] <mod-sequence-valzer>
Messages that have modification values that are equal to or greater than <mod-sequence-valzer>. This allows a client, for example, to find out which messages contain metadata items that have changed since the last time it updated its disconnected cache. The client may also specify <entry-name> (name of the metadata item) and <entry-type-req> (type of metadata item) before <mod-sequence-valzer>. <entry-type-req> can be one of "shared", "priv" (private), or "all". The last means that the server MUST use the biggest value among "priv" and "shared" mod-sequences for the metadata item. If the server doesn't store separate mod-sequences for different metadata items, it MUST ignore <entry-name> and <entry-type-req>. Otherwise, the server should use them to narrow down the search.
<mod-sequence-valzer>以上の変更値を持つメッセージ。これにより、たとえば、クライアントは、切断されたキャッシュを最後に更新してから変更されたメタデータ項目を含むメッセージを見つけることができます。クライアントは、<mod-sequence-valzer>の前に<entry-name>（メタデータアイテムの名前）および<entry-type-req>（メタデータアイテムのタイプ）も指定できます。 <entry-type-req>は、 "shared"、 "priv"（private）、または "all"のいずれかです。最後は、サーバーがメタデータアイテムの「priv」および「共有」のmodシーケンスの中で最大の値を使用する必要があることを意味します。サーバーが異なるメタデータ項目の個別のmodシーケンスを格納しない場合、サーバーは<entry-name>と<entry-type-req>を無視する必要があります。それ以外の場合、サーバーはそれらを使用して検索を絞り込みます。
For a flag <flagname>, the corresponding <entry-name> has the form "/flags/<flagname>". Note that the leading "\" character that denotes a system flag has to be escaped as per Section 4.3 of [RFC3501], as <entry-name> uses the syntax for quoted strings (see the examples below).
フラグ<flagname>の場合、対応する<entry-name>の形式は "/ flags / <flagname>"です。 <entry-name>は引用文字列の構文を使用するため（下記の例を参照）、システムフラグを示す先頭の「\」文字は[RFC3501]のセクション4.3に従ってエスケープする必要があります。
If the client specifies a MODSEQ criterion in a SEARCH (or UID SEARCH) command and the server returns a non-empty SEARCH result, the server MUST also append (to the end of the untagged SEARCH response) the highest mod-sequence for all messages being returned. See also Section 3.1.6. Note that other IMAP extensions such as ESEARCH [RFC4731] can override this requirement (see Section 3.1.10 for more details.)
クライアントがSEARCH（またはUID SEARCH）コマンドでMODSEQ基準を指定し、サーバーが空でないSEARCH結果を返す場合、サーバーは（タグなしのSEARCH応答の最後に）すべてのメッセージの最も高いmodシーケンスを追加する必要があります返されます。セクション3.1.6も参照してください。 ESEARCH [RFC4731]などの他のIMAP拡張機能がこの要件を上書きできることに注意してください（詳細については、セクション3.1.10を参照してください）。
C: a SEARCH MODSEQ "/flags/\\draft" all 620162338
S: * SEARCH 2 5 6 7 11 12 18 19 20 23 (MODSEQ 917162500)
S: a OK Search complete
In the above example, the message numbers of any messages having a mod-sequence equal to or greater than 620162338 for the "\Draft" flag are returned in the search results.
上記の例では、「\ Draft」フラグの620162338以上のmodシーケンスを持つメッセージのメッセージ番号が検索結果に返されます。
Example 15
実施例15
C: t SEARCH OR NOT MODSEQ 720162338 LARGER 50000
S: * SEARCH
S: t OK Search complete, nothing found
Example 16
実施例16
Data: zero or more numbers mod-sequence value (omitted if no match)
データ：0個以上の数値のmodシーケンス値（一致しない場合は省略）
This document extends the syntax of the untagged SEARCH response to include the highest mod-sequence for all messages being returned.
このドキュメントでは、タグ付けされていないSEARCH応答の構文を拡張して、返されるすべてのメッセージに対して最も高いmodシーケンスを含めています。
If a client specifies a MODSEQ criterion in a SEARCH (or UID SEARCH) command and the server returns a non-empty SEARCH result, the server MUST also append (to the end of the untagged SEARCH response) the highest mod-sequence for all messages being returned. See Section 3.1.5 for examples.
クライアントがSEARCH（またはUID SEARCH）コマンドでMODSEQ基準を指定し、サーバーが空でないSEARCH結果を返す場合、サーバーは（タグなしのSEARCH応答の最後に）すべてのメッセージの最も高いmodシーケンスを追加する必要があります返されます。例については、セクション3.1.5を参照してください。
This document defines a new status data item:
このドキュメントでは、新しいステータスデータアイテムを定義しています。
HIGHESTMODSEQ: The highest mod-sequence value of all messages in the mailbox. This is the same value that is returned by the server in the HIGHESTMODSEQ response code in an OK untagged response (see Section 3.1.2.1). If the server doesn't support the persistent storage of mod-sequences for the mailbox (see Section 3.1.2.2), the server MUST return 0 as the value of the HIGHESTMODSEQ status data item.
HIGHESTMODSEQ：メールボックス内のすべてのメッセージの最も高いmod-sequence値。これは、タグなしのOK応答のHIGHESTMODSEQ応答コードでサーバーから返される値と同じです（セクション3.1.2.1を参照）。サーバーがメールボックスのmodシーケンスの永続的なストレージをサポートしていない場合（セクション3.1.2.2を参照）、サーバーはHIGHESTMODSEQステータスデータ項目の値として0を返さなければなりません（MUST）。
C: A042 STATUS blurdybloop (UIDNEXT MESSAGES HIGHESTMODSEQ)
S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292
HIGHESTMODSEQ 7011231777)
S: A042 OK STATUS completed
Example 17
実施例17
The CONDSTORE extension defines a single optional select parameter, "CONDSTORE", which tells the server that it MUST include the MODSEQ FETCH response data items in all subsequent unsolicited FETCH responses.
CONDSTORE拡張は、単一のオプションの選択パラメーター「CONDSTORE」を定義します。これは、後続のすべての非送信請求FETCH応答にMODSEQ FETCH応答データ項目を含める必要があることをサーバーに通知します。
The CONDSTORE parameter to SELECT/EXAMINE helps avoid a race condition that might arise when one or more metadata items are modified in another session after the server has sent the HIGHESTMODSEQ response code and before the client was able to issue a CONDSTORE enabling command.
SELECT / EXAMINEへのCONDSTOREパラメータは、サーバーがHIGHESTMODSEQ応答コードを送信した後、クライアントがCONDSTORE有効化コマンドを発行できるようになる前に、1つ以上のメタデータ項目が別のセッションで変更されたときに発生する可能性がある競合状態を回避するのに役立ちます。
C: A142 SELECT INBOX (CONDSTORE)
S: * 172 EXISTS
S: * 1 RECENT
S: * OK [UNSEEN 12] Message 12 is first unseen
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * OK [UIDNEXT 4392] Predicted next UID
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
S: * OK [HIGHESTMODSEQ 715194045007]
S: A142 OK [READ-WRITE] SELECT completed, CONDSTORE is now enabled
Example 18
実施例18
The MODSEQ Search Criterion (see Section 3.1.5) causes modifications to SORT [RFC5256] responses similar to modifications to SEARCH responses defined in Section 3.1.6:
MODSEQ検索基準（セクション3.1.5を参照）は、セクション3.1.6で定義されたSEARCH応答の変更と同様に、SORT [RFC5256]応答を変更します。
SORT Response Data: zero or more numbers mod-sequence value (omitted if no match)
SORT応答データ：ゼロ以上の数値のmodシーケンス値（一致しない場合は省略）
This document extends the syntax of the untagged SORT response to include the highest mod-sequence for all messages being returned.
このドキュメントでは、タグ付けされていないSORT応答の構文を拡張して、返されるすべてのメッセージの最高のmodシーケンスを含めます。
If a client specifies a MODSEQ criterion in a SORT (or UID SORT) command and the server returns a non-empty SORT result, the server MUST also append (to the end of the untagged SORT response) the highest mod-sequence for all messages being returned. Note that other IMAP extensions such as ESORT [RFC5267] can override this requirement (see Section 3.1.10 for more details.)
クライアントがSORT（またはUID SORT）コマンドでMODSEQ基準を指定し、サーバーが空ではないSORT結果を返す場合、サーバーは（タグなしSORT応答の最後に）すべてのメッセージの最高のmodシーケンスを追加する必要があります返されます。 ESORT [RFC5267]などの他のIMAP拡張機能がこの要件を上書きできることに注意してください（詳細については、セクション3.1.10を参照してください）。
THREAD commands that include a MODSEQ Search Criterion return THREAD responses as specified in [RFC5256], i.e., THREAD responses are unchanged by the CONDSTORE extension.
MODSEQ検索基準を含むTHREADコマンドは、[RFC5256]で指定されているTHREAD応答を返します。つまり、THREAD応答はCONDSTORE拡張機能によって変更されません。
If a client specifies a MODSEQ criterion in an extended SEARCH (or extended UID SEARCH) [RFC4731] command and the server returns a non-empty SEARCH result, the server MUST return the ESEARCH response containing the MODSEQ result option as defined in Section 3.2 of [RFC4731].
クライアントが拡張SEARCH（または拡張UID SEARCH）[RFC4731]コマンドでMODSEQ基準を指定し、サーバーが空でないSEARCH結果を返す場合、サーバーは、セクション3.2で定義されているMODSEQ結果オプションを含むESEARCH応答を返す必要があります。 [RFC4731]。
C: a SEARCH RETURN (ALL) MODSEQ 1234
S: * ESEARCH (TAG "a") ALL 1:3,5 MODSEQ 1236
S: a OK Extended SEARCH completed
Example 19
実施例19
If a client specifies a MODSEQ criterion in an extended SORT (or extended UID SORT) [RFC5267] command and the server returns a non-empty SORT result, the server MUST return the ESEARCH response containing the MODSEQ result option defined in Section 3.2 of [RFC4731].
クライアントが拡張SORT（または拡張UID SORT）[RFC5267]コマンドでMODSEQ基準を指定し、サーバーが空ではないSORT結果を返す場合、サーバーは、セクション3.2で定義されたMODSEQ結果オプションを含むESEARCH応答を返さなければなりません（MUST）。 RFC4731]。
C: a SORT RETURN (ALL) (DATE) UTF-8 MODSEQ 1234
S: * ESEARCH (TAG "a") ALL 5,3,2,1 MODSEQ 1236
S: a OK Extended SORT completed
Example 20
実施例20
Server implementations should follow the following rule, which applies to any successfully completed STORE/UID STORE (with and without an UNCHANGEDSINCE modifier), as well as to a FETCH command that implicitly sets the \Seen flag:
サーバーの実装は、正常に完了したSTORE / UID STORE（UNCHANGEDSINCE修飾子の有無にかかわらず）、および\ Seenフラグを暗黙的に設定するFETCHコマンドに適用される次の規則に従う必要があります。
Adding the flag when it is already present or removing it when it is not present SHOULD NOT change the mod-sequence.
フラグがすでに存在する場合はフラグを追加し、存在しない場合は削除して、mod-sequenceを変更しないでください。
This will prevent spurious client synchronization requests.
これにより、偽のクライアント同期要求が防止されます。
However, note that client implementers MUST NOT rely on this server behavior. A client can't distinguish between the case when a server has violated the SHOULD mentioned above and when one or more clients set and unset (or unset and set) the flag in another session.
ただし、クライアントの実装者はこのサーバーの動作に依存してはならないことに注意してください。クライアントは、サーバーが上記のSHOULDに違反した場合と、1つ以上のクライアントが別のセッションでフラグを設定および設定解除（または設定解除と設定）した場合を区別できません。
This section describes how a server implementation that doesn't store separate per-metadata mod-sequences for different metadata items can avoid sending the MODIFIED response to any of the following conditional STORE operations:
このセクションでは、メタデータアイテムごとに個別のメタデータごとのmodシーケンスを格納しないサーバー実装が、MODIFIED応答を次の条件付きSTORE操作のいずれかに送信しないようにする方法について説明します。
+FLAGS
+フラグ
-FLAGS
-フラグ
+FLAGS.SILENT
+ FLAGS.SILENT
-FLAGS.SILENT
-FLAGS.SILENT
Note that the optimization described in this section can't be performed in case of a conditional STORE FLAGS (without "+" or "-") operation.
このセクションで説明する最適化は、条件付きSTORE FLAGS（「+」または「-」なし）操作の場合は実行できないことに注意してください。
Let's use the following example. The client has issued:
次の例を使用してみましょう。クライアントが発行したもの：
C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000) +FLAGS.SILENT ($Processed)
C：a106 STORE 100：150（UNCHANGEDSINCE 212030000000）+ FLAGS.SILENT（$ Processed）
When the server receives the command and parses it successfully, it iterates through the message set and tries to execute the conditional STORE command for each message.
サーバーがコマンドを受信して正常に解析すると、サーバーはメッセージセットを反復処理し、各メッセージに対して条件付きSTOREコマンドを実行しようとします。
Each server internally works as a client, i.e., it has to cache the current state of all IMAP flags as it is known to the client. In order to report flag changes to the client, the server compares the cached values with the values in its database for IMAP flags.
各サーバーは内部的にクライアントとして機能します。つまり、サーバーは、クライアントが認識しているすべてのIMAPフラグの現在の状態をキャッシュする必要があります。フラグの変更をクライアントに報告するために、サーバーはキャッシュされた値をデータベースのIMAPフラグの値と比較します。
Imagine that another client has changed the state of a flag \Deleted on the message 101 and that the change updated the mod-sequence for the message. The server knows that the mod-sequence for the mailbox has changed; however, it also knows that:
別のクライアントがメッセージ101のフラグ\ Deletedの状態を変更し、その変更によってメッセージのmodシーケンスが更新されたとします。サーバーは、メールボックスのmodシーケンスが変更されたことを認識しています。ただし、次のことも認識しています。
a. the client is not interested in the \Deleted flag, as it hasn't included it in the +FLAGS.SILENT operation and
a. + FLAGS.SILENT操作に含まれていないため、クライアントは\ Deletedフラグに関心がなく、
b. the state of the flag $Processed hasn't changed (the server can determine this by comparing the cached flag state with the state of the flag in the database).
b. フラグ$ Processedの状態は変更されていません（サーバーは、キャッシュされたフラグの状態をデータベース内のフラグの状態と比較することでこれを判別できます）。
Therefore, the server doesn't have to report MODIFIED to the client. Instead, the server may set the $Processed flag, update the mod-sequence for the message 101 once again, and send an untagged FETCH response with a new mod-sequence and flags:
したがって、サーバーはクライアントにMODIFIEDを報告する必要はありません。代わりに、サーバーは$ Processedフラグを設定し、メッセージ101のmod-sequenceをもう一度更新し、タグなしのFETCH応答を新しいmod-sequenceとフラグで送信します。
S: * 101 FETCH (MODSEQ (303011130956) FLAGS ($Processed \Deleted \Answered))
S：* 101 FETCH（MODSEQ（303011130956）FLAGS（$ Processed \ Deleted \ Answered））
See also Section 3.1.11 for additional quality-of-implementation issues.
実装の品質に関するその他の問題については、セクション3.1.11も参照してください。
All protocol changes and requirements specified for the CONDSTORE extension are also a part of the QRESYNC extension.
CONDSTORE拡張に指定されたすべてのプロトコルの変更と要件も、QRESYNC拡張の一部です。
The QRESYNC extension 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 would send 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, CLOSE, or MOVE [RFC6851]; the server MUST associate the incremented mod-sequence with the UIDs of the expunged messages. Additionally, if the server also supports the IMAP METADATA extension [RFC5464], it MUST increment the per-mailbox mod-sequence when SETMETADATA successfully changes an annotation on the corresponding mailbox.
QRESYNC拡張機能は、CONDSTORE拡張機能を実装するサーバーに追加の要件を課します。 mod-sequencesの永続的なストレージをサポートする各メールボックス、つまり、サーバーがSELECT / EXAMINEの成功時にHIGHESTMODSEQのタグなしOK応答コードを送信する場合、1つ以上のメッセージが削除された場合、メールボックスごとのmod-sequenceをインクリメントする必要があります。 EXPUNGE、UID EXPUNGE、CLOSE、またはMOVE [RFC6851];サーバーは、インクリメントされたmodシーケンスを消去されたメッセージのUIDに関連付けなければなりません（MUST）。さらに、サーバーがIMAP METADATA拡張[RFC5464]もサポートしている場合、SETMETADATAが対応するメールボックスの注釈を正常に変更すると、メールボックスごとのmodシーケンスをインクリメントする必要があります。
A server implementing QRESYNC MUST send untagged events to a client in a way that the client doesn't lose any changes in case of connectivity loss. In particular, this means that if the server sends MODSEQ FETCH data items while EXPUNGE (or VANISHED) replies with lower mod-sequences being delayed, the server MUST send the HIGHESTMODSEQ response code with a lower value than the EXPUNGE's mod-sequence. See the example in Section 6.
QRESYNCを実装するサーバーは、接続が失われた場合にクライアントが変更を失わないように、タグなしイベントをクライアントに送信する必要があります。特に、これは、サーバーがMODSEQ FETCHデータ項目を送信するときに、EXPUNGE（またはVANISHED）が遅延したより低いmodシーケンスで応答する場合、サーバーはEXPUNGEのmodシーケンスよりも低い値でHIGHESTMODSEQ応答コードを送信する必要があることを意味します。セクション6の例を参照してください。
A client that supports CONDSTORE but not QRESYNC 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 QRESYNC 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をサポートしていてQRESYNCをサポートしていないクライアントは、メールボックスを再同期し、そのHIGHESTMODSEQがクライアントによってキャッシュされた値から増加していることを検出する場合があります。クライアントが最後に同期してからメッセージが消去されたために増加した場合、クライアントはデータを返さないFETCH ... CHANGEDSINCEコマンドを送信する可能性があります。したがって、CONDSTOREをサポートしてQRESYNCをサポートしないクライアントは、一部のメールボックス（メッセージが消去されたが、最後の同期以降フラグが変更されていないメールボックス）を再同期するときに、不要なラウンドトリップのペナルティを被る可能性があります。
This extra round trip is only incurred by clients that support CONDSTORE but not QRESYNC 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 strongly encouraged that clients that support it also support QRESYNC.
この追加の往復は、CONDSTOREをサポートするがQRESYNCをサポートしないクライアントによってのみ発生し、メールボックスにメッセージが消去されたが、消去されていないメッセージに対するフラグの変更がない場合にのみ発生します。 CONDSTOREは比較的新しい拡張機能であるため、それをサポートするクライアントがQRESYNCもサポートすることを強くお勧めします。
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コマンドでサポートされている機能の1つとして「QRESYNC」を返す場合、クイック再同期IMAP拡張が存在します。
For compatibility with clients that only support the CONDSTORE IMAP extension, servers SHOULD also advertise "CONDSTORE" in the CAPABILITY response.
CONDSTORE IMAP拡張のみをサポートするクライアントとの互換性のために、サーバーはCAPABILITY応答で「CONDSTORE」も通知する必要があります（SHOULD）。
Servers supporting QRESYNC MUST implement and advertise support for the ENABLE [RFC5161] 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", see Section 3.1, and have identical results). Note that the order of parameters is not significant, 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 MUST start sending VANISHED responses (see
QRESYNCをサポートするサーバーは、ENABLE [RFC5161] IMAP拡張のサポートを実装してアドバタイズする必要があります。また、「QRESYNC」機能の存在は、「CONDSTORE」機能がアドバタイズされていなくても、CONDSTORE IMAP拡張がサポートされていることを意味します。この仕様に準拠するサーバーは、「ENABLE QRESYNC」と「ENABLE QRESYNC CONDSTORE」（「CONDSTORE有効化コマンド」であり、セクション3.1を参照して、同じ結果になる）をサポートする必要があります。パラメータの順序は重要ではありませんが、準拠サーバーがそれ自体で「ENABLE CONDSTORE」をサポートする必要はないことに注意してください。 "ENABLE QRESYNC" / "ENABLE QRESYNC CONDSTORE"コマンドは、サーバーにVANISHED応答の送信を開始する必要があることも通知します（
Section 3.2.10) instead of EXPUNGE responses for all mailboxes for which the server doesn't return the NOMODSEQ response code. This change remains in effect until the connection is closed.
セクション3.2.10）サーバーがNOMODSEQ応答コードを返さないすべてのメールボックスに対するEXPUNGE応答の代わり。この変更は、接続が閉じられるまで有効です。
A client making use of QRESYNC 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", or the server has not positively responded (in the current connection) to that command with the untagged ENABLED response containing QRESYNC.
QRESYNCを使用するクライアントは、認証されると「ENABLE QRESYNC」を発行する必要があります。 SELECT / EXAMINEコマンドへのQRESYNCパラメータまたはVANISHED UID FETCH修飾子が指定され、クライアントが「ENABLE QRESYNC」を発行していない場合、またはサーバーが積極的に応答していない場合、サーバーはタグ付きのBAD応答で応答する必要があります（現在接続）QRESYNCを含むタグなしのENABLED応答でそのコマンドに。
Once a CONDSTORE enabling command is issued by the client, the server MUST automatically include both UID and mod-sequence data in all subsequent untagged FETCH responses (until the connection is closed), whether they were caused by a regular STORE/UID STORE, a STORE/UID STORE with an UNCHANGEDSINCE modifier, a FETCH/UID FETCH that implicitly set the \Seen flag, or an external agent. Note that this rule doesn't affect untagged FETCH responses caused by a FETCH command that doesn't include UID and/or a MODSEQ FETCH data item (and doesn't implicitly set the \Seen flag) or UID FETCH without the MODSEQ FETCH data item.
CONDSTORE有効化コマンドがクライアントによって発行されると、サーバーは、通常のSTORE / UID STOREによるものかどうかに関係なく、後続のすべてのタグなしFETCH応答にUIDとmod-sequenceデータの両方を自動的に含める必要があります（接続が閉じるまで）。 UNCHANGEDSINCE修飾子付きのSTORE / UID STORE、\ Seenフラグを暗黙的に設定するFETCH / UID FETCH、または外部エージェント。このルールは、UIDおよび/またはMODSEQ FETCHデータ項目を含まない（そして\ Seenフラグを暗黙的に設定しない）FETCHコマンドまたはMODSEQ FETCHデータなしのUID FETCHによって引き起こされるタグなしFETCH応答には影響しないことに注意してください項目。
The Quick Resynchronization parameter to SELECT/EXAMINE commands has four arguments:
SELECT / EXAMINEコマンドへのクイック再同期パラメーターには、4つの引数があります。
o the last known UIDVALIDITY,
o 最後の既知のUIDVALIDITY、
o the last known modification sequence,
o 最後の既知の変更シーケンス、
o the optional set of known UIDs, and
o 既知のUIDのオプションセット、および
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 the SELECT/EXAMINE command is specified and the client hasn't issued "ENABLE QRESYNC" in the current connection, or the server has not positively responded to that command with the untagged ENABLED response containing QRESYNC.
SELECT / EXAMINEコマンドへのクイック再同期パラメーターが指定されていて、クライアントが現在の接続で「ENABLE QRESYNC」を発行していない場合、またはサーバーがそのコマンドに積極的に応答していない場合、サーバーはタグ付きのBAD応答で応答する必要があります。 QRESYNCを含むタグなしのENABLED応答。
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 the 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パラメーターが指定されていないかのようにメールボックスを開きます（これは、他の拡張機能で定義されている他のパラメーターの処理の影響を受けます）。特に、これはサーバーが[RFC3501]のセクション6.3.1および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] Highest mailbox
mod-sequence
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
Remaining parameters are described in the following subsections.
残りのパラメーターについては、以下のサブセクションで説明します。
A server that doesn't support the persistent storage of mod-sequences for the mailbox MUST send an OK untagged response including the NOMODSEQ response code with every successful SELECT or EXAMINE command (see Section 3.1.2.2). 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.
メールボックスのmodシーケンスの永続的なストレージをサポートしないサーバーは、成功したすべてのSELECTまたはEXAMINEコマンドで、NOMODSEQ応答コードを含むOKタグなし応答を送信する必要があります（セクション3.1.2.2を参照）。このようなサーバーは、メールボックス内の消去されたメッセージのmodシーケンスを覚えておく必要はありません。残りのパラメーターを無視し、動的メッセージデータが変更されていないかのように動作する必要があります。
If the provided UIDVALIDITY matches that of the selected mailbox, the server then checks the last known modification sequence.
指定されたUIDVALIDITYが選択したメールボックスの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 FETCH "known-uids"（FLAGS）（CHANGEDSINCE "mod-sequence-value" VANISHED）
In particular, this means that all requirements specified in Section 3.2.6 apply.
特に、これはセクション3.2.6で指定されたすべての要件が適用されることを意味します。
Example:
例：
C: A03 SELECT INBOX (QRESYNC (67890007
90060115194045000 41:211,214:541))
S: * OK [CLOSED]
S: * 100 EXISTS
S: * 11 RECENT
S: * OK [UIDVALIDITY 67890007] UIDVALIDITY
S: * OK [UIDNEXT 600] Predicted next UID
S: * OK [HIGHESTMODSEQ 90060115205545359] Highest
mailbox mod-sequence
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: * 51 FETCH (UID 541 FLAGS (\Seen $Forwarded) MODSEQ
(90060115194045001))
S: A03 OK [READ-WRITE] mailbox selected
In the above example, flag information for UID 42 is not returned, presumably because its flags haven't changed since the MODSEQ 90060115194045000.
上記の例では、おそらくMODSEQ 90060115194045000以降にフラグが変更されていないため、UID 42のフラグ情報は返されません。
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; thus, it 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-sequence-value」が古すぎてサーバーがそれらのメッセージが消去されたときのデータを保持できない場合でも、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.
したがって、リストの最初のセットのN番目のメッセージ番号が4で、リストの2番目のセットのN番目のUIDが8で、メールボックスの4番目のメッセージのUIDが8の場合、8以下のUIDはありません。 VANISHED応答に存在します。 （N + 1）番目のメッセージ番号が12で、（N + 1）番目のUIDが24で、メールボックス内の（N + 1）番目のメッセージのUIDが25の場合、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 it shows that judicious usage of the sequence match data can save a substantial amount of bandwidth.
次の2つの例では、サーバーは抹消をまったく記憶できず、メッセージが3で割り切れるUIDのみがメールボックスに存在します。最初の例では、クライアントは4番目のパラメーターを使用しません。第二に、それはそれを提供します。この例はやや極端ですが、シーケンス一致データを適切に使用すると、帯域幅を大幅に節約できることを示しています。
Example:
例：
C: A04 SELECT INBOX (QRESYNC (67890007
90060115194045000 1:29997))
S: * 10003 EXISTS
S: * 4 RECENT
S: * OK [UIDVALIDITY 67890007] UIDVALIDITY
S: * OK [UIDNEXT 30013] Predicted next UID
S: * OK [HIGHESTMODSEQ 90060115205545359] Highest mailbox
mod-sequence
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,[...],
29668:29669,29671:29996
S: * 1 FETCH (UID 3 FLAGS (\Seen \Answered $Important) MODSEQ
(90060115194045001))
S: ...
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
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: * 4 RECENT
S: * OK [UIDVALIDITY 67890007] UIDVALIDITY
S: * OK [UIDNEXT 30013] Predicted next UID
S: * OK [HIGHESTMODSEQ 90060115205545359] Highest mailbox mod-
sequence
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: * 1 FETCH (UID 3 FLAGS (\Seen \Answered $Important) MODSEQ
(90060115194045001))
S: ...
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
[RFC4466] 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.
[RFC4466]は、オプションのFETCH修飾子を含むようにFETCHおよびUID FETCHコマンドの構文を拡張しました。このドキュメントは、新しいUID FETCH修飾子を定義します：VANISHED。
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修飾子が指定されており、クライアントが現在の接続で「ENABLE QRESYNC」を発行していない場合、サーバーはタグ付きのBAD応答で応答する必要があります。
The VANISHED UID FETCH modifier MUST only be specified together with the CHANGEDSINCE UID FETCH modifier. If the VANISHED UID FETCH modifier is used without the CHANGEDSINCE UID FETCH modifier, the server MUST respond with a tagged BAD response.
VANISHED UID FETCH修飾子は、CHANGEDSINCE UID FETCH修飾子と一緒にのみ指定する必要があります。 VANISHED UID FETCH修飾子がCHANGEDSINCE UID FETCH修飾子なしで使用される場合、サーバーはタグ付きのBAD応答で応答する必要があります。
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 was updated when the messages were expunged (as described above). The expunged messages are reported using the VANISHED (EARLIER) response as described in Section 3.2.10.1. Any VANISHED (EARLIER) responses MUST be returned before any FETCH responses, otherwise the client might get confused about how message numbers map to UIDs.
VANISHED UID FETCH修飾子は、消去され、関連するmod-sequenceが指定されたmod-sequenceよりも大きいUIDセットパラメータからのメッセージを報告するようにサーバーに指示します。つまり、クライアントは、指定されたmodシーケンス以降に消去された、指定されたセットからのメッセージの通知を要求します。これらのメッセージに関連付けられたmod-sequenceは、メッセージが消去されたときに（上記のように）更新されたことに注意してください。消去されたメッセージは、セクション3.2.10.1で説明されているVANISHED（EARLIER）応答を使用して報告されます。 VANISHED（EARLIER）応答は、すべてのFETCH応答の前に返されなければなりません。
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>より小さいmod-sequenceを受信するサーバー（<minmodseq>は、記憶している最小の消去済みmod-sequenceの値から1を引いた値）は、提供されたすべての消去済みメッセージを報告するように要求されたかのように動作する必要があります。 UIDセットパラメータ。
Example 1: Without the VANISHED UID FETCH modifier, a CONDSTORE-aware
client needs to issue separate commands to learn of flag changes and
expunged messages since the last synchronization:
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
Where 300 and 500 are the lowest and highest UIDs from the 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番目のSEARCH応答は、UID 407、410、および412のメッセージがまだ存在するが、指定された変更シーケンス以降、フラグが変更されていないことをクライアントに通知します。
Using the VANISHED UID FETCH modifier, it is sufficient to issue only a single command:
VANISHED UID FETCH修飾子を使用すると、1つのコマンドのみを発行するだけで十分です。
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
Arguments: none
引数：なし
Responses: untagged responses: EXPUNGE or VANISHED
応答：タグなしの応答：EXPUNGEまたはVANISHED
Result: OK - expunge completed
NO - expunge failure: can't expunge (e.g., permission denied)
BAD - command unknown or arguments invalid
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をクライアントに返す前に、削除されたメッセージは、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 and QRESYNC was enabled, the server MUST send the updated per-mailbox modification sequence using the HIGHESTMODSEQ response code (see Section 3.1.2.1) in the tagged OK response.
サーバーが選択したメールボックスの変更シーケンスを保存できる場合、EXPUNGEコマンドの実行により少なくとも1つのメッセージが完全に削除された場合、メールボックスごとのmodシーケンスをインクリメントする必要があります。完全に削除されたメッセージごとに、サーバーはインクリメントされたmodシーケンスと対応するUIDを記憶する必要があります。少なくとも1つのメッセージが消去され、QRESYNCが有効になっている場合、サーバーはタグ付きOK応答でHIGHESTMODSEQ応答コード（セクション3.1.2.1を参照）を使用して、更新されたメールボックスごとの変更シーケンスを送信する必要があります。
Example: C: A202 EXPUNGE
S: * 3 EXPUNGE
S: * 3 EXPUNGE
S: * 5 EXPUNGE
S: * 8 EXPUNGE
S: A202 OK [HIGHESTMODSEQ 20010715194045319] expunged
Note: In this example, the client hasn't enabled QRESYNC, so the server is still using untagged EXPUNGE responses. Note that the presence of the HIGHESTMODSEQ response code is optional in this case. If the selected mailbox returned NOMODSEQ, the HIGHESTMODSEQ response code will be absent. 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 was decremented due to the previous EXPUNGE response). See the description of the EXPUNGE response in [RFC3501] for further explanation.
注：この例では、クライアントはQRESYNCを有効にしていないため、サーバーはタグなしのEXPUNGE応答をまだ使用しています。この場合、HIGHESTMODSEQ応答コードの存在はオプションです。選択したメールボックスがNOMODSEQを返した場合、HIGHESTMODSEQ応答コードはありません。この例では、メッセージ3、4、7、および11に\ Deletedフラグが設定されています。最初の「* 3 EXPUNGE」は、メッセージ＃3が消去されたことを報告します。 2番目の「* 3 EXPUNGE」は、メッセージ＃4が消去されたことを報告します（メッセージ番号は、前のEXPUNGE応答により減少しました）。詳細については、[RFC3501]のEXPUNGE応答の説明を参照してください。
Once the client enables QRESYNC, the server will always send VANISHED responses instead of EXPUNGE responses for mailboxes that support the storing of modification sequences, so the previous example might look like this:
クライアントがQRESYNCを有効にすると、サーバーは変更シーケンスの格納をサポートするメールボックスに対して、EXPUNGE応答ではなく常にVANISHED応答を送信するため、前の例は次のようになります。
Example: C: B202 EXPUNGE
S: * VANISHED 405,407,410,425
S: B202 OK [HIGHESTMODSEQ 20010715194045319] expunged
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（または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. The server MUST NOT send the updated per-mailbox modification sequence using the HIGHESTMODSEQ response code (see Section 3.1.2.1) in the tagged OK response, as this might cause loss of synchronization on the client.
サーバーが選択されたメールボックスの変更シーケンスを保存できる場合、CLOSEコマンドの実行により少なくとも1つのメッセージが完全に削除された場合、メールボックスごとのmodシーケンスをインクリメントする必要があります。完全に削除されたメッセージごとに、サーバーはインクリメントされたmodシーケンスと対応するUIDを記憶する必要があります。サーバーは、タグ付きOK応答でHIGHESTMODSEQ応答コード（セクション3.1.2.1を参照）を使用して、更新されたメールボックスごとの変更シーケンスを送信してはなりません。これにより、クライアントで同期が失われる可能性があります。
Example: C: A202 CLOSE S: A202 OK done
例：C：A202 CLOSE S：A202 OK完了
Arguments: message set
引数：メッセージセット
Responses: untagged responses: EXPUNGE or VANISHED
応答：タグなしの応答：EXPUNGEまたはVANISHED
Result: OK - expunge completed
NO - expunge failure: can't expunge (e.g., permission denied)
BAD - command unknown or arguments invalid
This section updates the definition of the UID EXPUNGE command described in Section 2.1 of [UIDPLUS], in the presence of QRESYNC. Servers that implement both [UIDPLUS] and QRESYNC extensions must implement UID EXPUNGE as described in this section.
このセクションは、QRESYNCが存在する場合、[UIDPLUS]のセクション2.1で説明されているUID EXPUNGEコマンドの定義を更新します。 [UIDPLUS]拡張とQRESYNC拡張の両方を実装するサーバーは、このセクションで説明するように、UID EXPUNGEを実装する必要があります。
The UID EXPUNGE command permanently removes from the currently selected mailbox all messages that have both the \Deleted flag set and 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 and QRESYNC was enabled, the server MUST send the updated per-mailbox modification sequence using the HIGHESTMODSEQ response code (see Section 3.1.2.1) in the tagged OK response.
サーバーが選択したメールボックスの変更シーケンスを保存できる場合、UID EXPUNGEコマンドの実行により少なくとも1つのメッセージが完全に削除された場合、メールボックスごとのmodシーケンスをインクリメントする必要があります。完全に削除されたメッセージごとに、サーバーはインクリメントされたmodシーケンスと対応するUIDを記憶する必要があります。少なくとも1つのメッセージが消去され、QRESYNCが有効になっている場合、サーバーはタグ付きOK応答でHIGHESTMODSEQ応答コード（セクション3.1.2.1を参照）を使用して、更新されたメールボックスごとの変更シーケンスを送信する必要があります。
Example: C: . UID EXPUNGE 3000:3002
S: * 3 EXPUNGE
S: * 3 EXPUNGE
S: * 3 EXPUNGE
S: . OK [HIGHESTMODSEQ 20010715194045319] Ok
Note: In this example, the client hasn't enabled QRESYNC, so the server is still using untagged EXPUNGE responses instead of VANISHED responses. Note that the presence of the HIGHESTMODSEQ response code is optional. If the selected mailbox returned NOMODSEQ, the HIGHESTMODSEQ response code will be absent. 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 was decremented due to the previous EXPUNGE response). See the description of the EXPUNGE response in [RFC3501] for further explanation.
注：この例では、クライアントはQRESYNCを有効にしていないため、サーバーはVANISHED応答の代わりにタグなしのEXPUNGE応答を引き続き使用しています。 HIGHESTMODSEQ応答コードの存在はオプションであることに注意してください。選択したメールボックスがNOMODSEQを返した場合、HIGHESTMODSEQ応答コードはありません。この例では、少なくともメッセージ番号3、4、および5（UID 3000〜3002）のメッセージに\ Deletedフラグが設定されています。最初の「* 3 EXPUNGE」は、メッセージ＃3が消去されたことを報告します。 2番目の「* 3 EXPUNGE」は、メッセージ＃4が消去されたことを報告します（メッセージ番号は、前のEXPUNGE応答により減少しました）。詳細については、[RFC3501]のEXPUNGE応答の説明を参照してください。
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.
VANISHED応答は、指定されたUIDがメールボックスから完全に削除されたことを報告します。この応答はEXPUNGE応答[RFC3501]に似ています。ただし、複数のメッセージに関する情報を返すことができ、メッセージ番号の代わりにUIDを返します。最初の利点は帯域幅を節約しますが、2番目の利点は、UIDのみを使用してIMAPサーバーにアクセスするクライアントにとってより便利です。
The VANISHED response has the same restrictions on when it can be sent as does the EXPUNGE response (see below). Once a client has issued "ENABLE QRESYNC" (and the server has positively responded to that command with the untagged ENABLED response containing QRESYNC), the server MUST use the VANISHED response without the EARLIER tag instead of the EXPUNGE response for all mailboxes that don't return NOMODSEQ when selected. The server continues 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.
VANISHED応答には、EXPUNGE応答の送信と同じ制限があります（下記参照）。クライアントが「ENABLE QRESYNC」を発行すると（サーバーがQRESYNCを含むタグなしのENABLED応答でそのコマンドに積極的に応答した場合）、サーバーは、すべてのメールボックスに対してEXPUNGE応答の代わりにEARLIERタグのないVANISHED応答を使用する必要があります。 t選択するとNOMODSEQを返します。サーバーは、接続の間、EXPUNGEの代わりにVANISHEDを使用し続けます。特に、これはEXPUNGE [RFC3501]コマンドとUID EXPUNGE [UIDPLUS]コマンド、および他の接続で消去されたメッセージに影響します。このようなVANISHED応答にはEARLIERタグを含めてはなりません。
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. The second form doesn't contain the EARLIER tag and is used for announcing message removals within an already selected mailbox.
VANISHED応答には2つの形式があります。最初のフォームにはEARLIERタグが含まれています。これは、応答がUID FETCH（VANISHED）またはSELECT / EXAMINE（QRESYNC）コマンドによって引き起こされたことを示します。 2番目のフォームにはEARLIERタグが含まれておらず、すでに選択されているメールボックス内のメッセージの削除を通知するために使用されます。
Because clients handle the two different forms of the VANISHED response differently, servers MUST NOT combine them. Messages are reported in VANISHED responses with or without the EARLIER tag, as appropriate to the cause, and, if necessary, two VANISHED responses are sent (one with EARLIER and one without).
クライアントはVANISHED応答の2つの異なる形式を異なる方法で処理するため、サーバーはそれらを組み合わせてはなりません（MUST NOT）。メッセージは、原因に応じて、EARLIERタグの有無にかかわらずVANISHED応答で報告され、必要に応じて、2つのVANISHED応答が送信されます（1つはEARLIERあり、もう1つはなし）。
Contents: an EARLIER tag
内容：EARLIERタグ
list of UIDs
UIDのリスト
The VANISHED (EARLIER) response is 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（EARLIER）応答は、UID FETCH（VANISHED）またはSELECT / EXAMINE（QRESYNC）コマンドが原因で発生します。この応答は、UID FETCH（VANISHED）コマンドのUIDセットパラメータに、メールボックスに存在しなくなったメッセージのUIDが含まれている場合に送信されます。クライアントがVANISHED EARLIER応答を受け取った場合、メールボックス内の連続するメッセージごとにメッセージシーケンス番号をデクリメントしてはなりません（MUST NOT）。
Contents: list of UIDs
内容：UIDのリスト
Once a client has issued "ENABLE QRESYNC" (and the server has positively responded to that command with the untagged ENABLED response containing QRESYNC), the server MUST use the VANISHED response without the EARLIER tag instead of the EXPUNGE response for all mailboxes that don't return NOMODSEQ when selected. The server continues 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.
クライアントが「ENABLE QRESYNC」を発行すると（サーバーがQRESYNCを含むタグなしのENABLED応答でそのコマンドに積極的に応答した場合）、サーバーは、すべてのメールボックスに対してEXPUNGE応答の代わりにEARLIERタグのないVANISHED応答を使用する必要があります。 t選択するとNOMODSEQを返します。サーバーは、接続の間、EXPUNGEの代わりにVANISHEDを使用し続けます。特に、これはEXPUNGE [RFC3501]コマンドとUID EXPUNGE [UIDPLUS]コマンド、および他の接続で消去されたメッセージに影響します。このようなVANISHED応答にはEARLIERタグを含めてはなりません。
Unlike VANISHED (EARLIER), this response also decrements the number of messages in the mailbox and adjusts the message sequence numbers for the messages remaining in the mailbox to account for the expunged messages. Because of this housekeeping, it is not necessary for the server to send an EXISTS response to report the new message count. See the example at the end of this section.
VANISHED（EARLIER）とは異なり、この応答はメールボックス内のメッセージ数を減らし、消去されたメッセージを考慮してメールボックスに残っているメッセージのメッセージシーケンス番号を調整します。このハウスキーピングのため、サーバーが新しいメッセージ数を報告するためにEXISTS応答を送信する必要はありません。このセクションの最後にある例を参照してください。
A VANISHED response without the EARLIER tag MUST refer only to messages that are visible to the client in the current session at the time the VANISHED response is sent. That is, servers MUST NOT send UIDs for previously expunged messages or messages that were not announced to the client via EXISTS. This means that each UID listed in a VANISHED response results in the client decrementing the message count by one. This is required to prevent a possible race condition where new arrivals for which the UID is not yet known by the client are immediately expunged.
EARLIERタグのないVANISHED応答は、VANISHED応答の送信時に現在のセッションでクライアントに表示されるメッセージのみを参照する必要があります。つまり、サーバーは、以前に消去されたメッセージまたはEXISTSを介してクライアントにアナウンスされなかったメッセージのUIDを送信してはなりません（MUST NOT）。つまり、VANISHED応答にリストされている各UIDにより、クライアントはメッセージカウントを1つ減らします。これは、クライアントがUIDをまだ認識していない新しい到着がすぐに消去される可能性のある競合状態を防ぐために必要です。
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 the 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コマンドに応答している間は、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、STORE、およびSEARCHとは異なるコマンドです。 UIDコマンドの実行中に、VANISHED応答が送信される場合があります。ただし、検索条件にメッセージ番号を含むUID SEARCHコマンドの実行中は、VANISHED応答を送信してはなりません（MUST NOT）。
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 "D" marks messages with the \Deleted flag set, and "x" represents UIDs, which are not relevant for the example):
例：現在選択されているメールボックスのメッセージ番号とUIDの間に次のマッピングがあると仮定しましょう（ここで、「D」は\ 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: D D D D
メッセージ番号：1 2 3 4 5 6 7 8 9 10 11 UID：x 504 505 507 508 x 510 x x x 625 \削除されたメッセージ：D D D D
In the presence of the extension defined in this document:
このドキュメントで定義されている拡張機能がある場合：
C: A202 EXPUNGE
S: * VANISHED 505,507,510,625
S: A202 OK EXPUNGE completed
Without the QRESYNC extension, the same example might look like:
C: A202 EXPUNGE
S: * 3 EXPUNGE
S: * 3 EXPUNGE
S: * 5 EXPUNGE
S: * 8 EXPUNGE
S: A202 OK EXPUNGE completed
(Continuing from the previous example.) If subsequently messages with UIDs 504 and 508 got marked as \Deleted:
（前の例から続けます。）その後、UID 504および508のメッセージが\ Deletedとしてマークされた場合：
C: A210 EXPUNGE
S: * VANISHED 504,508
S: A210 OK EXPUNGE completed
For Example, the last VANISHED response only contains UIDs of messages expunged since the previous VANISHED response.
たとえば、最後のVANISHED応答には、前回のVANISHED応答以降に消去されたメッセージのUIDのみが含まれています。
To illustrate the difference between VANISHED and VANISHED (EARLIER), suppose the mailbox contains UIDs 2 and 4. Any of the following responses would constitute a broken server implementation:
VANISHEDとVANISHED（EARLIER）の違いを説明するために、メールボックスにUID 2および4が含まれていると想定します。次の応答のいずれかが壊れたサーバーの実装を構成します。
S: * VANISHED 1
S: * VANISHED 3
S: * VANISHED 5
However, any of these UIDs can easily be referenced by the VANISHED (EARLIER) response.
ただし、これらのUIDはいずれも、VANISHED（EARLIER）応答で簡単に参照できます。
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応答コードの前のすべての応答は閉じられたメールボックスに関連し、後続のすべての応答は新しく開かれたメールボックスに関連します。
A server that advertises "QRESYNC" or "CONDSTORE" in the capability string must return the CLOSED response code in this case, whether or not a CONDSTORE enabling command was issued.
この場合、機能文字列で「QRESYNC」または「CONDSTORE」を通知するサーバーは、CONDSTORE有効化コマンドが発行されたかどうかにかかわらず、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応答コードを返す必要はありません。その目的は、現在選択されているメールボックスを新しいメールボックスを開かずに閉じることです。
While [RFC3501] doesn't specify a specific line-length limit, several server implementations chose to implement the recommended line-length limit suggested in Section 3.2.1.5 of [RFC2683] in order to protect from Denial-of-Service attacks. When the line-length limit is exceeded, such servers return a BAD response (as required by [RFC3501] in case of a syntactic error) and may even close the connection. Clients that support CONDSTORE/QRESYNC extensions can trigger this limit by sending a long UID sequence (previously returned by the server) in an extended SELECT or FETCH command.
[RFC3501]は特定の行の長さの制限を指定していませんが、いくつかのサーバー実装では、サービス拒否攻撃から保護するために、[RFC2683]のセクション3.2.1.5で提案されている推奨される行の長さの制限を実装することを選択しました。行の長さの制限を超えると、そのようなサーバーは（構文エラーの場合に[RFC3501]で要求されるように）BAD応答を返し、接続を閉じることさえできます。 CONDSTORE / QRESYNC拡張機能をサポートするクライアントは、拡張されたSELECTまたはFETCHコマンドで長いUIDシーケンス（以前はサーバーから返された）を送信することにより、この制限をトリガーできます。
This document updates recommended line-length limits specified in Section 3.2.1.5 of [RFC2683]. While the advice in the first paragraph of that section still applies (use compact message/UID set representations), the 1000-octet limit suggested in the second paragraph turns out to be quite problematic when the CONDSTORE and/or QRESYNC extension is used.
このドキュメントは、[RFC2683]のセクション3.2.1.5で指定されている推奨される行の長さの制限を更新します。そのセクションの最初の段落のアドバイスは引き続き適用されますが（コンパクトメッセージ/ UIDセット表現を使用）、2番目の段落で提案されている1000オクテットの制限は、CONDSTOREまたはQRESYNC拡張機能（あるいはその両方）が使用されている場合、かなり問題になることがわかります。
The updated recommendation is as follows: a client should limit the length of the command lines it generates to approximately 8192 octets (including all quoted strings but not including literals). If the client is unable to group things into ranges so that the command line is within that length, it should split the request into multiple commands. The client should use literals instead of long quoted strings in order to keep the command length down.
更新された推奨事項は次のとおりです。クライアントは、生成するコマンドラインの長さを約8192オクテットに制限する必要があります（すべての引用符付き文字列を含み、リテラルは含みません）。コマンドラインがその長さに収まるようにクライアントが物事を範囲にグループ化できない場合は、要求を複数のコマンドに分割する必要があります。クライアントは、コマンドの長さを抑えるために、長い引用文字列ではなくリテラルを使用する必要があります。
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-sequenceに注意を払うことなく、UID FETCH（VANISHED）コマンドのUIDセットで指定されたすべての消去されたメッセージを毎回返します。そのような実装は、同じUIDセットに対するUID SEARCHコマンドの結果よりも大きいVANISHED応答を返す可能性があるため、推奨されません。
A client can substantially reduce the size of VANISHED responses by providing the server with message sequence match data (see Section 3.2.5.2). This is especially effective in the typical case where no messages have been expunged, or all expunges were toward the end of the mailbox.
クライアントは、サーバーにメッセージシーケンス一致データを提供することで、VANISHED応答のサイズを大幅に削減できます（3.2.5.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 that HIGHESTMODSEQ value because there have been no messages expunged during the time period the client is concerned about.
最後のEXPUNGEの時点でHIGHESTMODSEQ値を格納するサーバーは、クライアントがその期間中に消去されたメッセージがないため、クライアントがそのHIGHESTMODSEQ値以上のMODSEQ値を提供する場合、VANISHED応答を省略できます。を懸念。
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, QRESYNC requires servers to store an 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拡張と比較すると、QRESYNCはサーバーに、消去されたメッセージに関連付けられた追加の状態を格納することを要求します。この状態を永続ストレージに保存するための実装は必要ないことに注意してください。ただし、永続ストレージの使用をお勧めします。
One possible way to correctly implement QRESYNC 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.
QRESYNCを正しく実装する1つの可能な方法は、<UIDセット、mod-sequence>ペアのキューを格納することです。 <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 64 GB 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メールボックスごとに約64 GBのストレージが発生する可能性があります。たとえば、同時に消去されるメッセージの範囲ごとに<min UID、max UID、mod-sequence>トリプルを格納する実装を考えます。各トリプルには16オクテットが必要です。2つのUIDのそれぞれに4オクテット、modシーケンスに8オクテットが必要です。 2 ** 32-1（可能な最大のUID値）のUIDを持つ単一のメッセージを含むメールボックスがあり、メッセージは以前に1から始まるUIDで存在し、一度に1つ消去されたと想定します。このメールボックスのみの場合、トリプル<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) is 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シーケンスです。
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, it reduces 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 [IMAP-DISC], in the presence of QRESYNC.
このセクションでは、QRESYNCが存在する場合の、[IMAP-DISC]のセクション6.1の最適化された同期の説明を更新します。
An advanced disconnected mail client SHOULD use the QRESYNC extension when it is supported by the server and SHOULD use CONDSTORE if it is supported and QRESYNC is not. The client uses the value from the HIGHESTMODSEQ OK response code received on the 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拡張機能を使用する必要があり（SHOULD）、サポートされているがQRESYNCがサポートされていない場合はCONDSTOREを使用する必要があります（SHOULD）。クライアントは、メールボックスの開口部で受信したHIGHESTMODSEQ OK応答コードの値を使用して、再同期する必要があるかどうかを判断します。同期が完了すると、受信した値をキャッシュする必要があります（メールボックスのUIDVALIDITY値が変更されていない限り、以下を参照してください）。サーバーが後続のHIGHESTMODSEQ OK応答コードを送信するたびに、クライアントはHIGHESTMODSEQ値のコピーを更新する必要があります。
After completing a full synchronization, the client MUST also take note of any unsolicited MODSEQ FETCH data items and HIGHESTMODSEQ response codes received from the server. Whenever the client receives a tagged response to a command, it checks the received unsolicited responses to calculate the new HIGHESTMODSEQ value. If the HIGHESTMODSEQ response code is received, the client MUST use it even if it has seen higher mod-sequences. Otherwise, the client 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データ項目とHIGHESTMODSEQ応答コードも記録する必要があります。クライアントは、コマンドに対するタグ付き応答を受信するたびに、受信した非送信請求応答をチェックして、新しいHIGHESTMODSEQ値を計算します。 HIGHESTMODSEQ応答コードが受信された場合、クライアントは、より高いmod-sequenceを見た場合でもそれを使用する必要があります。それ以外の場合、クライアントは、最後のタグ付き応答以降に受信したすべてのMODSEQ FETCHデータ項目の中で最も高い値を計算します。この値がクライアントのHIGHESTMODSEQ値のコピーよりも大きい場合、クライアントはこの値を新しいHIGHESTMODSEQ値として使用する必要があります。
Example:
例：
C: A150 STORE 1:2 (UNCHANGEDSINCE 96) +FLAGS.SILENT \Seen
S: * 1 FETCH (UID 6 MODSEQ (103))
S: * 2 FETCH (UID 7 MODSEQ (101))
S: * OK [HIGHESTMODSEQ 99] VANISHED reply with MODSEQ 100 is delayed
S: A150 OK [MODIFIED 3] done
C: A151 STORE 3 +FLAGS.SILENT \Seen
S: * 3 FETCH (UID 8 MODSEQ (104))
S: A151 OK [HIGHESTMODSEQ 99] Still delaying VANISHED
C: A152 NOOP
S: * VANISHED 8
S: A153 OK [HIGHESTMODSEQ 104] done
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 mod-sequence order. Some commands may also delay EXPUNGE (or VANISHED) replies with smaller mod-sequences. These can lead to the client missing some changes in case of connectivity loss.
注：サーバーはMODSEQ FETCHデータ項目を昇順で送信する必要がないため、受信した直後にクライアントのHIGHESTMODSEQ値のコピーをMODSEQ FETCHデータ項目値で更新することは安全ではありません。一部のコマンドは、より小さいmodシーケンスでEXPUNGE（またはVANISHED）応答を遅らせる場合もあります。これらにより、接続が失われた場合にクライアントが一部の変更を見逃す可能性があります。
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.
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].
SELECT / EXAMINE（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 6.1 of [IMAP-DISC] in the presence of the QRESYNC & CONDSTORE extensions is amended as follows:
QRESYNC＆CONDSTORE拡張が存在する場合の[IMAP-DISC]のセクション6.1のステップ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 [IMAP-DISC] for more details) after issuing the 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; and
* メールボックスのキャッシュされたHIGHESTMODSEQ値を「忘れる」。そして
* remove any pending "actions" that 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を参照する保留中の「アクション」を削除します。これは、クライアントが生成した偽のUIDで実行されるアクションには影響しません（[IMAP-DISC]のセクション5を参照）。
1b) This step is no longer required.
1b）この手順は不要になりました。
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] Highest
mailbox mod-sequence
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
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [RFC5234].
次の構文仕様は、[RFC5234]で指定されているAugmented Backus-Naur Form（ABNF）表記を使用しています。
Non-terminals referenced but not defined below are as defined by [RFC5234], [RFC3501], or [RFC4466].
以下で定義されていないが参照されている非端末は、[RFC5234]、[RFC3501]、または[RFC4466]で定義されているとおりです。
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 =/ "CONDSTORE" / "QRESYNC"
status-att =/ "HIGHESTMODSEQ" ;; Extends non-terminal defined in [RFC3501].
status-att = / "HIGHESTMODSEQ" ;; [RFC3501]で定義されている非端末を拡張します。
status-att-val =/ "HIGHESTMODSEQ" SP mod-sequence-valzer
;; Extends non-terminal defined in [RFC4466].
;; Value 0 denotes that the mailbox doesn't
;; support persistent mod-sequences
;; as described in Section 3.1.2.2.
store-modifier =/ "UNCHANGEDSINCE" SP mod-sequence-valzer ;; Only a single "UNCHANGEDSINCE" may be ;; specified in a STORE operation.
store-modifier = / "UNCHANGEDSINCE" SP mod-sequence-valzer ;;単一の「UNCHANGEDSINCE」のみが可能です。;; STOREオペレーションで指定されます。
fetch-modifier =/ chgsince-fetch-mod ;; Conforms to the generic "fetch-modifier" ;; syntax defined in [RFC4466].
fetch-modifier = / chgsince-fetch-mod ;;一般的な「fetch-modifier」に準拠;; [RFC4466]で定義されている構文。
chgsince-fetch-mod = "CHANGEDSINCE" SP mod-sequence-value ;; CHANGEDSINCE FETCH modifier conforms to ;; the fetch-modifier syntax.
chgsince-fetch-mod = "CHANGEDSINCE" SP mod-sequence-value ;; CHANGEDSINCE FETCH修飾子は;;に準拠します。 fetch-modifier構文。
fetch-att =/ fetch-mod-sequence ;; Modifies original IMAP4 fetch-att.
fetch-att = / fetch-mod-sequence ;;元のIMAP4フェッチattを変更します。
fetch-mod-sequence = "MODSEQ"
fetch-mod-resp = "MODSEQ" SP "(" permsg-modsequence ")"
fetch-mod-resp = "MODSEQ" SP "（" permsg-modsequence "）"
msg-att-dynamic =/ fetch-mod-resp
msg-att-dynamic = / fetch-mod-resp
search-key =/ search-modsequence
;; Modifies original IMAP4 search-key.
;;
;; This change applies to all commands
;; referencing this non-terminal -- in
;; particular, SEARCH, SORT, and THREAD.
search-modsequence = "MODSEQ" [search-modseq-ext] SP mod-sequence-valzer
search-modsequence = "MODSEQ" [search-modseq-ext] SP mod-sequence-valzer
search-modseq-ext = SP entry-name SP entry-type-req
resp-text-code =/ "HIGHESTMODSEQ" SP mod-sequence-value / "NOMODSEQ" / "MODIFIED" SP sequence-set
resp-text-code = / "HIGHESTMODSEQ" SP mod-sequence-value / "NOMODSEQ" / "MODIFIED" SPシーケンスセット
entry-name = entry-flag-name
entry-flag-name = DQUOTE "/flags/" attr-flag DQUOTE
;; Each system or user-defined flag <flag>
;; is mapped to "/flags/<flag>".
;;
;; <entry-flag-name> follows the escape rules
;; used by "quoted" string as described in
;; Section 4.3 of [RFC3501]; e.g., for the
;; flag \Seen, the corresponding <entry-name>
;; is "/flags/\\seen", and for the flag
;; $MDNSent, the corresponding <entry-name>
;; is "/flags/$mdnsent".
entry-type-resp = "priv" / "shared"
;; Metadata item type.
entry-type-req = entry-type-resp / "all"
;; Perform SEARCH operation on a private
;; metadata item, shared metadata item,
;; or both.
permsg-modsequence = mod-sequence-value ;; Per-message mod-sequence.
permsg-modsequence = mod-sequence-value ;;メッセージごとのmodシーケンス。
mod-sequence-value = 1*DIGIT
;; Positive unsigned 63-bit integer
;; (mod-sequence)
;; (1 <= n <= 9,223,372,036,854,775,807).
mod-sequence-valzer = "0" / mod-sequence-value
mod-sequence-valzer = "0" / mod-sequence-value
search-sort-mod-seq = "(" "MODSEQ" SP mod-sequence-value ")"
search-sort-mod-seq = "（" "MODSEQ" SP mod-sequence-value "）"
select-param =/ condstore-param ;; Conforms to the generic "select-param" ;; non-terminal syntax defined in [RFC4466].
select-param = / condstore-param ;;一般的な「select-param」に準拠;; [RFC4466]で定義されている非終端構文。
condstore-param = "CONDSTORE"
mailbox-data =/ "SEARCH" [1*(SP nz-number) SP search-sort-mod-seq]
mailbox-data = / "SEARCH" [1 *（SP nz-number）SP search-sort-mod-seq]
sort-data = "SORT" [1*(SP nz-number) SP search-sort-mod-seq] ; Updates the SORT response from RFC 5256.
sort-data = "SORT" [1 *（SP nz-number）SP search-sort-mod-seq]; RFC 5256からのSORT応答を更新します。
attr-flag = "\\Answered" / "\\Flagged" / "\\Deleted" /
"\\Seen" / "\\Draft" / attr-flag-keyword /
attr-flag-extension
;; Does not include "\\Recent".
attr-flag-extension = "\\" atom
;; Future expansion. Client implementations
;; MUST accept flag-extension flags. Server
;; implementations MUST NOT generate
;; flag-extension flags, except as defined by
;; future standards or Standards Track
;; revisions of [RFC3501].
attr-flag-keyword = atom
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 [RFC4466].
select-param = / "QRESYNC" SP "（" uidvalidity SP mod-sequence-value [SPknown-uids] [SP seq-match-data] "）" ;;一般的なselect-paramに準拠します;; [RFC4466]で定義されている構文。
seq-match-data = "(" known-sequence-set SP known-uid-set ")"
seq-match-data = "（" known-sequence-set SP known-uid-set "）"
uidvalidity = nz-number
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.
known-uid-set = sequence-set
;; Set of UIDs corresponding to the messages in
;; known-sequence-set, in ascending order.
;; * is not allowed.
message-data =/ expunged-resp
message-data = / expunged-resp
expunged-resp = "VANISHED" [SP "(EARLIER)"] SP known-uids
rexpunges-fetch-mod = "VANISHED"
;; VANISHED UID FETCH modifier conforms
;; to the fetch-modifier syntax
;; defined in [RFC4466]. It is only
;; allowed in the UID FETCH command.
resp-text-code =/ "CLOSED"
resp-text-code = / "クローズ"
As always, it is important to thoroughly test clients and servers implementing QRESYNC, as it changes how the server reports expunged messages to the client.
いつものように、QRESYNCを実装するクライアントとサーバーを徹底的にテストすることが重要です。サーバーがクライアントに消去されたメッセージを報告する方法が変わるためです。
It is believed that the CONDSTORE or the QRESYNC extensions don't raise any new security concerns that are not already discussed in [RFC3501]. However, the availability of CONDSTORE may make it possible for IMAP4 to be used in critical applications it could not be used for previously, making correct IMAP server implementation and operation even more important.
CONDSTOREまたはQRESYNC拡張機能は、[RFC3501]でまだ説明されていない新しいセキュリティ問題を引き起こさないと考えられています。ただし、CONDSTOREの可用性により、以前は使用できなかった重要なアプリケーションでIMAP4を使用できるようになり、正しいIMAPサーバーの実装と操作がさらに重要になります。
IMAP4 capabilities are registered by publishing a Standards Track or IESG-approved Experimental RFC. The registry is currently located at:
IMAP4機能は、Standards TrackまたはIESG承認の実験的RFCを公開することによって登録されます。レジストリは現在次の場所にあります。
http://www.iana.org/assignments/imap-capabilities
This document defines the CONDSTORE and QRESYNC IMAP capabilities. IANA has updated references for both extensions to point to this document.
このドキュメントでは、CONDSTOREおよびQRESYNC IMAP機能を定義します。 IANAは、このドキュメントを指すように両方の拡張機能の参照を更新しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2683] Leiba, B., "IMAP4 Implementation Recommendations", RFC 2683, September 1999.
[RFC2683] Leiba、B。、「IMAP4実装の推奨事項」、RFC 2683、1999年9月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501] Crispin、M。、「インターネットメッセージアクセスプロトコル-バージョン4rev1」、RFC 3501、2003年3月。
[RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006.
[RFC4466] Melnikov、A。およびC. Daboo、「IMAP4 ABNFに対する収集された拡張機能」、RFC 4466、2006年4月。
[RFC5161] Gulbrandsen, A. and A. Melnikov, "The IMAP ENABLE Extension", RFC 5161, March 2008.
[RFC5161] Gulbrandsen、A。およびA. Melnikov、「The IMAP ENABLE Extension」、RFC 5161、2008年3月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC5256] Crispin, M. and K. Murchison, "Internet Message Access Protocol - SORT and THREAD Extensions", RFC 5256, June 2008.
[RFC5256] Crispin、M。およびK. Murchison、「インターネットメッセージアクセスプロトコル-SORTおよびTHREAD拡張機能」、RFC 5256、2008年6月。
[RFC5464] Daboo, C., "The IMAP METADATA Extension", RFC 5464, February 2009.
[RFC5464] Daboo、C。、「The IMAP METADATA Extension」、RFC 5464、2009年2月。
[UIDPLUS] Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS extension", RFC 4315, December 2005.
[UIDPLUS] Crispin、M.、「インターネットメッセージアクセスプロトコル（IMAP）-UIDPLUS拡張機能」、RFC 4315、2005年12月。
[IMAP-DISC] Melnikov, A., Ed., "Synchronization Operations For Disconnected Imap4 Clients", RFC 4549, June 2006.
[IMAP-DISC] Melnikov、A。、編、「切断されたImap4クライアントの同期操作」、RFC 4549、2006年6月。
[NTP] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[NTP] Mills、D.、Martin、J.、Burbank、J。、およびW. Kasch、「Network Time Protocol Version 4：Protocol and Algorithms Specification」、RFC 5905、2010年6月。
[RFC2180] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC 2180, July 1997.
[RFC2180] Gahrns、M。、「IMAP4 Multi-Accessed Mailbox Practice」、RFC 2180、1997年7月。
[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", RFC 4314, December 2005.
[RFC4314] Melnikov、A。、「IMAP4 Access Control List（ACL）Extension」、RFC 4314、2005年12月。
[RFC4731] Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned", RFC 4731, November 2006.
[RFC4731] Melnikov、A。およびD. Cridland、「返される情報の種類を制御するためのSEARCHコマンドのIMAP4拡張機能」、RFC 4731、2006年11月。
[RFC5257] Daboo, C. and R. Gellens, "Internet Message Access Protocol - ANNOTATE Extension", RFC 5257, June 2008.
[RFC5257] Daboo、C。およびR. Gellens、「インターネットメッセージアクセスプロトコル-ANNOTATE拡張機能」、RFC 5257、2008年6月。
[RFC5267] Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267, July 2008.
[RFC5267] Cridland、D。およびC. King、「Contexts for IMAP4」、RFC 5267、2008年7月。
[RFC6851] Gulbrandsen, A. and N. Freed, "Internet Message Access Protocol (IMAP) - MOVE Extension", RFC 6851, January 2013.
[RFC6851] Gulbrandsen、A。およびN. Freed、「インターネットメッセージアクセスプロトコル（IMAP）-MOVE拡張機能」、RFC 6851、2013年1月。
[UNSELECT] Melnikov, A., "Internet Message Access Protocol (IMAP) UNSELECT command", RFC 3691, February 2004.
[UNSELECT] Melnikov、A。、「インターネットメッセージアクセスプロトコル（IMAP）UNSELECTコマンド」、RFC 3691、2004年2月。
Changed mod-sequences to be unsigned 63-bit values (instead of unsigned 64-bit values).
mod-sequencesを、符号なし64ビット値ではなく、符号なし63ビット値に変更しました。
Fixed the following errata, as posted on <http://www.rfc-editor.org>:
<http://www.rfc-editor.org>に投稿されている次のエラッタを修正しました。
o Errata ID 3401 ("several typos in UNCHANGEDSINCE spelling") o Errata ID 3506 ("invalid ABNF for the MODIFIED response code") o Errata ID 3509 ("correction to an example")
o エラッタID 3401（「UNCHANGEDSINCEスペルのいくつかのタイプミス」）oエラッタID 3506（「MODIFIED応答コードの無効なABNF」）oエラッタID 3509（「例の修正」）
Clarified that the returning of HIGHESTMODSEQ/NOMODSEQ response codes is only required once a CONDSTORE enabling command is issued.
HIGHESTMODSEQ / NOMODSEQ応答コードを返す必要があるのは、CONDSTORE有効化コマンドが発行された場合のみであることを明記しました。
Clarified that if multiple mod-sequences (for different metadata items) are associated with a message, then all of them affecting a particular STORE UNCHANGEDSINCE must be checked.
（異なるメタデータアイテムの）複数のmodシーケンスがメッセージに関連付けられている場合、特定のSTORE UNCHANGEDSINCEに影響するすべてのmodシーケンスをチェックする必要があることを明確にしました。
Updated references.
更新された参照。
Made editorial corrections.
編集を修正しました。
Changed mod-sequences to be unsigned 63-bit values (instead of unsigned 64-bit values).
mod-sequencesを、符号なし64ビット値ではなく、符号なし63ビット値に変更しました。
Addressed the following errata, as posted on <http://www.rfc-editor.org>:
<http://www.rfc-editor.org>に投稿されている次のエラッタに対処しました。
o Errata ID 1365 ("clarified that QRESYNC is only enabled when ENABLED QRESYNC is returned") o Errata ID 1807 ("unsolicited FETCH responses must include UID fetch response item") o Errata ID 1808 ("HIGHESTMODSEQ response code must not be returned for CLOSE") o Errata ID 1809 ("clarify how updated mailbox mod-sequence is calculated") o Errata ID 1810 ("server must send untagged events to client in a way that client doesn't lose any changes in case of connectivity loss") o Errata ID 3322 ("VANISHED responses must not reference non-existing UIDs")
o エラッタID 1365（「ENABLED QRESYNCが返された場合にのみQRESYNCが有効になることを明確にした」）oエラッタID 1807（「非送信請求FETCH応答にはUIDフェッチ応答項目が含まれている必要がある」）oエラッタID 1808（CLOSEに対して「HIGHESTMODSEQ応答コードを返してはならない」 "）o Errata ID 1809（"更新されたメールボックスのmod-sequenceの計算方法を明確にします "）o Errata ID 1810（"サーバーは、接続が失われた場合にクライアントが変更を失わないようにタグなしイベントをクライアントに送信する必要があります "） o Errata ID 3322（「VANISHED応答は存在しないUIDを参照してはなりません」）
Clarified that ENABLE QRESYNC CONDSTORE and ENABLE CONDSTORE QRESYNC are equivalent.
ENABLE QRESYNC CONDSTOREとENABLE CONDSTORE QRESYNCは同等であることを明確にしました。
Changed the requirement to return VANISHED from SHOULD to MUST as per the mailing list discussion. The only exception is for mailboxes that return the NOMODSEQ response code when they are selected.
メーリングリストのディスカッションに従って、VANISHEDをSHOULDからMUSTに戻す要件を変更しました。唯一の例外は、メールボックスが選択されたときにNOMODSEQ応答コードを返すメールボックスです。
Specified that IMAP SETMETADATA changes update per-mailbox HIGHESTMODSEQ.
IMAP SETMETADATAがメールボックスHIGHESTMODSEQごとに更新を変更することを指定しました。
Clarified that per-message annotations are also considered "metadata".
メッセージごとの注釈も「メタデータ」と見なされることを明確にしました。
Fixed some examples to report data that match requirements specified in the document.
ドキュメントで指定された要件に一致するデータを報告するいくつかの例を修正しました。
Clarified some text and made some requirements normative. Also, corrected a couple of SHOULDs to be MUSTs.
一部のテキストを明確にし、いくつかの要件を規範化しました。また、いくつかのSHOULDを必須に修正しました。
Updated references.
更新された参照。
Made editorial corrections.
編集を修正しました。
Thank you to Steve Hole for co-editing RFC 4551.
RFC 4551を共同編集してくれたSteve Holeに感謝します。
In this revision of the document, the authors also acknowledge the feedback provided by Timo Sirainen, Jan Kundrat, Pete Maclean, Barry Leiba, Eliot Lear, Chris Newman, Claudio Allocchio, Michael Slusarz, Bron Gondwana, Arnt Gulbrandsen, David Black, Hoa V. DINH, and Nick Hudson.
この文書の改訂では、著者はTimo Sirainen、Jan Kundrat、Pete Maclean、Barry Leiba、Eliot Lear、Chris Newman、Claudio Allocchio、Michael Slusarz、Bron Gondwana、Arnt Gulbrandsen、David Black、Hoa Vから提供されたフィードバックも認めます。DINH、およびNick Hudson。
Mark Crispin contributed to RFCs 4551 and 5162 that this document is replacing, and much of his contribution remains in this merged document.
Mark CrispinはRFC 4551および5162に貢献し、このドキュメントが置き換えられ、彼の貢献の多くはこのマージされたドキュメントに残っています。
See also the list of people who contributed to RFC 4551, which this document obsoletes.
このドキュメントで廃止されたRFC 4551に貢献した人々のリストも参照してください。
Authors' Addresses
著者のアドレス
Alexey Melnikov Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
Alexey Melnikov Isode Ltd 5 Castle Business Village 36 Station Road Hampton、Middlesex TW12 2BX UK
EMail: Alexey.Melnikov@isode.com
Dave Cridland Surevine Ltd PO Box 1136 Guildford, Surrey GU1 9ND UK
Dave Cridland Surevine Ltd PO Box 1136 Guildford、Surrey GU1 9ND UK
EMail: dave.cridland@surevine.com