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

[Alexey Melnikov <[e-mail]>]

John,


On 08/02/2017 15:03, John C Klensin wrote:
> --On Wednesday, February 8, 2017 14:27 +0000 Alexey Melnikov
> <[e-mail]> wrote:
>
>> Hi Andrew,
>>
>> On 08/02/2017 14:22, Andrew Sullivan wrote:
>>
>>> On Wed, Feb 08, 2017 at 01:52:00PM +0000, Alexey Melnikov
>>> wrote:
>>>> Agreed. JMAP and IMAP are likely to co-exist for long time.
>>> Isn't that exactly the complaint?  Something like, "Long
>>> periods of co-existence need to have lots of benefits or an
>>> existential one, or else they're not a good idea."
> It is certainly my main complaint.
>
>> They have slightly different audiences. People who want to do
>> something like JMAP are already doing something like JMAP.
>> They might or might not care about IMAP. People who are doing
>> IMAP and not webmail might not care about JMAP.
>> It is not yet clear to me that JMAP will replace IMAP. But I
>> don't think this is a reason not to let JMAP progress.
> Alexey, I think you are missing the point.
That is entirely possible :-).
> 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.    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.

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.
> Also, if that conversion is not
> absolutely lossless, there will be a large collection of ongoing
> problems, for an equally long time.
There is a single message format, so no need to convert.

Best Regards,
Alexey
> Those _are_  reasons to not let JMAP progress because it could
> easily make the mail system work worse.  Not, as Andrew (and
> several others) have suggested, not a risk we should encourage
> unless the benefits and improvements are significant.
>
>       best,
>        john
>