From nobody Mon Mar 6 08:06:47 2017 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C23671299B9; Fri, 3 Mar 2017 15:55:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148858532479.15846.4933861378120974765.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 15:55:24 -0800 Archived-At: X-Mailman-Approved-At: Mon, 06 Mar 2017 08:06:46 -0800 Cc: jmap@ietf.org, aamelnikov@fastmail.fm Subject: [Jmap] jmap - Requested session has been scheduled for IETF 98 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 23:55:25 -0000 Dear Cindy Morgan, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. jmap Session 1 (1:30:00) Thursday, Afternoon Session II 1520-1720 Room Name: Zurich G size: 115 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: JSON Mail Access Protocol Area Name: Applications and Real-Time Area Session Requester: Cindy Morgan Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: dispatch httpbis core uta cfrg Second Priority: cdni tls People who must be present: Alexey Melnikov Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Mar 16 06:16:16 2017 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F191294BF; Thu, 16 Mar 2017 06:16:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Cc: jmap@ietf.org, jmap-chairs@ietf.org, The IESG MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <148967016879.14173.4104049637598935178.idtracker@ietfa.amsl.com> Date: Thu, 16 Mar 2017 06:16:08 -0700 Archived-At: Subject: [Jmap] WG Action: Formed JSON Mail Access Protocol (jmap) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 13:16:09 -0000 A new IETF WG has been formed in the Applications and Real-Time Area. For additional information, please contact the Area Directors or the WG Chair. JSON Mail Access Protocol (jmap) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: Bron Gondwana Assigned Area Director: Alexey Melnikov Applications and Real-Time Area Directors: Ben Campbell Alissa Cooper Alexey Melnikov Mailing list: Address: jmap@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/jmap Archive: https://mailarchive.ietf.org/arch/search/?email_list=jmap Group page: https://datatracker.ietf.org/group/jmap/ Charter: https://datatracker.ietf.org/doc/charter-ietf-jmap/ A number of JSON-based email access protocols have been developed that 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 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 cannot send new messages). This is further exacerbated if the different protocols are authenticated separately. JMAP specifies the interactions between email clients and mail stores, providing an alternative to IMAP and SMTP submission. The JMAP working group will specify a mechanism to allow clients to both view and send email from a server over a single HTTPS channel with minimal round trips. A single protocol for receipt and submission will resolve long- standing difficulties users face setting up clients to talk to servers. The protocol will support push notification of changes using the mechanism defined in RFC 8030. This will give mobile clients benefits in terms of battery life and network usage. It will also support push notifications via server-sent events (https://www.w3.org/TR/eventsource/) for direct connection to clients that can support persistent TCP connections. Work on JMAP will be bound by the following constraints: 1) The protocol will operate on RFC 5322/MIME (RFC 2045-2047, etc.) message objects or information extracted from them. 2) JMAP needs to be implementable on top of an IMAP server, which also supports IMAP extensions specified below. The JMAP data model needs to remain backwards compatible with the IMAP mailstore model (where a message is always associated with a single mailbox), but it might support other underlying models (e.g. Gmail-style labels). The Working Group will discuss and document how a single server or proxy implementation can implement both IMAP and JMAP at the same time. 3) "Email submission by placing into designated outbox mailbox" will take into consideration extensive IMAPEXT mailing list discussions on message submission through IMAP. 4) The work of this group is limited to developing a protocol for a client synchronising data with a server. Any server-to-server issues are out of scope for this working group. 5) New end-to-end encryption mechanisms are out of scope, but the work should consider how to integrate with existing standards such as S/MIME and OpenPGP. 6) The working group will coordinate with the Security Area on credential management and authentication. The work will be based on draft-jenkins-jmap and draft-jenkins-jmapmail. Note that consensus is required both for changes to the current protocol mechanisms and retention of current mechanisms. In particular, because something is in the initial document set does not imply that there is consensus around the feature or around how it is specified. However gratuitous changes to proposed design should be avoided. Input to working group discussions shall include: - CONDSTORE and QRESYNC [RFC 7162] - Collection Synchronisation for WebDav [RFC 6578] - IMAP SPECIAL-USE [RFC 6154] - IMAP SORT and THREAD Extensions [RFC 5256] - LEMONADE and experiences from adoption of its output [https://datatracker.ietf.org/wg/lemonade/charter/] - SMTP SUBMISSION [RFC 6409] - 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, with support for 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. - A document describing how JMAP to IMAP/SUBMIT proxies can be implemented. Among different considerations, the document will cover security considerations involved in operating such a proxy. - A document describing how a dual IMAP and JMAP server implementation can be done. This can be combined with the above document, if that makes sense. - An executable test suite and documented test cases to assist developers of JMAP servers to ensure they conform to the specifications. Milestones: Jun 2017 - Submit detailed problem statement, if desired by the WG (Informational) Dec 2017 - Submit document describing generic protocol and data structures (Standards Track) Dec 2017 - Submit document describing mail data model and protocol (Standards Track) Mar 2018 - Submit document with guidance for implementation of IMAP servers and proxies (Informational) From nobody Wed Mar 29 10:20:54 2017 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 203891293E4; Tue, 28 Mar 2017 10:53:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149072363611.1189.14769846185748663461@ietfa.amsl.com> Date: Tue, 28 Mar 2017 10:53:56 -0700 Archived-At: X-Mailman-Approved-At: Wed, 29 Mar 2017 10:20:49 -0700 Subject: [Jmap] I-D Action: draft-ietf-jmap-core-00.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 17:53:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol of the IETF. Title : JSON Meta Application Protocol Author : Neil Jenkins Filename : draft-ietf-jmap-core-00.txt Pages : 42 Date : 2017-03-28 Abstract: This document specifies a protocol for synchronising JSON-based data objects efficiently, with support for push and out-of-band binary data upload/download. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-core/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-core-00 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-core-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 29 10:21:00 2017 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF71120046; Tue, 28 Mar 2017 10:54:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149072368921.1291.4352566913940367777@ietfa.amsl.com> Date: Tue, 28 Mar 2017 10:54:49 -0700 Archived-At: X-Mailman-Approved-At: Wed, 29 Mar 2017 10:20:49 -0700 Subject: [Jmap] I-D Action: draft-ietf-jmap-mail-00.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 17:54:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol of the IETF. Title : JMAP for Mail Author : Neil Jenkins Filename : draft-ietf-jmap-mail-00.txt Pages : 62 Date : 2017-03-28 Abstract: This document specifies a data model for synchronising email data with a server using JMAP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-mail/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-mail-00 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-mail-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Mar 31 16:23:19 2017 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A31B3127863 for ; Fri, 31 Mar 2017 16:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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=dcrocker.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 SAO7ERO9ZDtj for ; Fri, 31 Mar 2017 16:23:16 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 374AF127078 for ; Fri, 31 Mar 2017 16:23:16 -0700 (PDT) Received: from [192.168.1.158] (50-232-11-130-static.hfc.comcastbusiness.net [50.232.11.130]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v2VNPM7I012933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 31 Mar 2017 16:25:22 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1491002722; bh=NqKY3HbqiWdeePS6+tfwI5zCPhoLQsNgCLsCvhml/qI=; h=Subject:References:Reply-To:From:To:Date:In-Reply-To:From; b=Nogos2eJd16X7x83rC+BUnZxgQ3a47u1U9oVXLOVWS0Ebv2jjekwqDBDtwKkD8bzv 4FdSwpFd+TR/jXFX2mV90PgbEd1A1b5emLCcheC24mcT5phdiakksXLh+KmHcNXo5Q KjRkBsEKQ2SEc3SnB6saQodBwMdbPiwLhzD8UtXM= References: <148716911729.17277.15371202023742081890.idtracker@ietfa.amsl.com> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking To: jmap@ietf.org Message-ID: Date: Fri, 31 Mar 2017 18:23:13 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <148716911729.17277.15371202023742081890.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Jmap] message vs. annotation X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 23:23:18 -0000 G'day, The working group meeting discussion about a static message, dynamic annotation, etc., resonated with a variety of similar discussions I've been around over the years (dating back to the mid-1970.) A simpler version equates the constructs of message and document, as two views of the same thing. (Ie, Document with attributes; Message with a body.) The essence is to consider the nature and relationship of the objects, possibly permitting different semantics for the same set of objects, according to different applications or roles. That is, there can be a variety of constituent objects that are associated and can be viewed according to different semantics (or views)... So a message, a document, a calendar entry, a series of comments, etc. Each object has associated processing rules (eg, static vs. editable vs. executable; constrained choice of values; organization into folders or other schemas...) An environment like this can be powerful and very appealing. The challenge tends to be staying practical: With no effort at all it devolves into an abstract computer science exercise. Some of that is an efficiency issue(*) but I think it's mostly about the human manageability for design and operations. Based on both the years of commercial use and the public commentary about the performance, I've no doubt the fastmail system does not suffer these downsides. But it's a potential that this re-casting through the IETF could easily suffer. I'm posting this note partly because I think it would exciting to produce specs that permit a degree of flexibility that such an approach permits, but also wanted to cite the dangers. At the moment, I'm guessing there needs to be a small number of basic object types and a small number of 'relationship' types that define the association between objects. These could then be combined into higher-order, formal organizations/semantics the define an application semantic (mail, calendar, whatever.) d/ (*) A system I did in 1977 has a little bit of this and the extremely pure design produced impressively horrible performance. -- Dave Crocker Brandenburg InternetWorking bbiw.net