Dave and John, On 08/02/2017 15:33, Dave Crocker wrote: > On 2/8/2017 7:03 AM, John C Klensin wrote: >> However, from the perspective of someone trying to maintain servers >> or a mailstore, the fact that there will be both types of users (for >> a long time if not forever), it implies the need to maintain (and >> configure, support, etc.) both IMAP/SMTP and JMAP facilities in >> parallel and to support, also for a long time, the ability to convert >> between the two formats. Also, if that conversion is not absolutely >> lossless, there will be a large collection of ongoing problems, for >> an equally long time. > > +1 > > This creates a dual-stack operational environment. They always have > real -- and often problematic -- operational effects. > > Given the long-standing complaints about IMAP's complexity, it still > might be worth doing. But as has already been noted, what is required > here is a very compelling value statement that justifies the second > 'stack'. > > The posted list of folk who are expected to implement this helps quite a > bit, IMO. However we seem to be missing the compelling > /technical-operations/ value proposition. Will the resulting protocol > be simpler, more efficient, faster, ... and what is the basis for > asserting such improvements? Neil Jenkins did a very good summary of existing problems and how JMAP is trying to improve over IMAP: <https://www.ietf.org/mail-archive/web/imapext/current/msg05820.html> > On 2/6/2017 7:40 AM, Alexey Melnikov wrote: >> The current proposal is "advancing on the old". It is improving on >> some IMAP use cases > > Where is this explained in the charter -- with enough detail to make it > possible to assess it? This seems to me foundational for the effort's > value proposition. See pointer to Neil's email above. The list of improvements is rather long, so I didn't want to include it in the Charter. Instead, the Charter already says: The working group will deliver the following: - A problem statement detailing the deployment environment and situations that motivate work on a new protocol for client to server email synchronisation. The working group may choose not to publish this as an RFC. This item was intended to cover exactly that. > On 2/8/2017 5:34 AM, Alexey Melnikov wrote: >>> Drafts? What drafts? Perhaps you mean: >>> >>> https://tools.ietf.org/html/draft-jenkins-jmap >>> >>> Except that no draft is cited in the charter. >> >> I realized that I accidentally deleted an important sentence from >> the Charter while doing editing. One of the paragraphs should have >> read: >> >> The work of this group is limited to developing a protocol for a >> client synchronising data with a server. The work will be based on >> draft-jenkins-jmap and draft-jenkins-jmapmail. Any server-to-server >> issues are out of scope for this working group. New end-to-end >> encryption mechanisms are out of scope, but the work should consider >> how to integrate with existing standards such as S/MIME and OpenPGP. > > Ahh. Yes, very helpful. Thanks! > > This then raises a point of nuance about a charter's reference to the > documents that are foundational to a working group effort: indicating > constraints on their role. That is, what is the working group > authorized to do with the document. This can be extremely helpful with > working group management and helping participants to focus. > > Roughly the choices are a continuum between having no constraints -- > the doc is simply used as input and advice -- all the way to only > being permitted to fix bugs and improve editorial writing. > > The text you've provided here says 'based on'. In a more benign > world, clarifying what that means wouldn't be necessary, but in the > current reality, I urge adding text that indicates why degree of > modification the wg is allowed to make on the drafts. I think this is an excellent idea and I will add more text to the charter about constraints/expected changes. Best Regards, Alexey