Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity

[Ted Hardie <[e-mail]>]

On Wed, Feb 8, 2017 at 7:03 AM, John C Klensin <[e-mail]> 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
>
>
>
>