[要約] RFC 9394 は、IMAP PARTIAL 拡張機能を使用して、クライアントが返される SEARCH 結果の数を制限し、インクリメンタル（ページング）検索を実行できるようにします。これにより、サーバーは検索を実行する際のリソース使用を最適化できます。
Internet Engineering Task Force (IETF) A. Melnikov
Request for Comments: 9394 Isode
Updates: 4731, 5267 A. P. Achuthan
Category: Standards Track V. Nagulakonda
ISSN: 2070-1721 Yahoo!
L. Alves
June 2023
The PARTIAL extension of the Internet Message Access Protocol (see RFCs 3501 and 9051) allows clients to limit the number of SEARCH results returned, as well as to perform incremental (paged) searches. This also helps servers to optimize resource usage when performing searches.
インターネットメッセージアクセスプロトコル（RFCS 3501および9051を参照）の部分的な拡張により、クライアントは返される検索結果の数を制限し、インクリメンタル（ページ）検索を実行できます。これは、サーバーが検索を実行するときにリソースの使用を最適化するのにも役立ちます。
This document extends the PARTIAL SEARCH return option originally specified in RFC 5267. It also clarifies some interactions between RFC 5267 and RFCs 4731 and 9051.
このドキュメントは、元々RFC 5267で指定されていた部分的な検索リターンオプションを拡張します。また、RFC 5267とRFCS 4731および9051の間のいくつかの相互作用を明確にします。
This document updates RFCs 4731 and 5267.
このドキュメントは、RFCS 4731および5267を更新します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9394.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9394で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
1. Introduction and Overview
2. Document Conventions
3. The PARTIAL Extension
3.1. Incremental SEARCH and Partial Results
3.2. Interaction between PARTIAL, MIN, MAX, and SAVE SEARCH
Return Options
3.3. Extension to UID FETCH
3.4. Use of "PARTIAL" and "CONDSTORE" IMAP Extensions Together
4. Formal Syntax
5. Security Considerations
6. IANA Considerations
6.1. Changes/Additions to the IMAP Capabilities Registry
7. References
7.1. Normative References
7.2. Informative References
Acknowledgments
Authors' Addresses
This document defines an extension to the Internet Message Access Protocol [RFC3501] [RFC9051] for performing incremental searches and fetches. This extension is compatible with both IMAP4rev1 [RFC3501] and IMAP4rev2 [RFC9051]. This extension uses IMAP extensibility rules defined in [RFC4466].
このドキュメントでは、インターネットメッセージとフェッチを実行するために、インターネットメッセージアクセスプロトコル[RFC3501] [RFC9051]への拡張機能を定義します。この拡張は、IMAP4REV1 [RFC3501]とIMAP4REV2 [RFC9051]の両方と互換性があります。この拡張は、[RFC4466]で定義されているIMAP拡張性ルールを使用します。
The PARTIAL extension of the Internet Message Access Protocol allows clients to limit the number of SEARCH results returned, as well as to perform incremental (paged) searches. This also helps servers to optimize resource usage when performing searches.
インターネットメッセージアクセスプロトコルの部分的な拡張により、クライアントは返される検索結果の数を制限し、増分（ページ）検索を実行することができます。これは、サーバーが検索を実行するときにリソースの使用を最適化するのにも役立ちます。
This document extends the PARTIAL SEARCH return option originally specified in RFC 5267. It also clarifies some interactions between RFC 5267 and RFCs 4731 and 9051.
このドキュメントは、元々RFC 5267で指定されていた部分的な検索リターンオプションを拡張します。また、RFC 5267とRFCS 4731および9051の間のいくつかの相互作用を明確にします。
In protocol examples, this document uses a prefix of "C: " to denote lines sent by the client to the server and "S: " for lines sent by the server to the client. Lines prefixed with "// " are comments explaining the previous protocol line. These prefixes and comments are not part of the protocol. Lines without any of these prefixes are continuations of the previous line, and no line breaks are present in the protocol unless specifically mentioned.
プロトコルの例では、このドキュメントでは、「C：」のプレフィックスを使用して、クライアントからサーバーに送信された行、およびサーバーからクライアントに送信された行について「s：」を示します。「//」が付いた行は、以前のプロトコル行を説明するコメントです。これらのプレフィックスとコメントは、プロトコルの一部ではありません。これらのプレフィックスのない線は、前の行の継続であり、具体的に言及されていない限り、プロトコルにはラインブレークは存在しません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
Other capitalized words are IMAP key words [RFC3501] [RFC9051] or key words from this document.
その他の大文字の単語は、IMAPキーワード[RFC3501] [RFC9051]またはこのドキュメントのキーワードです。
An IMAP server advertises support for the PARTIAL extension by including the "PARTIAL" capability in the CAPABILITY response / response code.
IMAPサーバーは、機能応答 /応答コードに「部分的な」機能を含めることにより、部分拡張のサポートを宣伝します。
The PARTIAL SEARCH return option causes the server to provide in an ESEARCH response [RFC4731] [RFC9051] a subset of the results denoted by the sequence range given as the mandatory argument. The first result (message with the lowest matching Unique Identifier (UID)) 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.
部分的な検索リターンオプションにより、サーバーはeSearch応答[RFC4731] [RFC9051]で提供されます。最初の結果（一致する最低の一意の識別子（UID）のメッセージ）は1です。したがって、最初の500の結果は、「部分的な1：500」の返品オプションと2番目の500 by「Partial 501：1000」によって得られます。これは、メッセージシーケンス番号を意図的に反映しています。
It is also possible to direct the server to start the SEARCH from the latest matching (with the highest UID) message. This can be done by prepending "-" to the index. For example, -1 is the last message, -2 is next to the last, and so on. Using this syntax helps server implementations to optimize their SEARCHes.
また、サーバーに最新のマッチング（最高のUID）メッセージから検索を開始するように指示することもできます。これは、「 - 」をインデックスに準備することで実行できます。たとえば、-1は最後のメッセージ、-2は最後のメッセージなどです。この構文を使用すると、サーバーの実装が検索を最適化するのに役立ちます。
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.
単一のコマンドには、1つ以上の部分またはすべての検索戻りオプションを含めてはなりません。つまり、部分的で、すべて、または部分的またはすべてが許可されていません。
For SEARCH results, the entire list of results MUST be ordered in mailbox order -- that is, in UID or message sequence number order.
検索結果の場合、結果のリスト全体をメールボックスの順序で注文する必要があります。つまり、UIDまたはメッセージシーケンス番号の順序です。
In cases where a PARTIAL SEARCH return option references results that do not exist by using a range that starts or ends higher (or lower) than the current number of results, 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. If the whole range references results that do not exist, a special value "NIL" is returned by the server instead of the sequence set.
部分的な検索リターンオプションが、現在の結果よりも高い（または低い）範囲を使用する範囲を使用して存在しない結果を参照する場合、サーバーはセットにある結果を返します。これにより、ペイロードとして、元の範囲と潜在的に欠落している結果セットが範囲の範囲よりも短い場合がある部分的な返品データ項目が得られます。全範囲が存在しない結果を参照する場合、シーケンスセットの代わりにサーバーによって特別な値「nil」が返されます。
Clients need not request PARTIAL results in any particular order. Because mailboxes may change, clients might wish to use PARTIAL in combination with UPDATE (see [RFC5267]) if the server also advertises the "CONTEXT=SEARCH" capability, 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.
クライアントは、特定の順序で部分的な結果を要求する必要はありません。メールボックスが変更される可能性があるため、クライアントは、サーバーが「コンテキスト=検索」機能を宣伝する場合、特に意図が大量の結果を歩くことを宣伝する場合、更新と組み合わせて部分的に使用したい場合があります（[RFC5267]を参照）。ただし、これらのリターンオプションは相互作用しません。更新は、すべてのマッチング結果の通知を提供します。
// Let's assume that the A01 SEARCH without PARTIAL would return
// 23764 results.
C: A01 UID SEARCH RETURN (PARTIAL -1:-100) UNDELETED
UNKEYWORD $Junk
S: * ESEARCH (TAG "A01") UID PARTIAL (-1:-100 ...)
// 100 most recent results in set syntax elided.
S: A01 OK Completed.
// Let's assume that the A02 SEARCH without PARTIAL would return
// 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.
This section only applies if the server advertises the "PARTIAL" IMAP capability or "CONTEXT=SEARCH" [RFC5267], together with "ESEARCH" [RFC4731] and/or IMAP4rev2 [RFC9051].
このセクションは、サーバーが「eSearch」[RFC4731]および/またはIMAP4REV2 [RFC9051]とともに「部分的な」IMAP機能または「Context = search」[RFC5267]を宣伝する場合にのみ適用されます。
The SAVE result option doesn't change whether the server would return items corresponding to PARTIAL SEARCH result options.
Save resultオプションは、サーバーが部分的な検索結果オプションに対応するアイテムを返すかどうかを変更しません。
As specified in Section 3.1, it is an error to specify both the PARTIAL and ALL result options in the same SEARCH command.
セクション3.1で指定されているように、同じ検索コマンドで部分的な結果オプションとすべての結果オプションの両方を指定するのはエラーです。
When the SAVE result option is combined with the PARTIAL result option and none of the MIN/MAX/COUNT result options are present, the corresponding PARTIAL is returned, and the "$" marker would contain references to all messages returned by the PARTIAL result option.
保存結果オプションが部分結果オプションと組み合わされ、min/max/count結果オプションが存在しない場合、対応する部分的な部分が返され、「$」マーカーには、部分結果オプションによって返されるすべてのメッセージへの参照が含まれます。。
When the SAVE and PARTIAL result options are combined with the MIN or MAX result option and the COUNT result option is absent, the corresponding PARTIAL result and MIN/MAX are returned (if the SEARCH result is not empty), and the "$" marker would contain references to all messages returned by the PARTIAL result option together with the corresponding MIN/MAX message.
保存と部分的な結果オプションがMINまたはMAX結果オプションと組み合わされ、カウント結果オプションが存在しない場合、対応する部分結果とMIN/MAXが返されます（検索結果が空でない場合）、「$」マーカーは対応するMIN/MAXメッセージと一緒に、部分結果オプションによって返されるすべてのメッセージへの参照が含まれます。
If the SAVE and PARTIAL result options are combined with both the MIN and MAX result options and the COUNT result option is absent, the PARTIAL, MIN, and MAX result options are returned (if the SEARCH result is not empty), and the "$" marker would contain references to all messages returned by the PARTIAL result option together with the MIN and MAX messages.
保存と部分的な結果のオプションがMINとMAXの結果オプションの両方と組み合わされ、カウント結果オプションが存在しない場合、部分、MIN、およびMAXの結果オプションが返されます（検索結果が空でない場合）、「$は$が返されます。「マーカーには、部分的な結果オプションによって返されたすべてのメッセージへの参照が含まれています。
If the SAVE and PARTIAL result options are combined with the COUNT result option, the PARTIAL and COUNT result options are returned, and the "$" marker would always contain references to all messages found by the SEARCH or UID SEARCH command.
保存と部分的な結果オプションがカウント結果オプションと組み合わされている場合、部分的およびカウント結果オプションが返され、「$」マーカーには常に検索またはUID検索コマンドによって見つかったすべてのメッセージへの参照が含まれます。
Table 1 summarizes additional requirements for ESEARCH server implementations described in this section.
表1に、このセクションで説明するESEarch Serverの実装の追加要件をまとめたものです。
Note regarding Table 1: "[m]" means optional "MIN" and/or "MAX".
表1に関する注意：「[M]」は、オプションの「min」および/または「max」を意味します。
+===============================+=====================+
| Combination of Result Options | "$" Marker Value |
+===============================+=====================+
| SAVE PARTIAL | PARTIAL |
+-------------------------------+---------------------+
| SAVE PARTIAL MIN | PARTIAL & MIN |
+-------------------------------+---------------------+
| SAVE PARTIAL MAX | PARTIAL & MAX |
+-------------------------------+---------------------+
| SAVE PARTIAL MIN MAX | PARTIAL & MIN & MAX |
+-------------------------------+---------------------+
| SAVE PARTIAL COUNT [m] | all found messages |
+-------------------------------+---------------------+
Table 1
The PARTIAL extension also extends the UID FETCH command with a PARTIAL FETCH modifier. The PARTIAL FETCH modifier has the same syntax as the PARTIAL SEARCH result option. The presence of the PARTIAL FETCH modifier instructs the server to only return FETCH results for messages in the specified range. It is useful when the sequence-set (first) parameter in the UID FETCH command includes an unknown number of messages.
部分的な拡張子は、部分的なフェッチ修飾子を使用してUID Fetchコマンドを拡張します。部分的なフェッチモディファイアには、部分的な検索結果オプションと同じ構文があります。部分的なフェッチ修飾子の存在は、指定された範囲のメッセージのFetch結果のみを返すようにサーバーに指示します。UID Fetchコマンドのシーケンスセット（最初の）パラメーターに、未知の数のメッセージが含まれている場合に役立ちます。
// Returning information for the last 3 messages in the UID range
C: 10 UID FETCH 25900:26600 (UID FLAGS) (PARTIAL -1:-3)
S: * 12888 FETCH (FLAGS (\Seen) UID 25996)
S: * 12889 FETCH (FLAGS (\Flagged \Answered) UID 25997)
S: * 12890 FETCH (FLAGS () UID 26600)
S: 10 OK FETCH completed
// Returning information for the first 5 messages in the UID range
C: 11 UID FETCH 25900:26600 (UID FLAGS) (PARTIAL 1:5)
S: * 12591 FETCH (FLAGS (\Seen) UID 25900)
S: * 12592 FETCH (FLAGS (\Flagged) UID 25902)
S: * 12593 FETCH (FLAGS (\Answered) UID 26310)
S: * 12594 FETCH (FLAGS () UID 26311)
S: * 12595 FETCH (FLAGS (\Answered) UID 26498)
S: 11 OK FETCH completed
This section is informative.
このセクションは有益です。
The PARTIAL FETCH modifier can be combined with the CHANGEDSINCE FETCH modifier [RFC7162].
部分的なフェッチ修飾子は、Fetch Modifier [RFC7162]から変更された変更と組み合わせることができます。
// Returning information for the last 30 messages in the UID range
// that have any flags/keywords modified since MODSEQ 98305
C: 101 UID FETCH 25900:26600 (UID FLAGS
) (PARTIAL -1:-30 CHANGEDSINCE 98305)
S: * 12888 FETCH (FLAGS (\Flagged \Answered
) MODSEQ (98306) UID 25997)
S: * 12890 FETCH (FLAGS () MODSEQ (98312) UID 26600)
S: 101 OK FETCH completed
The above example causes the server to first select the last 30 messages and then only return flag changes for a subset of those messages that have MODSEQ higher than 98305.
上記の例により、サーバーは最初に最後の30メッセージを選択し、次にModSeqが98305を超えるメッセージのサブセットのフラグ変更のみを返します。
Note that the order of PARTIAL and CHANGEDSINCE FETCH modifiers in the UID FETCH command is not important, i.e., the above example can also use the "UID FETCH 25900:26600 (UID FLAGS) (CHANGEDSINCE 98305 PARTIAL -1:-30)" command and it would result in the same responses.
UID FetchコマンドのFetch Modifiersが重要ではないため、部分的および変更された順序は重要ではないことに注意してください。つまり、上記の例では、「UID Fetch 25900：26600（UIDフラグ）（変更98305 Partial -1：-30）」コマンドも使用できます。そして、それは同じ応答をもたらすでしょう。
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 IMAP4rev1 [RFC3501] or IMAP4rev2 [RFC9051].
参照されているが以下では定義されていない非末端は、IMAP4REV1 [RFC3501]またはIMAP4REV2 [RFC9051]によって定義されているとおりです。
Except as noted otherwise, all alphabetic characters are case insensitive. The use of uppercase or lowercase characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion.
それ以外の場合は、言及されている場合を除き、すべてのアルファベット文字は症例鈍感です。トークン文字列を定義するために大文字または小文字の文字を使用することは、編集の明確さのみを目的としています。実装は、これらの文字列をケースに依存しない方法で受け入れる必要があります。
SP = <Defined in RFC 5234>
MINUS = "-"
capability =/ "PARTIAL"
;; <capability> from [RFC3501].
modifier-partial = "PARTIAL" SP partial-range
partial-range-first = nz-number ":" nz-number
;; Request to search from oldest (lowest UIDs) to
;; more recent messages.
;; A range 500:400 is the same as 400:500.
;; This is similar to <seq-range> from [RFC3501]
;; but cannot contain "*".
partial-range-last = MINUS nz-number ":" MINUS nz-number
;; Request to search from newest (highest UIDs) to
;; oldest messages.
;; A range -500:-400 is the same as -400:-500.
partial-range = partial-range-first / partial-range-last
search-return-opt =/ modifier-partial
;; All conform to <search-return-opt> from
;; [RFC4466] and [RFC9051].
search-return-data =/ ret-data-partial
ret-data-partial = "PARTIAL"
SP "(" partial-range SP partial-results ")"
;; <partial-range> is the requested range.
partial-results = sequence-set / "NIL"
;; <sequence-set> from [RFC3501].
;; NIL indicates that no results correspond to
;; the requested range.
tagged-ext-simple =/ partial-range-last
fetch-modifier =/ modifier-partial
;; <fetch-modifier> from [RFC4466].
This document defines an additional IMAP4 capability. As such, it does not change the underlying security considerations of IMAP4rev1 [RFC3501] and IMAP4rev2 [RFC9051]. The authors and reviewers believe that no new security issues are introduced with these additional IMAP4 capabilities.
このドキュメントは、追加のIMAP4機能を定義します。そのため、IMAP4REV1 [RFC3501]およびIMAP4REV2 [RFC9051]の基礎となるセキュリティ上の考慮事項は変更されません。著者とレビュアーは、これらの追加のIMAP4機能については、新しいセキュリティの問題が導入されていないと考えています。
This document defines an optimization that can reduce both the amount of work performed by the server and the amount of data returned to the client. Use of this extension is likely to cause the server and the client to use less memory than when the extension is not used. However, as this is going to be new code in both the client and the server, rigorous testing of such code is required in order to avoid introducing new implementation bugs.
このドキュメントでは、サーバーが実行する作業量とクライアントに返されるデータの量の両方を減らすことができる最適化を定義します。この拡張機能の使用により、サーバーとクライアントは、拡張機能を使用していない場合よりも少ないメモリを使用する可能性があります。ただし、これはクライアントとサーバーの両方で新しいコードになるため、新しい実装バグの導入を避けるために、そのようなコードの厳密なテストが必要です。
IMAP4 capabilities are registered by publishing a Standards Track or IESG-approved Informational or Experimental RFC. The registry is currently located at <https://www.iana.org/assignments/imap-capabilities>.
IMAP4機能は、標準トラックまたはIESGが承認した情報または実験RFCを公開することにより登録されます。レジストリは現在、<https://www.iana.org/assignments/imap-capability>にあります。
IANA has added the PARTIAL extension to the "IMAP Capabilities" registry with RFC 9394 as the reference.
IANAは、RFC 9394を参照として「IMAP機能」レジストリに部分的な拡張を追加しました。
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
<https://www.rfc-editor.org/info/rfc3501>.
[RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
ABNF", RFC 4466, DOI 10.17487/RFC4466, April 2006,
<https://www.rfc-editor.org/info/rfc4466>.
[RFC4731] Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH
Command for Controlling What Kind of Information Is
Returned", RFC 4731, DOI 10.17487/RFC4731, November 2006,
<https://www.rfc-editor.org/info/rfc4731>.
[RFC5267] Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267,
DOI 10.17487/RFC5267, July 2008,
<https://www.rfc-editor.org/info/rfc5267>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message
Access Protocol (IMAP) - Version 4rev2", RFC 9051,
DOI 10.17487/RFC9051, August 2021,
<https://www.rfc-editor.org/info/rfc9051>.
[RFC7162] Melnikov, A. and D. Cridland, "IMAP Extensions: Quick Flag
Changes Resynchronization (CONDSTORE) and Quick Mailbox
Resynchronization (QRESYNC)", RFC 7162,
DOI 10.17487/RFC7162, May 2014,
<https://www.rfc-editor.org/info/rfc7162>.
This document was motivated by the Yahoo! team and their questions about best client practices for dealing with large mailboxes.
この文書はYahoo!によって動機付けられました大きなメールボックスを扱うための最高のクライアントプラクティスに関するチームとその質問。
The authors of this document would like to thank the following people, who provided useful comments or participated in discussions of this document: Timo Sirainen and Barry Leiba.
この文書の著者は、有用なコメントを提供するか、この文書の議論に参加した次の人々に感謝したいと思います：Timo SirainenとBarry Leiba。
This document uses a lot of text from RFC 5267. Thus, the work of the RFC 5267 authors -- Dave Cridland and Curtis King -- is appreciated.
このドキュメントでは、RFC 5267の多くのテキストを使用しています。したがって、RFC 5267の著者であるデイブクリッドランドとカーティスキングの作品は高く評価されています。
Alexey Melnikov
Isode Limited
Email: alexey.melnikov@isode.com
URI: https://www.isode.com
Arun Prakash Achuthan
Yahoo!
Email: arunprakash@myyahoo.com
Vikram Nagulakonda
Yahoo!
Email: nvikram_imap@yahoo.com
Luis Alves
Email: luis.alves@lafaspot.com