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

[Dave Crocker <[e-mail]>]

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