Subject: Re: [Jmap] New JSON message representation

From: Neil Jhaveri <[email-masked]>
Date: Thu, 1 Mar 2018 12:52:46 -0800

This proposal looks really great to me!  A few minor comments:

> A EmailBodyPart object has the following properties:
> […]
> width: Number|null The width (in px) of the image, if the type is an image and the server is able to determine this information for the image. This MAY not be supported for all or any image types on some servers.
> height: Number|null The height (in px) of the image, if the type is an image and the server is able to determine this information for the image. This MAY not be supported for all or any image types on some servers.
How strongly do you feel about the need for these properties? Is the primary intention for clients to have a more accurately-sized placeholder until the image can be downloaded?

There are some edge cases that can affect a client’s mapping of image pixels to points, e.g. EXIF image orientation, DPI, and screen resolution scale factor (in the case of screenshot images). In my opinion, these special image properties add relatively small benefit and aren’t bulletproof, but add a bit of clutter, so I personally lean towards these not being a part of the core spec (they could always be an extension or private extension). Thoughts?

> The following Email properties are specified for access to the body data of the message:
> […]
> textBody: EmailBodyPart[] (immutable) A list of text/plain, text/html and image/* parts to display (sequentially) as the message body, with a preference for text/plain when alternative versions are available.
> 
> htmlBody: EmailBodyPart[] (immutable) A list of text/plain, text/html and image/* parts to display (sequentially) as the message body, with a preference for text/html when alternative versions are available.
> 
Is the restriction to image/* non-text parts necessary? For instance, a user could e-mail a video/* part with Content-Disposition: inline, and I think it would be nice to include that in these array body properties.

One option is to re-define this to: 
“A list of text/plain, text/html, and attachment parts with the 'Content-Disposition: inline' header to display (sequentially) as the message body, with a preference for text/___ when alternative versions are available”. 

That seems more flexible in terms of including media parts, but it might be too strict if there are cases where an image/* part is included without a Content-Disposition header (or are C-D: attachment), but the server wants the MUA to display them inline anyways. I know that the Apple clients do that. If that case is common amongst other MUA's, could we just go even looser and say: 
"A list of parts to display (sequentially) as the message body, with a preference for text/____ when alternative text versions are available.” 

That leaves things pretty open-ended, though we do need to specify the recommendations for the mapping now.

---

From: Neil Jenkins <[email-masked]>
Date: Fri, 02 Mar 2018 13:40:40 +1100

On Fri, 2 Mar 2018, at 7:52 AM, Neil Jhaveri wrote:
> There are some edge cases that can affect a client’s mapping of image
> pixels to points, e.g. EXIF image orientation, DPI, and screen
> resolution scale factor (in the case of screenshot images). In my
> opinion, these special image properties add relatively small benefit
> and aren’t bulletproof, but add a bit of clutter, so I personally lean
> towards these not being a part of the core spec (they could always be
> an extension or private extension). Thoughts?
Yeh, reasonable. They require a lot of additional functionality on the
server and I'd already marked them as optional. I'll remove them from
the core spec.
> Is the restriction to image/* non-text parts necessary? For instance,
> a user could e-mail a video/* part with Content-Disposition: inline,
> and I think it would be nice to include that in these array body
> properties.
Hmm. This is a bit tricky. Apple Mail is the only common client I know
that generates anything like this, and it will do it with any file type
(e.g. a zip file in the middle of your text). My testing seems to show
that most clients treat that as an attachment (and show it at the end or
wherever they normally show attachments) unless it's an image, which
they show inline. Now, I haven't actually tested video so maybe clients
also show those inline? Anybody know?
I don't think this should be changed to allow any types in the
textBody/htmlBody list, but maybe allowing video/* as well as image/*
would be OK. Anyone else got an opinion on this?
Neil.

---

From: Stan Kalisch <[email-masked]>
Date: Mon, 19 Mar 2018 11:53:34 -0400

On Mar 1, 2018, at 9:40 PM, Neil Jenkins <[email-masked]> wrote:

> Hmm. This is a bit tricky. Apple Mail is the only common client I know that generates anything like this, and it will do it with any file type (e.g. a zip file in the middle of your text). My testing seems to show that most clients treat that as an attachment (and show it at the end or wherever they normally show attachments) unless it's an image, which they show inline. Now, I haven't actually tested video so maybe clients also show those inline? Anybody know?

IIRC, some version(s) of Outlook does/do this.

Stan