Showing content from https://www.rfc-editor.org/rfc/rfc9590.xml below:
Introduction 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. Conventions Used in This Document 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. 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 when, and only when, they appear in all capitals, as shown here. Long lines in examples are wrapped using "The Single Backslash Strategy" described in . METADATA Return Option to LIST Command 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. 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 ). As per , 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. 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. Examples The following are examples of fetching metadata from only the top-level hierarchies of the mailbox using different sets of selection criteria (see ). 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).
- "bar" has children, but isn't an actual mailbox itself, so it has no METADATA response.
========== 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. ========== 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. Formal Syntax The following syntax specification uses the Augmented Backus-Naur Form (ABNF) as described in . Note that "return-option" is defined in and "entry" is defined in . return-option =/ "METADATA" SP "(" entry *(SP entry) ")" Security Considerations This specification does not introduce any additional security concerns beyond those described in and . Privacy Considerations This specification does not introduce any additional privacy concerns beyond those described in . IANA Considerations Registration of IMAP Capability LIST-METADATA Per this document, IANA has added the "LIST-METADATA" IMAP capability to the "IMAP Capabilities" registry located at . Registration of LIST-EXTENDED Option METADATA Per this document, IANA has registered the "METADATA" LIST-EXTENDED option in the "LIST-EXTENDED options" registry located at .
-
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,
-
Security considerations:
-
RFC 9590,
-
Intended usage:
-
COMMON
-
Person and email address to contact for further information:
-
<murch@fastmailteam.com> and <brong@fastmailteam.com>
-
Owner/Change controller:
-
IESG <iesg@ietf.org>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4