[Jmap] Best vs Good enough - adoption of JMAP

"Adrien de Croy" <adrien@qbik.com> Mon, 24 April 2017 22:43 UTC

Return-Path: <adrien@qbik.com>
X-Original-To: jmap@ietfa.amsl.com
Delivered-To: jmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72DF2131953 for <jmap@ietfa.amsl.com>; Mon, 24 Apr 2017 15:43:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47Ra0iSzvvfc for <jmap@ietfa.amsl.com>; Mon, 24 Apr 2017 15:43:27 -0700 (PDT)
Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 141FB131954 for <jmap@ietf.org>; Mon, 24 Apr 2017 15:43:26 -0700 (PDT)
Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.5 (Build 5926)) with SMTP id <0001028965@smtp.qbik.com>; Tue, 25 Apr 2017 10:43:24 +1200
From: Adrien de Croy <adrien@qbik.com>
To: "jmap@ietf.org" <jmap@ietf.org>
Date: Mon, 24 Apr 2017 22:43:24 +0000
Message-Id: <em8b177018-4769-44ea-b033-90bd8155d11b@bodybag>
Reply-To: Adrien de Croy <adrien@qbik.com>
User-Agent: eM_Client/7.0.27943.0
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="------=_MB798A9939-F3B3-442A-8A1E-927D711702DC"
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/LPEKhVA6kcGR0C0cHrG5BBERNPA>
Subject: [Jmap] Best vs Good enough - adoption of JMAP
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: JSON Message Access Protocol <jmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jmap>, <mailto:jmap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jmap/>
List-Post: <mailto:jmap@ietf.org>
List-Help: <mailto:jmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jmap>, <mailto:jmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Apr 2017 22:43:29 -0000

On the topic of best vs good enough.  I agree they are perhaps opposed, 
you could say that good enough is the enemy of best however, since once 
you have something that is good enough, your incentive to do any better 
is greatly diminished.

However, we are up against several obstacles when it comes to adoption 
of JMAP.

1. Server authors won't want to add support unless there are clients
2. Client authors won't want to add support unless there are servers
3. Client or server authors won't want to add support unless they can 
make things significantly better for mail users.
4. We are losing customers to alternate messaging systems.

If our target is just going to end up providing no benefits to users 
over what we already have with IMAP+SMTP, then nobody will bother.

Where it gets interesting for me personally at least is if we can push 
the boundary of mail experience.  In many cases this can be done in the 
MUA but in some cases it requires support from the protocols.

I hear the arguments that the more complex we make the spec, the less 
likely it will be implemented, at least correctly. I'm not a fan of 
complexity either, and neither of my suggestions do I consider to be 
particularly complex.

My argument is that if the design doesn't hold out a carrot for better 
mail experience for users, then nobody will bother, and we're wasting 
our time here, which would be a shame because we have the potential to 
achieve a lot here.

At the moment, there is a benefit on the table, mostly being the ability 
to only require configuration of access to 1 service (that's if JMAP 
does submission).

I believe we should be looking for opportunities to make mail the best 
experience possible, come up with ideas, and we may decided to defer 
some or not implement others, but we should keep them in mind so that 
perhaps we don't close off the path to some of them.  We don't need 
another protocol that is hamstrung by lack of foresight.

there are plenty of ideas around, look at the competition.

Cheers

Adrien