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

Dave Crocker <dhc@dcrocker.net> Mon, 13 February 2017 17:30 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 9B6511296DA for <ietf@ietfa.amsl.com>; Mon, 13 Feb 2017 09:30:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.791
X-Spam-Level:
X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" 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 0aIWc5pK5ILT for <ietf@ietfa.amsl.com>; Mon, 13 Feb 2017 09:30:19 -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 61C6C1296D1 for <ietf@ietf.org>; Mon, 13 Feb 2017 09:30:19 -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 v1DHVx3I011227 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 13 Feb 2017 09:32:00 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1487007120; bh=qSggWoCKBzE+kMoZBpV8kzrkBm1gebgU9sD6bRmy7yQ=; h=Subject:To:References:Cc:From:Reply-To:Date:In-Reply-To:From; b=Jjrq/lTfqoKRp00poHs73NX15ffrGAVVY0XEYFPareATeGcLtJmzKoHAuhFvwbb3J LIJ4J3ckCRY4lcJ9H81URqqR5tgzp10y1TO+yY9YnSYme3YUCoQpx1FqPw9fHOIjro XghGrwr0LT/OOt1fuaK0jIW599y44ZhlLt/eYLqQ=
Subject: Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity
To: Dave Cridland <dave@cridland.net>, John C Klensin <john-ietf@jck.com>
References: <3b955910-12d0-2c56-0dc2-30279f98aea5@isode.com> <19fabdd7-77c5-fc13-616e-26d39d2f23df@isode.com> <20170208142241.GB84460@mx4.yitter.info> <217b1d1b-adba-2ebb-30ca-600f8dc77246@isode.com> <32D2801528D191A01AD4D3B2@PSB> <2fa724eb-18ba-b818-6a01-a07db5a9a9a4@isode.com> <01QANBYPRC140005AQ@mauve.mrochek.com> <1162BF5A37921B1555FF29F9@PSB> <CAKHUCzyQSTiLXg9W+ePwwm=B01TNgCN+L729pzP1iZvqG3Kweg@mail.gmail.com>
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Message-ID: <23132594-9f68-d7dc-fe92-6487182d4e59@dcrocker.net>
Date: Mon, 13 Feb 2017 09:30:09 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <CAKHUCzyQSTiLXg9W+ePwwm=B01TNgCN+L729pzP1iZvqG3Kweg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/FTVFTbGbl3AZavc75zSbGU9d2SA>
Cc: Alexey Melnikov <alexey.melnikov@isode.com>, Ned Freed <ned.freed@mrochek.com>, "ietf@ietf.org Discussion" <ietf@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: Mon, 13 Feb 2017 17:30:20 -0000

On 2/13/2017 9:17 AM, Dave Cridland wrote:
> I don't think this is true.
...
> JMAP, on the other hand, can cope with both gmail style labels and
> IMAP-style mailboxes, by stated design.


The constraints/flexibility of an effort depend on the goals it asserts 
and the support for those goals.  I think it's dandy to target an access 
protocol that is substantially different from the 
features/style/whatever of IMAP.  The requirements are to be very clear 
about the features/style/whatever of the new effort, very clear about 
the expected benefits, and very clear about the support for that.

Given the long history of IMAP, the proposed JMAP effort should offer 
clear assertions of the relative differences and benefits of the new 
effort, to aid in assessing likely appeal of the effort.

So, for example, the above comment about JMAP's handling of different 
reference models is substantive and appealing.  However the various 
notes that have been posted about JMAP leave me thinking that there is 
less clarity about the effort than one would like, among JMAP's supporters.

The embodiment of the clarity needs to be the charter text and I don't 
think it's made its case well enough.  For example, I don't see a 
reference to the ability to support different referencing models.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net