search

jmapio / jmap

JSON Meta Application Protocol Specification (JMAP)
http://jmap.io
Apache License 2.0
1.25k stars 82 forks source link

mail: define a message format that is somewhere between raw RFC5322 and the really basic format we have now #104

Closed brong closed 6 years ago

brong commented 7 years ago

As part of #103 - we find ourselves wanting partial fetch on the body components. There may be other parts of the MIME structure that would be useful to have access to via JMAP as well - some more work on defining which bits of the MIME structure are useful to people would be good.

This is also a place where JMAP extensions could add extra elements to the object, allowing other parts of RFC5322 messages to be available via JSON.

brong commented 7 years ago

Chris Newman commented:

  1. Messages

Overall, I find this to be almost as problematic as the sending model of the specification. I understand the goal of trying to make a minimal JMAP client work without having to implement 5322/MIME/2047/2231. But the problem with creating a data format gateway is you've got the union of the problems and the intersection of the functionality. And while having a way to fetch the raw blob is nice, that's not great for clients that want some of the 5322/MIME/2047/2231 functionality that's missing from JMAP but don't want to be forced to fetch the full message and do a full parse of it.

I suggest a different approach. First, define a set of properties that are largely un-adulterated (similar to IMAP header fetch, IMAP body part references, etc). Then define properties that try to convert/simplify/flatten that data (losing information in the process). Then clients can choose the level of precision they want. You'll need to describe the algorithms used to convert/simplify/flatten the data in detail. And if you're going to simplify some address fields, you need the ability to simplify all of them, including ones like Message-Disposition-To.

or RFC 2047 encoding of non-ASCII characters, MUST be fully decoded into standard UTF-8.

If you say this, you need to identify the charsets that MUST be supported; otherwise the requirement is impossible. You'll also want to mention RFC 2231.

brong commented 7 years ago

textBody & htmlBody: I assume these are converted to UTF-8? This model is not good. I generally want to be presented the plain text body if present and the HTML body if the text body is not present. Are you unfolding RFC 3676 for this? What if it's S/MIME signed?

brong commented 7 years ago

date: the timezone of the sender is relevant information, so if you're parsing out the date, you should parse out that field as well. For submission you need a way to provide the timezone.