rfc9590.original   rfc9590.txt 
EXTRA K. Murchison Internet Engineering Task Force (IETF) K. Murchison
Internet-Draft B. Gondwana Request for Comments: 9590 B. Gondwana
Intended status: Standards Track Fastmail Category: Standards Track Fastmail
Expires: 5 October 2024 3 April 2024 ISSN: 2070-1721 May 2024
IMAP4 Extension for Returning Mailbox METADATA in Extended LIST IMAP Extension for Returning Mailbox METADATA in Extended LIST
draft-ietf-extra-imap-list-metadata-05
Abstract Abstract
This document defines an extension to the to IMAP LIST command that This document defines an extension to the Internet Message Access
allows the client to request mailbox annotations (metadata), along Protocol (IMAP) LIST command that allows the client to request
with other information typically returned by the LIST command. mailbox annotations (metadata), along with other information
typically returned by the LIST command.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 5 October 2024. 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.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Conventions Used in This Document . . . . . . . . . . . . . . 2 2. Conventions Used in This Document
3. METADATA Return Option to LIST Command . . . . . . . . . . . 3 3. METADATA Return Option to LIST Command
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Examples
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Formal Syntax
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 4 7. Privacy Considerations
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 8. IANA Considerations
8.1. Registration of IMAP capability LIST-METADATA . . . . . . 5 8.1. Registration of IMAP Capability LIST-METADATA
8.2. Registration of LIST-EXTENDED option METADATA . . . . . . 5 8.2. Registration of LIST-EXTENDED Option METADATA
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 9. References
9.1. Normative References . . . . . . . . . . . . . . . . . . 5 9.1. Normative References
9.2. Informative References . . . . . . . . . . . . . . . . . 6 9.2. Informative References
Appendix A. Change History (To be removed by RFC Editor before Authors' Addresses
publication) . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
IMAP clients sometimes fetch mailbox metadata (e.g. color) to augment IMAP clients sometimes fetch mailbox metadata (e.g., color) to
the display of mailboxes to the logged-in user. In order to do that, augment the display of mailboxes for the logged-in user. In order to
the client is forced to issue a LIST or LSUB command to list all do that, the client is forced to issue a LIST or LSUB command to list
available mailboxes, followed by a GETMETADATA command for each all available mailboxes, followed by a GETMETADATA command for each
mailbox found. This document defines an extension to the to IMAP mailbox found. This document defines an extension to the IMAP LIST
LIST command that is identified by the capability string "LIST- command that is identified by the capability string "LIST-METADATA".
METADATA". The LIST-METADATA extension allows the client to request The LIST-METADATA extension allows the client to request annotations
annotations on available mailboxes, along with other information on available mailboxes, along with other information typically
typically returned by the LIST command. returned by the LIST command.
2. Conventions Used in This Document 2. Conventions Used in This Document
In examples, "C:" indicates lines sent by a client that is connected 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. to a server. "S:" indicates lines sent by the server to the client.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Long lines in examples are wrapped using "The Single Backslash
Strategy" described in [RFC8792].
3. METADATA Return Option to LIST Command 3. METADATA Return Option to LIST Command
[RFC5464] defines the GETMETADATA command which is used by an IMAP [RFC5464] defines the GETMETADATA command that is used by an IMAP
client to retrieve mailbox annotations. Sometimes, a client will client to retrieve mailbox annotations. Sometimes, a client will
have to look up the metadata for some or all of the mailboxes have to look up the metadata for some or all of the mailboxes
returned by the LIST command. Doing so in multiple GETMETADATA returned by the LIST command. Doing so in multiple GETMETADATA
commands wastes bandwidth and can degrade performance if the client commands wastes bandwidth and can degrade performance if the client
does not pipeline the requests. does not pipeline the requests.
This document extends the LIST command with a new return option, This document extends the LIST command with a new return option,
"METADATA", which allows the client to request all of the desired "METADATA", which allows the client to request all of the desired
information in a single command. For each listable mailbox matching information in a single command. For each listable mailbox matching
the list pattern and selection options, the server MUST return an the list pattern and selection options, the server MUST return an
untagged LIST response followed by one or more untagged METADATA untagged LIST response, followed by one or more untagged METADATA
responses containing the mailbox annotations requested by the client. responses containing the mailbox annotations requested by the client.
The untagged METADATA responses to an extended LIST command have the The untagged METADATA responses to an extended LIST command have the
same syntax and semantics as those that would be returned by same syntax and semantics as those that would be returned by
GETMETADATA commands on the same set of listable mailboxes (see GETMETADATA commands on the same set of listable mailboxes (see
Section 4.4.1 of [RFC5464]). As per Section 4.4 of [RFC5464], the Section 4.4.1 of [RFC5464]). As per Section 4.4 of [RFC5464], the
server may return all requested annotations in a single METADATA server may return all requested annotations in a single METADATA
response for each mailbox, or it may split the requested annotations response for each mailbox, or it may split the requested annotations
into multiple METADATA responses for each mailbox. into multiple METADATA responses for each mailbox.
If the server is unable to look up the annotations for given mailbox, If the server is unable to look up the annotations for given mailbox,
it MAY drop the corresponding METADATA response. In such a it MAY drop the corresponding METADATA response. In such a
situation, the LIST command would still return a tagged OK reply. situation, the LIST command would still return a tagged OK reply.
4. Examples 4. Examples
The following are examples of fetching metadata of only the top level The following are examples of fetching metadata from only the top-
of the mailbox hierarchies with different sets of selection criteria level hierarchies of the mailbox using different sets of selection
(see Section 6.3.9 of [RFC9051]). criteria (see Section 6.3.9 of [RFC9051]).
In this example: In this example:
* The "color" annotation for the "foo" mailbox has not been set, so * The "color" annotation for the "foo" mailbox has not been set, so
the METADATA response has a value of "NIL" (has no value). the METADATA response has a value of "NIL" (i.e., has no value).
* "bar" has children, but isn't an actual mailbox itself, so it has * "bar" has children, but isn't an actual mailbox itself, so it has
no METADATA response. no METADATA response.
NOTE: '\' line wrapping per [RFC8792] ========== NOTE: '\' line wrapping per RFC 8792 ===========
C: A00 CAPABILITY C: A00 CAPABILITY
S: * CAPABILITY IMAP4rev1 IMAP4rev2 \ S: * CAPABILITY IMAP4rev1 IMAP4rev2 \
LIST-EXTENDED LIST-METADATA METADATA LIST-EXTENDED LIST-METADATA METADATA
S: A00 OK Completed. S: A00 OK Completed.
C: A01 LIST "" % \ C: A01 LIST "" % \
RETURN (METADATA ("/shared/vendor/cmu/cyrus-imapd/color")) RETURN (METADATA ("/shared/vendor/cmu/cyrus-imapd/color"))
S: * LIST () "." "INBOX" S: * LIST () "." "INBOX"
S: * METADATA INBOX ("/shared/vendor/cmu/cyrus-imapd/color" "#b71c1c") S: * METADATA INBOX ("/shared/vendor/cmu/cyrus-imapd/color" "#b71c1c")
S: * LIST () "." "foo" S: * LIST () "." "foo"
S: * METADATA "foo" ("/shared/vendor/cmu/cyrus-imapd/color" NIL) S: * METADATA "foo" ("/shared/vendor/cmu/cyrus-imapd/color" NIL)
S: * LIST (\NonExistent) "." "bar" S: * LIST (\NonExistent) "." "bar"
S: A01 OK List completed. S: A01 OK List completed.
In this example the LIST response for the "foo" mailbox is returned In this example, the LIST response for the "foo" mailbox is returned
because it has matching children, but no METADATA response is because it has matching children, but no METADATA response is
returned because "foo" itself doesn't match the selection criteria. returned because "foo" itself doesn't match the selection criteria.
NOTE: '\' line wrapping per [RFC8792] ========== NOTE: '\' line wrapping per RFC 8792 ===========
C: A02 LIST (SUBSCRIBED RECURSIVEMATCH) "" % \ C: A02 LIST (SUBSCRIBED RECURSIVEMATCH) "" % \
RETURN (METADATA ("/shared/vendor/cmu/cyrus-imapd/color")) RETURN (METADATA ("/shared/vendor/cmu/cyrus-imapd/color"))
S: * LIST (\Subscribed) "." "INBOX" S: * LIST (\Subscribed) "." "INBOX"
S: * METADATA INBOX ("/shared/vendor/cmu/cyrus-imapd/color" "#b71c1c") S: * METADATA INBOX ("/shared/vendor/cmu/cyrus-imapd/color" "#b71c1c")
S: * LIST () "." "foo" (CHILDINFO ("SUBSCRIBED")) S: * LIST () "." "foo" (CHILDINFO ("SUBSCRIBED"))
S: A02 OK List completed. S: A02 OK List completed.
5. Formal Syntax 5. Formal Syntax
The following syntax specification uses the augmented Backus-Naur The following syntax specification uses the Augmented Backus-Naur
Form (BNF) as described in [RFC5234]. Note that "return-option" is Form (ABNF) as described in [RFC5234]. Note that "return-option" is
defined in [RFC5258] and "entry" is defined in [RFC5464]. defined in [RFC5258] and "entry" is defined in [RFC5464].
return-option =/ "METADATA" SP "(" entry *(SP entry) ")" return-option =/ "METADATA" SP "(" entry *(SP entry) ")"
6. Security Considerations 6. Security Considerations
This specification does not introduce any additional security This specification does not introduce any additional security
concerns beyond those described in [RFC5258] and [RFC5464]. concerns beyond those described in [RFC5258] and [RFC5464].
7. Privacy Considerations 7. Privacy Considerations
This specification does not introduce any additional privacy concerns This specification does not introduce any additional privacy concerns
beyond those described in [RFC5464]. beyond those described in [RFC5464].
8. IANA Considerations 8. IANA Considerations
8.1. Registration of IMAP capability LIST-METADATA
This document defines the "LIST-METADATA" IMAP capability to be added 8.1. Registration of IMAP Capability LIST-METADATA
to registry located at https://www.iana.org/assignments/imap-
capabilities/imap-capabilities.xhtml.
8.2. Registration of LIST-EXTENDED option METADATA 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/>.
This section registers the "METADATA" LIST-EXTENDED option to be 8.2. Registration of LIST-EXTENDED Option METADATA
added to the registry located at https://www.iana.org/assignments/
imap-list-extended/imap-list-extended.xhtml#imap-list-extended-1. 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/>.
LIST-EXTENDED option name: LIST-EXTENDED option name:
METADATA METADATA
LIST-EXTENDED option type: LIST-EXTENDED option type:
RETURN RETURN
LIST-EXTENDED option description: LIST-EXTENDED option description:
Causes the LIST command to return METADATA responses in addition Causes the LIST command to return METADATA responses in addition
to LIST responses. to LIST responses.
Published specification: Published specification:
RFC XXXX, Section 3 RFC 9590, Section 3
Security considerations: Security considerations:
RFC XXXX, Section 6 RFC 9590, Section 6
Intended usage: Intended usage:
COMMON COMMON
Person and email address to contact for further information: Person and email address to contact for further information:
Kenneth Murchison <murch@fastmailteam.com>, Bron Gondwana Kenneth Murchison <murch@fastmailteam.com> and Bron Gondwana
<brong@fastmailteam.com> <brong@fastmailteam.com>
Owner/Change controller: Owner/Change controller:
IESG <iesg@ietf.org> IESG <iesg@ietf.org>
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 6, line 35 skipping to change at line 254
DOI 10.17487/RFC9051, August 2021, DOI 10.17487/RFC9051, August 2021,
<https://www.rfc-editor.org/info/rfc9051>. <https://www.rfc-editor.org/info/rfc9051>.
9.2. Informative References 9.2. Informative References
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Content of Internet-Drafts and "Handling Long Lines in Content of Internet-Drafts and
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
<https://www.rfc-editor.org/info/rfc8792>. <https://www.rfc-editor.org/info/rfc8792>.
Appendix A. Change History (To be removed by RFC Editor before
publication)
Changes from draft-ietf-extra-imap-list-metadata-04:
* Added CAPABILITY command/response to example.
* Reference IANA registries by their URLs.
Changes from draft-ietf-extra-imap-list-metadata-03:
* Clarified why "bar" is returned in the first example.
Changes from draft-ietf-extra-imap-list-metadata-02:
* Used RFC 8792 '\' folding of the examples.
Changes from draft-ietf-extra-imap-list-metadata-01:
* Updated Security Considerations to also reference RFC 5464.
Changes from draft-ietf-extra-imap-list-metadata-00:
* Added missing SP in ABNF.
Changes from draft-murchison-imap-list-metadata-02:
* Renamed as a WG document.
* Clarified that the METADATA response with values is used.
* Miscellaneous editorial changes.
Changes from draft-murchison-imap-list-metadata-01:
* None.
Changes from draft-murchison-imap-list-metadata-00:
* Updated Keywords boilerplate.
* Changed RFC 3501 reference to RFC 9051.
Authors' Addresses Authors' Addresses
Kenneth Murchison Kenneth Murchison
Fastmail US LLC Fastmail US LLC
1429 Walnut Street - Suite 1201 1429 Walnut Street
Suite 1201
Philadelphia, PA 19102 Philadelphia, PA 19102
United States of America United States of America
Email: murch@fastmailteam.com Email: murch@fastmailteam.com
Bron Gondwana Bron Gondwana
Fastmail Pty Ltd Fastmail Pty Ltd
Level 2, 114 William Street Level 2, 114 William Street
Melbourne VIC 3000 Melbourne VIC 3000
Australia Australia
Email: brong@fastmailteam.com Email: brong@fastmailteam.com
 End of changes. 27 change blocks. 
119 lines changed or deleted 77 lines changed or added

This html diff was produced by rfcdiff 1.48.