On Wed, Feb 8, 2017 at 7:03 AM, John C Klensin <john-ietf@xxxxxxx> wrote:
Except for the small minority of users who switch MUAs back and forth (see below), I
would expect any given user to use either an IMAP approach, a
JSON or JSON-like one, or neither.
I am confused by this claim. There are substantial numbers of users who access their mail from mobile and from laptop/desktop systems. Those, generally speaking, are different MUAs.
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
and to support, also for a long time, the ability to convert
between the two formats.
Also, if that conversion is not
absolutely lossless, there will be a large collection of ongoing
problems, for an equally long time.
Those _are_ reasons to not let JMAP progress because it could
easily make the mail system work worse.
I think you and the proponents fundamentally disagree about what the current mail system is. They see a welter of proprietary systems based on JSON and HTTP, and they want to clean it up by standardizing on one approach. You see a standardized system of IMAP/SMTP and want to avoid standardizing another system. From the proponents perspective Andrew's question of "long periods of coexistence" has to be seen in the context of "long periods of coexistence" _of proprietary systems_ .
If you don't agree on what the mail system is, it's not particularly surprising that you don't agree on the method for optimizing it.
Not, as Andrew (and
several others) have suggested, not a risk we should encourage
unless the benefits and improvements are significant.
The proponents seem to have demonstrated that there are proprietary systems in place. So I believe the calculus of benefits and improvements must be done over a different set of data points.
regards,
Ted
best,
john