Network Working Group D. Cridland
Request for Comments: 5267 C. King
Category: Standards Track Isode Limited
July 2008
Contexts for 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
抽象
The IMAP4rev1 protocol has powerful search facilities as part of the core protocol, but lacks the ability to create live, updated results that can be easily handled. This memo provides such an extension, and shows how it can be used to provide a facility similar to virtual mailboxes.
IMAP4rev1のプロトコルは、コアプロトコルの一部として、強力な検索機能を持っていますが、簡単に扱うことができ、ライブ、更新された結果を作成する能力を欠いています。このメモは、そのような拡張を提供し、仮想メールボックスに似た機能を提供するために使用することができる方法を示しています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Extended Sort Syntax . . . . . . . . . . . . . . . . . . . . . 3
3.1. ESORT Extension . . . . . . . . . . . . . . . . . . . . . 4
3.2. Ranges in Extended Sort Results . . . . . . . . . . . . . 4
3.3. Extended SORT Example . . . . . . . . . . . . . . . . . . 4
4. Contexts . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Context Hint . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. Notifications of Changes . . . . . . . . . . . . . . . . . 6
4.3.1. Refusing to Update Contexts . . . . . . . . . . . . . 7
4.3.2. Common Features of ADDTO and REMOVEFROM . . . . . . . 8
4.3.3. ADDTO Return Data Item . . . . . . . . . . . . . . . . 8
4.3.4. REMOVEFROM Return Data Item . . . . . . . . . . . . . 9
4.3.5. The CANCELUPDATE Command . . . . . . . . . . . . . . . 10
4.4. Partial Results . . . . . . . . . . . . . . . . . . . . . 10
4.5. Caching Results . . . . . . . . . . . . . . . . . . . . . 11
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Cookbook . . . . . . . . . . . . . . . . . . . . . . 15
A.1. Virtual Mailboxes . . . . . . . . . . . . . . . . . . . . 15
A.2. Trash Mailboxes . . . . . . . . . . . . . . . . . . . . . 15
A.3. Immediate EXPUNGE Notifications . . . . . . . . . . . . . 15
A.4. Monitoring Counts . . . . . . . . . . . . . . . . . . . . 15
A.5. Resynchronizing Contexts . . . . . . . . . . . . . . . . . 16
Appendix B. Server Implementation Notes . . . . . . . . . . . . . 16
Although the basic SEARCH command defined in [IMAP], and as enhanced by [ESEARCH], is relatively compact in its representation, this reduction saves only a certain amount of data, and huge mailboxes might overwhelm the storage available for results on even relatively high-end desktop machines.
基本的な検索コマンドが[IMAP]で定義され、そして[ESEARCH]によって拡張として、その表現に比較的コンパクトであるが、この減少はデータのみ一定量を保存し、そして巨大なメールボックスは、比較的高いさえ上の結果を得るために使用可能なストレージを圧倒する可能性があります末端デスクトップマシン。
The SORT command defined in [SORT] provides useful features, but is hard to use effectively on changing mailboxes over low-bandwidth connections.
[ソート]で定義されたSORTコマンドは、便利な機能を提供するが、低帯域幅接続を介してメールボックスを変更することで効果的に使用することは困難です。
This memo borrows concepts from [ACAP], such as providing a windowed view onto search or sort results, and making updates that are bandwidth and round-trip efficient. These are provided by two extensions: "ESORT" and "CONTEXT".
このメモは、検索またはソート結果にウィンドウビューを提供し、帯域幅と往復が効率的更新を行うように、[ACAP]から概念を借り。 「ESORT」と「CONTEXT」：これらは、2つの拡張によって提供されています。
In examples, "C:" and "S:" indicate lines sent by the client messaging user agent and IMAP4rev1 ([IMAP]) server, respectively. "//" indicates inline comments not part of the protocol exchange. Line breaks are liberally inserted for clarity. Examples are intended to be read in order, such that the state remains from one example to the next.
実施例において、「C：」および「S：」は、それぞれ、クライアント・メッセージング・ユーザエージェントとのIMAP4rev1（[IMAP]）サーバによって送信されたラインを示します。 「//」プロトコル交換の一部ではないインラインコメントを示します。改行は自由にわかりやすくするために挿入されています。実施例は、状態は一例から次へのままであるように、順番に読まれることが意図されます。
Although the examples show a server that supports [ESEARCH], this is not a strict requirement of this specification.
例としては、[ESEARCH]サポートするサーバを示しているが、これは本明細書の厳密な要件ではありません。
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 [KEYWORDS].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[キーワード]に記載されているように解釈されます。
Other capitalized words are typically names of IMAP extensions or commands -- these are uppercased for clarity only, and are case-insensitive.
これらは唯一の明確化のために大文字にして、大文字と小文字を区別しません - その他の大文字の言葉は、一般的にIMAP拡張やコマンドの名前です。
Servers implementing the extended SORT provide a suite of extensions to the SORT and UID SORT commands defined in [SORT]. This allows for return options, as used with SEARCH and specified in [IMAP-ABNF], to be used with SORT in a similar manner.
拡張SORTを実装するサーバは、[ソート]で定義されたSORTとUIDのSORTコマンドの拡張のスイートを提供します。検索に使用され、同様にSORTで使用する、[IMAP-ABNF]で指定されるように、これは、リターン・オプションを可能にします。
The SORT and UID SORT commands are extended by the addition of an optional list of return options that follow a RETURN atom immediately after the command. If this is missing, the server will return results as specified in [SORT].
SORTとUIDのSORTコマンドは、コマンドの直後にRETURN原子をたどるリターンオプションのオプションリストの追加によって拡張されています。これが欠落している場合は、[SORT]で指定されているように、サーバは結果を返します。
The extended SORT command always returns results in the requested sort order, but is otherwise identical in its behaviour to the extended SEARCH command defined in [IMAP-ABNF], as extended by [ESEARCH]. In particular, the extended SORT command returns results in an ESEARCH response.
拡張SORTコマンドが常に要求されたソート順に結果を返すが、[ESEARCH]によって拡張されるように、[IMAP-ABNF]で定義された拡張検索コマンドにその挙動でそれ以外は同一です。特に、拡張SORTコマンド戻りESEARCH応答をもたらします。
Servers advertising the capability "ESORT" support the return options specified in [ESEARCH] in the SORT command. These return options are adapted as follows:
機能「ESCORT」を宣伝サーバーは、SORTコマンドで[研究]で指定された戻りオプションをサポートしています。次のようにこれらの戻りオプションが適応されます。
MIN Return the message number/UID of the lowest sorted message satisfying the search criteria.
MINは、検索基準を満たす最低のソートメッセージのメッセージ番号/ UIDを返します。
MAX Return the message number/UID of the highest sorted message satisfying the search criteria.
MAX戻り、検索条件を満たす最高のソートメッセージのメッセージ番号/ UID。
ALL Return all message numbers/UIDs which match the search criteria, in the requested sort order, using a sequence-set. Note the use of ranges described below in Section 3.2.
ALLは、配列のセットを使用して、要求されたソート順に、検索条件に一致するすべてのメッセージ番号/ UIDを返します。 3.2節で後述の範囲の使用に注意してください。
COUNT As in [ESEARCH].
【ESEARCH]のようにCOUNT。
Any ranges given by the server, including those given as part of the sequence-set, in an ESEARCH response resulting from an extended SORT or UID SORT command, MUST be ordered in increasing numerical order after expansion, as per usual [IMAP] rules.
拡張SORT又はUID SORTコマンドに起因ESEARCH応答のシーケンスセットの一部として与えられたものを含むサーバ、によって与えられた任意の範囲は、通常[IMAP]の規則に従って、拡張後の数値昇順に並べなければなりません。
In particular this means that 10:12 is equivalent to 12:10, and 10,11,12. To avoid confusion, servers SHOULD present ranges only when the first seq-number is lower than the second; that is, either of the forms 10:12 or 10,11,12 is acceptable, but 12:10 SHOULD be avoided.
特に、これは、10時12は、12：10、および10,11,12と同等であることを意味します。混乱を避けるために、サーバは範囲第SEQ-数が第2のより低い場合のみ提示しなければなりません。つまり、フォーム10時12分または10,11,12のいずれかが許容可能であるが、12:10避けるべきです。
If the list of return options is present but empty, then the server provides the ALL return data item in an ESEARCH response. This is functionally equivalent to an unextended UID SORT command, but can use a smaller representation:
リターン・オプションのリストが存在するが空の場合、サーバーはESEARCH応答ですべての戻りデータ項目を提供します。これは、未伸長UID SORTコマンドと機能的に同等であるが、より小さな表現を使用することができます。
C: E01 UID SORT RETURN () (REVERSE DATE) UTF-8 UNDELETED
UNKEYWORD $Junk
S: * ESEARCH (TAG "E01") UID ALL 23765,23764,23763,23761,[...]
S: E01 OK Sort completed
Note that the initial three results are not represented as the range 23765:23763 as mandated in Section 3.2.
3.2節で義務付けられ23763：初期の3つの結果が範囲23765として表現されていないことに注意してください。
The Contexts extension is present in any IMAP4rev1 server that includes the string "CONTEXT=SEARCH", and/or "CONTEXT=SORT", within its advertised capabilities.
コンテキスト拡張は、そのアドバタイズ能力の範囲内で、文字列「CONTEXT = SEARCH」を含む任意のIMAP4rev1サーバに存在する、および/または「CONTEXT = SORT」。
In the case of CONTEXT=SEARCH, the server supports the extended SEARCH command syntax described in [IMAP-ABNF], and accepts three additional return options.
CONTEXT = SEARCHの場合、サーバは[IMAP-ABNF]で説明した拡張検索コマンドの構文をサポートしており、三つの追加リターンオプションを受け付けます。
Servers advertising CONTEXT=SORT also advertise the SORT capability, as described in [SORT], support the extended SORT command syntax described in Section 3, and accept three additional return options for this extended SORT.
サーバーの広告はCONTEXT = SORTも[SORT]で説明したように、SORTの機能をアドバタイズ第3節で説明した拡張SORTコマンドの構文をサポートしており、この拡張SORTための3つの追加的なリターンのオプションを受け入れます。
These additional return options allow for notifications of changes to the results of SEARCH or SORT commands, and also allow for access to partial results.
これらの追加のリターンオプションは、検索やSORTコマンドの結果に対する変更の通知を可能にし、また部分的な結果へのアクセスを可能にします。
A server advertising the CONTEXT=SEARCH extension will order all SEARCH results, whether from a UID SEARCH or SEARCH command, in mailbox order -- that is, by message number and UID. Therefore, the UID SEARCH, SEARCH, UID SORT, or SORT command used -- collectively known as the searching command -- will always have an order, the requested order, which will be the mailbox order for UID SEARCH and SEARCH commands.
CONTEXT = SEARCH拡張子を広告するサーバーは、メールボックスのために、どうかUID SEARCHまたはSEARCHコマンドから、すべての検索結果を注文します - であること、メッセージ番号とUIDで。そのため、UID検索、検索、UID SORT、またはSORT使用するコマンド - をまとめて検索コマンドとして知られている - は常にUID検索と検索コマンド用メールボックスの順となりますため、要求された順序を、持っています。
All of the return specifiers have no interaction with either each other or any return specifiers defined in [ESEARCH] or Section 3.1; however, it is believed that implementations supporting CONTEXT will also support ESEARCH and ESORT.
戻り指定子の全ては、互いに、または[ESEARCH]またはセクション3.1で定義された戻り指定子のいずれかとの相互作用を持ちません。しかし、CONTEXTをサポートする実装もESEARCHとESORTをサポートすると考えられています。
The return option CONTEXT SHOULD be used by a client to indicate that subsequent use of the search criteria are likely. Servers MAY ignore this return option or use it as a hint to maintain a full result cache, or index.
リターンオプションCONTEXTは、検索条件のその後の使用がそうであることを示すために、クライアントによって使用されるべきです。サーバはこの戻りオプションを無視するか、完全な結果キャッシュ、またはインデックスを維持するためのヒントとしてそれを使用することができます。
A client might choose to obtain a count of matching messages prior to obtaining actual results. Here, the client signals its intention to fetch the results themselves:
クライアントは、実際の結果を取得する前にメッセージを照合のカウントを取得することを選択するかもしれません。ここでは、クライアントが結果自分自身を取得する意向を知らせます：
C: A01 SEARCH RETURN (CONTEXT COUNT) UNDELETED
UNKEYWORD $Junk
S: * ESEARCH (TAG "A01") COUNT 23765
S: A01 OK Search completed.
The search return option UPDATE, if used by a client, causes the server to issue unsolicited notifications containing updates to the results that would be returned by an unmodified searching command. These update sets are carried in ADDTO and REMOVEFROM data items in ESEARCH responses.
検索リターンオプションUPDATEは、クライアントが使用している場合、未修正の検索コマンドによって返される結果への更新を含む任意通知を発行するサーバーが発生します。これらのアップデートセットはESEARCH応答のADDTOとREMOVEFROMデータ項目に運ばれます。
These ESEARCH responses carry a search correlator of the searching command, hence clients MUST NOT reuse tags, as already specified in Section 2.2.1 of [IMAP]. An attempt to use UPDATE where a tag is already in use with a previous searching command that itself used UPDATE SHALL result in the server rejecting the searching command with a BAD response.
これらのESEARCH応答はすでに[IMAP]のセクション2.2.1に指定されているので、クライアントは、タグを再利用してはいけません、検索コマンドの検索相関器を運びます。タグ自体はUPDATEはBAD応答で検索コマンドを拒絶するサーバをもたらすものと使用した以前の検索コマンドを使用して、既に使用されている場合UPDATEを使用しようとします。
Both ADDTO and REMOVEFROM data items SHOULD be delivered to clients in a timely manner, as and when results change, whether by new messages arriving in the mailbox, metadata such as flags being changed, or messages being expunged.
どちらもADDTOとREMOVEFROMデータ項目は、前述したように、タイムリーにクライアントに配信されるべきであり、結果が変化したときに、メールボックスに到着した新しいメッセージによるかどうか、フラグなどのメタデータが変更され、またはメッセージが抹消されています。
Typically, this would occur at the same time as the FETCH, EXISTS, or EXPUNGE responses carrying the source of the change.
典型的には、これは、FETCH EXISTS、または変更のソースを運ぶ応答をEXPUNGEと同時に起こります。
Updates will cease when the mailbox is no longer selected, or when the CANCELUPDATE command, defined in Section 4.3.5, is issued by the client, whichever is sooner.
メールボックスがもはや選択されている、または4.3.5項で定義されているのCancelUpdateコマンドは、どちらでも早く、クライアントによって発行されたとき時に更新が停止しません。
Unlike [ACAP], there is no requirement that a context need be created with CONTEXT to use UPDATE, and in addition, the lack of UPDATE with a CONTEXT does not affect the results caused by later searching commands -- there is no snapshot facility.
[ACAP]とは異なり、コンテキストがUPDATEを使用するCONTEXTで作成する必要要件はない、と加えて、CONTEXTとUPDATEの欠如は、後でコマンドを検索して生じた結果には影響しません - 何のスナップショット機能はありません。
There is no interaction between UPDATE and any other return options; therefore, use of RETURN (UPDATE MIN), for example, does not notify about the minimum UID or sequence number, but notifies instead about all changes to the set of matching messages. In particular, this means that a client using UPDATE and PARTIAL on the same search program could receive notifications about messages that do not currently interest it.
UPDATEおよびその他のリターン・オプションの間には相互作用はありません。従って、RETURN（MINを更新する）の使用は、例えば、最小UIDまたはシーケンス番号を通知しないが、一致するメッセージのセットに対するすべての変更についての代わりに通知します。特に、これは、同じ検索プログラムにUPDATEとPARTIALを使用しているクライアントは、現在それを興味ないメッセージに関する通知を受け取ることができることを意味します。
Finally, as specified in the errata to [IMAP], any message sequence numbers used in the search program are evaluated at the time the command is received; therefore, if the messages referred to by such message sequence numbers change, no notifications will be emitted.
[IMAP]にエラッタで指定されるように最終的に、検索プログラムで使用される任意のメッセージシーケンス番号は、コマンドを受信した時に評価されます。メッセージは、メッセージシーケンス番号の変更によって参照場合従って、何ら通知は放出されないであろう。
This time, the client will require notifications of updates and chooses to obtain a count:
今回は、クライアントがアップデートの通知を必要とし、カウントを取得することを選択します。
C: B01 UID SEARCH RETURN (UPDATE COUNT) DELETED
KEYWORD $Junk
S: * ESEARCH (TAG "B01") COUNT 74
S: B01 OK Search completed, will notify.
// Note that the following is rejected, and has no effect:
C: B01 SORT RETURN (UPDATE) FLAGGED
S: B01 BAD Tag reuse
In some cases, the server MAY refuse to provide updates, such as if an internal limit on the number of update contexts is reached. In such a case, an untagged NO is generated during processing of the command with a response-code of NOUPDATE. The response-code contains, as argument, the tag of the search command for which the server is refusing to honour the UPDATE request.
いくつかのケースでは、サーバーは、このような更新コンテキストの数の内部制限に達した場合など最新情報を提供することを拒否するかもしれません。このような場合には、タグなしNOはNOUPDATEの応答コードと、コマンドの処理中に生成されます。応答コードは、引数、サーバはUPDATE要求を尊重することを拒否された検索コマンドのタグとして、含まれています。
Other return options specified SHALL still be honoured.
指定されたその他のリターンオプションは、まだ受け入れられないものとします。
Servers MUST provide at least one updating context per client, and SHOULD provide more -- see Appendix B for strategies on reducing the impact of additional updating contexts. Since sorted contexts require a higher implementation cost than unsorted contexts, refusal to provide updates for a SORT command does not imply that SEARCH contexts will also be refused.
サーバは、クライアントごとに少なくとも1つの更新状況を提供しなければならない、と多くを提供すべき - 追加の更新状況の影響を減らす上での戦略については、付録Bを参照してください。ソートされたコンテキストがソートされていない状況よりも高い実装コストを必要とするので、SORTコマンドのアップデートを提供するために、拒否は、検索コンテキストも拒否されることを意味するものではありません。
This time, the client will require notifications of updates, and chooses to obtain a count:
今回は、クライアントがアップデートの通知を必要とし、カウント数を取得することを選択します。
C: B02 UID SORT RETURN (UPDATE COUNT) UTF-8
KEYWORD $Junk
S: * ESEARCH (TAG "B02") COUNT 74
S: * NO [NOUPDATE "B02"] Too many contexts
S: B02 OK Search completed, will not notify.
Client handling might be to retry with a UID SEARCH command, or else cancel an existing context; see Section 4.3.5.
クライアントの取り扱いは、UID SEARCHコマンドを再試行するか、あるいは既存のコンテキストをキャンセルするかもしれません。 4.3.5項を参照してください。
The result update set included in the return data item is specified as UIDs or message numbers, depending on how the UPDATE was specified. If the UPDATE was present in a SEARCH or SORT command, the results will be message numbers; in a UID SEARCH or UID SORT command, they will be UIDs.
戻りデータ項目に含まれる結果の更新セットはUPDATEが指定された方法に応じて、UIDやメッセージ番号として指定されています。 UPDATE検索またはSORTコマンドで存在した場合、結果は、メッセージ番号であろう。 UID検索やUID SORTコマンドでは、彼らがのUIDとなります。
The client MUST process ADDTO and REMOVEFROM return data items in the order they appear, including those within a single ESEARCH response. Correspondingly, servers MUST generate ADDTO and REMOVEFROM responses such that the results are maintained in the requested order.
クライアントは、彼らが単一ESEARCH応答内のものを含めて、表示される順序でADDTOとREMOVEFROMリターンデータ項目を処理しなければなりません。これに対応し、サーバは、結果が要求された順序で維持されるようにADDTOやREMOVEFROM応答を生成しなければなりません。
As with any response aside from EXPUNGE, ESEARCH responses carrying ADDTO and/or REMOVEFROM return data items MAY be sent at any time. In particular, servers MAY send such responses when no command is in progress, during the processing of any command, or when the client is using the IDLE facility described in [IDLE]. Implementors are recommended to read [NOTIFY] as a mechanism for clients to signal servers that they are willing to process responses at any time, and are also recommended to pay close attention to Section 5.3 of [IMAP].
脇EXPUNGEからの応答と同様に、ADDTOおよび/またはREMOVEFROMリターンデータ項目を運ぶESEARCH応答は、任意の時点で送るかもしれません。具体的には、何のコマンドが進行中でない場合、サーバは、任意のコマンドの処理中に、そのような応答を送信することができる、またはクライアントが[IDLE]に記載の遊休設備を使用している場合。実装者は、クライアントがいつでも応答を処理するために喜んであり、また、[IMAP]の5.3節に細心の注意を払うことが推奨されているサーバを通知するためのメカニズムとして読み込む[NOTIFY]することをお勧めします。
It is anticipated that typical server implementations will emit ADDTO when they normally emit the causal FETCH or EXISTS, and similarly emit REMOVEFROM when they normally emit the causal FETCH or EXPUNGE.
それらは、通常、原因がFETCHまたは存在し、同様にそれらは通常因果フェッチまたはEXPUNGE発するときREMOVEFROMを放出する放出するとき、典型的なサーバの実装はADDTOを放出することが予想されます。
The ADDTO return data item contains, as payload, a list containing pairs of a context position and a set of result updates in the requested order to be inserted at the context position. Where the searching command is a SEARCH or UID SEARCH command, the context position MAY be zero. Each pair is processed in the order that it appears.
ADDTOリターンデータ項目は、ペイロードとして、コンテキストの位置と要求された順序で結果の更新のセットの対を含むリストは、コンテキストの位置に挿入されるように、含まれています。検索コマンドは、検索またはUID SEARCHコマンドである場合には、文脈位置はゼロであってもよいです。各ペアは、それが表示されていることを順番に処理されます。
Note that an ADDTO containing message sequence numbers added as a result of those messages being delivered or appended MUST be sent after the EXISTS notification itself, in order that those sequence numbers are valid.
これらのメッセージの結果として追加ADDTO含むメッセージシーケンス番号が送達されるか、または、それらのシーケンス番号が有効であるために、通知自体をEXISTS後に送信しなければならない添付されていることに注意してください。
If the context position is non-zero, the result update is inserted at the given context position, meaning that the first result in the set will occupy the new context position after insertion, and any prior existing result at that context position will be shifted to a later context position.
文脈位置が非ゼロの場合、結果の更新は、セット内の最初の結果は、挿入後に新しい文脈位置を占有し、そのコンテキスト位置の任意の前の既存の結果にシフトされることを意味し、特定のコンテキストの位置に挿入され後でコンテキスト位置。
Where the context position is zero, the client MAY insert the message numbers or UIDs in the result list such that the result list is maintained in mailbox order. In this case, servers are RECOMMENDED to order the result update into mailbox order to produce the shortest representation in set-syntax.
コンテキスト位置がゼロである場合には、クライアントが結果リストがメールボックスのために維持されるように結果リストのメッセージ番号またはUIDを挿入することができます。この場合、サーバはセット構文における最短表現を生成するために、メールボックスのために結果の更新を注文することをお勧めします。
[...]
S: * 23762 FETCH (FLAGS (\Deleted \Seen))
S: * 23763 FETCH (FLAGS ($Junk \Seen))
S: * ESEARCH (TAG "B01") UID ADDTO (0 32768:32769)
Note that this example assumes messages 23762 and 23763 with UIDs 32768 and 32769 (respectively) previously had neither \Deleted nor $Junk set. Also note that only the ADDTO is included, and not the (now changed) COUNT.
この例では、（それぞれ）メッセージ23762と32768のUIDと23763と32769を想定して、以前に\削除されたり$ジャンクセットどちらを持っていたことに注意してください。また、（今変更）COUNTのみADDTOが含まれていることに注意してください、とありません。
If the searching command "C01" initially generated a result list of 2734:2735, then the following three responses are equivalent, and yield a result list of 2731:2735:
検索コマンド「C01」は当初、2734年の結果リスト生成した場合：2735を、次の3つの応答は等価であり、2731年の結果リストもたらす：2735を：
[...]
S: * ESEARCH (TAG "C01") UID ADDTO (1 2733 1 2732 1 2731)
S: * ESEARCH (TAG "C01") UID ADDTO (1 2733) ADDTO (1 2731:2732)
S: * ESEARCH (TAG "C01") UID ADDTO (1 2731:2733)
The last is the preferred representation.
最後は、好適な表現です。
The REMOVEFROM return data item contains, as payload, a list containing pairs of a context position and a set of result updates in the requested order to be removed starting from the context position. Where the searching command is a SEARCH or UID SEARCH command, the context position MAY be zero. Each pair is processed in the order that it appears.
REMOVEFROMリターンデータ項目は、ペイロード、コンテキスト位置およびコンテキスト位置から除去される要求された順序で結果の更新のセットの対を含むリストとして、含まれています。検索コマンドは、検索またはUID SEARCHコマンドである場合には、文脈位置はゼロであってもよいです。各ペアは、それが表示されていることを順番に処理されます。
If the context position is non-zero, the results are removed at the given context position, meaning that the first result in the set will occupy the given context position before removal, and any prior existing result at that context position will be shifted to an earlier context position.
文脈位置が非ゼロの場合、結果は、セット内の最初の結果は、除去の前に指定されたコンテキストの位置を占有することを意味し、特定のコンテキストの位置で除去され、そのコンテキスト位置の任意の前の既存の結果は、ANに移行します以前のコンテキスト位置。
Where the context position is zero, the client removes the message numbers or UIDs in the result list wherever they occur, and servers are RECOMMENDED to order the result list in mailbox order to obtain the best benefit from the set-syntax.
コンテキスト位置がゼロである場合、クライアントは、彼らが起こるどこ結果リストのメッセージ番号またはUIDを削除し、サーバは、セットの構文から最高の利益を得るために、メールボックスのために、結果リストを注文することをお勧めします。
Note that a REMOVEFROM containing message sequence numbers removed as a result of those messages being expunged MUST be sent prior to the expunge notification itself, in order that those sequence numbers remain valid.
抹消されたこれらのメッセージの結果として除去REMOVEFROM含むメッセージシーケンス番号は、それらのシーケンス番号が有効なままであるために、EXPUNGE通知自体の前に送信されなければならないことに留意されたいです。
Here, a message in the result list is expunged. The REMOVEFROM is shown to happen without any command in progress; see Section 4.3.2. Note that EXPUNGE responses do not have this property.
ここでは、結果リストのメッセージが消去されます。 REMOVEFROMは、進行中の任意のコマンドなしで起こることが示されています。 4.3.2項を参照してください。 EXPUNGE応答は、このプロパティを持っていないことに注意してください。
[...]
S: * ESEARCH (TAG "B01") UID REMOVEFROM (0 32768)
C: B03 NOOP
S: * 23762 EXPUNGE
S: B03 OK Nothing done.
When a client no longer wishes to receive updates, it may issue the CANCELUPDATE command, which will prevent all updates to the contexts named in the arguments from being transmitted by the server. The command takes, as arguments, one or more tags of the commands used to request updates.
クライアントは、もはや更新を受信したいときは、サーバーによって送信されてから、引数で指定されたコンテキストに対するすべての更新を防ぐことができますのCancelUpdateコマンドを発行しないことがあります。コマンドには、引数、更新を要求するために使用されるコマンドの1つまたは複数のタグとして、かかります。
The server MAY free any resource associated with a context so disabled -- however, the client is free to issue further searching commands with the same criteria and requested order, including PARTIAL requests.
サーバは、その無効コンテキストに関連付けられているすべてのリソースを解放するかもしれ - しかし、クライアントは、同じ基準でさらに検索コマンドを発行して自由であるとPARTIAL要求を含む、順序を要求しました。
C: B04 CANCELUPDATE "B01"
S: B04 OK No further updates.
The PARTIAL search return option causes the server to provide in an ESEARCH response a subset of the results denoted by the sequence range given as the mandatory argument. The first result is 1; thus, the first 500 results would be obtained by a return option of "PARTIAL 1:500", and the second 500 by "PARTIAL 501:1000". This intentionally mirrors message sequence numbers.
PARTIAL検索リターンオプションは、サーバがESEARCH応答に必須の引数として与えられたシーケンスの範囲で示される結果のサブセットを提供する原因となります。最初の結果は1です。 「：1000 PARTIAL 501」で「500 PARTIAL 1」、及び第500従って、最初の500回の結果は、リターンオプションによって得られるであろう。これは意図的にメッセージのシーケンス番号を反映しています。
A single command MUST NOT contain more than one PARTIAL or ALL search return option -- that is, either one PARTIAL, one ALL, or neither PARTIAL nor ALL is allowed.
単一のコマンドは、複数のPARTIALつまたはすべての検索リターンオプションを含んではならない - つまり、PARTIAL 1、1 ALLのいずれか、またはPARTIALもALLどちらが許可されます。
For SEARCH results, the entire result list MUST be ordered in mailbox order, that is, in UID or message sequence number order.
検索結果を得るために、全体の結果リストは、UIDまたはメッセージシーケンス番号順に、つまり、メールボックスのために注文する必要があります。
Where a PARTIAL search return option references results that do not exist, by using a range which starts or ends higher than the current number of results, then the server returns the results that are in the set. This yields a PARTIAL return data item that has, as payload, the original range and a potentially missing set of results that may be shorter than the extent of the range.
存在しない場合はPARTIAL検索リターンオプションの参照結果は、開始さや結果の現在の数よりも高い終わる範囲を使用することにより、サーバはセットである結果を返します。これは、ペイロード、元の範囲及び範囲の範囲よりも短くてもよい結果の潜在的に欠落セットとして、有するPARTIALリターンデータ項目をもたらします。
Clients need not request PARTIAL results in any particular order. Because mailboxes may change, clients will often wish to use PARTIAL in combination with UPDATE, especially if the intent is to walk a large set of results; however, these return options do not interact -- the UPDATE will provide notifications for all matching results.
クライアントは、特定の順序で部分的な結果を要求する必要はありません。メールボックスが変更されることがあるため、クライアントはしばしば意図が結果の大規模なセットを歩いている場合は特に、UPDATEと組み合わせてPARTIAL使用したいでしょう。しかし、これらの戻りオプションは相互作用しない - UPDATEが一致するすべての結果の通知を提供します。
// Recall from A01 that there are 23764 results.
C: A02 UID SEARCH RETURN (PARTIAL 23500:24000) UNDELETED
UNKEYWORD $Junk
C: A03 UID SEARCH RETURN (PARTIAL 1:500) UNDELETED
UNKEYWORD $Junk
C: A04 UID SEARCH RETURN (PARTIAL 24000:24500) UNDELETED
UNKEYWORD $Junk
S: * ESEARCH (TAG "A02") UID PARTIAL (23500:24000 ...)
// 264 results in set syntax elided,
// this spans the end of the results.
S: A02 OK Completed.
S: * ESEARCH (TAG "A03") UID PARTIAL (1:500 ...)
// 500 results in set syntax elided.
S: A03 OK Completed.
S: * ESEARCH (TAG "A04") UID PARTIAL (24000:24500 NIL)
// No results are present, this is beyond the end of the results.
S: A04 OK Completed.
Server implementations MAY cache results from a SEARCH or SORT, whether or not hinted to by CONTEXT, in order to make subsequent searches more efficient, perhaps by recommencing a subsequent PARTIAL search where a previous search left off. However, servers MUST behave identically whether or not internal caching is taking place; therefore, any such cache is required to be updated as changes to the mailbox occur. An alternate strategy would be to discard results when any change occurs to the mailbox.
サーバ実装は、おそらく前の検索が中断し、その後の部分検索を再開することで、その後の検索は、より効率的にするためには、CONTEXTによって示唆かどうかにかかわらず、検索やSORTからの結果をキャッシュすることができます。内部キャッシュが行われているかどうかただし、サーバーは、同じように動作しなければなりません。メールボックスへの変更が発生すると、したがって、そのようなキャッシュを更新する必要があります。代替戦略は、任意の変更がメールボックスに発生したときの結果を破棄することです。
The collected formal syntax. This uses ABNF as defined in [ABNF]. It includes definitions from [IMAP], [IMAP-ABNF], and [SORT].
収集した正式な構文。 [ABNF]で定義されるように、これはABNFを使用します。これは、[IMAP]、[IMAP-ABNF]、および[SORT]の定義を含みます。
capability =/ "CONTEXT=SEARCH" / "CONTEXT=SORT" / "ESORT" ;; <capability> from [IMAP]
機能= / "CONTEXT = SEARCH" / "CONTEXT = SORT" / "ESORT" ;; [IMAP]から<機能>
command-select =/ "CANCELUPDATE" 1*(SP quoted) ;; <command-select> from [IMAP]
コマンド選択= / "のCancelUpdate" 1 *（SPが引用された）;; <コマンド選択> [IMAP]から
context-position = number ;; Context position may be 0 for SEARCH result additions. ;; <number> from [IMAP]
文脈位置=番号;;コンテキスト位置は、検索結果の追加のための0かもしれません。 ;; [IMAP]から<番号>
modifier-context = "CONTEXT"
修飾子コンテキスト= "CONTEXT"
modifier-partial = "PARTIAL" SP partial-range
修飾子-部分= "PARTIAL" SP部分範囲
partial-range = nz-number ":" nz-number ;; A range 500:400 is the same as 400:500. ;; This is similar to <seq-range> from [IMAP], ;; but cannot contain "*".
部分範囲= NZ-数 "：" NZ-数;;範囲500：500：400は400と同じです。 ;;これは、[IMAP]から<配列レンジ>と同様である;;しかし、「*」を含めることはできません。
modifier-update = "UPDATE"
修飾子更新= "UPDATE"
search-return-opt =/ modifier-context / modifier-partial / modifier-update ;; All conform to <search-return-opt>, from [IMAP-ABNF]
検索リターン-OPT = /修飾子コンテキスト/修飾子-部分/修飾子更新;;すべては[IMAP-ABNF]から、<検索リターン-OPT>に準拠します
resp-text-code =/ "NOUPDATE" SP quoted ;; <resp-text-code> from [IMAP]
RESP-テキストコード= / "NOUPDATE" SPは、引用符で囲まれた;; <RESPテキストコード> [IMAP]から
ret-data-addto = "ADDTO" SP "(" context-position SP sequence-set *(SP context-position SP sequence-set) ")" ;; <sequence-set> from [IMAP]
RET-データADDTO = "ADDTO" SP "（" コンテキスト位置SPシーケンスがセット*（SP文脈位置SP配列セット） "）" ;; <シーケンスセット> [IMAP]から
ret-data-partial = "PARTIAL" SP "(" partial-range SP partial-results ")" ;; <partial-range> is the requested range.
RET-データ部分= "PARTIAL" SP "（" 部分レンジSP部分結果 "）" ;; <部分範囲>は、要求された範囲です。
partial-results = sequence-set / "NIL" ;; <sequence-set> from [IMAP] ;; NIL indicates no results correspond to the requested range.
部分的な結果=配列セット/「NIL」;; <シーケンスセット> [IMAP]から;; NILは結果が要求された範囲に対応しないことを示します。
ret-data-removefrom = "REMOVEFROM" SP "(" context-position SP sequence-set *(SP context-position SP sequence-set) ")" ;; <sequence-set> from [IMAP]
RET-データremovefrom = "REMOVEFROM" SP "（" コンテキスト位置SPシーケンスセット*（SP文脈位置SP配列セット） "）" ;; <シーケンスセット> [IMAP]から
search-return-data =/ ret-data-partial / ret-data-addto / ret-data-removefrom ;; All conform to <search-return-data>, from [IMAP-ABNF]
検索リターンデータ= / RET-データ部分/ RET-データADDTO / RET-データremovefrom ;;すべては[IMAP-ABNF]から、<検索・リターン・データ>に準拠します
sort =/ extended-sort ;; <sort> from [SORT]
ソート= /拡張ソート;; [SORT]から<ソート>
extended-sort = ["UID" SP] "SORT" search-return-opts SP sort-criteria SP search-criteria ;; <search-return-opts> from [IMAP-ABNF] ;; <sort-criteria> and <search-criteria> from [SORT]
拡張ソート= [「UID」SP]「SORT」SPソート基準SPの検索条件を検索・リターンは、付き合え;; <リターン-optsの検索> [IMAP-ABNF] ;; [SORT]から<ソート基準>と<検索条件>
This document defines additional IMAP4 capabilities. As such, it does not change the underlying security considerations of [IMAP]. The authors and reviewers believe that no new security issues are introduced with these additional IMAP4 capabilities.
この文書では、追加のIMAP4機能を定義します。このように、それは、[IMAP]の基本的なセキュリティの考慮事項を変更しません。著者と査読には、新たなセキュリティ問題は、これらの追加IMAP4機能で導入されていないと信じています。
Creation of a large number of contexts may provide an avenue for denial-of-service attacks by authorized users. Implementors may reduce this by limiting the number of contexts possible to create, via the protocol features described in Section 4.3.1; by reducing the impact of contexts by the implementation strategies described in Appendix B; and by logging context creation and usage so that administrative remedies may be applied.
コンテキストの多数の作成が許可されたユーザーによるサービス拒否攻撃のための手段を提供することができます。実装者は、セクション4.3.1に記載したプロトコル機能を介して、作成することができるコンテキストの数を制限することによって、これを低減することができます。付録Bに記載の実装戦略によってコンテキストの影響を低減することにより、コンテキストの作成と使用をロギングすることで行政救済を適用することができるようになっています。
IMAP4 capabilities are registered by publishing a Standards Track or IESG-approved Experimental RFC.
IMAP4機能は標準化過程かIESGが承認した実験的RFCを公開することにより、登録されています。
This document defines the ESORT, CONTEXT=SEARCH, and CONTEXT=SORT IMAP capabilities. IANA has added them to the registry accordingly.
この文書はESORT、CONTEXT = SEARCH、およびCONTEXT = SORTのIMAP機能を定義します。 IANAはそれに応じて、レジストリに追加しました。
Much of the design of this extension can be found in ACAP. Valuable comments, both in agreement and in dissent, were received from Alexey Melnikov, Arnt Gulbrandsen, Cyrus Daboo, Filip Navara, Mark Crispin, Peter Coates, Philip Van Hoof, Randall Gellens, Timo Sirainen, Zoltan
この拡張機能の設計の多くはACAPで見つけることができます。契約のと反対意見の両方の貴重なコメントは、アレクセイ・メルニコフ、ARNT Gulbrandsenの、サイラスDaboo、フィリップナバラ、マーク・クリスピン、ピーター・コーツ、フィリップ・ヴァン・フーフ、ランドールGellens、ティモ・シレーヌン、ゾルタンから受け取りました
Ordogh, and others, and many of these comments have had significant influence on the design or the text. The authors are grateful to all those involved, including those not mentioned here.
Ordogh、その他、及びこれらのコメントの多くは、デザインやテキストに大きな影響を与えました。著者は、ここに記載されていないものも含め関係するすべてのものに感謝しています。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
、STD 68、RFC 5234、2008年1月： "ABNF構文仕様のための増大しているBNF" [ABNF]クロッカー、D.、およびP. Overell、。
[ESEARCH] Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned", RFC 4731, November 2006.
[ESEARCH]メルニコフ、A.とD. Cridland、2006年11月、RFC 4731「IMAP4拡張は、情報の種類が返されるどのような制御するためのコマンドを検索するために」。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP]クリスピン、M.、 "インターネットメッセージアクセスプロトコル - バージョン4rev1"、RFC 3501、2003年3月。
[IMAP-ABNF] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006.
[IMAP-ABNF]メルニコフ、A.およびC. Daboo、 "IMAP4 ABNFに収集された拡張機能"、RFC 4466、2006年4月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[SORT] Crispin, M. and K. Murchison, "Internet Message Access Protocol - SORT and THREAD Extensions", RFC 5256, June 2008.
[SORT]クリスピン、M.とK.マーチソン、 "インターネットメッセージアクセスプロトコル - SORTとTHREAD拡張機能"、RFC 5256、2008年6月。
[ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[ACAP]ニューマン、C.及びJ.マイヤーズ、 "ACAP - アプリケーション構成アクセスプロトコル"、RFC 2244、1997年11月。
[IDLE] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997.
[IDLE] Leiba、B.、 "IMAP4 IDLEコマンド"、RFC 2177、1997年6月。
[NOTIFY] Melnikov, A., Gulbrandsen, A., and C. King, "The IMAP NOTIFY Extension", Work in Progress, March 2008.
[NOTIFY]メルニコフは、A.、Gulbrandsenの、A.、およびC.王は、進歩、2008年3月に、仕事を "IMAPは、拡張子をNOTIFY"。
Appendix A. Cookbook
付録A.クックブック
A.1. Virtual Mailboxes
A.1。仮想メールボックス
It is possible to use the facilities described within this memo to create a facility largely similar to a virtual mailbox, but handled on the client side.
主に仮想メールボックスに似ていますが、クライアント側で処理施設を作成するには、このメモの中に説明する機能を使用することが可能です。
Initially, the client SELECTs the real "backing" mailbox. Next, it can switch to a filtered view at any time by issuing a RETURN (COUNT UPDATE CONTEXT), and using RETURN (PARTIAL x:y) as the user scrolls, feeding the results into a FETCH as required to populate summary views.
最初に、クライアントは本当の「裏」メールボックスを選択します。ユーザがスクロールとして、要約ビューを移入するために必要に応じてFETCHに結果を供給：次に、RETURN（カウント更新CONTEXT）を発行し、RETURN（Y PARTIAL X）を使用して、いつでも濾過ビューに切り替えることができます。
A typically useful view is "UID SORT (DATE) RETURN (...) UTF-8 UNSEEN UNDELETED", which can be used to show the mailbox sorted into INTERNALDATE order, filtered to only show messages which are unread and not yet deleted.
一般的に便利なビューだけで未読ではなく、まだ削除されたメッセージが表示されるようにフィルタ処理INTERNALDATE順にソートメールボックスを表示するために使用することができ、「UID SORT（DATE）RETURN（...）UTF-8 UNSEEN UNDELETED」、です。
A.2. Trash Mailboxes
A.2。ゴミ箱のメールボックス
Certain contexts are particularly useful for client developers wishing to present something similar to the common trash mailbox metaphor in limited bandwidth. The simple criteria of UNDELETED only matches undeleted messages, and the corresponding DELETED search key can be used to display a per-mailbox trash-like virtual mailbox.
特定のコンテキストでは、限られた帯域幅での一般的なゴミメールボックスのメタファーのようなものを提示したいクライアント開発者のために特に有用です。 UNDELETEDの簡単な基準が削除されなかっただけのメッセージと一致し、対応するDELETED検索キーは、メールボックスごとのゴミのような仮想メールボックスを表示するために使用することができます。
A.3. Immediate EXPUNGE Notifications
A.3。即時EXPUNGE通知
The command "SEARCH RETURN (UPDATE) ALL" can be used to create a context that notifies immediately about expunged messages, yet will not affect message sequence numbers until the normal EXPUNGE message can be sent. This may be useful for clients wishing to show this behavior without losing the benefit of sequence numbering.
コマンド「検索RETURN（UPDATE）がALL」消去されたメッセージについて、直ちに通知コンテキストを作成するために使用することができ、まだ通常のEXPUNGEメッセージを送ることができるようになるまで、メッセージシーケンス番号には影響しません。これは、シーケンス番号の利益を失うことなく、この動作を表示したいクライアントのために有用である可能性があります。
A.4. Monitoring Counts
A.4。監視カウント
A client need not maintain any result cache at all, but instead it can maintain a simple count of messages matching the search criteria. Typically, this would use the SEARCH command, as opposed to UID SEARCH, due to its smaller representation. Such usage might prove useful in monitoring the number of flagged, but unanswered, messages, for example, with "SEARCH RETURN (UPDATE COUNT) FLAGGED UNANSWERED".
クライアントは、まったく結果キャッシュを維持する必要はないが、その代わりに、それは、検索条件に一致するメッセージの簡単な数を維持することができます。典型的には、これは、その小さな表現に、UID検索とは対照的に、SEARCHコマンドを使用します。このような使用方法は、「検索RETURN（更新カウント）UNANSWEREDフラグ付き」で、例えば、フラグが付けられますが、未応答メッセージの数を監視するのに有用であることが分かるかもしれません。
A.5. Resynchronizing Contexts
A.5。再同期コンテキスト
The creation of a context, and immediate access to it, can all be accomplished in a single round-trip. Therefore, whilst it is possible to elide resynchronization if no changes have occurred, it is simpler in most cases to resynchronize by simply recreating the context.
コンテキストの作成、およびそれへの即時アクセスは、すべて単一のラウンドトリップで達成することができます。それは何も変化が生じていない場合は、再同期をElideのことが可能である一方でしたがって、単にコンテキストを再作成することによって再同期するために、ほとんどの場合、単純です。
Appendix B. Server Implementation Notes
付録B.サーバの実装の注意事項
Although a server may cache the results, this is neither mandated nor required, especially when the client uses SEARCH or UID SEARCH commands. UPDATE processing, for example, can be achieved efficiently by comparison of the old flag state (if any) and the new, and PARTIAL can be achieved by re-running the search until the suitable window is required. This is a result of there being no snapshot facility.
サーバが結果をキャッシュかもしれないが、これはどちらも、クライアントが検索またはUID SEARCHコマンドを使用する場合は特に、義務付けられていないにも必要です。更新処理は、例えば、古いフラグの状態（もしあれば）と新たに比較することにより効率的に達成することができ、部分は、適切なウィンドウが必要とされるまで、検索を再実行することによって達成することができます。これは、そこには、スナップショット機能であることなかった結果です。
For example, on a new message, the server can simply test for matches against all current UPDATE context search programs, and for any that match, send the ADDTO return data.
たとえば、新しいメッセージに、サーバーは、単純に現在のすべての更新コンテキスト検索プログラムに対する一致のためにテストすることができ、および任意のその試合のために、ADDTOリターンデータを送信します。
Similarly, for a flag change on an existing message, the server can check whether the message matched with its old flags, whether it matches with new flags, and provide ADDTO or REMOVEFROM return data accordingly if these results differ.
同様に、既存のメッセージにフラグ変更のために、サーバーは、それが新しいフラグと一致するかどうか、メッセージはその古いフラグと一致するかどうかを確認することができ、これらの結果が異なる場合に応じてADDTOまたはREMOVEFROMリターンデータを提供します。
For PARTIAL requests, the server can perform a full search, discarding results until the lower bound is hit, and stopping the search when sufficient results have been obtained.
PARTIAL要求の場合、サーバーは、下限がヒットするまで結果を破棄し、十分な結果が得られたときに、検索を停止し、完全な検索を行うことができます。
With some additional state, it is possible to restart PARTIAL searches, thus avoiding performing the initial discard phase.
いくつかの追加の状態で、このように初期の廃棄段階の実行を回避することができる、PARTIAL検索を再開することが可能です。
For the best performance, however, caching the full search results is needed, which can allow for faster responses at the expense of memory. One reasonable strategy would be to balance this trade-off at run-time, discarding search results after a suitable timeout, and regenerating them as required.
最高のパフォーマンスを実現するために、しかし、完全な検索結果をキャッシュするメモリを犠牲にしてより高速な応答を可能にすることができる、必要とされています。一つの合理的な戦略は、適切なタイムアウト後に、検索結果を破棄し、実行時に、このトレードオフのバランスを取ること、および必要に応じてそれらを再生させるでしょう。
This yields state requirements of storing the search program for any UPDATE contexts, and optionally storing both search program and (updated) results for further contexts as required.
これは、任意のUPDATEコンテキストの検索プログラムを記憶し、必要に応じて任意に検索プログラム、さらにコンテキストの（更新）結果の両方を記憶する状態要件をもたらします。
Note that in the absence of a server-side results cache, it may be impossible to know if an expunged message previously matched unless the original message is still available. Therefore, some implementations may be forced into using a results cache in many circumstances.
元のメッセージがまだ利用可能でない限り、サーバ側の結果キャッシュの非存在下で、消去されたメッセージは、以前に一致したかどうかを知ることは不可能であり得ることに留意されたいです。そのため、いくつかの実装は、多くの状況で結果キャッシュを使用するに強制することができます。
UPDATE contexts created with SORT or UID SORT will almost certainly require some form of results caching, however.
SORTまたはUID SORTで作成したUPDATEコンテキストはほぼ確実しかし、結果キャッシュのいくつかのフォームが必要になります。
Authors' Addresses
著者のアドレス
Dave Cridland Isode Limited 5 Castle Business Village 36, Station Road Hampton, Middlesex TW12 2BX GB
デイブCridland ISODE限定5キャッスルビジネス村36、駅の道ハンプトン、ミドルTW12 2BX GB
EMail: dave.cridland@isode.com
メールアドレス：dave.cridland@isode.com
Curtis King Isode Limited 5 Castle Business Village 36, Station Road Hampton, Middlesex TW12 2BX GB
カーティスキングISODE限定5キャッスルビジネス村36、駅の道ハンプトン、ミドルTW12 2BX GB
EMail: cking@mumbo.ca
メールアドレス：cking@mumbo.ca
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。