Re: [Jmap] Attachments and composing more complex MIME structures

[Josef 'Jeff' Sipek <[e-mail]>]

On Tue, Aug 08, 2017 at 20:28:37 +1000, Neil Jenkins wrote:
> On Tue, 8 Aug 2017, at 07:23 PM, Josef 'Jeff' Sipek wrote:
> > Some clients (most notably iOS Mail app) often produce multipart/mixed> emails with inline text and images.
> 
> Although not clear yet (this bit of the spec needs a lot more details),
> the intention is that a JMAP server would convert this to an htmlBody in
> the Message object that combined the text and images (with cids).

I guessed that was the idea there.

> > However, I don't think the attachment API can be used to draft one of
> > these inline-mime-image mails since setMessages:
> 
> No, but you could produce an HTML part that's going to render the same
> (and be more compatible).

Is there a MIME-aware client that breaks with what the iOS client generates?
In theory the multipart/mixed approach should be *more* compatible than
HTML, since the client doesn't have to deal with HTML on top of dealing with
MIME anyway.

<personal preference>
As a mutt user that likes text/plain emails... it'd be great if these
generated emails displayed nicely with non-HTML based MUAs. :)

At the very least, the multipart/mixed emails render rather sanely in mutt.
</personal preference>

> > Did I miss something, or does this really mean that a client like this
> > must save drafts that are pre-composed RFC 5322 messages with all the
> > inserted images already embedded?
> 
> If the client absolutely MUST create a multipart/mixed email like this,
> then yes. The intention with the Message object format is to hide the
> complexities of MIME, and try to remove alternative ways of representing
> the same things. This makes it easier for client authors, at the expense
> of some more complexity for server developers.

I suppose the textBody/htmlBody approach should easily cover 80% of the use
cases.  The remaining 20% are possible via the importMessages call and raw
email upload for now, or an extension in the future.

Is the goal to make only the simplest of clients easy to implement?  Where
does one draw the line between simple enough to use the nice jmap interface
and too complex (IOW: just implement the whole RFC 5322/MIME/etc. stack and
use the blob API)?

> > P.S. For what it is worth, the iOS mail app produces a totally
> >      different> structure if any of the text has formatting.:
> > 1.   text/plain with the whole text without any images
> > 2.   multipart/related
> > 2.1. text/html with the whole text with <img> tags using cids to
> >      refer to>     the images
> > 2.2. image/png with the first inserted image
> > 2.3. image/png with the second inserted image
> 
> Doesn't sound like it would be difficult for it just to always generate
> this even when no text formatting is applied then…

Agreed.

Thanks,

Jeff.