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?
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.
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.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net