ietf
[Top] [All Lists]

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

2017-02-12 14:16:01


--On Wednesday, February 8, 2017 12:39 -0800 Ned Freed
<ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:

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.

To be clear about what I'm concerned about, it isn't that.  My
assumption is that, although there might be exceptions, any
given client will support either one or the other, not both.  I
am concerned about what the servers and message stores need to
support and I think that would likely be "both" for a long time
or those who depend on IMAP clients would suffer gradual but
significant degradation of service.   See below for the latter.
Even if every client created after today supports JMAP only, I
would predict a long transition period.   That isn't really an
objection to the WG, just a request that the charter explicitly
requiring addressing the issue.

Parts of that are irrelevant if the message store supports pure
5322 objects with no metadata, but IMAP requires a certain
amount of metadata, so that, AFAICT, either makes the above
relevant or requires that JMAP support a strict superset on
those metadata in compatible formats.

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.

Yes.  See above.  But note that "JMAP replaces IMAP" requires
that it support identical functionality, be a superset of IMAP
function, or drop only the functions that no one is using or
cares about.  Note that I'm talking about functionality, not
syntax -- there are clearly a number of clumsy constructions in
IMAP that work that way only for historical compatibility
reasons and some cases of multiple ways to do the same thing.
If a new syntax and protocol model were adopted, no one sensible
would continue to defend those IMAP characteristics.

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.

Exactly.  If one expects JMAP to be wildly successful, and
unless there is either a plausible plan to make all of those
IMAP clients go away (even if there are no new ones), I think
that list should include either its being reasonable to
implement and support IMAP/SUBMIT-> JMAP proxies or other
overlays or a charter requirement to discuss residual use cases
for IMAP.    I'm particularly concerned about supporting
IMAP-native clients with a JMAP-native mailstore.

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?

I can't speak for anyone else, but I'm concerned about what it
takes to create and maintain servers and mailstores that are
compatible with both IMAP and JMAP.  If that means proxies, we
either need to address the question of IMAP proxies over JMAP
and JMAP mailstores as well as the JMAP over IMAP-compatible
ones or I'd like the charter is require a good explanation of
why that isn't necessary.  That might be "IMAP-based systems
with JMAP overlays forever", but, the more people argue that
JMAP will take over (rapidly or otherwise), the less plausible
that position feels.

best,
    john

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