[Jmap] Attachments and composing more complex MIME structures

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

Some clients (most notably iOS Mail app) often produce multipart/mixed
emails with inline text and images.  For example, if I compose a simple
email with no formatting and insert two images in the middle:

	This is a

	[inserted image]

	test of

	[another inserted image]

	iOS mail.

the email that gets produced has content-type multipart/mixed and there are
five parts (all at the top level with no nesting):

1. text/plain with "This is a"
2. image/png with the first inserted image
3. text/plain with "test of"
4. image/png with the second inserted image
5. text/plain with "iOS mail."

The image parts have inline content-disposition.

The attachment API (I'm not really sure what else to call it) as it is
currently described would work well for drafting what I think of as "email
with a bunch of attachments at the end" (that is parts with "attachment"
content disposition appended at the top-level of the MIME structure).
However, I don't think the attachment API can be used to draft one of these
inline-mime-image mails since setMessages:

1. assumes that the email text itself is one part (text/plain or text/html)
2. the attachment isInline property is meant only for HTML cid references

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?  This breaks one of the exciting features of jmap -
not having to reupload all the attachments during auto-saving of drafts.

At some point on the list, Chris suggested providing a set of properties to
allow the clients to easily extract important content from the email.  Would
it make sense to extend the setMessages call to do the reverse?  That is,
assemble a RFC 5322 message from a body structure specified by the client?
I imagine each supplied body structure part to either specify text/plain or
text/html as a property, or specify the content type and disposition along
with a blob id.

The current draft has something like it, but it doesn't specify the actual
structure - just a list of attachment blobIds with some hints about their
use (i.e., the isInline property which seems to control the content
disposition, but not the placement of the part within the MIME structure).

Thanks,

Jeff.


P.S. For what it is worth, the iOS mail app produces a totally different
structure if any of the text has formatting.  (OSX Mail.app seems to always
produce it as well.)  For example, with the same content as above, but with
formatting applied to any of the text produces a multipart/alternative email
with:

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