ietf
[Top] [All Lists]

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

2017-02-08 10:37:29
John,


On 08/02/2017 15:03, John C Klensin wrote:
--On Wednesday, February 8, 2017 14:27 +0000 Alexey Melnikov
<alexey(_dot_)melnikov(_at_)isode(_dot_)com> 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


<Prev in Thread] Current Thread [Next in Thread>