Subject: [Extra] Robert Wilton's No Objection on draft-ietf-extra-imap-fetch-preview-10: (with COMMENT)

From: Robert Wilton via Datatracker <[email-masked]>
Date: Mon, 05 Oct 2020 01:54:09 -0700

Robert Wilton has entered the following ballot position for
draft-ietf-extra-imap-fetch-preview-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-extra-imap-fetch-preview/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Discuss cleared.

One minor comment:

   This standardized display can reduce user confusion when using
   multiple clients, as abbreviated message representations in clients
   will show identical message contents.

I didn't really find this reasoning to be compelling, and perhaps it could be
removed.  In my experience the amount of preview displayed depends on client
behaviour or settings (e.g., how much space to allow for previews).

Regards,
Rob

---

From: Michael Slusarz <[email-masked]>
Date: Wed, 7 Oct 2020 10:42:37 -0600 (MDT)

> On 10/05/2020 2:54 AM Robert Wilton via Datatracker <[email-masked]> wrote:
> 
> One minor comment:
> 

Hypothetical: a message with two alternative parts - text and HTML.  The text part is a "your client doesn't support HTML message" placeholder, the HTML part is the "real" data.  One client may try to create a preview out of the most feature-rich alternative (HTML); another will create a preview out of the first sequential text part it finds.  Another example would be competency in HTML -> plaintext parsing.

I will agree that user confusion is not a major issue if preview display differs based on UI concerns: Are the first 40 characters displayed or the first 100 characters?  However, if the content is vastly different then I do think there is chances for confusion, especially for users that use previews as a way to contextually scan their mailboxes.

"Consistent previews across clients" was a product ask when this feature was first being developed.  Is it the most important feature?  Maybe not.  But it seems important enough to justify a mention since it does clean up, at best, a minor annoyance and, at worst, a real source of confusion that end-users have complained about in the past.

michael

---

From: Barry Leiba <[email-masked]>
Date: Wed, 7 Oct 2020 15:07:44 -0400

I had suggested wording for this; did you see it?  Michael?  Rob?

Barry

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 8 Oct 2020 08:54:08 +0000

That is just a stale comment in the datatracker from my previous ballot review.

Yes, I had already agreed with the text that Barry previous suggested.  Reproduced here for clarity:

> On thinking about re-phrasing, how does this sound?:
> 
> NEW
> 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.
> END
> 
> Barry

Regards,
Rob

> -----Original Message-----
> From: Barry Leiba <[email-masked]>
> Sent: 07 October 2020 20:08
> To: Michael Slusarz <michael.slusarz=[email-masked]>
> Cc: Rob Wilton (rwilton) <[email-masked]>; Robert Wilton via
> Datatracker <[email-masked]>; The IESG <[email-masked]>; [email-masked];
> Bron Gondwana <[email-masked]>; [email-masked]; draft-ietf-
> [email-masked]
> Subject: Re: [EXT] Robert Wilton's No Objection on draft-ietf-extra-imap-
> fetch-preview-10: (with COMMENT)
> 
> > Hypothetical: a message with two alternative parts - text and HTML.  The
> text part is a "your client doesn't support HTML message" placeholder, the
> HTML part is the "real" data.  One client may try to create a preview out
> of the most feature-rich alternative (HTML); another will create a preview
> out of the first sequential text part it finds.  Another example would be
> competency in HTML -> plaintext parsing.
> >
> > I will agree that user confusion is not a major issue if preview display
> differs based on UI concerns: Are the first 40 characters displayed or the
> first 100 characters?  However, if the content is vastly different then I
> do think there is chances for confusion, especially for users that use
> previews as a way to contextually scan their mailboxes.
> >
> > "Consistent previews across clients" was a product ask when this feature
> was first being developed.  Is it the most important feature?  Maybe not.
> But it seems important enough to justify a mention since it does clean up,
> at best, a minor annoyance and, at worst, a real source of confusion that
> end-users have complained about in the past.
> >
> > michael
> >