Re: [Extra] Barry Leiba's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT)

[Michael Slusarz <[e-mail]>]

Neil,

Thanks for your comments.  Responses below.

On June 2, 2019 6:27 PM Neil Jenkins <[e-mail]> wrote:

I must admit to having skimmed this discussion, but it seems to me that this extension is getting way over-complicated. The key here is simply to answer the question: what is this for? The only purpose of this is to provide a way for clients to get a snippet of (plain) text to shown in the mailbox listing without downloading whole body parts and expecting a fast response from the server (like fetching common headers). This is a common feature and worth making more efficient. Trying to do anything else is making things more complicated for close to zero benefit.

I agree that a plaintext preview, to mimic what exists in current client UIs, was a main driving factor for creating this draft.  I disagree that this is the only potential use-case.

I would contend:

• No server is going to implement more than one algorithm. Like with fuzzy searching, we should not specify the algorithm in the spec. Servers should be free to implement the best solution they can, which is likely to change over time as new edge cases are found and new capabilities are available (for example, skipping salutations, OCRing an image-only body, skipping broken auto-generated plain text components and generating the preview from the text/html version instead, etc.). The server should be free to choose which parts it thinks it should use to generate the preview.

We are in agreement here.  This is FUZZY.  We have defined some output requirements and limitations, but that output is up to the server.

• The client either accepts the server is going to give it a good preview or it will ignore the whole capability and generate its own, at the expense of being slower and more data hungry.
• The output is always just plain text. This is what is shown in mailbox listings as the preview in Apple Mail, Gmail, FastMail, etc. If you think an image or text/html preview is useful, I disagree, but regardless that should be a different spec rather than overcomplicating one that solves an actual use case today. (To be clear, I think the spec already says this, but some of the comments in this thread seemed to indicate to me people thought you might want different typed outputs in the future).

I disagree with this logic, as it is essentially "let's standardize what already exists in clients."  I'd rather design a standard that fits the current use cases AND can be extended to future use cases.

A real world example - we are currently working on an initiative to push email as a chat medium (Shameless plug: https://www.coi-dev.org/" rel="nofollow">https://www.coi-dev.org/).  In every chat client I have ever used, sending images and/or video is an important part of conversations.  When an image/video appears in a chat stream, the full contents are not generally displayed - it is a small preview of the image (or a small preview of a frame of the video).  That small image that is surely a "preview" of that message.  Mixed media previews are a very common paradigm in other messaging systems - why should email be any different?

We shouldn't have to come back in a year and propose a new "FETCH IMAGEPREVIEW" standard to support this - we should instead be able to propose a simple, optional extension to the base PREVIEW behavior.

• (Perhaps controversial but…) If the server offers the capability it should always have the data readily available, so the LAZY modifier is not necessary. I would expect servers that implement this to generally calculate and cache a preview on delivery. If it's going to take a while, the benefit to the client is much less and it might as well just calculate its own. That way the client only has two code paths (server-preview or client-preview) rather than three (server delayed preview as well).

We index on delivery, but there's plenty of reasons why preview may not be available at a later time.  More important, a preview is not a fundamental part of the message data - it is data created via transformation of that data.  The original message cannot be recreated, but previews can - a server operator should be allowed to choose different storage and/retention policies based on that fact.

A client doesn't have to use LAZY.  A server can quickly support LAZY by returning NIL for every message requested - this doesn't add any appreciable overhead to the client/server interaction, as the client would need to issue a separate FETCH PREVIEW call regardless of whether LAZY was supported or not.  If LAZY is not something a client/server operator wants to deal with the complexities of, they can be avoided at almost zero development cost.

In the JMAP Mail spec, we simply specify the following for the equivalent property:

preview :  String

A plain text fragment of the message body. This is intended to be shown as a preview line on a mailbox listing, and may be truncated when shown. The server may choose which part of the message to include in the preview; skipping quoted sections and salutations and collapsing white-space can result in a more useful preview.

This MUST NOT be more than 256 characters in length.

PREVIEW=FUZZY and JMAP preview can be serviced by the same data (Bron suggested changes to the preview spec in the past to ensure this), so I think we are good here.

michael