Subject: [Extra] I-D Action: draft-ietf-extra-imap-fetch-preview-07.txt

From: [email-masked]
Date: Tue, 10 Dec 2019 17:07:19 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF.

        Title           : IMAP4 Extension: Message Preview Generation
        Author          : Michael M. Slusarz
	Filename        : draft-ietf-extra-imap-fetch-preview-07.txt
	Pages           : 15
	Date            : 2019-12-10

Abstract:
   This document specifies an Internet Message Access Protocol (IMAP)
   protocol extension allowing a client to request a server-generated
   abbreviated representation of message data useful as a contextual
   preview of the entire message.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-extra-imap-fetch-preview/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-extra-imap-fetch-preview-07
https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap-fetch-preview-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap-fetch-preview-07

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Michael Slusarz <[email-masked]>
Date: Tue, 10 Dec 2019 18:21:15 -0700 (MST)

Sorry for the delay on this.

Per discussion in Singapore, the PREVIEW draft has been altered to replace "named algorithms" with media types.  The "FUZZY" algorithm was therefore renamed to "text/imap-fetch-preview" so that the semantics could be identified using the new media type method.

As part of this, it was necessary to clarify that the default algorithm, if either no algorithm list was provided or no algorithm was associated with a LAZY modifier, MUST be text/imap-fetch-preview.  Now that there is not a way for a client to determine which algorithms a server supports ("PREVIEW=" capability detection was removed), this seems to be the only rational choice - allowing every server to potentially specify a different default algorithm would lead to an inconsistent IMAP experience across installations.

I think this covers everything that was discussed at the last meeting.

michael

> On 12/10/2019 6:07 PM [email-masked] wrote:
> 
>  
> _______________________________________________
> Extra mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/extra

---

From: "Neil Jenkins" <[email-masked]>
Date: Wed, 11 Dec 2019 13:44:28 +1100

On Wed, 11 Dec 2019, at 12:21, Michael Slusarz wrote:
> The "FUZZY" algorithm was therefore renamed to "text/imap-fetch-preview" so that the semantics could be identified using the new media type method.

Huh? This is not at all what I thought we agreed on. The point of the discussion in Singapore was to remove any request for an algorithm. Instead you just request which media type(s) you are happy to get previews in, and if the server is able to generate a preview in that media type you'll get it. So the majority of standard email clients would just request "text/plain".

Neil.

---

From: Michael Slusarz <[email-masked]>
Date: Tue, 10 Dec 2019 20:43:29 -0700 (MST)

On 12/10/2019 7:44 PM Neil Jenkins <[email-masked]> wrote:

We definitely talked about this.  We got rid of the server advertising algorithms - we did not get rid of the need for a specific text preview semantic that matched the existing FUZZY functionality.  I wouldn't have agreed to a switch to media types without this.

michael

---

From: "Neil Jenkins" <[email-masked]>
Date: Wed, 11 Dec 2019 14:45:46 +1100

On Wed, 11 Dec 2019, at 14:43, Michael Slusarz wrote:
> we did not get rid of the need for a specific text preview semantic that matched the existing FUZZY functionality. 

Is that semantic not just "do whatever you want to provide a reasonable preview in text/plain format"?

Neil.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 11 Dec 2019 13:15:30 +0000

Hi Michael,

> I think this covers everything that was discussed at the last meeting.

This is a move in the right direction, but we are not quite there yet. I 
have a few questions that might affect my specific suggestions:

1) The document says to use media type syntax, but not necessarily media 
types. If you want the former, you probably need a new registry (I 
recommend against that). If you want the latter, then why not just use 
text/plain, as a registered media type?

2) If there is a good reason not to use "text/plain", you need to 
registered "text/imap-fetch-preview" with IANA.

3) For unsupported media types, it would be good to define a new IMAP 
response code, similar to BADCHARSET.

Best Regards,

Alexey