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

[Alexey Melnikov <[e-mail]>]

John and Ned,

On 12/02/2017 20:15, John C Klensin wrote:

> --On Wednesday, February 8, 2017 12:39 -0800 Ned Freed
> <[e-mail]>  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