[要約] RFC 4551は、IMAPの拡張機能であり、条件付きのSTORE操作やクイックフラグの変更の再同期を可能にするものです。目的は、サーバとクライアント間の同期を高速化し、ネットワークトラフィックを削減することです。
Network Working Group A. Melnikov
Request for Comments: 4551 Isode Ltd.
Updates: 3501 S. Hole
Category: Standards Track ACI WorldWide/MessagingDirect
June 2006
IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization
条件付き店舗操作またはクイックフラグの変更のためのIMAP拡張
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
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 synchronize state changes for messages within the mailbox. They must be able to guarantee that only one client can change message state (e.g., message flags) at any time. An example of such an application is use of an IMAP mailbox as a message queue with multiple dequeueing clients.
多くの場合、複数のIMAP（RFC 3501）クライアントは、一般的なIMAPメールボックスの変更を調整する必要があります。例には、同じユーザーに代わって作業しているさまざまなクライアントや、共有メールボックスにアクセスする複数のユーザーが含まれます。これらのクライアントには、メールボックス内のメッセージの状態変更を同期するメカニズムが必要です。1人のクライアントのみがメッセージ状態（メッセージフラグなど）をいつでも変更できることを保証できる必要があります。このようなアプリケーションの例は、IMAPメールボックスを複数のDequeueingクライアントを含むメッセージキューとして使用することです。
The Conditional Store facility provides a protected update mechanism for message state information that can detect and resolve conflicts between multiple writing mail clients.
条件付きストア施設は、複数のライティングメールクライアント間の競合を検出および解決できるメッセージ状態情報の保護された更新メカニズムを提供します。
The Conditional Store facility also allows a client to quickly resynchronize mailbox flag changes.
また、条件付きストア施設により、クライアントはメールボックスフラグの変更をすばやく再同期させることができます。
This document defines an extension to IMAP (RFC 3501).
このドキュメントは、IMAP（RFC 3501）の拡張機能を定義します。
Table of Contents
目次
1. Introduction and Overview ................................. 3
2. Conventions Used in This Document ......................... 5
3. IMAP Protocol Changes ..................................... 6
3.1. New OK untagged responses for SELECT and EXAMINE ......... 6
3.1.1. HIGHESTMODSEQ response code ............................ 6
3.1.2. NOMODSEQ response code ................................. 7
3.2. STORE and UID STORE Commands ............................. 7
3.3 FETCH and UID FETCH Commands ..............................13
3.3.1. CHANGEDSINCE FETCH modifier ............................13
3.3.2. MODSEQ message data item in FETCH Command ..............14
3.4. MODSEQ search criterion in SEARCH ........................16
3.5. Modified SEARCH untagged response ........................17
3.6. HIGHESTMODSEQ status data items ..........................17
3.7. CONDSTORE parameter to SELECT and EXAMINE ................18
3.8. Additional quality of implementation issues ..............18
4. Formal Syntax .............................................19
5. Server implementation considerations ......................21
6. Security Considerations ...................................22
7. IANA Considerations .......................................22
8. References ................................................23
8.1. Normative References .....................................23
8.2. Informative References ...................................23
9. Acknowledgements ..........................................23
The Conditional STORE extension is present in any IMAP4 implementation that returns "CONDSTORE" as one of the supported capabilities in the CAPABILITY command response.
条件付きストアの拡張機能は、「Condstore」を返すIMAP4実装に、Capabilityコマンド応答のサポートされている機能の1つとして存在します。
An IMAP server that supports this extension MUST associate a positive unsigned 64-bit value called a modification sequence (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. Note that the latter rule disallows the 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.
この拡張機能をサポートするIMAPサーバーは、修正シーケンス（MODシーケンス）と呼ばれる正の符号なしの64ビット値をすべてのIMAPメッセージに関連付ける必要があります。これは、メタデータアイテムが変更されるたびにサーバーによって更新される不透明な値です。サーバーは、同じメールボックスで実行された各ストアコマンド（異なる接続から異なるメタデータアイテムへの同時ストアを含む）で実行されることを保証する必要があります。また、同じメールボックスで同じセッションで実行された2つの成功した店舗操作について、2番目の完了した操作のmod-sequenceは、最初の完了した操作のmodシーケンスよりも大きくなければなりません。後者のルールは、システム時間が変更された場合（たとえば、NTP [NTP]クライアントが時間を調整する場合）、次の生成値が以前のものよりも少ないため、システムクロックの使用をmodシーケンスとして使用しないことに注意してください。
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 and before it was set) the value of the modification sequence for the message MUST be updated. Adding the flag when it is already present or removing when it is not present SHOULD NOT change the mod-sequence.
mod-sequencesにより、Condstore拡張機能をサポートするクライアントが、既知の瞬間からメッセージメタデータが変更されたかどうかを判断することができます。フラグの状態が変更されるたびに（つまり、以前に設定されていなかった場合にフラグが追加され、フラグが削除され、設定される前に）メッセージの変更シーケンスの値を更新する必要があります。フラグが既に存在しているときに追加するか、存在しないときに削除することは、modシーケンスを変更しないでください。
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追加コマンドを介して、メールボックスにコピーするか、外部メカニズムを使用して）、サーバーは、メールボックス内のすべてのメッセージの最高の変更シーケンスよりも高い新しい変更シーケンスを生成し、それを割り当てます追加されたメッセージに。
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 for the specified message.
サーバーは、さまざまなメタデータアイテムの個別の（メッセージごとの）変更シーケンス値を保存する場合があります。サーバーがそうする場合、メッセージパーセージのmod-sequenceは、指定されたメッセージのすべてのメタデータ項目の最も高いmodシーケンスです。
The server that supports this extension is not required to be able to store mod-sequences for every available mailbox. Section 3.1.2 describes how the server may act if a particular mailbox doesn't support the persistent storage of mod-sequences.
この拡張機能をサポートするサーバーは、利用可能なすべてのメールボックスのmodシーケンスを保存できるようにする必要はありません。セクション3.1.2では、特定のメールボックスがMODシーケンスの永続的なストレージをサポートしていない場合、サーバーがどのように動作するかについて説明します。
This extension makes the following changes to the IMAP4 protocol:
この拡張機能は、IMAP4プロトコルに次の変更を加えます。
a) adds UNCHANGEDSINCE STORE modifier.
a) Store Modifierを変更してください。
b) adds the MODIFIED response code which should be used with an OK response to the STORE command. (It can also be used in a NO response.)
b) ストアコマンドにOK応答で使用する必要がある修正された応答コードを追加します。（応答なしで使用することもできます。）
c) adds a new MODSEQ message data item for use with the FETCH command.
c) Fetchコマンドで使用する新しいmodSeqメッセージデータ項目を追加します。
d) adds CHANGEDSINCE FETCH modifier.
d) Fetch Modifierに変更されました。
e) adds a new MODSEQ search criterion.
e) 新しいmodSeq検索基準を追加します。
f) extends the syntax of untagged SEARCH responses to include mod-sequence.
f) 編集されていない検索応答の構文を拡張して、modシーケンスを含む。
g) adds new OK untagged responses for the SELECT and EXAMINE commands.
g) 選択コマンドを選択して調べるために、新しいOK Untagged応答を追加します。
h) defines an additional parameter to SELECT/EXAMINE commands.
h) コマンドを選択/調べるための追加のパラメーターを定義します。
i) adds the HIGHESTMODSEQ status data item to the STATUS command.
i) hightmodseqステータスデータ項目をステータスコマンドに追加します。
A client supporting CONDSTORE extension indicates its willingness to receive mod-sequence updates in all untagged FETCH responses by issuing:
Condstore拡張機能をサポートするクライアントは、発行することにより、すべての攻撃されていないFetch ResponseでMod-Sequenceの更新を受信する意欲を示しています。
- a SELECT or EXAMINE command with the CONDSTORE parameter, - a STATUS (HIGHESTMODSEQ) command, - a FETCH or SEARCH command that includes the MODSEQ message data item, - a FETCH command with the CHANGEDSINCE modifier, or - a STORE command with the UNCHANGEDSINCE modifier.
- condstoreパラメーターを使用してコマンドを選択または調べます - ステータス（hightmodseq）コマンド - modseqメッセージデータ項目を含むフェッチまたは検索コマンド - 変更された修飾子を含むフェッチコマンド、または - 変更されていないモディファイヤーを備えたストアコマンド。
The server MUST 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 UNCHANGEDSINCE modifier, or an external agent.
サーバーは、通常の店舗、変化のない修飾子を持つ店舗、または外部エージェントによって引き起こされたかどうかにかかわらず、後続のすべての未編集されていないフェッチ応答（接続が閉じられるまで）にモッドシーケンスデータを含める必要があります。
This document uses the term "CONDSTORE-aware client" to refer to a client that announces its willingness to receive mod-sequence updates as described above. The term "CONDSTORE enabling command" will refer any of the commands listed above. A future extension to this document may extend the list of CONDSTORE enabling commands. A first CONDSTORE enabling command executed in the session MUST cause the server to return HIGHESTMODSEQ (Section 3.1.1) unless the server has sent NOMODSEQ (Section 3.1.2) response code when the currently selected mailbox was selected.
このドキュメントでは、「Condstore-Awareクライアント」という用語を使用して、上記のようにMODシーケンスの更新を受信する意欲を発表するクライアントを参照しています。「condstore enablingコマンド」という用語は、上記のコマンドのいずれかを参照します。このドキュメントの将来の拡張機能は、コンドールを有効にするコマンドのリストを拡張する場合があります。セッションで実行された最初のcondstoreを有効にするコマンドは、サーバーが現在選択されているメールボックスが選択されたときにnomodseq（セクション3.1.2）の応答コードを送信しない限り、サーバーがhighestmodseq（セクション3.1.1）を返すようにしなければなりません。
The rest of this document describes the protocol changes more rigorously.
このドキュメントの残りの部分では、プロトコルの変化がより厳密に変更されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [キーワード]に記載されているとおりに解釈されます。
In examples, lines beginning with "S:" are sent by the IMAP server, and lines beginning with "C:" are sent by the client. Line breaks may appear in example commands solely for editorial clarity; when present in the actual message, they are represented by "CRLF".
たとえば、「s：」で始まる行はIMAPサーバーによって送信され、「c：」で始まる行はクライアントによって送信されます。編集上の明確さのためだけに、ラインブレークがサンプルコマンドに表示される場合があります。実際のメッセージに存在する場合、それらは「CRLF」で表されます。
Formal syntax is defined using ABNF [ABNF].
正式な構文は、ABNF [ABNF]を使用して定義されます。
The term "metadata" or "metadata item" is used throughout this document. It refers to any system or user-defined keyword. Future documents may extend "metadata" to include other dynamic message data.
「メタデータ」または「メタデータアイテム」という用語は、このドキュメント全体で使用されます。システムまたはユーザー定義のキーワードを指します。将来のドキュメントは、「メタデータ」を拡張して、他の動的なメッセージデータを含めることができます。
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 [ACL] 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メールボックスはプライベートで、所有者のユーザーのみがアクセスできます。他のメールボックスは、他のユーザーによるアクセスを許可するアクセス制御リスト[ACL]を設定しているため、または共有のメールボックスであるためです。メタデータアイテムの変更が永続的であり、メールボックスにアクセスする他のすべてのユーザーに見える場合、メールボックスのメタデータアイテムを「共有」と呼びましょう。それ以外の場合、メタデータアイテムは「プライベート」と呼ばれます。プライベートメタデータアイテムは、同じユーザーとしてメールボックスにアクセスするすべてのセッションにまだ表示されていることに注意してください。また、異なるメールボックスには、共有されているように異なるメタデータアイテムがある場合があることに注意してください。
See Section 1 for the definition of a "CONDSTORE-aware client" and a "CONDSTORE enabling command".
「Condstore-Awareクライアント」と「Condstore Enabling Command」の定義については、セクション1を参照してください。
This document adds two new response codes, HIGHESTMODSEQ and NOMODSEQ. One of those response codes MUST be returned in the OK untagged response for a successful SELECT/EXAMINE command.
このドキュメントには、2つの新しい応答コード、Hightmodseqとnomodseqが追加されています。これらの応答コードの1つは、選択/検査コマンドを成功させるために、OK Untagged応答で返品する必要があります。
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 the OK untagged response including HIGHESTMODSEQ response code. If the persistent storage for the mailbox is not supported, the server MUST send the OK untagged response including NOMODSEQ response code instead.
メールボックスを開くときは、メールボックスがモッドシーケンスの永続的なストレージをサポートしているかどうかをサーバーが確認する必要があります。メールボックスがmod-sequencesの永続的なストレージをサポートし、メールボックスのオープン操作が成功した場合、サーバーはhighestmodseq応答コードを含むOK未編成応答を送信する必要があります。メールボックスの永続的なストレージがサポートされていない場合、サーバーは代わりにnomodseq応答コードを含むOKの拡張されていない応答を送信する必要があります。
This document adds a new response code that is returned in the OK untagged response for the SELECT and EXAMINE commands. A server supporting the persistent storage of mod-sequences for the mailbox MUST send the OK untagged response including HIGHESTMODSEQ response code with every successful SELECT or EXAMINE command:
このドキュメントでは、選択コマンドと検査のコマンドのOK Untagged応答で返される新しい応答コードを追加します。メールボックスのMODシーケンスの永続的なストレージをサポートするサーバーは、SELECTのすべての選択または検査コマンドを使用して、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-sevecence-value>は、メールボックス内のすべてのメッセージの中で最も高いmodシーケンス値です。サーバーがメールボックスのuidvalidityを変更した場合、メールボックスに同じhighestmodseqを保持する必要はありません。
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.4) to find out exactly which metadata items have changed. Alternatively, the client MAY issue FETCH with the CHANGEDSINCE modifier (Section 3.3.1) in order to fetch data for all messages that have metadata items changed since some known modification sequence.
切断されたクライアントは、hightmodseqの値を使用して、サーバーからメタデータをrefetする必要があるかどうかを確認できます。選択したメールボックスのuidialidity値が変更された場合、クライアントはhighestmodseqのキャッシュ値を削除する必要があります。メールボックスのuidialitidityが同じであり、クライアントのキャッシュに保存されている最高型の値がサーバーによって返される値よりも少ない場合、サーバー上の一部のメタデータアイテムが最後の同期以来変更され、クライアントはその更新する必要がありますキャッシュ。クライアントは、検索modSeq（セクション3.4）を使用して、どのメタデータアイテムが変更されたかを正確に確認できます。あるいは、クライアントは、既知の変更シーケンス以降にメタデータアイテムが変更されたすべてのメッセージのデータを取得するために、変更された修飾子（セクション3.3.1）でフェッチを発行する場合があります。
Example 1:
例1：
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
A server that doesn't support the persistent storage of mod-sequences for the mailbox MUST send the OK untagged response including NOMODSEQ response code with every successful SELECT or EXAMINE command. A server that returned NOMODSEQ response code for a mailbox, which subsequently receives one of the following commands while the mailbox is selected:
メールボックスのMODシーケンスの永続的なストレージをサポートしていないサーバーは、SELECTコマンドを成功または検査するたびに、nomodSeq応答コードを含むOK未張りの応答を送信する必要があります。メールボックスのnomodseq応答コードを返したサーバー。その後、メールボックスが選択されている間に次のコマンドのいずれかを受信します。
- a FETCH command with the CHANGEDSINCE modifier, - a FETCH or SEARCH command that includes the MODSEQ message data item, or - a STORE command with the UNCHANGEDSINCE modifier
- Modseqメッセージデータ項目を含むフェッチまたは検索コマンド、または変更されていない修飾子を含むフェッチまたは検索コマンド、変更された変更のフェッチコマンド
MUST reject any such command with the tagged BAD response.
タグ付きの悪い応答でそのようなコマンドを拒否する必要があります。
Example 2:
例2：
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
This document defines the following STORE modifier (see Section 2.5 of [IMAPABNF]):
このドキュメントは、次のストア修飾子を定義します（[Imapabnf]のセクション2.5を参照）：
UNCHANGEDSINCE <mod-sequence>
変更されていない<mod-sequence>
For each message specified in the message set, the server performs the following. If the mod-sequence of any metadata item of the message is equal 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.3.2 for more details.
メッセージセットで指定された各メッセージについて、サーバーは次のことを実行します。メッセージのメタデータ項目のmod-sequenceが指定されていない値に等しいか小さい場合、要求された操作（メッセージデータ項目で説明されているように）が実行されます。操作が成功した場合、サーバーはメッセージのmod-sequence属性を更新する必要があります。.silentの接尾辞が指定されていても、ogingのないフェッチ応答を送信する必要があり、応答にはmodseqメッセージデータ項目を含める必要があります。これは、正しいmodシーケンス値でクライアントのキャッシュを更新するために必要です。詳細については、セクション3.3.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 UNCHANGESINCE test.
ただし、メッセージのメタデータ項目のmod-sequenceが指定されていない変更値よりも大きい場合、要求された操作を実行してはなりません。この場合、メッセージのmod-sequence属性は更新されず、メッセージ番号（またはUIDストアコマンドの場合の一意の識別子）が、不変のテストに失敗したメッセージのリストに追加されます。
When the server finished performing the operation on all the messages in the message set, it checks for a non-empty list of messages that failed the UNCHANGESINCE 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 UNCHANGESINCE test.
サーバーがメッセージセット内のすべてのメッセージで操作の実行が終了したとき、Unchangesテストに失敗したメッセージの非空白のリストをチェックします。このリストが空でない場合、サーバーはタグ付き応答で変更された応答コードを返す必要があります。変更された応答コードには、不変のテストに失敗したすべてのメッセージのメッセージセット（ストア用）またはUIDのセット（UIDストア）が含まれます。
Example 3:
例3：
All messages pass the UNCHANGESINCE test.
すべてのメッセージは、Unchangess testに合格します。
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 (12121130956))
S: a103 OK Conditional Store completed
Example 4:
例4：
C: a104 STORE * (UNCHANGEDSINCE 12121230045) +FLAGS.SILENT
(\Deleted $Processed)
S: * 50 FETCH (MODSEQ (12111230047))
S: a104 OK Store (conditional) completed
Example 5:
例5：
C: c101 STORE 1 (UNCHANGEDSINCE 12121230045) -FLAGS.SILENT
(\Deleted)
S: * OK [HIGHESTMODSEQ 12111230047]
S: * 50 FETCH (MODSEQ (12111230048))
S: c101 OK Store (conditional) completed
HIGHESTMODSEQ response code was sent by the server presumably because this was the first CONDSTORE enabling command.
おそらくこれが最初のcondstore有効コマンドであったため、おそらくサーバーによってhightmodseq応答コードが送信されました。
Example 6:
例6：
In spite of the failure of the conditional STORE operation for message 7, the server continues to process the conditional STORE in order to find all messages that fail the test.
メッセージ7の条件付きストア操作の障害にもかかわらず、サーバーはテストに失敗したすべてのメッセージを見つけるために条件付きストアを処理し続けます。
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 7:
例7：
Same as above, but the server follows the SHOULD recommendation in Section 6.4.6 of [IMAP4].
上記と同じですが、サーバーは[IMAP4]のセクション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の変更シーケンスを使用して0の変更シーケンスを使用して、常に不変の使用が失敗します。システムフラグは、設定されているかどうかにかかわらず、常に存在すると見なされる必要があります。
Example 8:
例8：
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ユーザー定義のキーワードの存在をテストしました。
Note: A client trying to make an atomic change to the state of a particular metadata item (or a set of metadata items) should 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 5 describes how this can be achieved.
注：特定のメタデータアイテム（またはメタデータアイテムのセット）の状態に原子変更を行おうとするクライアントは、メタデータアイテムの状態がある場合にサーバーが変更された応答コードを返す場合に、ケースに対処するために準備する必要があります。監視は変更されていません（しかし、他のいくつかのメタデータのアイテムの状態はあります）。一部のサーバーは、さまざまなメタデータアイテムに個別のmodシーケンスを保存しないため、これが必要です。ただし、サーバーの実装では、サーバーがメッセージごとに単一のmodシーケンスを保存している場合でも、フラグ/-flagsストア操作の偽の変更された応答の生成を避ける必要があります。セクション5では、これをどのように達成できるかについて説明します。
Unless the server has included an unsolicited FETCH to update 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 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 (Examples 9 and 10).
サーバーに、変更されていない応答コードを受け取ったときに、不変のテストに失敗したメッセージに関するクライアントの知識を更新するための未承諾のフェッチを含めていない限り、クライアントは、必要なメタデータ項目が実際にFetchまたはNOOPコマンドを発行することによって変更されたかどうかを把握しようとする必要があります。未承諾のフェッチ応答を送信することにより、サーバーがクライアントがそれを行う必要性を回避することをお勧めします（例9および10）。
If the required metadata items haven't changed, the client SHOULD retry the command with the new mod-sequence. The client SHOULD allow for a configurable but reasonable number of retries (at least 2).
必要なメタデータアイテムが変更されていない場合、クライアントは新しいmod-sequenceでコマンドを再試行する必要があります。クライアントは、構成可能であるが合理的な数のレトリ（少なくとも2）を許可する必要があります。
Example 9:
例9：
In the example below, the server returns the MODIFIED response code without sending information describing why the STORE UNCHANGEDSINCE operation has failed.
以下の例では、サーバーは、ストアが変更されていない理由を説明する情報を送信せずに変更された応答コードを返します。
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...
Flag $ Processedはメッセージ101に設定されていました...
C: a107 NOOP
S: * 101 FETCH (MODSEQ (303011130956) FLAGS ($Processed))
S: a107 OK
Or the flag hasn't changed, but another has (note that this server behaviour is discouraged. Server implementers should also see Section 5)...
または、フラグが変更されていませんが、別のフラグには変更されています（このサーバーの動作は落胆していることに注意してください。サーバーの実装者もセクション5を見る必要があります）...
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
C: b108 STORE 101 (UNCHANGEDSINCE 303011130956)
+FLAGS.SILENT ($Processed)
S: * 101 FETCH (MODSEQ (303181230852))
S: b108 OK Conditional Store completed
Example 10:
例10：
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...
Flag $ 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
Or the flag hasn't changed, but another has (note that this server behaviour is discouraged. Server implementers should also see Section 5)...
または、フラグが変更されていませんが、別のフラグには変更されています（このサーバーの動作は落胆していることに注意してください。サーバーの実装者もセクション5を見る必要があります）...
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 Valueでメッセージ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 behaviour. Server implementers should also see Section 5)...
または、フラグが変更されていませんが、別のフラグには（素晴らしいサーバーの動作があります。サーバーの実装者もセクション5を見る必要があります）...
C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000) +FLAGS.SILENT ($Processed)
C：A106ストア100：150（変わらない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
Example 11:
例11：
The following example is based on the example from the Section 4.2.3 of [RFC-2180] and demonstrates that the MODIFIED response code may be also returned in the tagged NO response.
次の例は、[RFC-2180]のセクション4.2.3の例に基づいており、変更された応答コードもタグ付きNO応答で返される可能性があることを示しています。
Client tries to conditionally STORE flags on a mixture of expunged and non-expunged messages; one message fails the UNCHANGEDSINCE test.
クライアントは、抹消されたメッセージと非拡張メッセージの混合物にフラグを条件付きで保存しようとします。1つのメッセージは、変更されていないテストに失敗します。
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 the message 2. The updated UNCHANGEDSINCE value is used.
メッセージ1と3のフェッチの回答を受信し、メッセージ4〜7が削除されたことを示す応答を抹消することにより、クライアントはメッセージ2のみの操作を再検索します。
C: b003 STORE 2 (UNCHANGEDSINCE 320172340) +FLAGS (\Seen)
S: * 2 FETCH (MODSEQ (320180050))
S: b003 OK Conditional Store completed
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回目（または後続）発生の条件付きストア操作に失敗してはなりません。最初の発生のために正常に完了しました。たとえば、クライアントが指定した場合：
e105 STORE 7,3:9 (UNCHANGEDSINCE 12121230045) +FLAGS.SILENT (\Deleted)
e105ストア7,3：9（変わらない12121230045）flags.silent（\削除）
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の操作に失敗してはなりません。
Once the client specified the UNCHANGEDSINCE modifier in a STORE command, the server MUST include the MODSEQ fetch response data items in all subsequent unsolicited FETCH responses.
クライアントがStoreコマンドで変更されていない修飾子を指定したら、サーバーはその後のすべての未承諾のフェッチ応答にModSeq Fetch Responseデータ項目を含める必要があります。
This document also changes the behaviour 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.
また、このドキュメントは、ストアまたはUIDストアコマンドを実行したときにサーバーの動作を変更し、変更されていない修飾子が指定されていません。メッセージの操作が成功した場合、サーバーはメッセージのmod-sequence属性を更新する必要があります。サーバーは、メッセージを含むメールボックスを開いたすべてのcondstore対応クライアントに未承諾のフェッチ応答を送信することを決定したときはいつでも、mod-sequence値を含める必要があります。
Server implementers should also see Section 3.8 for additional quality of implementation issues related to the STORE command.
サーバーの実装者は、ストアコマンドに関連する実装の問題の追加を追加するためにセクション3.8も表示する必要があります。
This document defines the following FETCH modifier (see Section 2.4 of [IMAPABNF]):
このドキュメントでは、次のフェッチ修飾子を定義します（[Imapabnf]のセクション2.4を参照）：
CHANGEDSINCE <mod-sequence>
<mod-sequence>を変更しました
CHANGEDSINCE FETCH modifier allows to create a further subset of the list of messages described by sequence set. The information described by message data items is only returned for messages that have mod-sequence bigger than <mod-sequence>.
Fetch Modifierを使用すると、シーケンスセットで説明されているメッセージのリストのさらにサブセットを作成できます。メッセージデータ項目によって説明されている情報は、<mod-sevesence>よりも大きいmod-sequenceを持つメッセージに対してのみ返されます。
When CHANGEDSINCE FETCH modifier is specified, it implicitly adds MODSEQ FETCH message data item (Section 3.3.2).
ModSeq Fetch Message Data Item（セクション3.3.2）を暗黙的に追加すると、Fetch Modifierが指定されたために変更された場合。
Example 12:
例12：
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
This extension 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.
この拡張機能は、fetchコマンドにmodseqメッセージデータ項目を追加します。ModSeqメッセージデータ項目を使用すると、クライアントは現在選択されているメールボックス内のさまざまなメッセージのmod-sequence値を取得できます。
Once the client specified the MODSEQ message data item in a FETCH request, the server MUST include the MODSEQ fetch response data items in all subsequent unsolicited FETCH responses.
クライアントがFetchリクエストでModSeqメッセージデータ項目を指定したら、サーバーには、その後のすべての未承諾フェッチ応答にModSeq Fetch Responseデータ項目を含める必要があります。
Syntax: MODSEQ
構文：modseq
The MODSEQ message data item causes the server to return MODSEQ fetch response data items.
modSeqメッセージデータ項目により、サーバーはModSeq Fetch Responseデータ項目を返します。
Syntax: MODSEQ ( <permsg-modsequence> )
MODSEQ response data items contain per-message mod-sequences.
modSeq応答データ項目には、1セッスルごとのmod-sequencesが含まれています。
The MODSEQ response data item is returned if the client issued FETCH with MODSEQ message data item. It also allows the server to notify the client about mod-sequence changes caused by conditional STOREs (Section 3.2) and/or changes caused by external sources.
MODSEQ応答データ項目は、MODSEQメッセージデータ項目を使用してFetchを発行した場合に返されます。また、サーバーは、条件付きストア（セクション3.2）によって引き起こされるMODシーケンスの変更および/または外部ソースによって引き起こされる変更について、クライアントに通知することができます。
Example 13:
例13：
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-sequencesを要求します。
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.
別のセッションでメッセージのフラグが変更されると、サーバーはメッセージのmodシーケンスを含む未承諾のフェッチ応答を送信します。
Example 14:
例14：
(Session 1, authenticated as a user "alex"). The user adds a shared flag \Deleted:
（セッション1、ユーザー「アレックス」として認証されています）。ユーザーは共有フラグを追加します\削除：
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 the 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 a user "andrew"). As \Deleted is a shared flag, changes in session 1 are also reported in session 3:
（セッション3、ユーザー「アンドリュー」として認証された）。\削除が共有フラグであるため、セッション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で見られるプライベートフラグを変更します...
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でFlags \ Answered（共有）および\ Seed（Private）を削除します。
C: A330 STORE 7 -FLAGS.SILENT (\Answered \Seen)
S: * 7 FETCH (MODSEQ (12121245160))
S: A330 OK Store completed
Both changes are reported in the 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
Server implementers should also see Section 3.8 for additional quality of implementation issues related to the FETCH command.
サーバーの実装者は、Fetchコマンドに関連する実装の問題の追加を追加するために、セクション3.8も表示する必要があります。
The MODSEQ criterion for the SEARCH command allows a client to search for the metadata items that were modified since a specified moment.
検索コマンドの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 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 latter means that the server should use the biggest value among "priv" and "shared" mod-sequences for the metadata item. If the server doesn't store internally 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>は、「共有」、「priv」（プライベート）、または「すべて」の1つにすることができます。後者は、サーバーがメタデータアイテムの「PRIV」および「共有」のモードシーケンスの中で最大の値を使用する必要があることを意味します。サーバーがさまざまなメタデータアイテムに内部的に個別のmodシーケンスを保存しない場合、<entry-name>および<entry-type-req>を無視する必要があります。それ以外の場合、サーバーはそれらを使用して検索を絞り込む必要があります。
For a flag <flagname>, the corresponding <entry-name> has a form "/flags/<flagname>" as defined in [IMAPABNF]. Note that the leading "\" character that denotes a system flag has to be escaped as per Section 4.3 of [IMAP4], as the <entry-name> uses syntax for quoted strings.
フラグ<Flagname>の場合、対応する<Entry-Name>には[Imapabnf]で定義されている形式「/flags/<flagname>」があります。[IMAP4]のセクション4.3に従って、システムフラグを示す主要な「\」文字は、引用された文字列に構文を使用するため、[IMAP4]のセクション4.3に従って逃げる必要があることに注意してください。
If client specifies a MODSEQ criterion in a 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.5.
クライアントが検索コマンドにmodSeq基準を指定し、サーバーが空でない検索結果を返す場合、サーバーは（未編成の検索応答の最後まで）返されるすべてのメッセージの最高のmodシーケンスを追加する必要があります。セクション3.5も参照してください。
Example 15:
例15：
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 containing the string "IMAP4" in the "value" attribute of the "/comment" entry and having a mod-sequence equal to or greater than 620162338 for the "\Draft" flag are returned in the search results.
上記の例では、「/コメント」エントリの「値」属性に文字列「IMAP4」を含むメッセージのメッセージ番号は、「\ draft」フラグの620162338以上のmodシーケンスを持つことです。検索結果に返されます。
Example 16:
例16：
C: t SEARCH OR NOT MODSEQ 720162338 LARGER 50000
S: * SEARCH
S: t OK Search complete, nothing found
Data: zero or more numbers mod-sequence value (omitted if no match)
データ：ゼロ以上の数字mod-sequence値（一致しない場合は省略）
This document extends syntax of the untagged SEARCH response to include the highest mod-sequence for all messages being returned.
このドキュメントでは、タグ付きの検索応答の構文を拡張して、返されるすべてのメッセージの最高の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.4 for examples.
クライアントが検索（またはUID検索）コマンドでmodSeq基準を指定し、サーバーが空でない検索結果を返す場合、サーバーはすべてのメッセージの最高のmodシーケンスを（未積ばれていない検索応答の最後まで）追加する必要があります返される。例については、セクション3.4を参照してください。
This document defines a new status data item:
このドキュメントは、新しいステータスデータ項目を定義します。
HIGHESTMODSEQ
hightimemodseq
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.1). If the server doesn't support the persistent storage of mod-sequences for the mailbox (see Section 3.1.2), the server MUST return 0 as the value of HIGHESTMODSEQ status data item.
メールボックス内のすべてのメッセージの最高のmodシーケンス値。これは、ak ow未編成の応答で最もhightmodseq応答コードのサーバーによって返されるのと同じ値です（セクション3.1.1を参照）。サーバーがメールボックスのmodシーケンスの永続的なストレージをサポートしていない場合（セクション3.1.2を参照）、サーバーはhighstmodseqステータスデータ項目の値として0を返す必要があります。
Example 17:
例17：
C: A042 STATUS blurdybloop (UIDNEXT MESSAGES HIGHESTMODSEQ)
S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292
HIGHESTMODSEQ 7011231777)
S: A042 OK STATUS completed
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」を定義します。これは、サーバーに、その後のすべての未承諾フェッチ応答にModSeq Fetch Responseデータ項目を含める必要があることを指示します。
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.
選択/検査するCondstoreパラメーターは、サーバーがHighmodSeq応答コードを送信した後、クライアントがCondstore有効コマンドを発行する前に、1つ以上のメタデータアイテムが別のセッションで変更されたときに発生する可能性のあるレース条件を回避するのに役立ちます。
Example 18:
例18：
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
Server implementations should follow the following rule, which applies to any successfully completed STORE/UID STORE (with and without UNCHANGEDSINCE modifier), as well as to a FETCH command that implicitly sets \Seen flag:
サーバーの実装は、正常に完了したストア/UIDストア（変更なしの修飾子の有無にかかわらず）に適用される次のルールと、暗黙のうちに\ Seedフラグを設定するフェッチコマンドに適用する必要があります。
Adding the flag when it is already present or removing when it is not present SHOULD NOT change the mod-sequence.
フラグが既に存在しているときに追加するか、存在しないときに削除することは、modシーケンスを変更しないでください。
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 that when one or more clients set and unset (or unset and set) the flag in another session.
ただし、クライアントの実装者はこのサーバーの動作に依存してはならないことに注意してください。クライアントは、サーバーが上記に違反した場合と、1つ以上のクライアントが別のセッションでフラグを設定して設定し（または設定して）設定（または設定して）ケースを区別することはできません。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) [ABNF] notation. Elements not defined here can be found in the formal syntax of the ABNF [ABNF], IMAP [IMAP4], and IMAP ABNF extensions [IMAPABNF] specifications.
次の構文仕様では、拡張されたBackus-Naurフォーム（ABNF）[ABNF]表記を使用します。ここで定義されていない要素は、ABNF [ABNF]、IMAP [IMAP4]、およびIMAP ABNF拡張[IMAPABNF]仕様の正式な構文にあります。
Except as noted otherwise, all alphabetic characters are case-insensitive. The use of upper- or lowercase characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion.
それ以外の場合は、言及されている場合を除き、すべてのアルファベット文字はケース非感受性です。トークン文字列を定義するために上限または小文字または小文字の文字を使用することは、編集の明確性のみを目的としています。実装は、これらの文字列をケースに依存しない方法で受け入れる必要があります。
capability =/ "CONDSTORE"
status-att =/ "HIGHESTMODSEQ"
;; extends non-terminal defined in RFC 3501.
status-att-val =/ "HIGHESTMODSEQ" SP mod-sequence-valzer
;; extends non-terminal defined in [IMAPABNF].
;; Value 0 denotes that the mailbox doesn't
;; support persistent mod-sequences
;; as described in Section 3.1.2
store-modifier =/ "UNCHANGEDSINCE" SP mod-sequence-valzer
;; Only a single "UNCHANGEDSINCE" may be
;; specified in a STORE operation
fetch-modifier =/ chgsince-fetch-mod
;; conforms to the generic "fetch-modifier"
;; syntax defined in [IMAPABNF].
chgsince-fetch-mod = "CHANGEDSINCE" SP mod-sequence-value
;; CHANGEDSINCE FETCH modifier conforms to
;; the fetch-modifier syntax
fetch-att =/ fetch-mod-sequence
;; modifies original IMAP4 fetch-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
search-key =/ search-modsequence
;; modifies original IMAP4 search-key
;;
;; This change applies to all commands
;; referencing this non-terminal, in
;; particular SEARCH.
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 set
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 [IMAP4], 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 private
;; metadata item, shared metadata item or both
permsg-modsequence = mod-sequence-value ;; per message mod-sequence
permsg-modsequence = mod-sequence-value ;;メッセージモードシーケンスごと
mod-sequence-value = 1*DIGIT
;; Positive unsigned 64-bit integer
;; (mod-sequence)
;; (1 <= n < 18,446,744,073,709,551,615)
mod-sequence-valzer = "0" / mod-sequence-value
mod-sequence-valzer = "0" / 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 [IMAPABNF].
condstore-param = "CONDSTORE"
mailbox-data =/ "SEARCH" [1*(SP nz-number) SP
search-sort-mod-seq]
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 standard or standards-track
;; revisions of [IMAP4].
attr-flag-keyword = atom
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:
このセクションでは、さまざまなメタデータアイテムのメタデータごとの個別のモードシーケンスを保存しないサーバーの実装が、次の条件付きストア操作のいずれかに変更された応答を送信することを避ける方法について説明します。
+FLAGS -FLAGS +FLAGS.SILENT -FLAGS.SILENT
flags -flags flags.silent -flags.silent
Note that the optimization described in this section can't be performed in case of a conditional STORE FLAGS operation.
このセクションで説明する最適化は、条件付きストアフラグ操作の場合に実行できないことに注意してください。
Let's use the following example. The client has issued
次の例を使用しましょう。クライアントが発行しました
C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000) +FLAGS.SILENT ($Processed)
C：A106ストア100：150（変わらない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.
サーバーがコマンドを受信して正常に解析すると、メッセージセットを介して反復し、各メッセージの条件付きストアコマンドを実行しようとします。
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で削除されたフラグ\の状態を変更し、変更がメッセージのmodシーケンスを更新したと想像してください。サーバーは、メールボックスのmodシーケンスが変更されたことを知っています。しかし、それはそれを知っています：
a) the client is not interested in \Deleted flag, as it hasn't included it in +FLAGS.SILENT operation; and
a) クライアントは、flags.silent操作に含まれていないため、\削除されたフラグに興味がありません。と
b) the state of the flag $Processed hasn't changed (the server can determine this by comparing cached flag state with the state of the flag in the database).
b) 処理されたフラグ$の状態は変更されていません（サーバーは、キャッシュされたフラグ状態とデータベース内のフラグの状態を比較することでこれを決定できます）。
Therefore, the server doesn't have to report MODIFIED to the client. Instead, the server may set $Processed flag, update the mod-sequence for the message 101 once again and send an untagged FETCH response with new mod-sequence and flags:
したがって、サーバーはクライアントに変更されたレポートを報告する必要はありません。代わりに、サーバーは$処理されたフラグを設定し、メッセージ101のmod-sequenceをもう一度更新し、新しいmodシーケンスとフラグを備えた未開拓のフェッチ応答を送信する場合があります。
S: * 101 FETCH (MODSEQ (303011130956) FLAGS ($Processed \Deleted \Answered))
S： * 101 Fetch（ModSeq（303011130956）フラグ（$ processed \ deleted \ Answered））
See also Section 3.8 for additional quality-of-implementation issues.
追加の実装の問題については、セクション3.8も参照してください。
It is believed that the Conditional STORE extension doesn't raise any new security concerns that are not already discussed in [IMAP4]. However, the availability of this extension 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.
条件付きストアの拡張は、[IMAP4]でまだ議論されていない新しいセキュリティ上の懸念を引き起こさないと考えられています。ただし、この拡張機能が可用性により、以前に使用できなかった重要なアプリケーションでIMAP4を使用できるようになる可能性があり、正しいIMAPサーバーの実装と操作がさらに重要になります。
IMAP4 capabilities are registered by publishing a standards track or IESG approved experimental RFC. The registry is currently located at:
IMAP4機能は、標準トラックまたはIESGが承認した実験RFCを公開することにより登録されます。レジストリは現在、次のようにしています。
http://www.iana.org/assignments/imap4-capabilities
This document defines the CONDSTORE IMAP capability. IANA has added it to the registry accordingly.
このドキュメントでは、Condstore IMAP機能を定義しています。IANAはそれに応じてレジストリに追加しました。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[ABNF] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 4234、2005年10月。
[IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP4] Crispin、M。、「インターネットメッセージアクセスプロトコル -バージョン4REV1」、RFC 3501、2003年3月。
[IMAPABNF] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006.
[Imapabnf] Melnikov、A。and C. daboo、「拡張機能をIMAP4 ABNFに収集しました」、RFC 4466、2006年4月。
[ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[ACAP] Newman、C。and J. Myers、「ACAP-アプリケーション構成アクセスプロトコル」、RFC 2244、1997年11月。
[ACL] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", RFC 4314, December 2005.
[ACL] Melnikov、A。、「IMAP4アクセス制御リスト（ACL）拡張機能」、RFC 4314、2005年12月。
[ANN] Daboo, C. and R. Gellens, "IMAP ANNOTATE Extension", Work in Progress, March 2006.
[Ann] Daboo、C。およびR. Gellens、「IMAP Annotate Extension」、2006年3月、進行中の作業。
[NTP] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[NTP] Mills、D。、「ネットワークタイムプロトコル（バージョン3）仕様、実装および分析」、RFC 1305、1992年3月。
[RFC-2180] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC 2180, July 1997.
[RFC-2180] Gahrns、M。、「IMAP4マルチアクセスメールボックスプラクティス」、RFC 2180、1997年7月。
Some text was borrowed from "IMAP ANNOTATE Extension" [ANN] by Randall Gellens and Cyrus Daboo and from "ACAP -- Application Configuration Access Protocol" [ACAP] by Chris Newman and John Myers.
いくつかのテキストは、Randall GellensとCyrus Dabooによる「IMAP Annotate Extension」[Ann]、およびChris NewmanとJohn Myersによる「ACAP-アプリケーション構成アクセスプロトコル」[ACAP]から借用されました。
Many thanks to Randall Gellens for his thorough review of the document.
ドキュメントを徹底的にレビューしてくれたRandall Gellensに感謝します。
The authors also acknowledge the feedback provided by Cyrus Daboo, Larry Greenfield, Chris Newman, Harrie Hazewinkel, Arnt Gulbrandsen, Timo Sirainen, Mark Crispin, Ned Freed, Ken Murchison, and Dave Cridland.
著者はまた、Cyrus Daboo、Larry Greenfield、Chris Newman、Harrie Hazewinkel、Arnt Gulbrandsen、Timo Sirainen、Mark Crispin、Ned Freed、Ken Murchison、Dave Cridlandが提供するフィードバックを認めています。
Authors' Addresses
著者のアドレス
Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX, United Kingdom
アレクセイメルニコフアイソードリミテッド5キャッスルビジネスビレッジ36ステーションロードハンプトン、ミドルセックスTW12 2BX、イギリス
EMail: Alexey.Melnikov@isode.com
Steve Hole ACI WorldWide/MessagingDirect #1807, 10088 102 Ave Edmonton, AB T5J 2Z1 Canada
Steve Hole ACI Worldwide/MessagingDirect＃1807、10088 102 Ave Edmonton、AB T5J 2Z1カナダ
EMail: Steve.Hole@messagingdirect.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。