Internet Engineering Task Force (IETF) A. Melnikov
Request for Comments: 9586 Isode
Category: Experimental A. P. Achuthan
ISSN: 2070-1721 V. Nagulakonda
A. Singh
Yahoo!
L. Alves
May 2024
The UIDONLY extension to the Internet Message Access Protocol (RFCs 3501 and 9051) allows clients to enable a mode in which information about mailbox changes is returned using only Unique Identifiers (UIDs). Message numbers are not returned in responses and cannot be used in requests once this extension is enabled. This helps both clients and servers to reduce resource usage required to maintain a map between message numbers and UIDs.
インターネットメッセージアクセスプロトコル（RFCS 3501および9051）へのUIDONLY拡張により、クライアントは、一意の識別子（UID）のみを使用してメールボックスの変更に関する情報が返されるモードを有効にすることができます。メッセージ番号は応答では返されず、この拡張機能が有効になったらリクエストでは使用できません。これにより、クライアントとサーバーの両方が、メッセージ番号とUIDの間のマップを維持するために必要なリソース使用量を削減するのに役立ちます。
This document defines an experimental IMAP extension.
このドキュメントは、実験的なIMAP拡張を定義します。
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントは、インターネット標準の追跡仕様ではありません。試験、実験的実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントでは、インターネットコミュニティ向けの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。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/rfc9586.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9586で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 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 UIDONLY Extension
3.1. Enabling the UIDONLY Extension
3.2. Changes to FETCH/STORE/SEARCH/COPY/MOVE
3.3. Changes to UID FETCH / UID STORE
3.4. Changes to EXPUNGE / UID EXPUNGE
3.5. Changes to UID SEARCH
3.6. Changes to How Other Mailbox Changes Are Announced
3.7. Interaction with the CONDSTORE and QRESYNC Extensions
3.8. Interaction with Other Extensions
4. Formal Syntax
5. Security Considerations
6. IANA Considerations
7. Alternative Solutions Not Taken
8. Normative References
9. Informative References
Acknowledgments
Authors' Addresses
This document defines an extension to the Internet Message Access Protocol [RFC3501] [RFC9051] for eliminating the use of message numbers. This extension is compatible with both IMAP4rev1 [RFC3501] and IMAP4rev2 [RFC9051].
このドキュメントでは、メッセージ番号の使用を排除するために、インターネットメッセージアクセスプロトコル[RFC3501] [RFC9051]への拡張機能を定義します。この拡張は、IMAP4REV1 [RFC3501]とIMAP4REV2 [RFC9051]の両方と互換性があります。
The UIDONLY extension of the Internet Message Access Protocol allows clients to request that servers only use and return UIDs. This helps both clients and servers to reduce resource usage required to maintain a map between message numbers and UIDs.
インターネットメッセージアクセスプロトコルのuidonly拡張機能により、クライアントはサーバーがUIDのみを使用して返すことを要求できます。これにより、クライアントとサーバーの両方が、メッセージ番号とUIDの間のマップを維持するために必要なリソース使用量を削減するのに役立ちます。
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 break is 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.
キーワード「必須」、「必要」、「必須」、「shall」、「shall」、「shill "of"、 "nove"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Other capitalized words are names of IMAP commands or responses [RFC3501] [RFC9051] or keywords from this document.
その他の大文字の単語は、IMAPコマンドまたは応答の名前[RFC3501] [RFC9051]またはこのドキュメントのキーワードです。
An IMAP server advertises support for the UIDONLY extension by including the "UIDONLY" capability in the CAPABILITY response/ response code.
IMAPサーバーは、機能応答/応答コードに「uidonly」機能を含めることにより、uidonly拡張機能のサポートを宣伝します。
Once the UIDONLY extension is enabled (see Section 3.1), the client MUST NOT use message sequence numbers (including the special marker "*") in any arguments to IMAP commands, and the server MUST return a tagged BAD response if the client uses message sequence numbers. The server MUST include the UIDREQUIRED response code in such BAD responses (see below). Additionally, once the UIDONLY extension is enabled, the server MUST NOT return message sequence numbers in any response.
Uidonly拡張機能が有効になったら（セクション3.1を参照）、クライアントはIMAPコマンドの引数でメッセージシーケンス番号（特別なマーカー「*」を含む）を使用してはなりません。シーケンス番号。サーバーは、このような悪い応答にUIDRequed応答コードを含める必要があります（以下を参照）。さらに、Uidonly拡張機能が有効になったら、サーバーはどの応答でもメッセージシーケンス番号を返してはなりません。
The UIDREQUIRED response code is defined as follows:
UIDRequed応答コードは、次のように定義されています。
UIDREQUIRED:
uidrequired：
Once the UIDONLY extension is enabled, the server returns the UIDREQUIRED response code when the client issues a command that includes message numbers instead of UIDs.
Uidonly拡張機能が有効になると、クライアントがUIDの代わりにメッセージ番号を含むコマンドを発行すると、サーバーはUIDRequed Responseコードを返します。
C: 07 FETCH 10000:14589 (UID FLAGS)
S: 07 BAD [UIDREQUIRED] Message numbers are not allowed
once UIDONLY is enabled
The UIDONLY extension affects how information about new, expunged, or changed messages is returned in unsolicited responses. In particular, it affects responses to UID FETCH/UID STORE/EXPUNGE/UID EXPUNGE, as well as how unsolicited mailbox changes are announced.
uidonly拡張機能は、新しい、削除された、または変更されたメッセージに関する情報が未承諾の応答でどのように返されるかに影響します。特に、UID Fetch/UID Store/expunge/UID Ovengeへの応答と、未承諾のメールボックスの変更が発表される方法に影響します。
The following subsections describe changes introduced by this extension in more detail.
次のサブセクションでは、この拡張機能によって導入された変更について詳しく説明します。
As the UIDONLY extension affects how information about new, expunged, or changed messages is returned in unsolicited responses, it has to be enabled by the client first using the ENABLE command.
uidonly拡張機能は、新しい、抹消された、または変更されたメッセージに関する情報が未承諾の応答でどのように返されるかに影響するため、最初にenableコマンドを使用してクライアントが有効にする必要があります。
S: * OK [CAPABILITY IMAP4rev1 ENABLE CONDSTORE QRESYNC UIDONLY
AUTH=SCRAM-SHA-256]
C: 01 ENABLE UIDONLY
S: * ENABLED UIDONLY
S: 01 OK ENABLE completed
When UIDONLY is enabled, the FETCH, STORE, SEARCH, COPY, and MOVE commands are prohibited and MUST result in a tagged BAD response. Clients should instead use UID FETCH, UID STORE, UID SEARCH, UID COPY, or UID MOVE, respectively.
uidonlyが有効になっている場合、コマンドをフェッチ、保存、検索、コピー、および移動するコマンドが禁止されており、タグ付きの悪い応答が必要です。代わりに、クライアントは、それぞれUIDフェッチ、UIDストア、UID検索、UIDコピー、またはUID移動を使用する必要があります。
When UIDONLY is enabled, all FETCH responses that would be returned by UID FETCH / UID STORE are replaced by UIDFETCH responses.
uidonlyが有効になっている場合、uid fetch / uidストアによって返されるすべてのフェッチ応答は、uidfetch応答に置き換えられます。
Note that the UIDFETCH response contains the same response data items as specified for the FETCH response. The UID is always returned at the beginning of a UIDFETCH response, and it can also appear in the UID response data item, if requested by the client. While the UID response data item is redundant when requested, it can simplify the updating of existing (non-UIDONLY) implementations to support UIDONLY.
UIDFETCH Responseには、Fetch Responseに指定されたものと同じ応答データ項目が含まれていることに注意してください。UIDは、UIDFetch応答の開始時に常に返され、クライアントが要求した場合、UID応答データ項目に表示される可能性もあります。UID応答データ項目は要求されたときに冗長ですが、Uidonlyをサポートするために既存の（非uidonly）実装の更新を簡素化できます。
C: 10 UID FETCH 25900:26600 (FLAGS)
[...]
S: * 25996 UIDFETCH (FLAGS (\Seen))
S: * 25997 UIDFETCH (FLAGS (\Flagged \Answered))
S: * 26600 UIDFETCH (FLAGS ())
S: 10 OK FETCH completed
C: 11 UID FETCH 25900:26600 (UID FLAGS)
S: * 25900 UIDFETCH (FLAGS (\Seen) UID 25900)
S: * 25902 UIDFETCH (FLAGS (\Flagged) UID 25902)
S: * 26310 UIDFETCH (FLAGS (\Answered) UID 26310)
S: * 26311 UIDFETCH (FLAGS () UID 26311)
S: * 26498 UIDFETCH (FLAGS (\Answered) UID 26498)
[...]
S: 11 OK FETCH completed
When UIDONLY is enabled, all EXPUNGED responses that would be returned by EXPUNGE / UID EXPUNGE are replaced by VANISHED responses, as defined in [RFC7162]. Note that a server that implements the UIDONLY extension is not required (but allowed) to also implement the CONDSTORE and/or QRESYNC extensions.
uidonlyが有効になると、[RFC7162]で定義されているように、oadge / uid obungeによって返されるすべての抹消された応答が消失した応答に置き換えられます。uidonly拡張機能を実装するサーバーは、condstoreおよび/またはqresync拡張機能を実装するために必要ではない（ただし、許可されている）ことに注意してください。
C: 12 EXPUNGE
S: * VANISHED 405,407,410,425
S: 12 OK expunged
The "<sequence set>" UID SEARCH criterion is prohibited (and results in a tagged BAD response) once UIDONLY is enabled. Clients should use ALL or "UID <sequence set>" UID SEARCH criterion instead.
uidonlyが有効になると、「<sequence set>」uid検索基準は禁止されています（そして、タグ付きの悪い応答になります）。クライアントは、代わりにすべてまたは「uid <sequence set>」を使用する必要があります。
When UIDONLY is enabled, all changes to flags (and other dynamic message attributes) are returned using UIDFETCH responses instead of FETCH responses.
uidonlyが有効になると、フラグのすべての変更（およびその他の動的メッセージ属性）は、フェッチの応答ではなくuidfetch応答を使用して返されます。
Similarly, all expunged messages are announced using VANISHED responses instead of EXPUNGE responses.
同様に、消去された応答の代わりに消失した応答を使用して、すべての消去されたメッセージが発表されます。
This extension doesn't affect EXISTS or RECENT responses.
この拡張機能は存在したり、最近の応答に影響しません。
The UID MOVE / UID COPY commands SHOULD return the COPYUID response code, as specified in [RFC4315].
[RFC4315]で指定されているように、UID MOVE / UIDコピーコマンドはCopyUID応答コードを返す必要があります。
Use of the UIDNOTSTICKY response code (see [RFC4315]) is not compatible with the UIDONLY extension, i.e., a server that advertises the UIDONLY extension MUST NOT return a UIDNOTSTICKY response code.
uidnotsticky応答コード（[rfc4315]を参照）の使用は、uidonly拡張機能、つまりuidonly拡張機能を宣伝するサーバーと互換性がありません。
C: 15 UID move 597 "Archives/2023/2023-05"
S: * OK [COPYUID 1685977201 597 2] UID MOVE
S: * VANISHED 597
S: 15 OK UID MOVE Completed
The CONDSTORE extension is compatible with the UIDONLY extension. The MODSEQ message data item is returned in UIDFETCH responses instead of FETCH responses.
Condstore拡張機能は、Uidonly拡張機能と互換性があります。ModSeqメッセージデータ項目は、フェッチの応答ではなくuidfetch応答で返されます。
The QRESYNC extension is compatible with the UIDONLY extension, but once UIDONLY is enabled, the fourth SELECT QRESYNC parameter (see Section 3.2.5.2 ("Message Sequence Match Data") of [RFC7162]) MUST NOT be used. The server MUST return a tagged BAD response if such a parameter is observed once UIDONLY is enabled.
QRESYNC拡張はUIDONLY拡張子と互換性がありますが、UIDONLYが有効になると、4番目の選択QRESYNCパラメーター（[RFC7162]のセクション3.2.5.2（「メッセージシーケンスマッチデータ」」を参照）を使用してはなりません）を使用してはなりません。Uidonlyが有効になったら、そのようなパラメーターが観察される場合、サーバーはタグ付きの悪い応答を返す必要があります。
IMAP extensions might define other commands that accept message sequence numbers ("sequence-set" ABNF non-terminal; see Section 9 of [RFC9051]). Once UIDONLY is enabled, the server MUST reject such commands with a tagged BAD response. For example, the SORT and THREAD [RFC5256] commands are prohibited, similarly to the SEARCH command. However, UID SORT and UID THREAD can be used instead.
IMAP拡張機能は、メッセージシーケンス番号を受け入れる他のコマンドを定義する場合があります（ "Sequence-Set" abnf nonterminal; [rfc9051]のセクション9を参照）。Uidonlyが有効になると、サーバーはタグ付きの悪い応答でそのようなコマンドを拒否する必要があります。たとえば、seart and thread [rfc5256]コマンドは、検索コマンドと同様に禁止されています。ただし、代わりにUIDソートとUIDスレッドを使用できます。
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 in Section 9 of IMAP4 [RFC9051].
参照されていないが、以下に定義されていない非末端は、IMAP4 [RFC9051]のセクション9で定義されているとおりです。
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>
capability =/ "UIDONLY"
;; <capability>; see RFC 9051
message-data =/ uidfetch-resp
uidfetch-resp = uniqueid SP "UIDFETCH" SP msg-att
;; The uniqueid is the UID of
;; the corresponding message
message-data =/ expunged-resp
expunged-resp = <defines VANISHED response; see RFC 7162>
resp-text-code =/ "UIDREQUIRED"
This IMAP extension is not believed to add any additional Security Considerations beyond the ones that are generally applicable to IMAP4rev1 [RFC3501] and IMAP4rev2 [RFC9051].
このIMAP拡張は、IMAP4REV1 [RFC3501]およびIMAP4REV2 [RFC9051]に一般的に適用できるものを超えて、セキュリティ上の考慮事項を追加するとは考えられていません。
IMAP4 capabilities are registered by publishing a Standards Track or IESG-approved Informational or Experimental RFC.
IMAP4機能は、標準トラックまたはIESGが承認した情報または実験RFCを公開することにより登録されます。
IANA has added the UIDONLY extension to the "IMAP Capabilities" registry with RFC 9586 as the reference. The registry is located at <https://www.iana.org/assignments/imap4-capabilities/>.
IANAは、RFC 9586を参照として「IMAP機能」レジストリにUidonly拡張機能を追加しました。レジストリは<https://www.iana.org/assignments/imap4-capabilities/>にあります。
IANA has also added the UIDREQUIRED response code to the "IMAP Response Codes" registry with RFC 9586 as the reference. The registry is located at <https://www.iana.org/assignments/imap-response-codes/>.
IANAは、RFC 9586を参照として「IMAP応答コード」レジストリにUIDRequed応答コードを追加しました。レジストリは<https://www.iana.org/assignments/imap-response-codes/>にあります。
An earlier draft version of this document proposed use of FETCH responses with the message number parameter always set to 0. This was considered to be too risky as it could cause unexpected side effects and cache corruptions in client code that was not properly updated to handle a lack of message numbers.
このドキュメントの以前のドラフトバージョンは、メッセージ番号パラメーターを常に0に設定したフェッチ応答の使用を提案した。メッセージ番号の欠如。
[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>.
[RFC4315] Crispin, M., "Internet Message Access Protocol (IMAP) -
UIDPLUS extension", RFC 4315, DOI 10.17487/RFC4315,
December 2005, <https://www.rfc-editor.org/info/rfc4315>.
[RFC5256] Crispin, M. and K. Murchison, "Internet Message Access
Protocol - SORT and THREAD Extensions", RFC 5256,
DOI 10.17487/RFC5256, June 2008,
<https://www.rfc-editor.org/info/rfc5256>.
[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>.
[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>.
[IMAP-UIDONLY-ORIG]
Gulbrandsen, A., "The IMAP UIDONLY Extension", Work in
Progress, Internet-Draft, draft-gulbrandsen-imap-uidonly-
00, 25 April 2014, <https://datatracker.ietf.org/doc/html/
draft-gulbrandsen-imap-uidonly-00>.
The editors of this document would like to thank the following people who provided useful comments and/or participated in discussions that lead to this document: Arnt Gulbrandsen, Ken Murchison, Bron Gondwana, Barry Leiba, and Elwyn Davis.
このドキュメントの編集者は、この文書につながる有用なコメントを提供したり、議論に参加したりした以下の人々に感謝したいと思います：Arnt Gulbrandsen、Ken Murchison、Bron Gondwana、Barry Leiba、およびElwyn Davis。
This document is similar to [IMAP-UIDONLY-ORIG], but some different syntactic choices were made in the end.
このドキュメントは[IMAP-Uidonly-Orig]に似ていますが、最終的にはいくつかの異なる構文の選択が行われました。
Alexey Melnikov
Isode Limited
Email: alexey.melnikov@isode.com
URI: https://www.isode.com
Arun Prakash Achuthan
Yahoo Inc.
Email: arunprakash@myyahoo.com
Vikram Nagulakonda
Yahoo Inc.
Email: nvikram_imap@yahoo.com
Ashutosh Singh
Yahoo Inc.
Email: ashutoshvsingh@yahoo.com
Luis Alves
Email: luis.alves@lafaspot.com