[Top] [All Lists]

Re: [ietf-smtp] [imapext] Fwd: Request to form a new WG: JMAP

2016-11-09 11:02:04
On 09/11/2016 16:42, John C Klensin wrote:

My guestimate is that - and here I'm speaking only of the
message access space - that a HTTPS/JSON approach wins in
terms of effective implementation complexity, although it is
far from clear to me by how much.
But, unless we can get rid of IMAP (and some of the
functionality, like disconnected mode, that can't obviously be
supported over a purely HTTPS/JSON interface) entirely, it seems
to me that an HTTPS/JOSN approach is additive, requiring the
mail environment to support both it and IMAP for (at least) a
very long time.  So, while I agree with your guess, I don't see
the need to support an additional as a net gain, especially in
the short to medium term.

I'm looking at this 'JMAP' idea and wondering - why? What is it trying to solve that we can't already do.

'Making it more consistent' isn't a good enough reason IMHO. IMAP4 may be a bit weird, but it's here, and widely used. So, I'm not entirely sure what a 'JMAP' would achieve that we can't already do.

Is it so that people can write webmail apps in pure Javascript (without needing PHP/Python/whatever running on the server). That's a possible benefit of a HTTPS/JSON interface, but I'm not sure how important that would be long term.

Is it so that mail backends which don't really fit into the IMAP4 way of working (eg gmail) are easier to work with? That's a potential goal to make a whole new protocol, but it seems odd to try to standardise a whole new protocol just for that.

There may be something else; it may be that I'm underestimating the benefits I've seen. But, so far all I seem to see is 'people don't like IMAP4 so we want something new', which I'm not sure is a good enough reason.

So, what is 'JMAP' trying to give us that we can't already do? (Or that well designed IMAP4 extensions couldn't give us)

Will it be such an amazing advantage that developers (of both servers and clients) are willing to learn a whole new system and rewrite their software to deal with it? Will it let users do things they're desperate to do but can't do now, so they're clamouring at the doors of the developers to force them to do it? If not, then it'll be yet another protocol which may looks good but never gets widely implemented.

ietf-smtp mailing list