That is entirely possible :-). > Except for the small > minority of users who switch MUAs back and forth (see below),
FWIW, this is not a small minority any more. A fair number of people own and use multiple mobile devices and access their email from all of them.
> I would expect any given user to use either an IMAP approach, a > JSON or JSON-like one, or neither. No long transition as far > as they are concerned. However, from the perspective of > someone trying to maintain servers or a mailstore, the fact that > there will be both types of users (for a long time if not > forever), it implies the need to maintain (and configure, > support, etc.) both IMAP/SMTP and JMAP facilities in parallel
As far as deployments are concerned, if there is a case of co-existentence, then it would fall into one of two categories:
1). JMAP is just a a proxy and uses IMAP on the backend. Configuring JMAP server is the same as configuring a MUA.
This is a key point. A lot of people have criticized this proposal based on the assumption that new clients will have to support both IMAP/SUBMIT and JMAP. I think this is very unlikely to be the case. Once JMAP is out there I suspect there will be a significant number of clients - perhaps the majority - that will only support JMAP. These clients will depend on a combination of (1) Large MSPs quickly moving to deploy JMAP in addition to IMAP, (2) The availability of JMAP->IMAP/SUBMIT proxies, and (3) The addition of JMAP support to at least some of the open source message store implemenations. (2) in particular creates additional requirements that need to be explicitly called out in the charter. In particular, it's imperative that (a) It be reasonable to implement JMAP->IMAP/SUBMIT proxies, even if that constrains JMAP in ways some folks do not like, (b) The list of IMAP extensions needed to properly implement JMAP be called out, and (c) The security considerations involved in operating such a proxy need to be described in detail.
2). Both are supported by the same software (i.e. Cyrus and Dovecot use case). I doubt that incremental cost of configuring both is much higher than just configuring one of them.
In either case configuring JMAP clients is a simple(r) proposition: just distribute HTTP URI for a JMAP instance.
> and to support, also for a long time, the ability to convert > between the two formats.
There are no 2 formats, both IMAP and JMAP operate on RFC 5322 objects, so the rest of your argument is invalid.
Agreed. I have to say I really don't understand the confusion surrounding this point. IMAP has bodystructure plus a couple of other formats for returning message data, and a means of creating new messages from pieces of other messages, none of which look remotely like MIME/RFC 5322, and nobody cares. This is effectively the same thing; why should anyone care here? Ned