|
John and Ned, On 12/02/2017 20:15, John C Klensin wrote: [snip]--On Wednesday, February 8, 2017 12:39 -0800 Ned Freed <ned.freed@xxxxxxxxxxx> wrote: I updated Charter text to mention these.(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'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.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 Regards, Alexey |