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

Dave Cridland <dave@cridland.net> Mon, 13 February 2017 19:52 UTC

Return-Path: <dave@cridland.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 5016812989C for <ietf@ietfa.amsl.com>; Mon, 13 Feb 2017 11:52:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=cridland.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 J5YJzJdgp_zo for <ietf@ietfa.amsl.com>; Mon, 13 Feb 2017 11:52:23 -0800 (PST)
Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D58912986D for <ietf@ietf.org>; Mon, 13 Feb 2017 11:52:22 -0800 (PST)
Received: by mail-wr0-x233.google.com with SMTP id 89so157991821wrr.2 for <ietf@ietf.org>; Mon, 13 Feb 2017 11:52:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=cv+T+WNVovI/7qmnobA/lN7r+fnLKnmaaJNkuJ/zmTs=; b=jb3UbsrL2DqXHxDIXkc8pQ05k0v9SJOk1QRmfOWIaSuQCf6Yl0WrD1To4dWEuFkMCx VlcIWHDcLI9OBEGmuxRgnKN1BJXgJmPnJWsHhlZ/1gpvy10u178oEYiwWDtlE4lD4hxS oKAuki/ZqgEkTgm+igjmWoXWC9DL0NcW8UX3g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=cv+T+WNVovI/7qmnobA/lN7r+fnLKnmaaJNkuJ/zmTs=; b=qieX0pJTiQsuYxIe9LEZm68j+CFx2xzkpttkyOvK/oVy8iqoHHxZsEwcyMHGQxvyZq X3GKjzNoSuKWDYZMu83UhdwjBn4PvAfGCq8gyJHaQkf3ayKdKLPgWs5tPxKrg7N2R+5Z abqPh3ZbBBbJThmqnKdE6Jacq9FHkCYVgSPusgt9U/ZyuHLBHOwYCplpaCMi+Vqd6JNg yicSWi010tO7a3MttzPTPu9SdkMexd5+Vb6usd5gMURLsIb5SqHEK3j96pStlZOB2CtV AySxnwfTALJzeLnaNYXlxAPiQq7X3gyQbRl9DRaodH54IFUPC72Pfbyg/gpcoIsU1eNG nQZQ==
X-Gm-Message-State: AMke39ljKmB32gS54orlUUwPEfvnpI3Y5lRmJE4FvwumM95tyCCsfGLvvXOHuynBrM8Z7eSls+Eze8wdrnb2W022
X-Received: by 10.223.152.2 with SMTP id v2mr21418025wrb.109.1487015540436; Mon, 13 Feb 2017 11:52:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.136.199 with HTTP; Mon, 13 Feb 2017 11:52:19 -0800 (PST)
In-Reply-To: <E555C5F4-2B61-4705-B62C-998769E5FC1D@fugue.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> <E555C5F4-2B61-4705-B62C-998769E5FC1D@fugue.com>
From: Dave Cridland <dave@cridland.net>
Date: Mon, 13 Feb 2017 19:52:19 +0000
Message-ID: <CAKHUCzzToOM4YAeeJTdiqx4av2JMuFP1Vgo1-XLVQJBs11vuiA@mail.gmail.com>
Subject: Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity
To: Ted Lemon <mellon@fugue.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/L-EMRbNEvaVTa087iM7EGwdJf2M>
Cc: John C Klensin <john-ietf@jck.com>, 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
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 19:52:25 -0000

On 13 February 2017 at 18:48, Ted Lemon <mellon@fugue.com> wrote:
> On Feb 13, 2017, at 12:17 PM, Dave Cridland <dave@cridland.net> wrote:
>
> If JMAP is to supplant IMAP - and I think that's a worthy goal even if
> its likelihood remains a matter for debate - then JMAP has to support
> the same model.
>
> The model of IMAP is that:
>
> * Each message resides in a single mailbox,
> * Each message has a set of independent flags,
> * Each message is immutable.
>
>
> This would be unfortunate.  The "mailbox" paradigm really doesn't work
> well—as someone mentioned earlier in this thread, it makes synchronization
> needlessly slow and painful, and it also restricts the end user's ability to
> tag messages with more than one meaning.
>

I'm not claiming it's a good model, or even (see John's messages) that
this precludes any other model being made to fit. But I *am* asserting
this is the model around which IMAP was designed. In fact, I could go
further and suggest that at least some portions of the IMAP design
assume that a mailbox is embodied by a single file, but workarounds
for that issue have been long-implemented in the community. And other
models are possible to expose with greater or lesser degrees of
fidelity.

When gmail, for example, exposes its mailstore over IMAP, it does so
by playing fast and loose (and often loose) with the IMAP model. So
messages are visible in multiple mailboxes, but there's no method
exposed within IMAP that allows a client to understand that - to the
client, they're distinct messages with the same content. Flags (or
labels, which are exposed as mailbox names) change on all the copies
in step, but the copies remain copies, from an IMAP perspective.

Within JMAP, the semantics available are a proper superset of IMAP, so
while the IMAP model can be exposed, so can a more gmail-like concept
wherein the same message can appear in multiple mailboxes, for
example. This means, as a casual observation, that the JMAP model (and
therefore protocol) can be used to expose nearly every mailstore
available. Curiously, this was the driver behind some of IMAP's design
choices at the time.

I'd recommend, if you're interested in the differences between the
JMAP and IMAP models, to go look at the https://jmap.io site, which
explains them very thoroughly.

I'd note in passing that I was deeply skeptical of JMAP initially, and
I've been persuaded by solid technical argument as well as market
pressures. I'd be curious about concrete issues rather than
hypothetical issues.

Dave.