IMAP4 Extension: Message Preview Generation
draft-ietf-extra-imap-fetch-preview-10

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Bron Gondwana <brong@fastmailteam.com>, extra-chairs@ietf.org, The IESG <iesg@ietf.org>, barryleiba@gmail.com, rfc-editor@rfc-editor.org, draft-ietf-extra-imap-fetch-preview@ietf.org, brong@fastmailteam.com, extra@ietf.org
Subject: Protocol Action: 'IMAP4 Extension: Message Preview Generation' to Proposed Standard (draft-ietf-extra-imap-fetch-preview-10.txt)

The IESG has approved the following document:
- 'IMAP4 Extension: Message Preview Generation'
  (draft-ietf-extra-imap-fetch-preview-10.txt) as Proposed Standard

This document is the product of the Email mailstore and eXtensions To Revise
or Amend Working Group.

The IESG contact persons are Murray Kucherawy and Barry Leiba.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-extra-imap-fetch-preview/

Ballot Text

Technical Summary
  This spec extends IMAP with an additional fetch item (PREVIEW)
  which allows clients to obtain a short piece of text to use as
  a preview line in mailbox listings.

Working Group Summary
  This document and fetch item was originally named "snippet", however
  JMAP uses "preview" for the equivalent field, and "snippet" for a
  marked up section of the message containing search terms, so the
  working group agreed to change the naming to be consistent.

  There was also debate over the maximum length, with both JMAP and
  EXTRA working groups settling on 256 characters maximum.

  Finally there were questions over whether "LAZY" was useful, but nobody
  saw any downside to including it.  Servers can choose to always calculate
  the preview even if LAZY is given.

  There was a significant amount of rework through multiple meetings which
  led to a very complex document.  In the end, the authors asked to drop
  the complexity and go back to an earlier version, which achieved working
  group consensus.

Document Quality
  This spec is quite easy to implement - it has multiple examples for all
  the likely cases.  It's been implemented in Dovecot and Cyrus IMAPd.

Personnel
  Document Shepherd - Bron Gondwana (EXTRA co-chair)
  Responsible Area Director - Barry Leiba

RFC Editor Note
Please make the following change to the second paragraph in Section 1:

OLD
   Generation of a preview on the server has several benefits.  First,
   it allows consistent representation of previews across all clients.
   This standardized display can reduce user confusion when using
   multiple clients, as abbreviated message representations in clients
   will show identical message contents.

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

RFC Editor Note