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

Dave Crocker <dhc@dcrocker.net> Tue, 07 February 2017 20:12 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B876129579; Tue, 7 Feb 2017 12:12:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net
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 HQ_uBgjY1rsJ; Tue, 7 Feb 2017 12:12:42 -0800 (PST)
Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0700E1294AB; Tue, 7 Feb 2017 12:12:42 -0800 (PST)
Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v17KEJQ6017221 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 7 Feb 2017 12:14:20 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1486498460; bh=EMgmRx/oNDJcCwpoixrc4Ot1rtspvWSaST1Qe839Ztg=; h=Subject:To:References:Reply-To:Cc:From:Date:In-Reply-To:From; b=kscXkCpr103bHivOHbi1QchPGIRnfYU9MM4oPaZhq04DVMA2mB1k8ZBjht76bgjl5 a3M0fZKZYXO4IdVbuZ4Lhge6+qDhL6x7vNCvCThpHMj6NMmSZxviku05aY5YRz3M3U yN4uSBs80dui1w4PqQLNm9YSzK4GvAPaiTeHjiPc=
Subject: Re: Fwd: Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity
To: Gren Elliot <fatkudu@gmail.com>, ietf@ietf.org
References: <CAMQk0F-6CFLHKvTxSaPV20Lp-hVOSSk_WrHOGq6-LOUO8aDNww@mail.gmail.com>
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Message-ID: <b83068ad-602b-8feb-f808-35befd13ae29@dcrocker.net>
Date: Tue, 07 Feb 2017 12:12:31 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <CAMQk0F-6CFLHKvTxSaPV20Lp-hVOSSk_WrHOGq6-LOUO8aDNww@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/2eqTpAmUOWoRp51ZLBQLKf3AYyM>
Cc: jmap@ietf.org, iesg@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Feb 2017 20:12:43 -0000

On 2/7/2017 7:38 AM, Gren Elliot wrote:
> You will either be using IMAP/SMTP to access your mail/submit your
> messages or you will be using JMAP.  If you have the option of the
> latter, you’ve just halved the number of things that need configuring.


The primary argument being put forward here is simplification of 
end-user configuration effort.

While that has an intuitive appeal, a basic question for any effort to 
replace and existing technology is how big the benefit will be and for 
how much of the market?

In this case, for most people, the configuration effort is quite rare. 
So while it might be a bit of a hassle, it has no effect on daily life.

Well, ok, there are some folk who have to make this change more often, 
due to Draconian and misguided local policies -- the current advice 
about password changes, from the UX community, is not to make changes 
often, since this becomes a serious attack surface.

But how large a community is this and why is this problem not mitigated 
simply by having the user interface take one password specification and 
map it to the two, underlying (and existing) protocols?

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net