John and Ned,
On 12/02/2017 20:15, John C Klensin wrote:
> --On Wednesday, February 8, 2017 12:39 -0800 Ned Freed > <ned.freed@xxxxxxxxxxx> 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.
Good.
> 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.
I agree with the assessment, but what if the propsoal changes substantially? That's the case I'm worried about. Ned