ietf
[Top] [All Lists]

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

2017-02-08 15:09:21
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



<Prev in Thread] Current Thread [Next in Thread>