Subject: [Jmap] JMAP spec status

From: Neil Jenkins <[email-masked]>
Date: Tue, 06 Mar 2018 17:45:45 +1100

As you probably saw, I pushed a new draft of the core and mail specs
before the IETF101 cutoff. I have merged the Email object changes, since
these seem to have broad support, with the following minor changes:
 * The ability to add the :all modifier[1] to get all instances of a
   header. e.g. the "header:received:all" property would return an array
   containing the raw values of each Received header field (in the order
   they appear in the message).
 * An initial suggested algorithm for decomposing bodyStructure[2] into
   textBody/htmlBody/attachedEmails/attachedFiles – feedback welcome on
   improvements to this, as while it should work well for conformant
   messages, I expect people may have real-world experience of hacks
   required to display malformed messages seen in the wild well. It
   would be great to pool some of this experience into the suggested
   algorithm.
 * The attachedFiles array is now defined to also contain[3] any images
   that are just in textBody or htmlBody but not in both. It's easy for
   a client to skip them when rendering attachments if the body list the
   client used already contains it (you can just compare the partId),
   but without this important content might disappear when rendering one
   of the text/html versions.
The latest drafts of core/mail are available in standard IETF formats
from the datatracker[4] site, or the same content is available with
better formatting on the jmap.io website (core spec[5]/mail spec[6]).
Almost all the GitHub issues[7] have now been resolved. The remaining
few tasks are mainly some IANA updates, which should be easy to get
done at IETF101. So now is the time to do a final review of the two
specs and raise any remaining issues in advance of the conference! I
plan to review the changes since Singapore, and we can go over any
remaining issues, but my hope is to have this finished and published
before IETF102.
Cheers,
Neil.

Links:

  1. https://github.com/jmapio/jmap/commit/b180278da6d83a69795dffa667bac941775b7ab5
  2. https://github.com/jmapio/jmap/commit/200e6c068e939d5f5d5e847f6f7e8a88b624001b
  3. https://github.com/jmapio/jmap/commit/5122b475b45841e9c3235e0ba5c0c0959847fd5e
  4. https://datatracker.ietf.org/wg/jmap/documents/
  5. http://jmap.io/spec-core.html
  6. http://jmap.io/spec-mail.html
  7. https://github.com/jmapio/jmap/issues

---

From: Neil Jhaveri <[email-masked]>
Date: Tue, 6 Mar 2018 00:25:21 -0800

The new draft looks great, Neil!
> An initial suggested algorithm for decomposing bodyStructure <https://github.com/jmapio/jmap/commit/200e6c068e939d5f5d5e847f6f7e8a88b624001b> into textBody/htmlBody/attachedEmails/attachedFiles – feedback welcome on improvements to this, as while it should work well for conformant messages, I expect people may have real-world experience of hacks required to display malformed messages seen in the wild well. It would be great to pool some of this experience into the suggested algorithm.
I took a look at this suggested algorithm, and while basic, it looks pretty solid to me. My recollection working on Apple's Mail clients is that there actually weren’t many special cases in the flattening logic, and that the suggested algorithm already in the draft actually covers any special cases I saw added over the years. The major differences are around additional supported features, such as support for displaying text/enriched.

I do have one minor nit-pick comment, related to the assumption of Content-Type. If a part has no Content-Type, I believe it’s supposed to be assumed to be text/plain (unless it’s a child of message/digest, in which case it’s assumed to be message/rfc822). In these cases, I think the algorithm could use a small tweak to consider a part’s assumed Content-Type when the Content-Type is null?

From the other thread, I’d still also like to see video/* and audio/* join image/* in being included in the list of types that can be inlined into textBody/htmlBody when the Content-Disposition is not attachment (since these can be easily displayed using the HTML5 <video> and <audio> tags), but am also interested in seeing what others think before this is done.
>> The attachedFiles array is now defined to also contain <https://github.com/jmapio/jmap/commit/5122b475b45841e9c3235e0ba5c0c0959847fd5e> any images that are just in textBody or htmlBody but not in both. It's easy for a client to skip them when rendering attachments if the body list the client used already contains it (you can just compare the partId), but without this important content might disappear when rendering one of the text/html versions.

I agree with this.

---

From: Neil Jenkins <[email-masked]>
Date: Thu, 08 Mar 2018 10:26:47 +1100

On Tue, 6 Mar 2018, at 7:25 PM, Neil Jhaveri wrote:
> I do have one minor nit-pick comment, related to the assumption of Content-
> Type. If a part has no Content-Type, I believe it’s supposed to be
> assumed to be text/plain (unless it’s a child of message/digest, in
> which case it’s assumed to be message/rfc822).
Good point. I think the place to fix this is actually in the
EmailBodyPart object – the *type* property should fill in the default
content-type for you automatically as the client may not be aware of the
context if it's getting a flat list. (Since the algorithm is based on
these objects, that would automatically fix the algorithm.) Sound
reasonable?
The property description would change to:

 * *type*: String The value of the *Content-Type* header field of the
   part, if present, otherwise the implicit type as per the MIME
   standard (text/plain, or message/rfc822 if inside a
   multipart/digest). CFWS is removed and any parameters are stripped.
>  From the other thread, I’d still also like to see video/* and audio/*
>  join image/* in being included in the list of types that can be
>  inlined into textBody/htmlBody when the Content-Disposition is not
>  attachment (since these can be easily displayed using the HTML5
>  <video> and <audio> tags), but am also interested in seeing what
>  others think before this is done.
I don't really have a strong opinion on this, but I think this change is
reasonable (although I don't know I've ever come across such emails in
the wild). Anyone else got strong views/arguments on whether video/* and
audio/* should also be allowed in the inline body part arrays?
Neil.