Hacker News Reader

Comment by andris9 | Hacker News Reader

There is only a handful of IMAP server implementations and there are going to be even fever JMAP servers. It is super bloated, the RFCs 8620 and 8621 are already 200 pages in total. Not an easy thing to integrate with.

View on HN

To be fair, RFC3501 is 108 pages, and the bis (draft-ietf-extra-imap4rev2-12) is 157 pages. It's a complex problem space.

I'm looking forward to getting JMAP Calendars and JMAP Contacts done, at which point is becomes a much more compelling replacement for multiple protocols.

Anything we can do to help in getting those other extensions done?

The next IETF meeting is in Vancouver in late March - we'll be discussing them there. Other than that, get involved on the mailing list, and help review the documents!

https://datatracker.ietf.org/group/jmap/meetings/

https://www.ietf.org/mailman/listinfo/jmap

https://datatracker.ietf.org/doc/draft-ietf-jmap-calendars/

https://datatracker.ietf.org/doc/draft-ietf-jmap-jscontact/

The problem JMAP is addressing is quite complex that’s why the JMAP spec is long. I do not however find it to be bloated. On the contrary I actually found it quite easy to read. (I've implemented jmap-mail on the client side.)

One could potentially write JMAP as a proxy to an existing IMAP server (just like your 'imap-api') therefore the current lack of JMAP servers doesn’t really matter.

It is easier on the client side as you’d only have to implement the parts you actually need. In server side if you want to expose JMAP then you’d have implement _everything_. You can’t decide for example that as no-one actually copies messages but moves, then you’d skip the copy endpoint.

I had a chat with Neil Jenkins and Bron about this (two of the authors & WG chairs). That skew is intentional - their rationale is that there's way more email clients out there than email server implementations. So it makes sense to load more of the complexity into the servers.

Of course, until other email servers add support for jmap, the protocol has a bit of a bootstrapping problem. Getting support from gmail + microsoft exchange would be a huge win for jmap, and in the long run email as a whole.

And indeed, https://proxy.jmap.io/ demonstrates a JMAP proxy to IMAP servers—though note Bron’s comment downthread concerning this (jmap-perl).

Reply on news.ycombinator.com