Re: [imapext] [ietf-smtp] Request to form a new WG: JMAP
Jacob Palme <jpalme@dsv.su.se> Thu, 17 November 2016 17:47 UTC
Return-Path: <jpalme@dsv.su.se>
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 1029C1299B0; Thu, 17 Nov 2016 09:47:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.841
X-Spam-Level:
X-Spam-Status: No, score=-1.841 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NEUTRAL=0.779] 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 dljUlR_rDEB6; Thu, 17 Nov 2016 09:47:12 -0800 (PST)
Received: from smtprelay-b32.telenor.se (smtprelay-b32.telenor.se [213.150.131.21]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5F8E1299B6; Thu, 17 Nov 2016 09:47:10 -0800 (PST)
Received: from ipb4.telenor.se (ipb4.telenor.se [195.54.127.167]) by smtprelay-b32.telenor.se (Postfix) with ESMTP id E242E87C7F; Thu, 17 Nov 2016 18:47:08 +0100 (CET)
X-SENDER-IP: [84.216.244.191]
X-LISTENER: [smtp.bredband.net]
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2CYAQDT6y1Y/7/02FQNHDEEFgQBAQEBAgEBAQEIAQEBAYM3AQEBAQF3gQCkUJRkggAHHQuFeQKCWhMBAgEBAQEBAQGBTBIBgU+CRAEBAQECAQEBASAERwsFCwsYAgImAgInMAYTGYhLFqwXZ4FsPYthAQEBAQEBAQEBAQEBAQEBAQEBARkFgQmFM4F9CIJVgSUqgkYGCgYCAQUMCoJMOC2CMAWOYYtihkCaU3GMTBOECx8BgRIREQwdgyUcgV5xhQM6gjwBAQE
X-IPAS-Result: A2CYAQDT6y1Y/7/02FQNHDEEFgQBAQEBAgEBAQEIAQEBAYM3AQEBAQF3gQCkUJRkggAHHQuFeQKCWhMBAgEBAQEBAQGBTBIBgU+CRAEBAQECAQEBASAERwsFCwsYAgImAgInMAYTGYhLFqwXZ4FsPYthAQEBAQEBAQEBAQEBAQEBAQEBARkFgQmFM4F9CIJVgSUqgkYGCgYCAQUMCoJMOC2CMAWOYYtihkCaU3GMTBOECx8BgRIREQwdgyUcgV5xhQM6gjwBAQE
X-IronPort-AV: E=Sophos;i="5.31,506,1473112800"; d="scan'208";a="611416476"
Received: from c-bff4d854.022-17-73746f16.cust.bredbandsbolaget.se (HELO [192.168.0.162]) ([84.216.244.191]) by ipb4.telenor.se with ESMTP; 17 Nov 2016 18:47:07 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Jacob Palme <jpalme@dsv.su.se>
In-Reply-To: <01Q7166TP70G011H9Q@mauve.mrochek.com>
Date: Thu, 17 Nov 2016 18:47:07 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <093F7E2F-B932-4272-99DD-1F3F95186D18@dsv.su.se>
References: <1478539079.1706686.780110457.75B1F9CF@webmail.messagingengine.com> <a786d82d-7134-c7bc-24ef-5dfb56e7bbac@isode.com> <01Q7166TP70G011H9Q@mauve.mrochek.com>
To: Ned Freed <ned.freed@mrochek.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/imapext/c_Upyt7DRz4amwzoK_2mk9dO8k0>
Cc: Alexey Melnikov <alexey.melnikov@isode.com>, ietf-smtp@ietf.org, "imapext@ietf.org" <imapext@ietf.org>
Subject: Re: [imapext] [ietf-smtp] 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, 17 Nov 2016 17:47:17 -0000
The MHTML format may be of interest as input to this group. It compiles encapsulation of various parts in MIME-formatted e-mail. See: https://en.wikipedia.org/wiki/MHTML https://tools.ietf.org/html/rfc2557 — Jacob Palme professor emeritus Stockholm University for more info see https://people.dsv.su.se/~jpalme/ > On 07 Nov 2016, at 19:05, Ned Freed <ned.freed@mrochek.com> 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. > >> The JMAP working group will specify an mechanism to allow clients to >> both view and send email from a server over a single stateless HTTPS >> channel with minimal round trips. > > And now we appear to be talking about a replacment for both IMAP and SUBMIT. > This effectively means we're replacing all of the email protocol and format > suite with the exception of SMTP. > >> The protocol will support >> out-of-band signaling of changes, and will give mobile clients >> significant benefits in terms of battery life and network usage. > > And now we appear to be talking about server->client synchronization, which > is, in standards terms at least, new. > >> The use of multiple protocols to perform actions within a single >> application creates significant support challenges, as users may get a >> variety of partial failure modes (for example, can receive email, but >> can not send new messages). This is further exacerbated if the >> different protocols are authenticated separately. > > So we're clearly aiming to replace multiple protocols here. > >> The work of this group is limited to developing a protocol for a client >> synchronising data with a server. > > Whoops! Now we're talking we're limiting ourselves to synchronization of > the client with the server. Which would seem to exclude SUBMIT, unless > you're doing SUBMIT with magic folders and header fields or something > similar. > >> Any server-to-server issues or >> end-to-end encryption of messages are out of scope for this working >> group. > > If you're talking about a new message format, you're going to have > to deal with end-to-end encryption issues whether you like it or not, either > by changing SMTP as well so that message in this new format can in fact > be transmitted end-to-end, by defining an encapsulation format, by allowing > servers to perform gateways, etc. > >> The working group will coordinate with the Security Area on credential >> management and authentication. > > Again, if you're talking about a new message format, this isn't going > to be remotely adequate. > >> Input to working group discussions shall include: > >> - Internet Message Format >> [RFC 5322] > > This also would seem to imply the message format is in play. > >> - CONDSTORE and QRESYNC >> [RFC 7162] > >> - Collection Synchronisation for WebDav >> [RFC 6578] > >> - LEMONADE and experiences from adoption of its output >> [https://datatracker.ietf.org/wg/lemonade/charter/] > >> - SMTP SUBMISSION >> [RFC 4409] > > And SUBMIT is in play. > >> - SMTP BURL >> [RFC 4468] > > Again, I'm not prepared to offer an opinion as to whether or not this whole > thing is a good idea. But I will say that effectively replacing the entire > email protocol suite - which is entirely consistent with what's been said here > - would at a minimum be a tremendous amount of work requiring a tremendous > amount of justification, and what's in this propsoal doesn't come close. > > Ned > > _______________________________________________ > ietf-smtp mailing list > ietf-smtp@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-smtp
- [imapext] Fwd: Request to form a new WG: JMAP Alexey Melnikov
- Re: [imapext] [ietf-smtp] Fwd: Request to form a … John C Klensin
- Re: [imapext] [ietf-smtp] Fwd: Request to form a … Ned Freed
- Re: [imapext] [ietf-smtp] Fwd: Request to form a … John C Klensin
- Re: [imapext] Fwd: Request to form a new WG: JMAP Arnt Gulbrandsen
- Re: [imapext] [ietf-smtp] Fwd: Request to form a … Adrien de Croy
- Re: [imapext] Request to form a new WG: JMAP Julien ÉLIE
- Re: [imapext] [ietf-smtp] Fwd: Request to form a … Doug Royer
- Re: [imapext] [ietf-smtp] Fwd: Request to form a … Ned Freed
- Re: [imapext] [ietf-smtp] Fwd: Request to form a … John C Klensin
- Re: [imapext] [ietf-smtp] Fwd: Request to form a … Arnt Gulbrandsen
- Re: [imapext] [ietf-smtp] Fwd: Request to form a … Alexey Melnikov
- Re: [imapext] [ietf-smtp] Fwd: Request to form a … Alexey Melnikov
- Re: [imapext] [ietf-smtp] Fwd: Request to form a … Doug Royer
- Re: [imapext] [ietf-smtp] Fwd: Request to form a … Ned Freed
- Re: [imapext] [ietf-smtp] Fwd: Request to form a … John C Klensin
- Re: [imapext] [ietf-smtp] Fwd: Request to form a … Neil Jenkins
- Re: [imapext] [ietf-smtp] Fwd: Request to form a … Tony Finch
- Re: [imapext] [ietf-smtp] Fwd: Request to form a … Ned Freed
- Re: [imapext] [ietf-smtp] Fwd: Request to form a … Ned Freed
- Re: [imapext] [ietf-smtp] Fwd: Request to form a … Ted Lemon
- Re: [imapext] [ietf-smtp] Fwd: Request to form a … Doug Royer
- Re: [imapext] [ietf-smtp] Fwd: Request to form a … Ted Lemon
- Re: [imapext] [ietf-smtp] Fwd: Request to form a … Bron Gondwana
- Re: [imapext] [ietf-smtp] Fwd: Request to form a … Ned Freed
- Re: [imapext] [ietf-smtp] Fwd: Request to form a … Ted Lemon
- [imapext] offline mode, was Re: [ietf-smtp] Fwd: … Tony Finch
- Re: [imapext] [ietf-smtp] Fwd: Request to form a … Doug Royer
- Re: [imapext] [ietf-smtp] Fwd: Request to form a … Bron Gondwana
- [imapext] Further discussions of JMAP Alexey Melnikov
- [imapext] I moved to jmap@ietf.org Doug Royer
- Re: [imapext] [ietf-smtp] Request to form a new W… Jacob Palme
- Re: [imapext] offline mode, was Re: [ietf-smtp] F… Brandon Long