Internet Engineering Task Force (IETF) K. Murchison
Request for Comments: 9590 B. Gondwana
Category: Standards Track Fastmail
ISSN: 2070-1721 May 2024
This document defines an extension to the Internet Message Access Protocol (IMAP) LIST command that allows the client to request mailbox annotations (metadata), along with other information typically returned by the LIST command.
このドキュメントでは、クライアントがメールボックスアノテーション（メタデータ）を要求できるようにするインターネットメッセージアクセスプロトコル（IMAP）リストコマンドへの拡張機能と、通常はリストコマンドによって返される他の情報を定義します。
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/rfc9590.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9590で取得できます。
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ライセンステキストを含める必要があります。
1. Introduction
2. Conventions Used in This Document
3. METADATA Return Option to LIST Command
4. Examples
5. Formal Syntax
6. Security Considerations
7. Privacy Considerations
8. IANA Considerations
8.1. Registration of IMAP Capability LIST-METADATA
8.2. Registration of LIST-EXTENDED Option METADATA
9. References
9.1. Normative References
9.2. Informative References
Authors' Addresses
IMAP clients sometimes fetch mailbox metadata (e.g., color) to augment the display of mailboxes for the logged-in user. In order to do that, the client is forced to issue a LIST or LSUB command to list all available mailboxes, followed by a GETMETADATA command for each mailbox found. This document defines an extension to the IMAP LIST command that is identified by the capability string "LIST-METADATA". The LIST-METADATA extension allows the client to request annotations on available mailboxes, along with other information typically returned by the LIST command.
IMAPクライアントは、Mailboxメタデータ（色）を取得することがあり、ログインしたユーザーのメールボックスの表示を拡張します。それを行うために、クライアントは、利用可能なすべてのメールボックスをリストするためにリストまたはLSUBコマンドを発行せざるを得ません。このドキュメントは、機能文字列「List-Metadata」によって識別されるIMAPリストコマンドへの拡張機能を定義します。List-Metadata拡張機能により、クライアントは利用可能なメールボックスで注釈を要求し、通常はリストコマンドによって返される他の情報を要求できます。
In examples, "C:" indicates lines sent by a client that is connected to a server. "S:" indicates lines sent by the server to the client.
たとえば、「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]で説明されているように解釈されます。
Long lines in examples are wrapped using "The Single Backslash Strategy" described in [RFC8792].
例の長い行は、[RFC8792]で説明されている「単一のバックスラッシュ戦略」を使用して包まれています。
[RFC5464] defines the GETMETADATA command that is used by an IMAP client to retrieve mailbox annotations. Sometimes, a client will have to look up the metadata for some or all of the mailboxes returned by the LIST command. Doing so in multiple GETMETADATA commands wastes bandwidth and can degrade performance if the client does not pipeline the requests.
[RFC5464]は、IMAPクライアントがメールボックスアノテーションを取得するために使用するGetMetadataコマンドを定義します。場合によっては、クライアントがリストコマンドによって返されたメールボックスの一部またはすべてのメタデータを検索する必要がある場合があります。複数のGetMetadataコマンドでそうすることで、帯域幅を廃棄し、クライアントがリクエストをパイプラインしないとパフォーマンスを低下させることができます。
This document extends the LIST command with a new return option, "METADATA", which allows the client to request all of the desired information in a single command. For each listable mailbox matching the list pattern and selection options, the server MUST return an untagged LIST response, followed by one or more untagged METADATA responses containing the mailbox annotations requested by the client. The untagged METADATA responses to an extended LIST command have the same syntax and semantics as those that would be returned by GETMETADATA commands on the same set of listable mailboxes (see Section 4.4.1 of [RFC5464]). As per Section 4.4 of [RFC5464], the server may return all requested annotations in a single METADATA response for each mailbox, or it may split the requested annotations into multiple METADATA responses for each mailbox.
このドキュメントは、新しいリターンオプション「Metadata」を使用してListコマンドを拡張します。これにより、クライアントはすべての目的の情報を単一のコマンドで要求できます。リストのパターンと選択オプションに一致するリスト可能なメールボックスごとに、サーバーは、クライアントがリクエストしたメールボックスアノテーションを含む1つ以上の未積層メタデータ応答を続けていないものを返す必要があります。拡張リストコマンドへの未積層のメタデータ応答は、同じリスト可能なメールボックスのセットでGetMetadataコマンドによって返されるものと同じ構文とセマンティクスを持っています（[RFC5464]のセクション4.4.1を参照）。[RFC5464]のセクション4.4によると、サーバーは、各メールボックスの単一のメタデータ応答で要求されたすべての注釈を返すか、要求された注釈を各メールボックスの複数のメタデータ応答に分割する場合があります。
If the server is unable to look up the annotations for given mailbox, it MAY drop the corresponding METADATA response. In such a situation, the LIST command would still return a tagged OK reply.
サーバーが特定のメールボックスの注釈を検索できない場合、対応するメタデータ応答をドロップする場合があります。このような状況では、リストコマンドは引き続きタグ付きOK返信を返します。
The following are examples of fetching metadata from only the top-level hierarchies of the mailbox using different sets of selection criteria (see Section 6.3.9 of [RFC9051]).
以下は、さまざまな選択基準を使用して、メールボックスのトップレベルの階層のみからメタデータを取得する例です（[RFC9051]のセクション6.3.9を参照）。
In this example:
この例では：
* The "color" annotation for the "foo" mailbox has not been set, so the METADATA response has a value of "NIL" (i.e., has no value).
* 「Foo」メールボックスの「色」注釈は設定されていないため、メタデータ応答には「nil」の値があります（つまり、値はありません）。
* "bar" has children, but isn't an actual mailbox itself, so it has no METADATA response.
* 「bar」には子供がいますが、実際のメールボックス自体ではないため、メタデータ応答はありません。
========== NOTE: '\' line wrapping per RFC 8792 ===========
C: A00 CAPABILITY
S: * CAPABILITY IMAP4rev1 IMAP4rev2 \
LIST-EXTENDED LIST-METADATA METADATA
S: A00 OK Completed.
C: A01 LIST "" % \
RETURN (METADATA ("/shared/vendor/cmu/cyrus-imapd/color"))
S: * LIST () "." "INBOX"
S: * METADATA INBOX ("/shared/vendor/cmu/cyrus-imapd/color" "#b71c1c")
S: * LIST () "." "foo"
S: * METADATA "foo" ("/shared/vendor/cmu/cyrus-imapd/color" NIL)
S: * LIST (\NonExistent) "." "bar"
S: A01 OK List completed.
In this example, the LIST response for the "foo" mailbox is returned because it has matching children, but no METADATA response is returned because "foo" itself doesn't match the selection criteria.
この例では、「foo」メールボックスのリスト応答は、一致する子供がいるため返されますが、「foo」自体が選択基準と一致しないため、メタデータ応答は返されません。
========== NOTE: '\' line wrapping per RFC 8792 ===========
C: A02 LIST (SUBSCRIBED RECURSIVEMATCH) "" % \
RETURN (METADATA ("/shared/vendor/cmu/cyrus-imapd/color"))
S: * LIST (\Subscribed) "." "INBOX"
S: * METADATA INBOX ("/shared/vendor/cmu/cyrus-imapd/color" "#b71c1c")
S: * LIST () "." "foo" (CHILDINFO ("SUBSCRIBED"))
S: A02 OK List completed.
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) as described in [RFC5234]. Note that "return-option" is defined in [RFC5258] and "entry" is defined in [RFC5464].
次の構文仕様では、[RFC5234]で説明されているように、拡張されたバックスノーフォーム（ABNF）を使用しています。「return-option」は[RFC5258]で定義されており、「エントリ」は[RFC5464]で定義されていることに注意してください。
return-option =/ "METADATA" SP "(" entry *(SP entry) ")"
This specification does not introduce any additional security concerns beyond those described in [RFC5258] and [RFC5464].
この仕様では、[RFC5258]および[RFC5464]に記載されているものを超えて、追加のセキュリティ上の懸念は導入されません。
This specification does not introduce any additional privacy concerns beyond those described in [RFC5464].
この仕様では、[RFC5464]に記載されているものを超えて、追加のプライバシーの懸念は導入されません。
Per this document, IANA has added the "LIST-METADATA" IMAP capability to the "IMAP Capabilities" registry located at <https://www.iana.org/assignments/imap4-capabilities/>.
このドキュメントに従って、IANAは、<https://www.iana.org/assignments/imap4-capabilities/>にある「IMAP機能」レジストリに「List-Metadata」IMAP機能を追加しました。
Per this document, IANA has registered the "METADATA" LIST-EXTENDED option in the "LIST-EXTENDED options" registry located at <https://www.iana.org/assignments/imap-list-extended/>.
このドキュメントに従って、IANAは、<https://www.iana.org/assignments/imap-list-extended/>にある「リスト拡張オプション」レジストリに「メタデータ」拡張オプションを登録しています。
LIST-EXTENDED option name:
リスト拡張オプション名：
METADATA
メタデータ
LIST-EXTENDED option type:
リスト拡張オプションタイプ：
RETURN
戻る
LIST-EXTENDED option description:
リスト拡張オプション説明：
Causes the LIST command to return METADATA responses in addition to LIST responses.
リストコマンドは、リスト応答に加えてメタデータ応答を返します。
Published specification:
公開された仕様：
RFC 9590, Section 3
RFC 9590、セクション3
Security considerations:
セキュリティ上の考慮事項：
RFC 9590, Section 6
RFC 9590、セクション6
Intended usage:
意図された使用法：
COMMON
一般
Person and email address to contact for further information:
詳細については、人とメールアドレスをお問い合わせください。
Kenneth Murchison <murch@fastmailteam.com> and Bron Gondwana <brong@fastmailteam.com>
Kenneth Murchison <murch@fastmailteam.com>およびbron gondwana <brong@fastmailteam.com>
Owner/Change controller:
所有者/変更コントローラー：
IESG <iesg@ietf.org>
iesg <iesg@ietf.org>
[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>.
[RFC5234] 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>.
[RFC5258] Leiba, B. and A. Melnikov, "Internet Message Access
Protocol version 4 - LIST Command Extensions", RFC 5258,
DOI 10.17487/RFC5258, June 2008,
<https://www.rfc-editor.org/info/rfc5258>.
[RFC5464] Daboo, C., "The IMAP METADATA Extension", RFC 5464,
DOI 10.17487/RFC5464, February 2009,
<https://www.rfc-editor.org/info/rfc5464>.
[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>.
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Content of Internet-Drafts and
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
<https://www.rfc-editor.org/info/rfc8792>.
Kenneth Murchison
Fastmail US LLC
1429 Walnut Street
Suite 1201
Philadelphia, PA 19102
United States of America
Email: murch@fastmailteam.com
Bron Gondwana
Fastmail Pty Ltd
Level 2, 114 William Street
Melbourne VIC 3000
Australia
Email: brong@fastmailteam.com