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

[[e-mail]]

> 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