IMAP4 Extension: Message Preview Generation
RFC 8970

Document Type RFC - Proposed Standard (December 2020; No errata)
Author Michael Slusarz 
Last updated 2020-12-18
Replaces draft-ietf-extra-imap-fetch-snippet
Stream IETF
Formats plain text html xml pdf htmlized bibtex
Reviews
Stream WG state Submitted to IESG for Publication
Document shepherd Bron Gondwana
Shepherd write-up Show (last changed 2020-07-23)
IESG IESG state RFC 8970 (Proposed Standard)
Consensus Boilerplate Yes
Telechat date
Responsible AD Barry Leiba
Send notices to Bron Gondwana <brong@fastmailteam.com>
IANA IANA review state Version Changed - Review Needed
IANA action state RFC-Ed-Ack


Internet Engineering Task Force (IETF)                        M. Slusarz
Request for Comments: 8970                             Open-Xchange Inc.
Category: Standards Track                                  December 2020
ISSN: 2070-1721

              IMAP4 Extension: Message Preview Generation

Abstract

   This 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
   https://www.rfc-editor.org/info/rfc8970.

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
   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

   1.  Introduction
   2.  Conventions Used in This Document
   3.  FETCH Data Item
     3.1.  Command
     3.2.  Response
     3.3.  Preview Text Format
   4.  LAZY Priority Modifier
     4.1.  LAZY
     4.2.  Client Implementation Advice
   5.  Examples
   6.  Formal Syntax
   7.  IANA Considerations
   8.  Security Considerations
   9.  References
     9.1.  Normative References
     9.2.  Informative References
   Acknowledgments
   Author's Address

1.  Introduction

   Many 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 [RFC3501] 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 [RFC2045] 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 [RFC2854] 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.

2.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Show full document text