John and Ned,
On 12/02/2017 20:15, John C Klensin wrote:
--On Wednesday, February 8, 2017 12:39 -0800 Ned Freed
<ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
[snip]
(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.
I updated Charter text to mention these.
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.
I've done some prototyping of existing JMAP proposal and I am quite
confident that underlying models are close enough that implementing one
on top of another is doable. IMAP+QRESYNC extension require IMAP
mailstores to store change sequence numbers, which is required feature
in JMAP.
Best Regards,
Alexey