Re: [imapext] [ietf-smtp] Fwd: Request to form a new WG: JMAP
John C Klensin <john-ietf@jck.com> Mon, 07 November 2016 17:59 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 3CEAE12952E; Mon, 7 Nov 2016 09:59:10 -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 IRUldg6b2woX; Mon, 7 Nov 2016 09:59:07 -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 AE02312948D; Mon, 7 Nov 2016 09:59:07 -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 1c3oCI-000FHz-0E; Mon, 07 Nov 2016 12:59:06 -0500
Date: Mon, 07 Nov 2016 12:59:00 -0500
From: John C Klensin <john-ietf@jck.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>, ietf-smtp@ietf.org, "'imapext@ietf.org'" <imapext@ietf.org>
Message-ID: <56DA516EAC53C07E3F453BA6@JcK-HP8200>
In-Reply-To: <a786d82d-7134-c7bc-24ef-5dfb56e7bbac@isode.com>
References: <1478539079.1706686.780110457.75B1F9CF@webmail.messagingengine.com> <a786d82d-7134-c7bc-24ef-5dfb56e7bbac@isode.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/O4gFZXP6WDddkEduJqRQD1r__go>
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: Mon, 07 Nov 2016 17:59:10 -0000
Alexey, These are just questions, not opposition, but the answers should probably be clear in any charter or chartering effort. (1) We've had a long history of variations on The Format to End All Formats, none of which have lasted a very long time. I think JSON is better than most, but, if yet another wonderful format shows up in a few years and takes over, is it worth thinking now about what a transition plan would look like? (2) Some of us believe, at least on some days, that a key reason why SMTP, the message formats that started with RFC 822, POP3, and IMAP have survived against a large number of proprietary and other SDO alternatives have been precisely because they operate in plain text, with all but IMAP using very simple command-argument or name:value syntax. Are we ready to give that up? Do we really need interoperability between a server and a captive Webmail interface? Arguably, standards of that type are part of the province of the IETF only if someone is contemplating generic webmail clients that can interact with the servers of more than one organization. (3) In terms of email models, this would presumably provides an alternative to IMAP (or maybe POP3) on the mail receiving side. Would it be equally sensible to define an IMAP extension that would deliver responses (and maybe accept requests) in a specified JSON format rather than the LISP-like IMAP one? Seems to me that would promote much more compatibility and flexibility. (4) Similarly, there is lots of practice about use of IMAP to send. Is to time to make sure the standards for that (presumably as an alternative to RFC 6409-style message submission) and then provide a JSON format IMAP option to support this form? Again, just questions, but questions I think we need to ask carefully before standardizing yet another alternative way to do much the same thing. john --On Monday, November 07, 2016 17:31 +0000 Alexey Melnikov <alexey.melnikov@isode.com> wrote: > Hi, > > I am forwarding my email here, as I suspect people on these > two mailing lists might be interested in this. > > Please post your comments/questions to dispatch@ietf.org or > directly to me. > > Best Regards, > > Alexey > > -------- Forwarded Message -------- > Subject: Request to form a new WG: JMAP > Date: Mon, 07 Nov 2016 17:17:59 +0000 > From: Alexey Melnikov <aamelnikov@fastmail.fm> > To: DISPATCH <dispatch@ietf.org> > > > > Hi, > I have received a request to form a new WG: JSON Mail Access > Protocol > (JMAP). Draft charter is included below. Please send your > comments in > reply to this email or directly to me. > > I am also looking for possible chairs for this work, so if you > are > interested, please contact me off-list. > > Thank you, > Alexey > > ------------------------------------ > > 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. > > 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. 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. > > 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. > > The work of this group is limited to developing a protocol for > a client > synchronising data with a server. Any server-to-server issues > or > end-to-end encryption of messages are out of scope for this > working > group. > > The working group will coordinate with the Security Area on > credential > management and authentication. > > Input to working group discussions shall include: > > - Internet Message Format > [RFC 5322] > > - 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] > > - SMTP BURL > [RFC 4468] > > The working group will deliver the following: > > - A problem statement detailing the deployment environment and > situations that motivate work on a new protocol for client > to > server email synchronisation. The working group may choose > not to publish this as an RFC. > > - A document describing an extensible protocol and data > structures which > supports stateless use, flood control and batched > operations. > > - A document describing how to use the extensible protocol > over HTTPS > with the data structures expressed as JSON. > > - A document describing a data model for email viewing, > management, > searching, and submission on top of the extensible protocol. > > - An executable test suite and documented test cases to assist > developers of JMAP servers to ensure they conform to the > specifications. >
- [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