Re: [imapext] [ietf-smtp] Fwd: Request to form a new WG: JMAP

Ned Freed <ned.freed@mrochek.com> Thu, 10 November 2016 04:13 UTC

Return-Path: <ned.freed@mrochek.com>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C05901288B8; Wed, 9 Nov 2016 20:13:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level:
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-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 FoMA3yvMkcHp; Wed, 9 Nov 2016 20:13:50 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 AD627127071; Wed, 9 Nov 2016 20:13:50 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q74JD3OR9C014IYX@mauve.mrochek.com>; Wed, 9 Nov 2016 20:08:42 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: TEXT/PLAIN; CHARSET="us-ascii"; format="flowed"
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q74BD9SBVK00Z4TS@mauve.mrochek.com>; Wed, 09 Nov 2016 20:08:37 -0800 (PST)
Message-id: <01Q74JCZZYFG00Z4TS@mauve.mrochek.com>
Date: Wed, 09 Nov 2016 19:57:23 -0800
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Wed, 09 Nov 2016 19:03:36 +0000" <b85870ed-86e0-0f97-fece-476399124e81@isode.com>
References: <1478539079.1706686.780110457.75B1F9CF@webmail.messagingengine.com> <a786d82d-7134-c7bc-24ef-5dfb56e7bbac@isode.com> <01Q7166TP70G011H9Q@mauve.mrochek.com> <b85870ed-86e0-0f97-fece-476399124e81@isode.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/imapext/nvhi9x_gmtZrVRF3_bci1I9CydQ>
Cc: Ned Freed <ned.freed@mrochek.com>, ietf-smtp@ietf.org, "'imapext@ietf.org'" <imapext@ietf.org>
Subject: Re: [imapext] [ietf-smtp] Fwd: Request to form a new WG: JMAP
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Nov 2016 04:13:52 -0000

> Hi Ned,

> If this work goes forward, there is definitely some wordsmithing to do
> to address your comments. Quick answers to some of them below:

Sounds good.

> On 07/11/2016 18:05, Ned Freed wrote:
> > Without getting into whether or not this is in general a good idea, I
> > want to
> > note that the proposal as written is self-contradictory, making it very
> > difficult to evaluate. In particular:
> >
> >> Name:    JSON Mail Access Protocol
> >> Acronym: jmap
> >> Area:    Applications and Real-Time Area (art)
> >
> >> Charter for Working Group
> >
> >> Many companies and projects are developing their own JSON based
> >> representations of email which are proprietary, non-standard, and
> >> incompatible with each other. These protocols are proliferating due
> >> to existing standards being insufficient or poorly suited to the
> >> environments they are operating in, particularly mobile and webmail.
> >
> > "Representation of email" would seem to imply that we're talking about
> > a new
> > message format.

> No, the email format is unchanged.

I note in passing that this is actually a departure from some of the
existing APIs, where messages are mapped into and out of JSON at least
some of the time.

> > Whoops! Now we're talking we're limiting ourselves to synchronization of
> > the client with the server.
> Yes, basically the IMAP side of things.
> > Which would seem to exclude SUBMIT, unless
> > you're doing SUBMIT with magic folders

> Most likely, yes.

And as I indicated previously, that's a problem, because magic folder are a
poor means of doing message submission, mostly because of their lousy error
handling.

I'll also note that none of the existing APIs I know of use magic folders. For
example, the Gmail API has two methods to send mail - message.send and
drafts.send, which return the error information you need. And the Outlook API
is very similar except that HTTP POST is used

But this really isn't the time to get into details. My point here is that if
you're going to do message submission, you need to get it right - something
essentially none of the current specifications do -  and that's going to
require an expansion of the model being proposed here.

				Ned