IMAP4 Extension: Message Preview GenerationOpen-Xchange Inc.530 Lytton AvenuePalo AltoCalifornia94301USmichael.slusarz@open-xchange.com
ART
EXTRAIMAP4FETCHPREVIEWThis document specifies an Internet Message Access Protocol (IMAP)
protocol extension that allows a client to request a server-generated
abbreviated text representation of message data that is useful as a contextual
preview of the entire message.Status of This Memo
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.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() 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 Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
. Introduction
. Conventions Used in This Document
. FETCH Data Item
. Command
. Response
. Preview Text Format
. LAZY Priority Modifier
. LAZY
. Client Implementation Advice
. Examples
. Formal Syntax
. IANA Considerations
. Security Considerations
. References
. Normative References
. Informative References
Acknowledgments
Author's Address
IntroductionMany modern mail clients display small extracts of the body text as
an aid to allow a user to quickly decide whether they are interested
in viewing the full message contents. Mail clients implementing the
Internet Message Access Protocol
would benefit from a standardized, consistent way to
generate these brief textual previews of messages.
Generation of a preview on the server has several benefits. First,
it allows consistent representation of previews across all clients.
While different clients might generate quite different preview text,
having common preview text generated by the server can give a more
consistent user experience to those who use multiple clients.
Second, server-side preview generation is more efficient. A
client-based algorithm needs to issue, at a minimum, a FETCH
BODYSTRUCTURE command in order to determine which MIME body part(s) should be represented in
the preview. Subsequently, at least one FETCH BODY command may be
needed to retrieve body data used in preview generation. These FETCH
commands cannot be pipelined since the BODYSTRUCTURE query must be
parsed on the client before the list of parts to be retrieved via the
BODY command(s) can be determined.Additionally, it may be difficult to predict the amount of body
data that must be retrieved to adequately represent the part via a
preview, therefore requiring inefficient fetching of excessive data
in order to account for this uncertainty. For example, a preview
algorithm to display data contained in a text/html part will likely
strip the markup tags to obtain textual content. However, without
fetching the entire content of the part, there is no way to guarantee
that sufficient non-tag content will exist unless either 1) the entire
part is retrieved or 2) an additional partial FETCH is executed when
the client determines that it does not possess sufficient data from a
previous partial FETCH to display an adequate representation of the
preview.Finally, server generation allows caching in a centralized
location. Using server-generated previews allows global generation
once per message, and that preview can be cached for the retention
period of the source message. Retrieval of message data may be
expensive within a server, for example, so a server can be configured
to reduce its storage retrieval load by pre-generating preview
data.A server indicates support for this extension via the "PREVIEW"
capability name.Conventions Used in This Document
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.
"User" is used to refer to a human user, whereas "client" refers to
the software being run by the user.In examples, "C:" and "S:" indicate lines sent by the client and
server, respectively. If a single "C:" or "S:" label applies to
multiple lines, then the line breaks between those lines are for
editorial clarity only and are not part of the actual protocol
exchange.As with all IMAP extension documents, the case used in writing
IMAP protocol elements herein is chosen for editorial clarity, and
implementations must pay attention to the numbered rules at the
beginning of .FETCH Data ItemCommandTo retrieve a preview for a message, the PREVIEW FETCH attribute
is used when issuing a FETCH command.ResponseThe server returns a variable-length string that is the generated
preview for that message. This string is intended to be viewed by the
user as a contextual preview of the entire message and is not
intended to be interpreted in any way by the client software.Example: Retrieving preview information in a SELECTed
mailbox.
C: A1 FETCH 1 (PREVIEW)
S: * 1 FETCH (PREVIEW "Preview text!")
S: A1 OK FETCH complete.
A server SHOULD strive to generate the same string for a given
message for each request. However, since previews are understood to be
an approximation of the message data and not a canonical view of its
contents, a client MUST NOT assume that a message preview is
immutable for a given message. This relaxed requirement permits a
server to offer previews as an option without requiring potentially
burdensome storage and/or processing requirements to guarantee
immutability for a use case that does not require this strictness.
For example, the underlying IMAP server may change due to a system
software upgrade; an account's state information may be retained in
the migration, but the new server may generate different preview
text than the old server.It is possible that the server has determined that no meaningful
preview text can be generated for a particular message. Examples of
this involve encrypted messages, content types the server does not
support previews of, and other situations where the server is not
able to extract information for a preview. In such cases, the
server MUST return a zero-length string. Clients SHOULD NOT send
another FETCH for a preview for such messages. (As discussed
previously, preview data is not immutable, so there is chance that
at some point in the future the server would be able to generate
meaningful text. However, this scenario is expected to be rare, so a
client should not continually send out requests to try to detect
this infrequent occurrence.)If the LAZY modifier is
used, the server MAY return NIL for the preview response, indicating
that preview generation could not be completed without causing
undue delay. A server MUST NOT return NIL to a FETCH PREVIEW request
made without the LAZY modifier.Preview Text FormatThe generated preview text MUST be treated as
text/plain media type data by the
client.The generated string MUST NOT be content transfer encoded and MUST
be encoded in UTF-8. The server SHOULD
remove any formatting markup and do whatever processing might be
useful in rendering the preview as plain text.For purposes of this section, a "preview character" is defined as a
single Universal Character Set (UCS) character encoded in UTF-8. Note: a single preview
character may comprise multiple octets, so any buffers implemented
to conform to the string limitations identified in this document
should be sized to prevent possible overflow errors.The server SHOULD limit the length of the preview text to 200
preview characters. This length should provide sufficient data to
generally support both various languages (and their different average
word lengths) and diverse client display size requirements.The server MUST NOT output preview text longer than 256 preview
characters.If the preview is not generated based on the body content of the
message, and the LANGUAGE extension is
supported by the server, the preview text SHOULD be generated
according to the language rules that apply to human-readable text.
For example, a message that consists of a single image MIME part has
no human-readable text from which to generate preview information.
Instead, the server may wish to output a description that the message
contains an image and describe some attributes of the image, such as
image format, size, and filename. This descriptive text is not a
product of the message body itself but is rather auto-generated data
by the server; it should thus use the rules defined for
human-readable text described in the LANGUAGE extension (if
supported on the server).LAZY Priority ModifierLAZYThe LAZY modifier directs the server to return the preview
representation only if that data can be returned without undue
delay to the client.If this modifier is used, and the server is unable to return
preview data without undue delay, the server MUST return NIL as the
preview response.The LAZY modifier MUST be implemented by any server that supports
the PREVIEW extension.Client Implementation AdviceUpon opening a mailbox, a client generally performs a FETCH of
message details in order to create a listing to present to the user
(e.g., ENVELOPE data). Using this extension, a client may want to
additionally display preview information as part of this listing.
Quickly providing the base mailbox listing with basic message
details is the primary goal of this command as this is required
to allow the user to begin interacting with the mailbox. Preview data
is likely to be of secondary importance; it provides useful context,
but it is not necessary to perform message actions. A client can
load unavailable previews in the background and display them
asynchronously to the user as the preview data is provided by the
server.In this scenario, the client would add the PREVIEW data item, with
the LAZY modifier, to the list of FETCH items needed to generate the
mailbox listing. This allows the server to advantageously return
preview data without blocking the primary goal of quickly returning
the basic message details used to generate the mailbox listing.Once this initial FETCH is complete, the client can then issue
FETCH requests, without the LAZY modifier, to load the PREVIEW data
item for the messages in which preview data was not returned. It is
RECOMMENDED that these FETCH requests be issued in small batches,
e.g., 50 messages per FETCH command, since preview generation may be
expensive and a single large request may exceed server resource
limits.See Example 2 in for an implementation of this strategy.A client SHOULD NOT continually issue FETCH PREVIEW
requests with the LAZY modifier in a selected mailbox as the server is
under no requirement to return preview information for this command,
which could lead to an unnecessary waste of system and network
resources.ExamplesExample 1: Requesting preview without LAZY
modifier.
C: A1 CAPABILITY
S: * CAPABILITY IMAP4rev1 PREVIEW
S: A1 OK Capability command completed.
[...a mailbox is SELECTed...]
C: A2 FETCH 1 (RFC822.SIZE PREVIEW)
S: * 1 FETCH (RFC822.SIZE 5647 PREVIEW {200}
S: Lorem ipsum dolor sit amet, consectetur adipiscing elit.
S: Curabitur aliquam turpis et ante dictum, et pulvinar dui congue.
S: Maecenas hendrerit, lorem non imperdiet pellentesque, nulla
S: ligula nullam
S: )
S: A2 OK FETCH complete.
Example 2: Requesting preview with LAZY modifier, to
obtain previews during initial mailbox listing if readily
available; otherwise, load previews in background.
C: B1 FETCH 1:4 (ENVELOPE PREVIEW (LAZY))
S: * 1 FETCH (ENVELOPE ("Wed, 23 Sep 2020 15:03:11 +0000" [...])
PREVIEW "Preview text for message 1.")
S: * 2 FETCH (PREVIEW "" ENVELOPE
("Thu, 24 Sep 2020 12:17:23 +0000" [...]))
S: * 3 FETCH (ENVELOPE ("Fri, 25 Sep 2020 09:13:45 +0000" [...])
PREVIEW NIL)
S: * 4 FETCH (ENVELOPE ("Sat, 26 Sep 2020 07:11:18 +0000" [...])
PREVIEW NIL)
S: B1 OK FETCH completed.
[...Client has preview for message 1 and knows that message 2 has
a preview that is empty; only need to request preview of
messages 3 & 4 (e.g., in background)...]
C: B2 FETCH 3:4 (PREVIEW)
S: * 3 FETCH (PREVIEW {30}
S: Message data from message 3.
S: )
S: * 4 FETCH (PREVIEW "Message 4 preview")
S: B2 OK Fetch completed.
Example 3: Requesting preview for
search results within a single mailbox. Use the SEARCHRES extension to save a round-trip.
C: C1 CAPABILITY
S: * CAPABILITY IMAP4rev1 PREVIEW SEARCHRES
S: C1 OK Capability command completed.
[...a mailbox is SELECTed...]
C: C2 SEARCH RETURN (SAVE) FROM "FOO"
C: C3 FETCH $ (UID PREVIEW (LAZY))
S: C2 OK SEARCH completed.
S: * 5 FETCH (UID 13 PREVIEW "Preview!")
S: * 9 FETCH (UID 23 PREVIEW NIL)
S: C3 OK FETCH completed.
[...Retrieve message 9 preview in background...]
C: C4 UID FETCH 23 (PREVIEW)
S: * 9 FETCH (UID 23 PREVIEW "Another preview!")
S: C4 OK FETCH completed.
Formal SyntaxThe following syntax specification uses the Augmented Backus-Naur
Form (ABNF) as described in . It
includes definitions from IMAP.
capability =/ "PREVIEW"
fetch-att =/ "PREVIEW" [SP "(" preview-mod *(SP
preview-mod) ")"]
msg-att-dynamic =/ "PREVIEW" SP nstring
preview-mod = "LAZY"
IANA ConsiderationsIMAP capabilities are
registered by publishing a Standards Track or IESG-approved Experimental
RFC in the "IMAP Capabilities" registry located at .
IANA has added the "PREVIEW" capability to this registry.Security ConsiderationsImplementation of this extension might enable denial-of-service
attacks against server resources, due to excessive memory or CPU usage
during preview generation or increased storage usage if preview results
are stored on the server after generation. In order to mitigate such
attacks, servers SHOULD log the client authentication identity on FETCH
PREVIEW operations in order to facilitate tracking of abusive
clients.Servers MAY limit the resources that preview generation uses. Such
resource limitations might, in an extreme example, cause a server to
return a preview that is the empty string for a message that otherwise
would have had a non-empty preview. However, it is recommended that at
least some preview text be provided in this situation, even if the
quality of the preview is degraded.Just as the messages they summarize, preview data may contain
sensitive information. If generated preview data is stored on the
server, e.g., for caching purposes, these previews MUST be protected with
equivalent authorization and confidentiality controls as the source
message.ReferencesNormative ReferencesMultipurpose Internet Mail Extensions (MIME) Part Two: Media TypesThis second document defines the general structure of the MIME media typing system and defines an initial set of media types. [STANDARDS-TRACK]Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev1 also provides the capability for an offline client to resynchronize with the server. IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev1 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev1 supports a single server. A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in RFC 2244. IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as RFC 2821. [STANDARDS-TRACK]UTF-8, a transformation format of ISO 10646ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279.Augmented BNF for Syntax Specifications: ABNFInternet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]Internet Message Access Protocol InternationalizationInternet Message Access Protocol (IMAP) version 4rev1 has basic support for non-ASCII characters in mailbox names and search substrings. It also supports non-ASCII message headers and content encoded as specified by Multipurpose Internet Mail Extensions (MIME). This specification defines a collection of IMAP extensions that improve international support including language negotiation for international error text, translations for namespace prefixes, and comparator negotiation for search, sort, and thread. [STANDARDS-TRACK]Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Informative ReferencesMultipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message BodiesThis initial document specifies the various headers used to describe the structure of MIME messages. [STANDARDS-TRACK]The 'text/html' Media TypeThis document summarizes the history of HTML development, and defines the "text/html" MIME type by pointing to the relevant W3C recommendations. This memo provides information for the Internet community.IMAP Extension for Referencing the Last SEARCH ResultMany IMAP clients use the result of a SEARCH command as the input to perform another operation, for example, fetching the found messages, deleting them, or copying them to another mailbox.This can be achieved using standard IMAP operations described in RFC 3501; however, this would be suboptimal. The server will send the list of found messages to the client; after that, the client will have to parse the list, reformat it, and send it back to the server. The client can't pipeline the SEARCH command with the subsequent command, and, as a result, the server might not be able to perform some optimizations.This document proposes an IMAP extension that allows a client to tell a server to use the result of a SEARCH (or Unique Identifier (UID) SEARCH) command as an input to any subsequent command. [STANDARDS-TRACK]AcknowledgmentsThe author would like to thank the following people for their
comments and contributions to this document: , , , , , ,
, , , , , , and .Author's AddressOpen-Xchange Inc.530 Lytton AvenuePalo AltoCalifornia94301USmichael.slusarz@open-xchange.com