[要約] RFC 5162は、IMAP4の拡張機能であるクイックメールボックスの再同期に関する要約と目的を提供しています。このRFCの目的は、メールボックスの同期を高速化し、効率的なメールの管理を可能にすることです。
Network Working Group A. Melnikov
Request for Comments: 5162 D. Cridland
Category: Standards Track Isode Ltd
C. Wilson
Nokia
March 2008
IMAP4 Extensions for Quick Mailbox Resynchronization
Quick Mailboxの再同期のためのIMAP4拡張機能
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
This document defines an IMAP4 extension, which gives an IMAP client the ability to quickly resynchronize any previously opened mailbox as part of the SELECT command, without the need for server-side state or additional client round-trips. This extension also introduces a new response that allows for a more compact representation of a list of expunged messages (and always includes the Unique Identifiers (UIDs) expunged).
このドキュメントでは、IMAP4拡張機能を定義します。これにより、IMAPクライアントは、サーバー側の状態や追加のクライアントのラウンドトリップを必要とせずに、以前に開かれたメールボックスをSelectコマンドの一部として迅速に再同期させる機能を提供します。また、この拡張機能は、抹消されたメッセージのリストのよりコンパクトな表現を可能にする新しい応答を導入します（そして、常に一意の識別子（UID）が消去された一意の識別子（UID）が含まれます）。
Table of Contents
目次
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 4
3.1. QRESYNC Parameter to SELECT/EXAMINE . . . . . . . . . . . 4
3.2. VANISHED UID FETCH Modifier . . . . . . . . . . . . . . . 8
3.3. EXPUNGE Command . . . . . . . . . . . . . . . . . . . . . 10
3.4. CLOSE Command . . . . . . . . . . . . . . . . . . . . . . 11
3.5. UID EXPUNGE Command . . . . . . . . . . . . . . . . . . . 11
3.6. VANISHED Response . . . . . . . . . . . . . . . . . . . . 12
3.7. CLOSED Response Code . . . . . . . . . . . . . . . . . . . 15
4. Server Implementation Considerations . . . . . . . . . . . . . 15
4.1. Server Implementations That Don't Store Extra State . . . 15
4.2. Server Implementations Storing Minimal State . . . . . . . 16
4.3. Additional State Required on the Server . . . . . . . . . 16
5. Updated Synchronization Sequence . . . . . . . . . . . . . . . 17
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . . 22
The [CONDSTORE] extension gives a disconnected client the ability to quickly resynchronize IMAP flag changes for previously seen messages. This can be done using the CHANGEDSINCE FETCH modifier once a mailbox is opened. In order for the client to discover which messages have been expunged, the client still has to issue a UID FETCH or a UID SEARCH command. This document defines an extension to [CONDSTORE] that allows a reconnecting client to perform full resynchronization, including discovery of expunged messages, in a single round-trip. This extension also introduces a new response, VANISHED, that allows for a more compact representation of a list of expunged messages.
[condstore]拡張機能は、切断されたクライアントに、以前に見られたメッセージのIMAPフラグの変更を迅速に再同期させる機能を提供します。これは、メールボックスが開かれた後に変更されたModifierを使用して実行できます。クライアントがどのメッセージを削除したかを発見するためには、クライアントはまだUIDフェッチまたはUID検索コマンドを発行する必要があります。このドキュメントでは、[Condstore]への拡張機能を定義して、再接続するクライアントが1回の往復で、消火したメッセージの発見を含む完全な再同期を実行できるようにします。この拡張機能は、消去されたメッセージのリストのよりコンパクトな表現を可能にする新しい応答を導入します。
This extension can be useful for mobile clients that can experience frequent disconnects caused by environmental factors (battery life, signal strength, etc.). Such clients need a way to quickly reconnect to the IMAP server, while minimizing delay experienced by the user as well as the amount of traffic (and hence the expense) generated by resynchronization.
この拡張機能は、環境要因（バッテリー寿命、信号強度など）によって引き起こされる頻繁な切断を経験できるモバイルクライアントに役立ちます。このようなクライアントは、IMAPサーバーにすばやく再接続する方法が必要でありながら、ユーザーが経験した遅延と、再同期によって生成されるトラフィックの量（したがって費用）を最小限に抑える必要があります。
By extending the SELECT command to perform the additional resynchronization, this also allows clients to reduce concurrent connections to the IMAP server held purely for the sake of avoiding the resynchronization.
選択コマンドを拡張して追加の再同期を実行することにより、クライアントは再同期を回避するために純粋に保持されているIMAPサーバーへの同時接続を減らすことができます。
The quick resync IMAP extension is present if an IMAP4 server returns "QRESYNC" as one of the supported capabilities to the CAPABILITY command.
IMAP4サーバーが「QRESYNC」がサポートされている機能の1つとして「QRESYNC」を機能コマンドに返すと、クイック再配置IMAP拡張が存在します。
Servers supporting this extension MUST implement and advertise support for the [ENABLE] IMAP extension. Also, the presence of the "QRESYNC" capability implies support for the [CONDSTORE] IMAP extension even if the CONDSTORE capability isn't advertised. A server compliant with this specification is REQUIREd to support "ENABLE QRESYNC" and "ENABLE QRESYNC CONDSTORE" (which are "CONDSTORE enabling commands", as defined in [CONDSTORE], and have identical results), but there is no requirement for a compliant server to support "ENABLE CONDSTORE" by itself. The "ENABLE QRESYNC"/"ENABLE QRESYNC CONDSTORE" command also tells the server that it SHOULD start sending VANISHED responses (see Section 3.6) instead of EXPUNGE responses. This change remains in effect until the connection is closed.
この拡張機能をサポートするサーバーは、[有効] IMAP拡張機能のサポートを実装および宣伝する必要があります。また、「QRESYNC」機能の存在は、Condstore機能が宣伝されていなくても、[Condstore] IMAP拡張のサポートを意味します。この仕様に準拠したサーバーは、[condstore]で定義されているように、[condstore enablingコマンド]をサポートし、「condstore有効化コマンド」をサポートし、同一の結果を持っていますが、準拠するための要件はありません。「Condstoreを有効にする」というサーバー自体をサポートします。「qresyncを有効にする」/「qresync condstoreを有効にする」コマンドは、応答を消去する代わりに消失した応答（セクション3.6を参照）を送信し始める必要があることをサーバーに伝えます。この変更は、接続が閉じるまで有効です。
For compatibility with clients that only support the [CONDSTORE] IMAP extension, servers SHOULD advertise CONDSTORE in the CAPABILITY response as well.
[condstore] IMAP拡張機能のみをサポートするクライアントとの互換性については、サーバーはcondstoreも機能応答で宣伝する必要があります。
A client making use of this extension MUST issue "ENABLE QRESYNC" once it is authenticated. A server MUST respond with a tagged BAD response if the QRESYNC parameter to the SELECT/EXAMINE command or the VANISHED UID FETCH modifier is specified and the client hasn't issued "ENABLE QRESYNC" in the current connection.
この拡張機能を使用するクライアントは、認証されたら「QRESYNCを有効にする」ことを発行する必要があります。Select/exemineコマンドにQRESYNCパラメーターを使用するか、消滅したUIDフェッチモディファイアが指定されており、クライアントが現在の接続で「QRESYNCを有効にする」ことを発行していない場合、サーバーはタグ付きの悪い応答で応答する必要があります。
This document puts additional requirements on a server implementing the [CONDSTORE] extension. Each mailbox that supports persistent storage of mod-sequences, i.e., for which the server has sent a HIGHESTMODSEQ untagged OK response code on a successful SELECT/ EXAMINE, MUST increment the per-mailbox mod-sequence when one or more messages are expunged due to EXPUNGE, UID EXPUNGE or CLOSE; the server MUST associate the incremented mod-sequence with the UIDs of the expunged messages.
このドキュメントは、[condstore]拡張機能を実装するサーバーに追加の要件を掲載しています。MODシーケンスの永続的なストレージをサポートする各メールボックス、つまりサーバーがSelect/ exemineの成功してhightmodseq untagged ok応答コードを送信した場合、1つ以上のメッセージが削除された場合に1つ以上のメッセージが削除された場合、mailboxごとのmod-seavesをインクリメントする必要があります。obunge、uid obunge or close;サーバーは、増分されたmod-sequenceを消去されたメッセージのUIDと関連付ける必要があります。
A client that supports CONDSTORE but not this extension might resynchronize a mailbox and discover that its HIGHESTMODSEQ has increased from the value cached by the client. If the increase is only due to messages having been expunged since the client last synchronized, the client is likely to send a FETCH ... CHANGEDSINCE command that returns no data. Thus, a client that supports CONDSTORE but not this extension might incur a penalty of an unneeded round-trip when resynchronizing some mailboxes (those that have had messages expunged but no flag changes since the last synchronization).
Condstoreをサポートしているが、この拡張機能をサポートするクライアントは、メールボックスを再同期させ、その最高のモッデクがクライアントによってキャッシュされた値から増加したことを発見する可能性があります。クライアントが最後に同期してからメッセージが削除されたために増加が原因である場合、クライアントはフェッチを送信する可能性があります...データを返さないコマンドを変更します。したがって、Condstoreをサポートするが、この拡張機能をサポートするクライアントは、いくつかのメールボックス（メッセージが削除されたが最後の同期以来フラグの変更がない）を再同期させるときに、不必要な往復のペナルティが発生する可能性があります。
This extra round-trip is only incurred by clients that support CONDSTORE but not this extension, and only when a mailbox has had messages expunged but no flag changes to non-expunged messages. Since CONDSTORE is a relatively new extension, it is thought likely that clients that support it will also support this extension.
この余分な往復は、Condstoreをサポートするクライアントによってのみ発生しますが、この拡張機能ではなく、メールボックスにメッセージが消去されたが、拡張メッセージにフラグが変更されない場合のみです。Condstoreは比較的新しい拡張機能であるため、それをサポートするクライアントもこの拡張機能をサポートする可能性が高いと考えられています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
In examples, "C:" and "S:" indicate lines sent by the client and server respectively. If a single "C:" or "S:" label applies to multiple lines, then the line breaks between those lines are for editorial clarity only and are not part of the actual protocol exchange. The five characters [...] means that something has been elided.
例では、「C：」と「S：」は、それぞれクライアントとサーバーから送信された行を示します。単一の「c：」または「s：」が複数の行に適用される場合、それらの線間のラインが編集の明確さのみを目的としており、実際のプロトコル交換の一部ではありません。5人のキャラクター[...]は、何かが排除されたことを意味します。
Understanding of the IMAP message sequence numbers and UIDs and the EXPUNGE response [RFC3501] is essential when reading this document.
このドキュメントを読むとき、IMAPメッセージシーケンス番号とUIDおよびobunge応答[RFC3501]の理解が不可欠です。
The Quick Resynchronization parameter to SELECT/EXAMINE commands has four arguments:
コマンドを選択/調べるためのクイック再同期パラメーターには4つの引数があります。
o the last known UIDVALIDITY,
o 最後に既知のuidvalidity、
o the last known modification sequence,
o 最後の既知の変更シーケンス、
o the optional set of known UIDs, and
o 既知のuidsのオプションのセット、および
o an optional parenthesized list of known sequence ranges and their corresponding UIDs.
o 既知のシーケンス範囲とそれらに対応するUIDのオプションの括弧リスト。
A server MUST respond with a tagged BAD response if the Quick Resynchronization parameter to SELECT/EXAMINE command is specified and the client hasn't issued "ENABLE QRESYNC" in the current connection.
[コマンド]を選択/検査するクイック再同時期化パラメーターが指定され、クライアントが現在の接続で「QRESYNCを有効にする」ことを発行していない場合、サーバーはタグ付きの悪い応答で応答する必要があります。
Before opening the specified mailbox, the server verifies all arguments for syntactic validity. If any parameter is not syntactically valid, the server returns the tagged BAD response, and the mailbox remains unselected. Once the check is done, the server opens the mailbox as if no SELECT/EXAMINE parameters are specified (this is subject to processing of other parameters as defined in other extensions). In particular this means that the server MUST send all untagged responses as specified in Sections 6.3.1 and 6.3.2 of [RFC3501].
指定されたメールボックスを開く前に、サーバーは構文の妥当性に関するすべての引数を検証します。任意のパラメーターが構文的に有効でない場合、サーバーはタグ付きの悪い応答を返し、メールボックスは選択されていないままです。チェックが完了すると、サーバーは、選択/検査パラメーターが指定されていないかのようにメールボックスを開きます（これは、他の拡張機能で定義されている他のパラメーターの処理の対象となります）。特に、これは、[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.
その後、サーバーはクライアントが提供するuidalivityの値をチェックします。提供されたuidialidityが開かれているメールボックスのuidialidityと一致しない場合、サーバーは残りのパラメーターを無視し、動的メッセージデータが変更されないかのように動作する必要があります。クライアントは、サーバーによって返されたuidalidityの値を比較することで、この状況を発見できます。この動作により、クライアントはメールボックスを同期したり、最良の同期戦略を決定したりしません。
Example: Attempting to resynchronize INBOX, but the provided UIDVALIDITY parameter doesn't match the current UIDVALIDITY value.
例：受信トレイを再同期させようとしますが、提供されたuidialidityパラメーターは現在のuidialidityの値と一致しません。
C: A02 SELECT INBOX (QRESYNC (67890007 20050715194045000
41,43:211,214:541))
S: * 464 EXISTS
S: * 3 RECENT
S: * OK [UIDVALIDITY 3857529045] UIDVALIDITY
S: * OK [UIDNEXT 550] Predicted next UID
S: * OK [HIGHESTMODSEQ 90060128194045007]
S: * OK [UNSEEN 12] Message 12 is first unseen
S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft
\Deleted \Seen \*)] Permanent flags
S: A02 OK [READ-WRITE] Sorry, UIDVALIDITY mismatch
Modification Sequence and UID Parameters:
変更シーケンスとUIDパラメーター：
A server that doesn't support the persistent storage of mod-sequences for the mailbox MUST send the OK untagged response including the NOMODSEQ response code with every successful SELECT or EXAMINE command, as described in [CONDSTORE]. Such a server doesn't need to remember mod-sequences for expunged messages in the mailbox. It MUST ignore the remaining parameters and behave as if no dynamic message data changed.
メールボックスのmodシーケンスの永続的なストレージをサポートしていないサーバーは、[condstore]で説明されているように、Condstore]に記載されているように、Commodseq応答コードを含むOK Untagged Responseコードを含むOK Untagged応答コードを送信する必要があります。このようなサーバーは、メールボックス内の削除されたメッセージのmod-sequencesを覚えておく必要はありません。残りのパラメーターを無視し、動的なメッセージデータが変更されていないかのように動作する必要があります。
If the provided UIDVALIDITY matches that of the selected mailbox, the server then checks the last known modification sequence.
提供されたuidialidityが選択したメールボックスのそれと一致する場合、サーバーは最後の既知の変更シーケンスをチェックします。
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を含む必要があるフェッチ応答を使用）、提供された変更シーケンス以来、このメールボックスで発生したものを抹消します。
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)
したがって、クライアントはこれらの保留中のイベントのみを処理でき、完全な再同期を実行する必要はありません。メッセージシーケンス番号が一致する情報がない場合、このステップの結果は、クライアントの発行と同等です。TAG1UIDFETCE "nown-uids"（flags）（「mod-sequence-value」の変更が消滅しました）
Example:
C: A03 SELECT INBOX (QRESYNC (67890007
90060115194045000 41,43:211,214:541))
S: * OK [CLOSED]
S: * 314 EXISTS
S: * 15 RECENT
S: * OK [UIDVALIDITY 67890007] UIDVALIDITY
S: * OK [UIDNEXT 567] Predicted next UID
S: * OK [HIGHESTMODSEQ 90060115205545359]
S: * OK [UNSEEN 7] There are some unseen messages in the mailbox
S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft
\Deleted \Seen \*)] Permanent flags
S: * VANISHED (EARLIER) 41,43:116,118,120:211,214:540
S: * 49 FETCH (UID 117 FLAGS (\Seen \Answered) MODSEQ
(90060115194045001))
S: * 50 FETCH (UID 119 FLAGS (\Draft $MDNSent) MODSEQ
(90060115194045308))
S: ...
S: * 100 FETCH (UID 541 FLAGS (\Seen $Forwarded) MODSEQ
(90060115194045001))
S: A03 OK [READ-WRITE] mailbox selected
Message sequence match data:
メッセージシーケンス一致データ：
A client MAY provide a parenthesized list of a message sequence set and the corresponding UID sets. Both MUST be provided in ascending order. The server uses this data to restrict the range for which it provides expunged message information.
クライアントは、メッセージシーケンスセットと対応するUIDセットの括弧付きリストを提供できます。どちらも昇順で提供する必要があります。サーバーは、このデータを使用して、消去されたメッセージ情報を提供する範囲を制限します。
Conceptually, the client provides a small sample of sequence numbers for which it knows the corresponding UIDs. The server then compares each sequence number and UID pair the client provides with the current state of the mailbox. If a pair matches, then the client knows of any expunges up to, and including, the message, and thus will not include that range in the VANISHED response, even if the "mod-sequence-value" provided by the client is too old for the server to have data of when those messages were expunged.
概念的には、クライアントは、対応するUIDを知っているシーケンス番号の小さなサンプルを提供します。次に、サーバーは各シーケンス番号を比較し、クライアントが提供するUIDペアをメールボックスの現在の状態にします。ペアが一致する場合、クライアントが提供する「Mod-Sequence-value」が古すぎても、クライアントはメッセージを含めて、メッセージを含めて、その範囲を消滅した応答に含めることはありません。サーバーがこれらのメッセージが削除されたときのデータを持つために。
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以下のuidsは8であるか消滅した応答に存在します。（n 1）thメッセージ番号が12で、（n 1）uidが24であり、メールボックス内の（n 1）メッセージがuid 25にある場合、消失した応答に含まれる最低uidは9になります。。
In the following two examples, the server is unable to remember expunges at all, and only UIDs with messages divisible by three are present in the mailbox. In the first example, the client does not use the fourth parameter; in the second, it provides it. This example is somewhat extreme, but shows that judicious usage of the sequence match data can save a substantial amount of bandwidth.
次の2つの例では、サーバーはExpungをまったく覚えていないため、3人で割り切れるメッセージがあるUIDのみがメールボックスに存在します。最初の例では、クライアントは4番目のパラメーターを使用しません。第二に、それはそれを提供します。この例はやや極端ですが、シーケンスマッチデータの賢明な使用により、かなりの量の帯域幅を節約できることが示されています。
Example:
C: A04 SELECT INBOX (QRESYNC (67890007
90060115194045000 1:29997))
S: * 10003 EXISTS
S: * 5 RECENT
S: * OK [UIDVALIDITY 67890007] UIDVALIDITY
S: * OK [UIDNEXT 30013] Predicted next UID
S: * OK [HIGHESTMODSEQ 90060115205545359]
S: * OK [UNSEEN 7] There are some unseen messages in the mailbox
S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft
\Deleted \Seen \*)] Permanent flags
S: * VANISHED (EARLIER) 1:2,4:5,7:8,10:11,13:14 [...]
29998:29999,30001:30002,30004:30005,30007:30008
S: * 9889 FETCH (UID 29667 FLAGS (\Seen \Answered) MODSEQ
(90060115194045027))
S: * 9890 FETCH (UID 29670 FLAGS (\Draft $MDNSent) MODSEQ
(90060115194045028))
S: ...
S: * 9999 FETCH (UID 29997 FLAGS (\Seen $Forwarded) MODSEQ
(90060115194045031))
S: A04 OK [READ-WRITE] mailbox selected
Example:
C: B04 SELECT INBOX (QRESYNC (67890007
90060115194045000 1:29997 (5000,7500,9000,9990:9999 15000,
22500,27000,29970,29973,29976,29979,29982,29985,29988,29991,
29994,29997)))
S: * 10003 EXISTS
S: * 5 RECENT
S: * OK [UIDVALIDITY 67890007] UIDVALIDITY
S: * OK [UIDNEXT 30013] Predicted next UID
S: * OK [HIGHESTMODSEQ 90060115205545359]
S: * OK [UNSEEN 7] There are some unseen messages in the mailbox
S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft
\Deleted \Seen \*)] Permanent flags
S: * VANISHED (EARLIER) 29998:29999,30001:30002,30004:30005,30007:
30008
S: * 9889 FETCH (UID 29667 FLAGS (\Seen \Answered) MODSEQ
(90060115194045027))
S: * 9890 FETCH (UID 29670 FLAGS (\Draft $MDNSent) MODSEQ
(90060115194045028))
S: ...
S: * 9999 FETCH (UID 29997 FLAGS (\Seen $Forwarded) MODSEQ
(90060115194045031))
S: B04 OK [READ-WRITE] mailbox selected
[IMAPABNF] has extended the syntax of the FETCH and UID FETCH commands to include an optional FETCH modifier. This document defines a new UID FETCH modifier: VANISHED.
[IMAPABNF]は、Optional Fetchモディファイアを含めるように、FetchおよびUID Fetchコマンドの構文を拡張しました。このドキュメントでは、新しいUID Fetch Modifier：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.
Vanisped UID Fetch Modifierは、Fetchコマンドで許可されていないことに注意してください。この応答がFetchコマンドの修飾子として指定されている場合、サーバーはタグ付きの悪い応答を返す必要があります。
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.
Vanisped UID Fetch Modifierが指定され、クライアントが現在の接続で「QRESYNCを有効にする」ことを発行していない場合、サーバーはタグ付きの悪い応答で応答する必要があります。
The VANISHED UID FETCH modifier MUST only be specified together with the CHANGEDSINCE UID FETCH modifier.
Vanisped UID Fetch Modifierは、UID Fetch Modifierの変更とともにのみ指定する必要があります。
The VANISHED UID FETCH modifier instructs the server to report those messages from the UID set parameter that have been expunged and whose associated mod-sequence is larger than the specified mod-sequence. That is, the client requests to be informed of messages from the specified set that were expunged since the specified mod-sequence. Note that the mod-sequence(s) associated with these messages were updated when the messages were expunged (as described above). The expunged messages are reported using the VANISHED response as described in Section 3.6, which MUST contain the EARLIER tag. Any VANISHED (EARLIER) responses MUST be returned before any FETCH responses, as otherwise the client might get confused about how message numbers map to UIDs.
Vanished UID Fetch Modifierは、削除されたUIDセットパラメーターからこれらのメッセージを報告するようにサーバーに指示し、関連するmodシーケンスが指定されたmod-sevecenceよりも大きい。つまり、クライアントは、指定されたmod-sequence以降に削除された指定されたセットからのメッセージを通知することを要求します。これらのメッセージに関連付けられたmodシーケンスは、メッセージが削除されたときに更新されたことに注意してください（上記のように）。廃棄されたメッセージは、以前のタグを含める必要があるセクション3.6で説明されているように、消滅した応答を使用して報告されます。消滅した（以前の）応答は、フェッチの応答の前に返される必要があります。そうしないと、クライアントはメッセージ番号がUIDにどのようにマップされるかについて混乱する可能性があります。
Note: A server that receives a mod-sequence smaller than <minmodseq>, where <minmodseq> is the value of the smallest expunged mod-sequence it remembers minus one, MUST behave as if it was requested to report all expunged messages from the provided UID set parameter.
注：<minmodseq>よりも小さいmodシーケンスを受信するサーバー。ここで、<minmodseq>は最小の削除されたmodシーケンスの値です。UIDセットパラメーター。
Example 1: Without the VANISHED UID FETCH modifier, a CONDSTORE-aware client [CONDSTORE] needs to issue separate commands to learn of flag changes and expunged messages since the last synchronization:
例1：消滅したUID Fetch Modifierがなければ、Condstoreを認識するクライアント[Condstore]は、最後の同期以降のフラグの変更と消去されたメッセージを学ぶために、個別のコマンドを発行する必要があります。
C: s100 UID FETCH 300:500 (FLAGS) (CHANGEDSINCE 12345)
S: * 1 FETCH (UID 404 MODSEQ (65402) FLAGS (\Seen))
S: * 2 FETCH (UID 406 MODSEQ (75403) FLAGS (\Deleted))
S: * 4 FETCH (UID 408 MODSEQ (29738) FLAGS ($NoJunk
$AutoJunk $MDNSent))
S: s100 OK FETCH completed
C: s101 UID SEARCH 300:500
S: * SEARCH 404 406 407 408 410 412
S: s101 OK search completed
Where 300 and 500 are the lowest and highest UIDs from client's cache. The second SEARCH response tells the client that the messages with UIDs 407, 410, and 412 are still present, but their flags haven't changed since the specified modification sequence.
ここで、300と500がクライアントのキャッシュから最も低く、最高のUIDです。2番目の検索応答は、UIDS 407、410、および412を含むメッセージがまだ存在していることをクライアントに伝えますが、指定された変更シーケンス以降にフラグは変更されていません。
Using the VANISHED UID FETCH modifier, it is sufficient to issue only a single command:
Vanished UID Fetch Modifierを使用すると、単一のコマンドのみを発行するだけで十分です。
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
応答：じゃんの回答：抹消または消滅します
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コマンドは、現在選択されているメールボックスから\削除されたフラグセットがあるすべてのメッセージを永続的に削除します。クライアントにOKを返す前に、削除されたメッセージは、消滅した応答または抹消の応答を使用して報告されます。
If the server is capable of storing modification sequences for the selected mailbox, it MUST increment the per-mailbox mod-sequence if at least one message was permanently removed due to the execution of the EXPUNGE command. For each permanently removed message, the server MUST remember the incremented mod-sequence and corresponding UID. If at least one message got expunged, the server MUST send the updated per-mailbox modification sequence using the HIGHESTMODSEQ response code (defined in [CONDSTORE]) in the tagged OK response.
サーバーが選択したメールボックスの変更シーケンスを保存できる場合、Excungeコマンドの実行により少なくとも1つのメッセージが永続的に削除された場合、Mailbox Per-box Mod-sevecenceをインクリメントする必要があります。永久に削除された各メッセージについて、サーバーはインクリメントされたmodシーケンスと対応するUIDを覚えておく必要があります。少なくとも1つのメッセージが削除された場合、サーバーは、タグ付きOK応答でhighestmodseq応答コード（[condstore]で定義）を使用して更新されたmailbox変更シーケンスを送信する必要があります。
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, messages 3, 4, 7, and 11 had the \Deleted flag set. The first "* 3 EXPUNGE" reports message # 3 as expunged. The second "* 3 EXPUNGE" reports message # 4 as expunged (the message number got decremented due to the previous EXPUNGE response). See the description of the EXPUNGE response in [RFC3501] for further explanation.
注：この例では、メッセージ3、4、7、および11には\削除されたフラグが設定されていました。最初の「* 3 expunge」は、メッセージ＃3を消去されたと報告しています。2番目の "* 3 expunge"は、削除された場合にメッセージ＃4を報告します（以前の抹消の応答により、メッセージ番号は減少しました）。詳細な説明については、[RFC3501]の抹消反応の説明を参照してください。
Note that if the server chooses to always send VANISHED responses instead of EXPUNGE responses, the previous example might look like this:
サーバーが抹消する代わりに常に消失した応答を送信することを選択した場合、前の例は次のようになる可能性があることに注意してください。
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のメッセージには、それぞれのUIDS 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-閉じて完了しました、現在認証された状態の悪い状態で - コマンド不明または引数が無効です
This section updates the definition of the CLOSE command described in Section 6.4.2 of [RFC3501].
このセクションでは、[RFC3501]のセクション6.4.2で説明されている閉鎖コマンドの定義を更新します。
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コマンドは、現在選択されているメールボックスから\削除されたフラグセットがあるすべてのメッセージを永久に削除し、選択した状態から認証された状態に戻ります。未積ばられていない除去（または消滅した）応答は送信されません。
If the server is capable of storing modification sequences for the selected mailbox, it MUST increment the per-mailbox mod-sequence if at least one message was permanently removed due to the execution of the CLOSE command. For each permanently removed message, the server MUST remember the incremented mod-sequence and corresponding UID. If at least one message got expunged, the server MUST send the updated per-mailbox modification sequence using the HIGHESTMODSEQ response code (defined in [CONDSTORE]) in the tagged OK response.
サーバーが選択したメールボックスの変更シーケンスを保存できる場合、Closeコマンドの実行により少なくとも1つのメッセージが永続的に削除された場合、Mailbox Per-box Mod-sevecenceをインクリメントする必要があります。永久に削除された各メッセージについて、サーバーはインクリメントされたmodシーケンスと対応するUIDを覚えておく必要があります。少なくとも1つのメッセージが削除された場合、サーバーは、タグ付きOK応答でhighestmodseq応答コード（[condstore]で定義）を使用して更新されたmailbox変更シーケンスを送信する必要があります。
Example: C: A202 CLOSE S: A202 OK [HIGHESTMODSEQ 20010715194045319] done
例：C：A202クローズS：A202 OK [HighestModseq 20010715194045319]完了
Arguments: message set
引数：メッセージセット
Responses: untagged responses: EXPUNGE or VANISHED
応答：じゃんの回答：抹消または消滅します
Result: OK - expunge completed
NO - expunge failure: can't expunge (e.g., permission denied)
BAD - command unknown or arguments invalid
This section updates the definition of the UID EXPUNGE command described in Section 2.1 of [UIDPLUS]. Servers that implement both [UIDPLUS] and QRESYNC extensions must implement UID EXPUNGE as described in this section.
このセクションでは、[uidplus]のセクション2.1で説明されているuid expungeコマンドの定義を更新します。[uidplus]とqresync拡張機能の両方を実装するサーバーは、このセクションで説明されているようにuid expungeを実装する必要があります。
The UID EXPUNGE command permanently removes from the currently selected mailbox all messages that both have the \Deleted flag set and have a UID that is included in the specified message set. If a message either does not have the \Deleted flag set or has a UID that is not included in the specified message set, it is not affected.
uid expungeコマンドは、\削除されたフラグセットと指定されたメッセージセットに含まれるUIDを持つ両方とも、現在選択されているメールボックスから永続的に削除されます。メッセージに\削除されたフラグセットがないか、指定されたメッセージセットに含まれていない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.
このコマンドは、切断されたモードクライアントに特に役立ちます。サーバーと再同期するときに抹消する代わりにUID消去を使用することにより、クライアントは、クライアントが最後に接続された時間とクライアントが再同期するまでに、他のクライアントによって削除されたとマークされたメッセージを不注意に削除することを避けることができます。
Before returning an OK to the client, those messages that are removed are reported using a VANISHED response or EXPUNGE responses.
クライアントにOKを返す前に、削除されたメッセージは、消滅した応答または抹消の応答を使用して報告されます。
If the server is capable of storing modification sequences for the selected mailbox, it MUST increment the per-mailbox mod-sequence if at least one message was permanently removed due to the execution of the UID EXPUNGE command. For each permanently removed message, the server MUST remember the incremented mod-sequence and corresponding UID. If at least one message got expunged, the server MUST send the updated per-mailbox modification sequence using the HIGHESTMODSEQ response code (defined in [CONDSTORE]) in the tagged OK response.
サーバーが選択したメールボックスの変更シーケンスを保存できる場合、UID消去コマンドの実行により少なくとも1つのメッセージが永続的に削除された場合、PER-Mailbox Mod-seveanceを増分する必要があります。永久に削除された各メッセージについて、サーバーはインクリメントされたmodシーケンスと対応するUIDを覚えておく必要があります。少なくとも1つのメッセージが削除された場合、サーバーは、タグ付きOK応答でhighestmodseq応答コード（[condstore]で定義）を使用して更新されたmailbox変更シーケンスを送信する必要があります。
Example: C: . UID EXPUNGE 3000:3002
S: * 3 EXPUNGE
S: * 3 EXPUNGE
S: * 3 EXPUNGE
S: . OK [HIGHESTMODSEQ 20010715194045319] Ok
Note: In this example, at least messages with message numbers 3, 4, and 5 (UIDs 3000 to 3002) had the \Deleted flag set. The first "* 3 EXPUNGE" reports message # 3 as expunged. The second "* 3 EXPUNGE" reports message # 4 as expunged (the message number got decremented due to the previous EXPUNGE response). See the description of the EXPUNGE response in [RFC3501] for further explanation.
注：この例では、少なくともメッセージ番号3、4、および5（UIDS 3000〜3002）を持つメッセージには\削除されたフラグが設定されていました。最初の「* 3 expunge」は、メッセージ＃3を消去されたと報告しています。2番目の "* 3 expunge"は、削除された場合にメッセージ＃4を報告します（以前の抹消の応答により、メッセージ番号は減少しました）。詳細な説明については、[RFC3501]の抹消反応の説明を参照してください。
Contents: an optional EARLIER tag
内容：オプションの以前のタグ
list of UIDs
UIDのリスト
The VANISHED response reports that the specified UIDs have been permanently removed from the mailbox. This response is similar to the EXPUNGE response [RFC3501]; however, it can return information about multiple messages, and it returns UIDs instead of message numbers. The first benefit saves bandwidth, while the second is more convenient for clients that only use UIDs to access the IMAP server.
消滅した応答は、指定されたUIDがメールボックスから永久に削除されたことを報告しています。この応答は、消火応答[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).
消失した応答には、抹消の応答と同じように、いつ送信できるかについて同じ制限があります（以下を参照）。
The VANISHED response has two forms. The first form contains the EARLIER tag, which signifies that the response was caused by a UID FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) command. This response is sent if the UID set parameter to the UID FETCH (VANISHED) command includes UIDs of messages that are no longer in the mailbox. When the client sees a VANISHED EARLIER response, it MUST NOT decrement message sequence numbers for each successive message in the mailbox.
消滅した応答には2つの形式があります。最初のフォームには、以前のタグが含まれており、応答がUIDフェッチ（消失）またはSelect/Exemine（QRESYNC）コマンドによって引き起こされたことを意味します。この応答は、UID Fetch（vanished）コマンドにUIDセットパラメーターが、メールボックスにないメッセージのUIDが含まれている場合に送信されます。クライアントが以前の応答に消滅した場合、メールボックス内の連続したメッセージごとにメッセージシーケンス番号を減少させてはなりません。
The second form doesn't contain the EARLIER tag and is described below. Once a client has issued "ENABLE QRESYNC", the server SHOULD use the VANISHED response without the EARLIER tag instead of the EXPUNGE response. The server SHOULD continue using VANISHED in lieu of EXPUNGE for the duration of the connection. In particular, this affects the EXPUNGE [RFC3501] and UID EXPUNGE [UIDPLUS] commands, as well as messages expunged in other connections. Such a VANISHED response MUST NOT contain the EARLIER tag.
2番目のフォームには以前のタグが含まれておらず、以下に説明します。クライアントが「QRESYNCを有効にする」を発行したら、サーバーはexpunge応答の代わりに以前のタグなしで消滅した応答を使用する必要があります。サーバーは、接続期間中、抹消の代わりに消失し続ける必要があります。特に、これはexpunge [rfc3501]およびuid expunge [uidplus]コマンド、および他の接続で抹消されたメッセージに影響します。このような消滅した応答には、以前のタグが含まれてはなりません。
A VANISHED response sent because of an EXPUNGE or UID EXPUNGE command or because messages were expunged in other connections (i.e., the VANISHED response without the EARLIER tag) also decrements the number of messages in the mailbox; it is not necessary for the server to send an EXISTS response with the new value. It also decrements message sequence numbers for each successive message in the mailbox (see the example at the end of this section). Note that a VANISHED response caused by EXPUNGE, UID EXPUNGE, or messages expunged in other connections SHOULD only contain UIDs for messages expunged since the last VANISHED/EXPUNGE response sent for the currently opened mailbox or since the mailbox was opened. That is, servers SHOULD NOT send UIDs for previously expunged messages, unless explicitly requested to do so by the UID FETCH (VANISHED) command.
消失した応答は、抹消またはUID消去コマンドのために送信された、または他の接続でメッセージが削除されたため（つまり、以前のタグなしで消滅した応答）、メールボックス内のメッセージの数も減少します。サーバーが新しい値で存在する応答を送信する必要はありません。また、メールボックス内の各連続したメッセージのメッセージシーケンス番号も減少します（このセクションの最後の例を参照）。他の接続で抹消、UIDの抹消、または抹消されたメッセージによって引き起こされる消滅した応答は、現在開かれているメールボックスに送信された最後の消滅/抹消の応答、またはメールボックスが開かれて以来、消去されたメッセージのUIDのみを含む必要があることに注意してください。つまり、サーバーは、UID Fetch（vanished）コマンドによって明示的に要求されない限り、以前に削除されたメッセージに対してUIDを送信しないでください。
Note that client implementors must take care to properly decrement the number of messages in the mailbox even if a server violates this last SHOULD or repeats the same UID multiple times in the returned UID set. In general, this means that a client using this extension should either avoid using message numbers entirely, or have a complete mapping of UIDs to message sequence numbers for the selected mailbox.
クライアントの実装者は、サーバーがこの最後の違反に違反する場合でも、メールボックス内のメッセージの数を適切に減少させるように注意する必要があることに注意してください。一般に、これは、この拡張機能を使用しているクライアントがメッセージ番号を完全に使用しないか、選択したメールボックスのメッセージシーケンス番号にUIDを完全にマッピングすることを避ける必要があることを意味します。
Because clients handle the two different forms of the VANISHED response differently, servers MUST NOT report UIDs resulting from a UID FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) in the same VANISHED response as UIDs of messages expunged now (i.e., messages expunged in other connections). Instead, the server MUST send separate VANISHED responses: one with the EARLIER tag and one without.
クライアントは、消滅した応答の2つの異なるフォームを異なる方法で処理するため、サーバーは、UIDフェッチ（消失）またはSelect/exemine（QRESYNC）に起因するUIDを報告してはなりません。他のつながりで）。代わりに、サーバーは別々の消滅した応答を送信する必要があります。1つは以前のタグがあり、1つはありません。
A VANISHED response MUST NOT be sent when no command is in progress, nor while responding to a FETCH, STORE, or SEARCH command. This rule is necessary to prevent a loss of synchronization of message sequence numbers between client and server. A command is not "in progress" until the complete command has been received; in particular, a command is not "in progress" during the negotiation of command continuation.
コマンドが進行中のときも、フェッチ、保存、または検索コマンドに応答したときに、消滅した応答を送信してはなりません。このルールは、クライアントとサーバー間のメッセージシーケンス番号の同期の損失を防ぐために必要です。コマンドは、完全なコマンドが受信されるまで「進行中」ではありません。特に、コマンドの継続の交渉中にコマンドは「進行中」ではありません。
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ストア、およびUID検索は、フェッチ、ストア、および検索とは異なるコマンドです。UIDコマンド中に消滅した応答が送信される場合があります。ただし、検索条件にメッセージ番号を含むUID検索コマンド中に消滅した応答を送信してはなりません。
The update from the VANISHED response MUST be recorded by the client.
消滅した応答からの更新は、クライアントが記録する必要があります。
Example: Let's assume that there is the following mapping between message numbers and UIDs in the currently selected mailbox (here "X" marks messages with the \Deleted flag set, and "x" represents UIDs which are not relevant for the example):
例：現在選択されているメールボックスにメッセージ番号とUIDの間に次のマッピングがあると仮定します（ここでは、\削除されたフラグセットでメッセージをマークし、「X」は例に関連しないUIDを表します）：
Message numbers: 1 2 3 4 5 6 7 8 9 10 11 UIDs: x 504 505 507 508 x 510 x x x 625 \Deleted messages: X X X X
メッセージ番号：1 2 3 4 5 6 7 8 9 10 11 UIDS：X 504 505 507 508 X 510 X X X 625 \削除メッセージ：X X X X
In the presence of the extension defined in this document:
このドキュメントで定義されている拡張機能の存在下で：
C: A202 EXPUNGE
S: * VANISHED 505,507,510,625
S: A202 OK EXPUNGE completed
Without the QRESYNC extension, the same example might look like:
QRESYNC拡張機能がなければ、同じ例が次のように見えるかもしれません。
C: A202 EXPUNGE
S: * 3 EXPUNGE
S: * 3 EXPUNGE
S: * 5 EXPUNGE
S: * 8 EXPUNGE
S: A202 OK EXPUNGE completed
(Continuing previous example) If subsequently messages with UIDs 504
and 508 got marked as \Deleted:
C: A210 EXPUNGE
S: * VANISHED 504,508
S: A210 OK EXPUNGE completed
i.e., the last VANISHED response only contains UIDs of messages expunged since the previous VANISHED response.
つまり、最後の消滅した応答には、以前の消滅した応答以来、削除されたメッセージのUIDのみが含まれています。
The CLOSED response code has no parameters. A server implementing the extension defined in this document MUST return the CLOSED response code when the currently selected mailbox is closed implicitly using the SELECT/EXAMINE command on another mailbox. The CLOSED response code serves as a boundary between responses for the previously opened mailbox (which was closed) and the newly selected mailbox: all responses before the CLOSED response code relate to the mailbox that was closed, and all subsequent responses relate to the newly opened mailbox.
閉じた応答コードにはパラメーターがありません。このドキュメントで定義されている拡張機能を実装するサーバーは、現在選択されているメールボックスが別のメールボックスのSelect/exemineコマンドを使用して暗黙的に閉じられている場合、閉じた応答コードを返す必要があります。閉じた応答コードは、以前に開かれたメールボックス（閉じられた）の応答と新しく選択されたメールボックスの境界として機能します。閉じた応答コードの前のすべての応答は、閉じられたメールボックスに関連し、その後のすべての応答は新しく開かれたものに関連していますメールボックス。
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の完了時に閉じた応答コードを返す必要はありません。または、新しい電子メールを開くことなく、現在選択されているメールボックスを閉じることが目的であるCloseまたはUnSelect [unselect]コマンド（または類似）コマンドを返す必要はありません。
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シーケンスを覚えていないサーバーの実装は、この仕様に準拠していると見なすことができます。このような実装は、指定された変更に注意することなく、毎回UIDフェッチ（消失）コマンドのUIDセットで指定されたすべての消去されたメッセージを返します。このような実装は、同じUIDセットのUID検索コマンドの結果よりも大きい消滅した応答を返すことになる可能性があるため、落胆しています。
Clients that use the message sequence match data can reduce the scope of this VANISHED response substantially in the typical case where expunges have not happened, or happen only toward the end of the mailbox.
メッセージシーケンスマッチデータを使用するクライアントは、expungedが発生していない場合、またはメールボックスの最後に向かってのみ発生する典型的なケースで、この消滅した応答の範囲を大幅に削減できます。
A server that stores the HIGHESTMODSEQ value at the time of the last EXPUNGE can omit the VANISHED response when a client provides a MODSEQ value that is equal to, or higher than, the current value of this datum, that is, when there have been no EXPUNGEs.
最後の抹消時にhightmodseq値を保存するサーバーは、クライアントがこのデータムの現在の値と等しい、またはより高いmodseq値を提供する場合、つまり、ない場合、つまり、ない場合に消滅した応答を省略できます。経験します。
A client providing message sequence match data can reduce the scope as above. In the case where there have been no expunges, the server can ignore this data.
メッセージシーケンスマッチデータを提供するクライアントは、上記のようにスコープを削減できます。抹消がなかった場合、サーバーはこのデータを無視できます。
When compared to the [CONDSTORE] extension, this extension requires servers to store additional state associated with expunged messages. Note that implementations are not required to store this state in persistent storage; however, use of persistent storage is advisable.
[condstore]拡張機能と比較すると、この拡張機能は、抹消されたメッセージに関連付けられた追加の状態を保存するためにサーバーを必要とします。この状態を永続的なストレージに保存するために実装は必要ないことに注意してください。ただし、永続的なストレージの使用をお勧めします。
One possible way to correctly implement the extension described in this document is to store a queue of <UID set, mod-sequence> pairs. <UID set> can be represented as a sequence of <min UID, max UID> pairs.
このドキュメントで説明されている拡張機能を正しく実装する可能性のある方法の1つは、<uidセット、mod-sequence>ペアのキューを保存することです。<uid set>は、<min uid、max 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-seecence seaseenceから最低へ）指定されたmodシーケンス以下のシーケンスまたはキューのヘッドに到達します。
Note that indefinitely storing information about expunged messages can cause storage and related problems for an implementation. In the worst case, this could result in almost 64Gb of storage for each IMAP mailbox. For example, consider an implementation that stores <min UID, max UID, mod-sequence> triples for each range of messages expunged at the same time. Each triple requires 16 octets: 4 octets for each of the two UIDs, and 8 octets for the mod-sequence. Assume that there is a mailbox containing a single message with a UID of 2**32-1 (the maximum possible UID value), where messages had previously existed with UIDs starting at 1, and have been expunged one at a time. For this mailbox alone, storage is required for the triples <1, 1, modseq1>, <2, 2, modseq2>, ..., <2**32-2, 2**32-2, modseq4294967294>.
抹消されたメッセージに関する情報を無期限に保存すると、実装のためにストレージや関連する問題が発生する可能性があることに注意してください。最悪の場合、これにより、IMAPメールボックスごとにほぼ64GBのストレージが発生する可能性があります。たとえば、<min uid、max uid、mod-sequence>同時に削除された各範囲の範囲のトリプルを保存する実装を検討してください。各トリプルには、2つのUIDのそれぞれに4オクテット、MODシーケンスに8オクテットが必要です。2 ** 32-1（可能な最大UID値）のUIDを含む単一のメッセージを含むメールボックスがあると仮定します。ここでは、以前は1からUIDが1から除去され、一度に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) are deleted from the queue (note that such records are located at the queue head). For all such "expired" records, the server needs to store a single mod-sequence, which is the highest mod-sequence for all "expired" expunged messages.
したがって、実装は、消去されたメッセージのMODシーケンスを保存するために使用されるキューのサイズを制限し、この制限に達したときに古いレコードを「期限切れ」するなど、そのようなストレージの問題から保護するための戦略を採用することを奨励されます。選択した実装固有のキューの制限に到達すると、最古のレコードがキューから削除されます（そのようなレコードはキューヘッドにあることに注意してください）。このようなすべての「期限切れ」のレコードについて、サーバーは単一のmodシーケンスを保存する必要があります。これは、すべての「有効期限が切れた」削除されたメッセージで最も高いMODシーケンスです。
Note that if the client provides the message sequence match data, this can heavily reduce the data cost of sending a complete set of missing UIDs; thus, reducing the problems for clients if a server is unable to persist much of this queue. If the queue contains data back to the requested mod-sequence, this data can be ignored.
クライアントがメッセージシーケンス一致データを提供する場合、これにより、欠落しているUIDの完全なセットを送信するデータコストを大幅に削減できることに注意してください。したがって、サーバーがこのキューの大部分を保持できない場合、クライアントの問題を減らします。キューに要求されたmod-sequenceに戻るデータが含まれている場合、このデータは無視できます。
Also, note that if the UIDVALIDITY of the mailbox changes or if the mailbox is deleted, then any state associated with expunged messages doesn't need to be preserved and SHOULD be deleted.
また、メールボックスのuidvalidityが変更された場合、またはメールボックスが削除されている場合、抹消されたメッセージに関連付けられた状態は保存する必要がなく、削除する必要があります。
This section updates the description of optimized synchronization in Section 6.1 of the [IMAP-DISC].
このセクションでは、[IMAP-DISC]のセクション6.1の最適化された同期の説明を更新します。
An advanced disconnected mail client should use the QRESYNC and [CONDSTORE] extensions when they are supported by the server. The client uses the value from the HIGHESTMODSEQ OK response code received on mailbox opening to determine if it needs to resynchronize. Once the synchronization is complete, it MUST cache the received value (unless the mailbox UIDVALIDITY value has changed; see below). The client MUST update its copy of the HIGHESTMODSEQ value whenever the server sends a subsequent HIGHESTMODSEQ OK response code.
高度な切断されたメールクライアントは、サーバーによってサポートされている場合は、QRESYNCおよび[Condstore]拡張機能を使用する必要があります。クライアントは、メールボックスの開口部で受信したhightmodseq OK応答コードの値を使用して、再同期する必要があるかどうかを判断します。同期が完了したら、受信された値をキャッシュする必要があります（メールボックスuidalidity値が変更されていない限り、以下を参照）。クライアントは、サーバーが後続のHightModSeq OK応答コードを送信するたびに、HightModSeq値のコピーを更新する必要があります。
After completing a full synchronization, the client MUST also take note of any unsolicited MODSEQ FETCH data items received from the server. Whenever the client receives a tagged response to a command, it calculates the highest value among all MODSEQ FETCH data items received since the last tagged response. If this value is bigger than the client's copy of the HIGHESTMODSEQ value, then the client MUST use this value as its new HIGHESTMODSEQ value.
完全な同期を完了した後、クライアントは、サーバーから受信した未承諾のmodSeqフェッチデータ項目にも注意する必要があります。クライアントがコマンドに対するタグ付けされた応答を受信するたびに、最後にタグ付けされた応答以降に受信したすべてのMODSEQフェッチデータ項目の中で最高値を計算します。この値がクライアントのhighestmodseq値のコピーよりも大きい場合、クライアントはこの値を新しいhighestmodseq値として使用する必要があります。
Note: It is not safe to update the client's copy of the HIGHESTMODSEQ value with a MODSEQ FETCH data item value as soon as it is received because servers are not required to send MODSEQ FETCH data items in increasing modseqence order. This can lead to the client missing some changes in case of connectivity loss.
注：サーバーがModSeqcenceの注文を増やす際にModSeq Fethデータアイテムを送信する必要がないため、受信したらすぐに、ModSeq Fetch Data Item値を使用して、highestmodseq値のクライアントのコピーをModSeq Fetch Data Item値を更新することは安全ではありません。これにより、クライアントが接続性の損失の場合にいくつかの変更を欠いている可能性があります。
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.
同期のためにメールボックスを開くと、クライアントはQRESYNCパラメーターを[選択]コマンドに使用します。QRESYNCパラメーターの後には、クライアントに知られているように、uidalivityとMailbox 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.
選択/検査コマンドが成功した場合、クライアントは、[IMAP-disc]のセクション3でステップd）で説明されているようにuidiality性を比較します。キャッシュされたuidalidity値がサーバーによって返されたものと一致し、サーバーがhightmodseq応答コードも返している場合、サーバーは削除されたメッセージを報告し、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/exemine（QRESYNC）コマンドが成功したときに、クライアントは（最高のモデク応答コードの代わりに）nomodSeq ok untagged応答を受信した場合、キャッシュから最後の既知のhightmodseq値を削除し、セクション3のより一般的な指示に従う必要があります。[IMAP-DISC]。
At this point, the client is in sync with the server regarding old messages. This client can now fetch information about new messages (if requested by the user).
この時点で、クライアントは古いメッセージに関してサーバーと同期しています。このクライアントは、新しいメッセージに関する情報を取得できるようになりました（ユーザーが要求した場合）。
Step d) ("Server-to-client synchronization") in Section 4 of the [IMAP-DISC] in the presence of the QRESYNC & CONDSTORE extensions is amended as follows:
ステップD）（ "Server-to-client Synchronization"）QResync＆Condstore拡張機能の存在下での[IMAP-DISC]のセクション4の拡張が修正されます。
d) "Server-to-client synchronization" -- for each mailbox that requires synchronization, do the following:
d) 「サーバー間同期」 - 同期を必要とする各メールボックスについて、次を実行します。
1a) Check the mailbox UIDVALIDITY (see Section 4.1 of the [IMAP-DISC] for more details) after issuing SELECT/EXAMINE (QRESYNC) command.
1a）select/exemine（qresync）コマンドを発行した後、メールボックスuidalidity（[IMAP-disc]のセクション4.1を参照）を確認してください）。
If the UIDVALIDITY value returned by the server differs, the client MUST
サーバーによって返されたuidialidity値が異なる場合、クライアントは
* empty the local cache of that mailbox;
* そのメールボックスのローカルキャッシュを空にします。
* "forget" the cached HIGHESTMODSEQ value for the mailbox;
* メールボックスのキャッシュされたHighestModSeq値を「忘れて」。
* remove any pending "actions" which refer to UIDs in that mailbox. Note, this doesn't affect actions performed on client generated fake UIDs (see Section 5 of the [IMAP-DISC]);
* そのメールボックス内のUIDを指す保留中の「アクション」を削除します。注意してください、これはクライアントで生成された偽のUIDで実行されるアクションに影響しません（[IMAP-DISC]のセクション5を参照）。
2) Fetch the current "descriptors";
2) 現在の「記述子」を取得します。
I) Discover new messages.
i）新しいメッセージを発見します。
3) Fetch the bodies of any "interesting" messages that the client doesn't already have.
3) クライアントがまだ持っていない「興味深い」メッセージのボディを取得します。
Example: The UIDVALIDITY value is the same, but the HIGHESTMODSEQ value has changed on the server while the client was offline:
例：UIDALICIDITIONの値は同じですが、クライアントがオフラインである間にサーバー上で最も高いModSeq値が変更されました。
C: A142 SELECT INBOX (QRESYNC (3857529045 20010715194032001 1:198))
S: * 172 EXISTS
S: * 1 RECENT
S: * OK [UNSEEN 12] Message 12 is first unseen
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * OK [UIDNEXT 201] Predicted next UID
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
S: * OK [HIGHESTMODSEQ 20010715194045007]
S: * VANISHED (EARLIER) 1:5,7:8,10:15
S: * 2 FETCH (UID 6 MODSEQ (20010715205008000)
FLAGS (\Deleted))
S: * 5 FETCH (UID 9 MODSEQ (20010715195517000)
FLAGS ($NoJunk $AutoJunk $MDNSent))
...
S: A142 OK [READ-WRITE] SELECT completed
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF].
次の構文仕様では、[ABNF]で指定されているように、拡張されたBackus-Naurフォーム（ABNF）表記を使用します。
Non-terminals referenced but not defined below are as defined by [RFC3501], [CONDSTORE], or [IMAPABNF].
参照されていないが、以下に定義されていない非末端は、[RFC3501]、[condstore]、または[imapabnf]で定義されています。
Except as noted otherwise, all alphabetic characters are case-insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion.
それ以外の場合は、言及されている場合を除き、すべてのアルファベット文字はケース非感受性です。トークン文字列を定義するために上または小文字または小文字の文字を使用することは、編集の明確性のみを目的としています。実装は、これらの文字列をケースに依存しない方法で受け入れる必要があります。
capability =/ "QRESYNC"
select-param = "QRESYNC" SP "(" uidvalidity SP mod-sequence-value [SP known-uids] [SP seq-match-data] ")" ;; conforms to the generic select-param ;; syntax defined in [IMAPABNF]
select-param = "qresync" sp "（" uidicalidity sp mod-sequence-value [sp kend-uids] [sp seq-match-data] "）" ;;一般的なセレクトパラムに準拠しています;;[imapabnf]で定義された構文
seq-match-data = "(" known-sequence-set SP known-uid-set ")"
seq-match-data = "（"既知のシーケンスセットSP既知のuid-set "）"
uidvalidity = nz-number
known-uids = sequence-set
;; sequence of UIDs, "*" is not allowed
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
expunged-resp = "VANISHED" [SP "(EARLIER)"] SP known-uids
oabunged-resp = "vanished" [sp "（learte）"] sp known-uids
rexpunges-fetch-mod = "VANISHED"
;; VANISHED UID FETCH modifier conforms
;; to the fetch-modifier syntax
;; defined in [IMAPABNF]. It is only
;; allowed in the UID FETCH command.
resp-text-code =/ "CLOSED"
As always, it is important to thoroughly test clients and servers implementing this extension, as it changes how the server reports expunged messages to the client.
いつものように、この拡張機能を実装するクライアントとサーバーを徹底的にテストすることが重要です。サーバーがクライアントに削除されたメッセージを報告する方法を変更するためです。
Security considerations relevant to [CONDSTORE] are relevant to this extension.
[condstore]に関連するセキュリティ上の考慮事項は、この拡張機能に関連しています。
This document doesn't raise any new security concerns not already raised by [CONDSTORE] or [RFC3501].
このドキュメントは、[Condstore]または[RFC3501]によってまだ提起されていない新しいセキュリティ上の懸念を提起しません。
IMAP4 capabilities are registered by publishing a standards track or IESG approved experimental RFC. The registry is currently located at:
IMAP4機能は、標準トラックまたはIESGが承認した実験RFCを公開することにより登録されます。レジストリは現在、次のようにしています。
http://www.iana.org/assignments/imap4-capabilities
This document defines the QRESYNC IMAP capability. IANA has added this capability to the registry.
このドキュメントでは、QRESYNC IMAP機能を定義します。IANAはこの機能をレジストリに追加しました。
Thanks to Steve Hole, Cyrus Daboo, and Michael Wener for encouraging creation of this document.
この文書の作成を奨励してくれたSteve Hole、Cyrus Daboo、Michael Wenerに感謝します。
Valuable comments, both in agreement and in dissent, were received from Timo Sirainen, Michael Wener, Randall Gellens, Arnt Gulbrandsen, Chris Newman, Peter Coates, Mark Crispin, Elwyn Davies, Dan Karp, Eric Rescorla, and Mike Zraly.
合意と異議の両方で、貴重なコメントは、ティモ・シライネン、マイケル・ウェナー、ランドール・ゲレンズ、アルント・ガルブランドセン、クリス・ニューマン、ピーター・コーツ、マーク・クリスピン、エルウィン・デイビス、ダン・カープ、エリック・レスカルラ、マイク・ズラリーから受け取られました。
This document takes substantial text from [RFC3501] by Mark Crispin.
このドキュメントは、Mark Crispinによる[RFC3501]からかなりのテキストを撮影します。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[ABNF] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF：STD 68、RFC 5234、2008年1月。
[CONDSTORE] Melnikov, A. and S. Hole, "IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization", RFC 4551, June 2006.
[Condstore] Melnikov、A。and S. Hole、「条件付き店舗運用またはクイックフラグの変更のためのIMAP拡張」、RFC 4551、2006年6月。
[ENABLE] Gulbrandsen, A., Ed. and A. Melnikov, Ed., "The IMAP ENABLE Extension", RFC 5161, March 2008.
[有効] Gulbrandsen、A.、ed。A. Melnikov編、「IMAP Enable Extension」、RFC 5161、2008年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月。
[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月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501] CRISPIN、M。、「インターネットメッセージアクセスプロトコル - バージョン4REV1」、RFC 3501、2003年3月。
[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.、ed。、「切断されたIMAP4クライアントの同期操作」、RFC 4549、2006年6月。
[UNSELECT] Melnikov, A., "Internet Message Access Protocol (IMAP) UNSELECT command", RFC 3691, February 2004.
[UNSELECT] Melnikov、A。、「インターネットメッセージアクセスプロトコル（IMAP）UNSELECTコマンド」、RFC 3691、2004年2月。
Authors' Addresses
著者のアドレス
Alexey Melnikov Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
Alexey Melnikov Isode Ltd 5 Castle Business Village 36 Station Road Hampton、Middlesex TW12 2BX UK
EMail: Alexey.Melnikov@isode.com
Dave Cridland Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
Dave Cridland Isode Ltd 5 Castle Business Village 36 Station Road Hampton、Middlesex TW12 2BX UK
EMail: dave.cridland@isode.com
Corby Wilson Nokia 5 Wayside Rd. Burlington, MA 01803 USA
Corby Wilson Nokia 5 Wayside Rd。マサチューセッツ州バーリントン01803 USA
EMail: corby@computer.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。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への情報をお問い合わせください。