--On Wednesday, February 8, 2017 12:39 -0800 Ned Freed
<ned.freed@xxxxxxxxxxx> 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