--- 1/draft-ietf-extra-imap-fetch-preview-09.txt 2020-09-30 22:13:23.343916467 -0700 +++ 2/draft-ietf-extra-imap-fetch-preview-10.txt 2020-09-30 22:13:23.371917198 -0700 @@ -1,18 +1,18 @@ EXTRA M. Slusarz Internet-Draft Open-Xchange Inc. -Intended status: Standards Track July 29, 2020 -Expires: January 30, 2021 +Intended status: Standards Track September 30, 2020 +Expires: April 3, 2021 IMAP4 Extension: Message Preview Generation - draft-ietf-extra-imap-fetch-preview-09 + draft-ietf-extra-imap-fetch-preview-10 Abstract This document specifies an Internet Message Access Protocol (IMAP) protocol extension allowing a client to request a server-generated abbreviated text representation of message data useful as a contextual preview of the entire message. Status of This Memo @@ -22,21 +22,21 @@ 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 30, 2021. + This Internet-Draft will expire on April 3, 2021. 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -101,24 +101,24 @@ 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 then 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. + 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. 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all @@ -141,21 +141,23 @@ 3. FETCH Data Item 3.1. Command To retrieve a preview for a message, the "PREVIEW" FETCH attribute is used when issuing a FETCH command. 3.2. Response The server returns a variable-length string that is the generated - preview for that message. + 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 @@ -163,31 +165,31 @@ 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, and that - decision won't change later. 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 capture this infrequent occurrence.) + 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 capture 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. 3.3. Preview Text Format The generated preview text MUST be treated as text/plain [RFC2046] media type data by the client. @@ -214,23 +216,22 @@ If the preview is not generated based on the body content of the message, and the LANGUAGE [RFC5255] 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, and should thus use the rules defined for human-generated - text described in the LANGUAGE extension (if supported on the - server). + server, and should thus use the rules defined for human-readable text + described in the LANGUAGE extension (if supported on the server). 4. LAZY Priority Modifier 4.1. LAZY The 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 @@ -238,42 +239,43 @@ response. The LAZY modifier MUST be implemented by any server that supports the PREVIEW extension. 4.2. Client Implementation Advice Upon 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 - additional display preview information as part of this listing. + 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 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. + 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 for an implementation of this strategy. A client SHOULD NOT continually issue LAZY PREVIEW FETCH commands 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. 5. Examples Example 1: Requesting PREVIEW without LAZY modifier. @@ -289,27 +291,27 @@ 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: D1 FETCH 1:4 (ENVELOPE PREVIEW (LAZY)) - S: * 1 FETCH (ENVELOPE ("Wed, 25 Oct 2017 15:03:11 +0000" [...]) + S: * 1 FETCH (ENVELOPE ("Wed, 23 Sep 2020 15:03:11 +0000" [...]) PREVIEW "Preview text for message 1.") S: * 2 FETCH (PREVIEW "" ENVELOPE - ("Thu, 26 Oct 2017 12:17:23 +0000" [...])) - S: * 3 FETCH (ENVELOPE ("Fri, 27 Oct 2017 22:19:21 +0000" [...]) + ("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, 28 Oct 2017 07:11:18 +0000" [...]) + S: * 4 FETCH (ENVELOPE ("Sat, 26 Sep 2020 07:11:18 +0000" [...]) PREVIEW NIL) S: D1 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: D2 FETCH 3:4 (PREVIEW) S: * 3 FETCH (PREVIEW {30} S: Message data from message 3. S: ) S: * 4 FETCH (PREVIEW "Message 4 preview") @@ -358,25 +360,31 @@ http://www.iana.org/assignments/imap-capabilities This document requests that IANA adds the "PREVIEW" capability to the IMAP4 [RFC3501] capabilities registry. 8. Security Considerations Implementation 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. Servers MAY limit - the resources that preview generation uses. 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. + 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. 9. References 9.1. Normative References @@ -559,20 +567,29 @@ o Remove algorithm selection; PREVIEW always returns text in format defined in Section 3.3 Changes from draft-ietf-extra-imap-fetch-preview-08: o FETCH PREVIEW without LAZY modifier MUST NOT return NIL o Improve client implementation advice for LAZY modifier + Changes from draft-ietf-extra-imap-fetch-preview-09: + + o Clarified that string response is to be interpreted by user, not + the client + + o Give example behavior of resource limitation + + o Various editorial fixes + Acknowledgments The author would like to thank the following people for their comments and contributions to this document: Stephan Bosch, Bron Gondwana, Teemu Huovila, Neil Jenkins, Steffen Lehmann, Barry Leiba, Alexey Melnikov, Chris Newman, Pete Resnick, Jeff Sipek, Timo Sirainen, Steffen Templin, and Aki Tuomi. Author's Address