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

John C Klensin <john-ietf@jck.com> Thu, 10 November 2016 14:28 UTC

Return-Path: <john-ietf@jck.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 1319D12944D; Thu, 10 Nov 2016 06:28:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.397
X-Spam-Level:
X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] 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 feKTl2wRzTND; Thu, 10 Nov 2016 06:28:58 -0800 (PST)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11075126FDC; Thu, 10 Nov 2016 06:28:58 -0800 (PST)
Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1c4qLX-000Csn-7Y; Thu, 10 Nov 2016 09:28:55 -0500
Date: Thu, 10 Nov 2016 09:28:50 -0500
From: John C Klensin <john-ietf@jck.com>
To: Ned Freed <ned.freed@mrochek.com>, Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <E99C5826138657241662E74E@JcK-HP8200>
In-Reply-To: <01Q74JCZZYFG00Z4TS@mauve.mrochek.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> <01Q74JCZZYFG00Z4TS@mauve.mrochek.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/imapext/xpHAqcsR55VUn51HfyH2ILUuQcg>
Cc: 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 14:28:59 -0000


--On Wednesday, November 09, 2016 19:57 -0800 Ned Freed
<ned.freed@mrochek.com> wrote:

>> > 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.

It is also worth noting that magic folders have been repeatedly
proposed for IMAP and rejected every time, always for reasons
that included the above.  If you decide to charter this, please
let's be sure that there are built-in mechanisms for adequate
review that considers those prior discussions.  In principle,
I'm not opposed to a carefully-considered decision that reaches
a different conclusion, but "carefully-considered" --and not
just by advocates of this work -- is key. 

>From my point of view, we went to the trouble to separate
message submission from SMTP for only two important reasons: to
make it clear what things a submission server could reasonably
do (and be expected to do) that an SMTP relay could not and to
permit (and encourage) a better error-handling model among
cooperating parties.  At least for me, that created a message
creation and submission model that was a partnership between the
creating MUA and a first-hop server, paralleling what we've
often called a "split MUA" model between an IMAP (or POP) server
and client at the receiving end.  Again, if a different model is
really needed --and, so far, I'm not convinced -- those
advocating it should be required to demonstrate to the community
that they understand all the implications of discarding or
bypassing the older one.

best,
     john


> 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.
> 

best,
   john