From nobody Mon Feb 6 11:25:33 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 3D74E129471; Mon, 6 Feb 2017 11:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-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 PRNybIS64PZS; Mon, 6 Feb 2017 11:25:24 -0800 (PST) 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 6344E12950B; Mon, 6 Feb 2017 11:25:24 -0800 (PST) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v16JR2k8022994 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 6 Feb 2017 11:27:02 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1486409222; bh=FF0cLK87WZq2XNAAewc3vTz0lPGDObJbtIVLBebigAI=; h=Subject:To:References:Cc:From:Reply-To:Date:In-Reply-To:From; b=olLciwATfLs4s7MExqj+vED+42/1J7Pug3ikowFbK6YruUHr8riULkUgxhaCzzXkz mYb4aSmPo/futh/+E5AwGcoI3H37lP7hFEGXQOwKDQaNZwLyAN8Q4Dd5kRetUigLmS xR3NC6WTcpFoAb13wDiYMy+mstj4211koDYg8xdM= To: ietf@ietf.org, jmap@ietf.org References: <148616796247.4079.7104562493351135409.idtracker@ietfa.amsl.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <11e900d0-553e-0635-06f4-8510bd80ecfd@dcrocker.net> Date: Mon, 6 Feb 2017 11:25:15 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <148616796247.4079.7104562493351135409.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: iesg Subject: Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 19:25:31 -0000 On 2/3/2017 4:26 PM, The IESG wrote: > A new IETF WG has been proposed in the Applications and Real-Time Area. A November version of this charter was circulated and while there have been some changes to produce the current draft charter, some issues noted earlier have not been reflected here (and did not receive comments in November.) > JSON Mail Access Protocol (jmap) > ----------------------------------------------------------------------- > Current status: Proposed WG > > Chairs: > TBD > > 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 representations of email 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. From my November comments: As with others, I take 'representations' to mean formats. And given what JSON is[0] that seems an appropriate interpretation even without that word. So I take this asserted need as having a form of email data format that is an alternative to RFC 5322/MIME. Prior to chartering, we should document just how extensive the current problem of multiple JSON email formats is, to establish the practical benefit of unifying it. The theoretical benefit should be obvious, but that's not enough to justify the cost of a working group. We should establish real market need. Having spent quite a bit of my early career on email gatewaying, I'll comment that getting a common interchange format is especially powerful. The active protocols aren't irrelevant, but stabilizing the message object itself is, IMO, far more important. I'm more than a little biased about this strategic approach: It provided the unifying base for email, during the Internet's early growth into commercial markets. And it happens that focusing on this narrow requirement permits end-to-end -- and I mean the real kind: author to recipient, not just originating operator to receiving operator -- benefits without having to change the infrastructure, other than insertion of gateways. Working groups need task serialization. So I'll suggest that having an effort to standardize an JSON representation of an RFC5322/MIME object would be the highest-leverage first task. Adding to this: JSON is a meta-format. It isn't a 'protocol'. Something encoded in JSON is a format, not a protocol. Hence one of the tasks apparently being chartered would be to create a new message access protocol, encoded in JSON. While that might be worth doing, there needs to be clarity that this is more than a 'representation'. There also needs to be clarity about the relationship between the JSON encodings and the encodings in 'native' Internet Mail. > 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. From my November comments: There is no justification given for this approach. For each activity, there needs to be a clear and solid need documented, based on actual industry activities or at least industry statements. Besides clarifying /what/ needs doing, it should serve to indicate likely industry uptake after the work is done. Adding to this: The IETF email technical community looked at the question of making email submission part of IMAP or keeping it separate. It took an entire year to debate this point extensively and (imo) constructively, and decided to keep them separate. The current charter draft appears to have decided otherwise, but offers only the barest of justifications, which I suspect has not factored in the earlier evaluation. > The JMAP working group will specify a mechanism to allow clients to > both view and send email from a server over a single stateless 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. > > 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. > 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. Why not TLS, also? ... > 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, and operating over > a stateless connection such as HTTPS. 'flood control'? what does this mean, since I assume the target protocol won't be using a flooding algorithm. If it really means 'congestion control', that's not typically part of an application protocol, so why would it be an issue here? From the November comments Since client/server email access typically benefits from having the server retain state about the client's activities, I can't tell whether this actually means stateless lower-level transport or whether it really does mean a stateless email protocol. So this needs to be made much more clear, as to the what and the why, as well as to the benefit that will accrue. Given the considerable complexity of HTTP, I continue to fail to see why making it be a universal, lower-layer transport is so popular. Again, the need and the benefit need to be documented. Adding to this: HTTP/HTTPS are not stateless, since they are connection-based. > - 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. From the November comments: This last is useful, but I think it's not typically an IETF work product? d/ [0] http://www.json.org/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Feb 6 11:42:08 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 7645F129478; Mon, 6 Feb 2017 11:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 yuzOZHMQ9gEF; Mon, 6 Feb 2017 11:41:59 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD6C129458; Mon, 6 Feb 2017 11:41:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1486410118; d=isode.com; s=june2016; i=@isode.com; bh=MREtn65r3SpwC8tbGiEeDlVVZMhD8aUefQQ6alGndcU=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=nsfHCJDcNk6rcN8Sw7MwtApGub3iTzkI+SDPDRV6C1aExr6XN1DZSIGFf/709W71LuxYOx 94X/ccpGrRZyJvSISqVcXdt+6ZjDBy6FzoecuStzal8/kslTaQgtsw5llSs4NI7QXfcnIB PiBJ72n5em5bpA2QEkRwLNNDxEY1IFQ=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 6 Feb 2017 19:41:58 +0000 To: dcrocker@bbiw.net, ietf@ietf.org, jmap@ietf.org References: <148616796247.4079.7104562493351135409.idtracker@ietfa.amsl.com> <11e900d0-553e-0635-06f4-8510bd80ecfd@dcrocker.net> From: Alexey Melnikov Message-ID: <4ff42a3b-1f8e-3e25-14e7-b1d3ed2f69c2@isode.com> Date: Mon, 6 Feb 2017 19:41:57 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 In-Reply-To: <11e900d0-553e-0635-06f4-8510bd80ecfd@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: iesg Subject: Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 19:42:01 -0000 Hi Dave, I am mostly proxying proponents of the Charter, but I did some editing pass over it, so I am replying to some of your comments. On 06/02/2017 19:25, Dave Crocker wrote: > On 2/3/2017 4:26 PM, The IESG wrote: >> A new IETF WG has been proposed in the Applications and Real-Time Area. > > A November version of this charter was circulated and while there have > been some changes to produce the current draft charter, some issues > noted earlier have not been reflected here (and did not receive > comments in November.) > > >> JSON Mail Access Protocol (jmap) >> ----------------------------------------------------------------------- >> Current status: Proposed WG >> >> Chairs: >> TBD >> >> 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 representations of email 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. > > From my November comments: > > As with others, I take 'representations' to mean formats. And > given what JSON is[0] that seems an appropriate interpretation even > without that word. So I take this asserted need as having a form of > email data format that is an alternative to RFC 5322/MIME. > > Prior to chartering, we should document just how extensive the > current problem of multiple JSON email formats is, to establish the > practical benefit of unifying it. The theoretical benefit should be > obvious, but that's not enough to justify the cost of a working group. > We should establish real market need. > > Having spent quite a bit of my early career on email gatewaying, > I'll comment that getting a common interchange format is especially > powerful. The active protocols aren't irrelevant, but stabilizing the > message object itself is, IMO, far more important. I'm more than a > little biased about this strategic approach: It provided the unifying > base for email, during the Internet's early growth into commercial > markets. And it happens that focusing on this narrow requirement > permits end-to-end -- and I mean the real kind: author to recipient, > not just originating operator to receiving operator -- benefits > without having to change the infrastructure, other than insertion of > gateways. > > Working groups need task serialization. So I'll suggest that > having an effort to standardize an JSON representation of an > RFC5322/MIME object would be the highest-leverage first task. I don't think there is intent to specify full mapping of RFC5322/MIME to JSON. IMAP has BODYSTRUCTURE element that contains parsed representation of message structure and most commonly used header fields for different body parts. The intent is to do the same here. Additionally, it is still possible to retrieve full RFC5322/MIME payloads over JMAP. I have tried to reflect your comments in the Charter, but I struggled a bit. If you can suggest how to make the above clearer, that would be much appreciated. > > Adding to this: > > JSON is a meta-format. It isn't a 'protocol'. Something encoded in > JSON is a format, not a protocol. Hence one of the tasks apparently > being chartered would be to create a new message access protocol, > encoded in JSON. While that might be worth doing, there needs to be > clarity that this is more than a 'representation'. No, it is a representation. See above. > There also needs to be clarity about the relationship between the JSON > encodings and the encodings in 'native' Internet Mail. See drafts (and above). > >> 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. > > From my November comments: > > There is no justification given for this approach. For each > activity, there needs to be a clear and solid need documented, based > on actual industry activities or at least industry statements. > Besides clarifying /what/ needs doing, it should serve to indicate > likely industry uptake after the work is done. I am not sure what kind of justification is needed. This is a clear deployment problem. > Adding to this: > > The IETF email technical community looked at the question of making > email submission part of IMAP or keeping it separate. It took an > entire year to debate this point extensively and (imo) constructively, > and decided to keep them separate. The current charter draft appears > to have decided otherwise, but offers only the barest of > justifications, which I suspect has not factored in the earlier > evaluation. There was a followup discussion about doing an IMAP extension for submission and how it should look like to remain compatible with SMTP Submission. I don't think this is an attempt to just ignore earlier discussions. >> The JMAP working group will specify a mechanism to allow clients to >> both view and send email from a server over a single stateless 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. >> >> 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. >> 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. > > Why not TLS, also? TLS is assumed. I think the Charter text says HTTPS elsewhere. > > > ... > >> 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, and operating over >> a stateless connection such as HTTPS. > > 'flood control'? what does this mean, since I assume the target > protocol won't be using a flooding algorithm. If it really means > 'congestion control', that's not typically part of an application > protocol, so why would it be an issue here? > > From the November comments > > Since client/server email access typically benefits from having > the server retain state about the client's activities, I can't tell > whether this actually means stateless lower-level transport or whether > it really does mean a stateless email protocol. Stateless lower level transport. The addition of "such as HTTPS" was trying to make this clearer. > So this needs to be made much more clear, as to the what and the why, > as well as to the benefit that will accrue. > > Given the considerable complexity of HTTP, I continue to fail to > see why making it be a universal, lower-layer transport is so popular. > Again, the need and the benefit need to be documented. Presence of tools for manipulating JSON and ease of development. This was mentioned on the JMAP mailing list. I don't think this needs to be said here. > Adding to this: > > HTTP/HTTPS are not stateless, since they are connection-based. Yeah, I struggled with this a bit. Each request/response can be sent on a separate connection and it is stateless in that sense. > >> - 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. > > From the November comments: > > This last is useful, but I think it's not typically an IETF work > product? I don't mind deleting this, but I would like to see if IESG approves this as is ;-). Best Regards, Alexey > > > > d/ > > [0] http://www.json.org/ From nobody Mon Feb 6 12:04:51 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 CBB75129411; Mon, 6 Feb 2017 12:04:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 JTcPHgvBn23l; Mon, 6 Feb 2017 12:04:43 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5CAB12960E; Mon, 6 Feb 2017 12:04:42 -0800 (PST) Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.4 (Build 5913)) with SMTP id <0000957243@smtp.qbik.com>; Tue, 07 Feb 2017 09:04:39 +1300 From: "Adrien de Croy" To: "Alexey Melnikov" , "dcrocker@bbiw.net" , "ietf@ietf.org" , "jmap@ietf.org" Date: Mon, 06 Feb 2017 20:04:39 +0000 Message-Id: In-Reply-To: <4ff42a3b-1f8e-3e25-14e7-b1d3ed2f69c2@isode.com> User-Agent: eM_Client/6.0.24928.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: iesg Subject: Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Adrien de Croy List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 20:04:45 -0000 >>Adding to this: >> >> HTTP/HTTPS are not stateless, since they are connection-based. A lot of the people on the HTTP WG would have an issue with this=20 statement. In fact there has been a lot of discussion about the evils of=20 connection-oriented anything in regard to HTTP, especially around=20 authentication (e.g. NTLM). There are proxies that reuse upstream connections between different=20 clients, the protocol (1.1 at least) is designed to be stateless in=20 terms of each message being independent of others, whether on the same=20 connection or not. So I wouldn't start a new protocol based on the presumption that=20 HTTP/HTTPS is connection-oriented and not stateless. >> From nobody Mon Feb 6 12:12:05 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 F3BA91294A6; Mon, 6 Feb 2017 12:11:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-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 4PujrhF4OTw3; Mon, 6 Feb 2017 12:11:57 -0800 (PST) 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 65E16129606; Mon, 6 Feb 2017 12:11:57 -0800 (PST) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v16KDYbh026375 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 6 Feb 2017 12:13:34 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1486412015; bh=KbTWi4RP2Dd3wyRANIzfL4FFE7v9hCmbETFL7/4fKh8=; h=Subject:To:References:Cc:From:Reply-To:Date:In-Reply-To:From; b=PiWkaid2hPyYo8cmGGApLGB78oPMajC90V7JbAPMA/I8jmNBaPnPSSThtznpBLm+c ayC5iEJo+g2dwFsu+P4MxAB94oPkTWrdiBboc+Aw5LCsR6/VM75j2tXIF2yy4lN9O5 DklvWgaKfWQCv+lNW+vl6P7wtFZJODJxPRwv2e7A= To: Alexey Melnikov References: <148616796247.4079.7104562493351135409.idtracker@ietfa.amsl.com> <11e900d0-553e-0635-06f4-8510bd80ecfd@dcrocker.net> <4ff42a3b-1f8e-3e25-14e7-b1d3ed2f69c2@isode.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <368f2b68-8f10-9517-1edb-d213ff10563b@dcrocker.net> Date: Mon, 6 Feb 2017 12:11:47 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <4ff42a3b-1f8e-3e25-14e7-b1d3ed2f69c2@isode.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: jmap@ietf.org, ietf@ietf.org, iesg Subject: Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 20:11:59 -0000 Alexey, thanks for the quick followup. inline... On 2/6/2017 11:41 AM, Alexey Melnikov wrote: >> Working groups need task serialization. So I'll suggest that >> having an effort to standardize an JSON representation of an >> RFC5322/MIME object would be the highest-leverage first task. > I don't think there is intent to specify full mapping of RFC5322/MIME to > JSON. IMAP has BODYSTRUCTURE element that contains parsed representation > of message structure and most commonly used header fields for different > body parts. The intent is to do the same here. > Additionally, it is still possible to retrieve full RFC5322/MIME > payloads over JMAP. This highlights the need to have far more clarity about what specific work is to be done and what is not. The existing text has some generic out-of-scope text, but nothing as frankly useful as your above comment. Given that comment, I can't text what parts of the resulting jmap service will use 'native' Internet Mail technical details and what parts will be new-for-JSON. > I have tried to reflect your comments in the Charter, but I struggled a > bit. If you can suggest how to make the above clearer, that would be > much appreciated. I make a point of offering candidate text when I think I understand the context and needs well enough. Unfortunately I don't have that here. Hence, questions and general suggestions is the best I can offer. Sorry. >> Adding to this: >> >> JSON is a meta-format. It isn't a 'protocol'. Something encoded in >> JSON is a format, not a protocol. Hence one of the tasks apparently >> being chartered would be to create a new message access protocol, >> encoded in JSON. While that might be worth doing, there needs to be >> clarity that this is more than a 'representation'. > No, it is a representation. See above. As soon as one says that the task is client/server interaction, one is declaring the goal of a protocol. So it is more than just a format (representation.) >> There also needs to be clarity about the relationship between the JSON >> encodings and the encodings in 'native' Internet Mail. > See drafts (and above). Drafts? What drafts? Perhaps you mean: https://tools.ietf.org/html/draft-jenkins-jmap Except that no draft is cited in the charter. >>> 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. >> >> From my November comments: >> >> There is no justification given for this approach. For each >> activity, there needs to be a clear and solid need documented, based >> on actual industry activities or at least industry statements. >> Besides clarifying /what/ needs doing, it should serve to indicate >> likely industry uptake after the work is done. > > I am not sure what kind of justification is needed. This is a clear > deployment problem. As I said, there was a year-long, serious and diligent debate about this in the IETF and it came to a different conclusion. So it's not nearly as 'clear' as you are asserting. >> Adding to this: >> >> The IETF email technical community looked at the question of making >> email submission part of IMAP or keeping it separate. It took an >> entire year to debate this point extensively and (imo) constructively, >> and decided to keep them separate. The current charter draft appears >> to have decided otherwise, but offers only the barest of >> justifications, which I suspect has not factored in the earlier >> evaluation. > There was a followup discussion about doing an IMAP extension for > submission and how it should look like to remain compatible with SMTP > Submission. I don't think this is an attempt to just ignore earlier > discussions. Discussion is different than deployment. The fact that it isn't used now suggests that the benefit(s) you are asserting aren't as clear-cut as is being implied here. To the extent that the current proposal does indeed represent a consideration of the prior, extended IETF work in this realm, the charter should indicate the basis for making a different choice here, in terms of the points considered earlier. >>> 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, and operating over >>> a stateless connection such as HTTPS. >> >> 'flood control'? what does this mean, since I assume the target >> protocol won't be using a flooding algorithm. If it really means >> 'congestion control', that's not typically part of an application >> protocol, so why would it be an issue here? >> >> From the November comments >> >> Since client/server email access typically benefits from having >> the server retain state about the client's activities, I can't tell >> whether this actually means stateless lower-level transport or whether >> it really does mean a stateless email protocol. > > Stateless lower level transport. The addition of "such as HTTPS" was > trying to make this clearer. Didn't succeed, given that HTTP runs over TCP. >> So this needs to be made much more clear, as to the what and the why, >> as well as to the benefit that will accrue. >> >> Given the considerable complexity of HTTP, I continue to fail to >> see why making it be a universal, lower-layer transport is so popular. >> Again, the need and the benefit need to be documented. > > Presence of tools for manipulating JSON and ease of development. This > was mentioned on the JMAP mailing list. I don't think this needs to be > said here. A new protocol is choosing to operate over a very complex substrate. Having some basic justification for that choice, in the charter, seems somewhere between appropriate and obligatory. >> Adding to this: >> >> HTTP/HTTPS are not stateless, since they are connection-based. > Yeah, I struggled with this a bit. Each request/response can be sent on > a separate connection and it is stateless in that sense. In other words, jmap will be stateless. That's what the charter should say. ...Except that that seems odd, since it means that every exchange would have to self-identify and self-authorize. I suspect that's not what's going to be defined. So, really, it isn't obvious to me at all what will be stateless. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Feb 6 18:52:53 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 BD5911297E8; Mon, 6 Feb 2017 18:52:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.718 X-Spam-Level: X-Spam-Status: No, score=-2.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=fastmail.com header.b=WzNOwq0e; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=TveEP980 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 ZLgku-b3pa3t; Mon, 6 Feb 2017 18:52:50 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00EF21297E7; Mon, 6 Feb 2017 18:52:49 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 69AA1206E0; Mon, 6 Feb 2017 21:52:49 -0500 (EST) Received: from betaweb1 ([10.202.2.10]) by compute1.internal (MEProxy); Mon, 06 Feb 2017 21:52:49 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=QGiY8NT5nby9k92Yy7lCTrcLE+ I=; b=WzNOwq0ey2azEsXdeau6G7j+xhgG7o7KDpq5tSD/fTfBAcILt2NyI/NxV3 6KhRc+1ErLomBqjRON2nZvg+NZM793dL/gXCM2J+Ygv6+A9Y/Za31dInIsmx+equ WBMiFnNEx1m9l9UjioL6hXQcMqmLgKuEp5+4HAn9GqDTPdWhA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=smtpout; bh=QG iY8NT5nby9k92Yy7lCTrcLE+I=; b=TveEP980PkImJgW8Qa8qw+qoOuJw94Nowh B9bXQYUX5SEtddu2T2uCQKkNU4nrGkUY3jvAjA8ReenRfJ540wGJ9p4XXy9+RKRE F2nhqVY4zGgfvYlxl89y+vrWfLNgCTm39DhWJhmybcDQ7KthjcY37xZkQHSTLtjA nzWbaK1Tg= X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 28085E23C8; Mon, 6 Feb 2017 21:52:49 -0500 (EST) Message-Id: <1486435969.2314063.872594064.21072F60@webmail.messagingengine.com> From: Neil Jenkins To: dcrocker@bbiw.net, Alexey Melnikov MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_148643596923140630" X-Mailer: MessagingEngine.com Webmail Interface - ajax-fdb7c997 In-Reply-To: <368f2b68-8f10-9517-1edb-d213ff10563b@dcrocker.net> Date: Tue, 07 Feb 2017 13:52:49 +1100 References: <148616796247.4079.7104562493351135409.idtracker@ietfa.amsl.com> <11e900d0-553e-0635-06f4-8510bd80ecfd@dcrocker.net> <4ff42a3b-1f8e-3e25-14e7-b1d3ed2f69c2@isode.com> <368f2b68-8f10-9517-1edb-d213ff10563b@dcrocker.net> Archived-At: Cc: jmap@ietf.org, ietf@ietf.org, iesg Subject: Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 02:52:52 -0000 This is a multi-part message in MIME format. --_----------=_148643596923140630 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi I'll try to clarify a few of these points. *Message representation* JMAP defines a JSON structure that represents in a consistent and structured way all the information that the vast majority of clients need from an RFC5322 message. The server deals with the complexities of MIME, encoding issues, parsing headers etc. The intention is that the server will still operate with RFC5322 messages for storage and certainly transmission; the JSON representation is not intended to replace RFC5322, just relieve client authors from having to deal with it. Clients can also just fetch the properties they need, reducing bandwidth overhead. Clients that want to or need to (for example those doing PGP in the client) can still fetch the RFC5322 if needed. *Industry need* A number of proprietary protocols have been popping up as alternatives to IMAP, which all also have their own JSON representation of message objects. Here are a few examples, the latter two being from whole companies that formed just to try to help people not have to deal with IMAP: * Gmail[1] * Outlook[2] * Nylas[3] * Context.io[4] In addition, we=E2=80=99re seeing most new mobile email clients proxy every= thing via their own server rather than talking directly to the user=E2=80=99s mail store. Examples include Mailbox (now defunct), Alto, Outlook and Newton. This is bad for security and privacy, and also bad for the client authors as they have to run server infrastructure in addition to just building their clients. Despite not only being proprietary but patented (and expensive!), ActiveSync has seen a big increase in adoption, and not just with Microsoft servers, due to its better support for mobile environments and ease of setup (one login for mail receive/send, contacts and calendars). *Protocol vs representation* JMAP is a protocol. It primarily defines a way of syncing data objects in a network-efficient, developer friendly way. Objects are defined to represent mailboxes, threads and messages in a consistent manner. These are encoded as JSON for transmission over HTTPS. *Message submission* > There is no justification given for this approach. For each > activity, there needs to be a clear and solid need documented, based > on actual industry activities or at least industry statements. > Besides clarifying /what/ needs doing, it should serve to indicate > likely industry uptake after the work is done. This *is* based on industry statements. This is a very common support problem we see here at FastMail, and from our conversations with other mailbox vendors, we don't think this is just us. *Flood control* In IMAP, suppose you have a mailbox with 1,000,000 messages in it selected, and another client expunges the lot. You get * 1 EXPUNGE sent to you 1 million times (and you don't even know how many you are going to receive); the only option is to drop the connection if it gets too much. By flood control, we mean the client can ensure it does not get flooded with data, especially important on low-bandwidth connections like many mobile networks and in developing countries. Reducing data usage is of course vital for saving battery, another key concern for mobile. Similarly, the server has well defined ways of rate limiting the amount of work the client can ask it to do to ensure it too does not get flooded and either accidentally or deliberately DOSed by client requests. *Why HTTP underneath* The short answer is it=E2=80=99s good enough, widely understood and it=E2= =80=99s by far the easiest thing for developers to adopt. There=E2=80=99s support in basic= ally all OSes and programming languages. It=E2=80=99s easy to read and debug. HTTP doesn=E2=80=99t tend to run into firewall issues, and is so commonly u= sed it has integrations which can help with optimisation (for example, iOS has built-in support for optimising radio usage by batching HTTP calls from different apps where possible, which their mail team have told us they would like to be able to use). This isn=E2=80=99t an innate advantage = of HTTP, but rather an advantage of its ubiquity. *Statelessness* The protocol does not make use of any connection persistence to the server. HTTPS may establish this underneath, but the protocol on top is agnostic to it. Each request to the server contains an authorisation token (in the Authorization header) to identify and authenticate the request. Neil. Links: 1. https://developers.google.com/gmail/api/v1/reference/ 2. https://msdn.microsoft.com/office/office365/APi/mail-rest-operations 3. https://nylas.com/cloud/docs 4. https://context.io/docs/lite --_----------=_148643596923140630 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Hi

I'll try to clarify a few of these points.

Message representation

JMAP defines a JSON structure that represents in a consistent and stru= ctured way all the information that the vast majority of clients need from = an RFC5322 message. The server deals with the complexities of MIME, encodin= g issues, parsing headers etc. The intention is that the server will still = operate with RFC5322 messages for storage and certainly transmission; the J= SON representation is not intended to replace RFC5322, just relieve client = authors from having to deal with it. Clients can also just fetch the proper= ties they need, reducing bandwidth overhead.

Clients that want to or need to (for example those doing PGP in the cl= ient) can still fetch the RFC5322 if needed.

Industry need

A number of proprietary protocols have been popping up as alternatives= to IMAP, which all also have their own JSON representation of message obje= cts. Here are a few examples, the latter two being from whole companies tha= t formed just to try to help people not have to deal with IMAP:


In addition, we=E2=80=99re seeing most new mobile email clients proxy = everything via their own server rather than talking directly to the user=E2= =80=99s mail store. Examples include Mailbox (now defunct), Alto, Outlook a= nd Newton. This is bad for security and privacy, and also bad for the clien= t authors as they have to run server infrastructure in addition to just bui= lding their clients.

Despite not only being proprietary but patented (and expensive!), Acti= veSync has seen a big increase in adoption, and not just with Microsoft ser= vers, due to its better support for mobile environments and ease of setup (= one login for mail receive/send, contacts and calendars).

Protocol vs representation

JMAP is a protocol. It primarily defines a way of syncing data objects= in a network-efficient, developer friendly way. Objects are defined to rep= resent mailboxes, threads and messages in a consistent manner. These are en= coded as JSON for transmission over HTTPS.

Message submission

There is no justification given for this app= roach.  For each
activity, there needs to be a clear and solid need documented, based
on actual industry activities or at least industry statements.
Besides clarifying /what/ needs doing, it should serve to indicate
=
likely industry uptake after the work is done.

This is based on industry statements. This is a very common sup= port problem we see here at FastMail, and from our conversations with other= mailbox vendors, we don't think this is just us.

Flood control

In IMAP, suppose you have a mailbox with 1,000,000 messages in it sele= cted, and another client expunges the lot. You get * 1 EXPUNGE sent to you = 1 million times (and you don't even know how many you are going to receive)= ; the only option is to drop the connection if it gets too much. By flood c= ontrol, we mean the client can ensure it does not get flooded with data, es= pecially important on low-bandwidth connections like many mobile networks a= nd in developing countries. Reducing data usage is of course vital for savi= ng battery, another key concern for mobile.

Similarly, the server has well defined ways of rate limiting the amoun= t of work the client can ask it to do to ensure it too does not get flooded= and either accidentally or deliberately DOSed by client requests.

Why HTTP underneath

The short answer is it=E2=80=99s good enough, widely understood and it= =E2=80=99s by far the easiest thing for developers to adopt. There=E2=80=99= s support in basically all OSes and programming languages. It=E2=80=99s eas= y to read and debug.

HTTP doesn=E2=80=99t tend to run into firewall issues, and is so commo= nly used it has integrations which can help with optimisation (for example,= iOS has built-in support for optimising radio usage by batching HTTP calls= from different apps where possible, which their mail team have told us the= y would like to be able to use). This isn=E2=80=99t an innate advantage of = HTTP, but rather an advantage of its ubiquity.

Statelessness

The protocol does not make use of any connection persistence to the se= rver. HTTPS may establish this underneath, but the protocol on top is agnos= tic to it. Each request to the server contains an authorisation token (in t= he Authorization header) to identify and authenticate the request.

Neil.
--_----------=_148643596923140630-- From nobody Tue Feb 7 03:26:50 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 B06E9129B51 for ; Tue, 7 Feb 2017 03:26:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9VglqXpi78Et for ; Tue, 7 Feb 2017 03:26:47 -0800 (PST) Received: from mail-yw0-x243.google.com (mail-yw0-x243.google.com [IPv6:2607:f8b0:4002:c05::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCEA4129B50 for ; Tue, 7 Feb 2017 03:26:47 -0800 (PST) Received: by mail-yw0-x243.google.com with SMTP id u68so9182408ywg.0 for ; Tue, 07 Feb 2017 03:26:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:cc; bh=r1ZIDXpdxroaPSVM7gEcKOIEv1P+ohShsvIOReDAr9s=; b=VuXoYrGRc+jn+3nRNXs/ThDBYkn6i7irU/rIrPltruzqaUYuMSH1QKvbLYI6ozKPy5 a4SdjIkcJD3r8rYrRRLefXN6xSch/KPbNLWDTyiV0QlMgguL1Q/NuUMRm8N1ghxpee1I /uXQyQmpzUaCQoG2pflmM2gWrYA8OkRCxBK4YFTyHV7s70/B5FvrSNjuTef1S9JRZiiB GzEUf4I3InASMvtjG7gknSZhZLMhsMzNeYQRyWdK9W4MkqSfvq2g+RBV/JeOqIDEz9or Kblw+8FowfHFbzfM0B6KMyy0Vn7D0tM2gtlJWAi+g7P4RnkyDW6a8TrvKs8WPn8m62Jv kUuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:cc; bh=r1ZIDXpdxroaPSVM7gEcKOIEv1P+ohShsvIOReDAr9s=; b=I2kUiOnZYtDZnSXv7AqLHxOgQrZjBW2dmD3+uscUlku0znqhDV3SZugCwRwhkD1ndp +n865UNeKBAWSTxWQXI5vlO3nUXgkrbdKscTbC57jch6gp7lGkU6vfU3chrlPKSEBPtf lK6lLbOuF3BNqTetyhDcnYqpe2mhr1qiExoMmet1UrF6Xx5l7a/0SawTCWUcJcC5y4rG d0EKEHZ5zz9pGi7g0csBZiNOc/8jbN/LmkGdbMSz2uS1kTQ8c/yNOR0kIZQYUzmrABwT wZNyf3PKLYaA/uKlkUYXBQhC1bICrNHAE5/iYkfdlPUg2Aftqu6XiHycI5/dIqBnWb4X fxWg== X-Gm-Message-State: AMke39nBLNIoemU5Th5ILIW+RcKi19o+9d4CjC4II5CF1ySkX4GEBbJYCqLx1P22aW6GEFJBQJpSRIBbaJY5rA== X-Received: by 10.13.193.68 with SMTP id c65mt10909932ywd.88.1486466806915; Tue, 07 Feb 2017 03:26:46 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 7 Feb 2017 03:26:45 -0800 From: Gren Elliot In-Reply-To: <1486435969.2314063.872594064.21072F60@webmail.messagingengine.com> References: <148616796247.4079.7104562493351135409.idtracker@ietfa.amsl.com> <11e900d0-553e-0635-06f4-8510bd80ecfd@dcrocker.net> <4ff42a3b-1f8e-3e25-14e7-b1d3ed2f69c2@isode.com> <368f2b68-8f10-9517-1edb-d213ff10563b@dcrocker.net> <1486435969.2314063.872594064.21072F60@webmail.messagingengine.com> X-Mailer: Airmail (397) MIME-Version: 1.0 Date: Tue, 7 Feb 2017 03:26:45 -0800 Message-ID: Content-Type: multipart/alternative; boundary=001a114e6c00ff44950547ef05bd Archived-At: Cc: jmap@ietf.org, iesg , ietf@ietf.org Subject: Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 11:26:48 -0000 --001a114e6c00ff44950547ef05bd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Just to add my voice to the call for easier configuration where we don=E2= =80=99t force users to configure countless different things. Trying to setup a new device for use with open protocols is a complete nightmare - you end up needing to configure 2 things for mail (IMAP and SMTP) plus something for Contacts (CardDAV - perhaps LDAP as well) plus something for Calendar (CalDAV). Many users, myself included are also at the mercy of frequent forced password changes, which necessitate modifying the configuration of each of these on each device. Bizarrely, I suspect across 99% odd of use cases, this separation is completely artificial as the same password is used on the server for all services (and cannot be different because most servers regard them as all relating to the same account). This configuration complexity must waste countless hours across the world and is a major reason why businesses welcome ActiveSync - just to solve this one huge problem with the open protocol landscape. There may be some good esoteric academic reasons why keeping IMAP and message submission protocols separate but I think the real world has clearly showed that the added complexity is too expensive. I believe JMAP is intending to extend from just Mail to encompass Calendar and Contacts too and I truly hope it will (in a way that doesn=E2=80=99t re= quire servers to offer everything) Folks at Calconnect and the IETF have been working on https://tools.ietf.org/html/draft-daboo-aggregated-service-discovery-03 whi= ch attempts to ease the configuration burden but that looks like being a long process and needs buy in from device vendors to be really successful. I see most of the need behind this work as a sticky plaster trying to cover up the un-necessary mess we have created :-( It would be nice to see config dialogs where user=E2=80=99s are asked for m= inimal information (user name, perhaps server name) and then the device discovers what is available there (Mail/Contacts/Calendar/=E2=80=A6) and offers the u= ser a way to select them and perhaps a choice of preferred client(s) to handle each service. The way Android handles some things, where a single bit of software is responsible for server access and perhaps local caching and other clients can provide UIs to access this is kind of neat too. Regards, Gren Elliot Zimbra Software Engineer at Synacor --001a114e6c00ff44950547ef05bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =
Hi,

Just to add my voice to the call for easier configuration where we= don=E2=80=99t force users to configure countless different things.=C2=A0 T= rying to setup a new device for use with open protocols is a complete night= mare - you end up needing to configure 2 things for mail (IMAP and SMTP) pl= us something for Contacts (CardDAV - perhaps LDAP as well) plus something f= or Calendar (CalDAV).=C2=A0 Many users, myself included are also at the mer= cy of frequent forced password changes, which necessitate modifying the con= figuration of each of these on each device.=C2=A0 Bizarrely, I suspect acro= ss 99% odd of use cases, this separation is completely artificial as the sa= me password is used on the server for all services (and cannot be different= because most servers regard them as all relating to the same account).=C2= =A0 This configuration complexity must waste countless hours across the wor= ld and is a major reason why businesses welcome ActiveSync - just to solve = this one huge problem with the open protocol landscape. There may be some g= ood esoteric academic reasons why keeping IMAP and message submission proto= cols separate but I think the real world has clearly showed that the added = complexity is too expensive.

I believe JMAP is intending to extend from just Mail to encompass C= alendar and Contacts too and I truly hope it will (in a way that doesn=E2= =80=99t require servers to offer everything)

Folks at Calconnect and the = IETF have been working on=C2=A0https://tools.ietf.org/html/draft-d= aboo-aggregated-service-discovery-03=C2=A0which attempts to ease the co= nfiguration burden but that looks like being a long process and needs buy i= n from device vendors to be really successful.=C2=A0 I see most of the need= behind this work as a sticky plaster trying to cover up the un-necessary m= ess we have created :-(

It would be nice to see config dialogs where user=E2=80=99s are asked fo= r minimal information (user name, perhaps server name) and then the device = discovers what is available there (Mail/Contacts/Calendar/=E2=80=A6) and of= fers the user a way to select them and perhaps a choice of preferred client= (s) to handle each service.=C2=A0 The way Android handles some things, wher= e a single bit of software is responsible for server access and perhaps loc= al caching and other clients can provide UIs to access this is kind of neat= too.

Regards,
Gren Elliot
Zimbra Software Enginee= r at Synacor
--001a114e6c00ff44950547ef05bd-- From nobody Tue Feb 7 06:21:20 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 C993B129C64; Tue, 7 Feb 2017 06:21:11 -0800 (PST) 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, 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 S81QAEutkQRy; Tue, 7 Feb 2017 06:21:10 -0800 (PST) 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 C4E72129C62; Tue, 7 Feb 2017 06:21:10 -0800 (PST) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v17EMmEM004300 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 7 Feb 2017 06:22:48 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1486477368; bh=KxWKYDKe37ta0S9CO9qjMz63xjjlUfEX5Rl2ZpdE41o=; h=Subject:To:References:Cc:Reply-To:From:Date:In-Reply-To:From; b=juaw9FbJfF9Pg8Oijqy3XVFoRnWR8BUj6jo/G7BMO0TcORXMqGb+ZyphX0TZ94Jx5 J0+H++CAXHspYISvHMQUwovSzjaxvTcNMPI4tXy1pFDi3e2V0f8W+XhON6uTZCA+BA X2tAGqN8ES/COwAc2RF0Ga4AH45blhlWLQgnukC0= To: Gren Elliot References: <148616796247.4079.7104562493351135409.idtracker@ietfa.amsl.com> <11e900d0-553e-0635-06f4-8510bd80ecfd@dcrocker.net> <4ff42a3b-1f8e-3e25-14e7-b1d3ed2f69c2@isode.com> <368f2b68-8f10-9517-1edb-d213ff10563b@dcrocker.net> <1486435969.2314063.872594064.21072F60@webmail.messagingengine.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Tue, 7 Feb 2017 06:21:00 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: jmap@ietf.org, iesg , ietf@ietf.org Subject: Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 14:21:12 -0000 On 2/7/2017 3:26 AM, Gren Elliot wrote: > Just to add my voice to the call for easier configuration where we don’t > force users to configure countless different things. Trying to setup a > new device for use with open protocols is a complete nightmare - you end > up needing to configure 2 things for mail (IMAP and SMTP) ... > It would be nice to see config dialogs where user’s are asked for > minimal information (user name, perhaps server name) and then the device > discovers what is available there (Mail/Contacts/Calendar/…) and offers > the user a way to select them and This issue is for user interface design, not underlying protocol design. Hence while it is extremely important in terms of usability, it is outside the scope of the IETF. Having these functions embedded into a single protocol implicitly requires that these different functions share the same configuration data. While such sharing might be common practice, requiring the sharing limits operational choices. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Feb 7 07:19:02 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 26363129CAD for ; Tue, 7 Feb 2017 07:18:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 D2duDuWSPyXL for ; Tue, 7 Feb 2017 07:18:53 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8400129CB1 for ; Tue, 7 Feb 2017 07:18:51 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id k15so137440647qtg.3 for ; Tue, 07 Feb 2017 07:18:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=upxyFFSs8w1zOzixauNrrHtqMwX1OVNYfhUVmXMqd3c=; b=nrTlhYFQLwe5hkiiJr+jFM3eToS5rHA1syXt30/n5oHpch59aAJ+66o62QIYdqG1BI eNkHCfY4oeLr3LzbpKM/pL/XWe/OyY+vbYN4Hrjeu7MtoESmNLL1cH06KDiW6RlFokYA edTt8yMJCPw9nqnsXYvbFX/2idbNH5G/sTER+EgkQQW71n10/ZM+hEQ1FDwgsaDDoInQ JsKqv5qfs8vi5Sak9HQaIWsZgxESMC8sA95NYQCEcSzq7aqapkOCf7+sAWlIChr7UlPz +x9YHX9kymW3OESKP4O3tZIPo3EkFtTMWYQU900EUXbqr2SEFOHHPFiNGKqrGiU5KW1s 9rMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=upxyFFSs8w1zOzixauNrrHtqMwX1OVNYfhUVmXMqd3c=; b=RCyrvhqlTT84nWQyLG5deQ0y8XgGV47q8Z5xjpg2H7AW5UVN9U/R5enYkyFeGcO21p ajggh/E931k/q0h+LVliw6iF2d3h9rQv5M7N6zm5jeTKf40wNmD+pT4yA5Z9hrCFXMd0 VJXYHtpVi++ZywG+mYAmXDpV+knc3jClyZTr1KNP0MIrFeLINbk16z9IY4R7zhA6g9AL AHVL/nSn0zGB6N1em1b4i5G3a8N2oIJke2mN/KNrLKMq2QunSsJyS2j8DCPrL0pn6kI8 AyNamtHxdvUxJJBob4shLPlPLxNks8Cu+Szkm5PTaAO/SlLpuJABhkHRvaJa6YN6HAFX wg4w== X-Gm-Message-State: AMke39lNWwHnyFP42KkSQE+7XG+kWfItvYbFqbBFHEK2bSRqmDzOGRsYhAv/TPEOLbWVBA== X-Received: by 10.200.47.129 with SMTP id l1mr14308854qta.148.1486480730382; Tue, 07 Feb 2017 07:18:50 -0800 (PST) Received: from [10.0.20.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id k8sm3590624qke.29.2017.02.07.07.18.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Feb 2017 07:18:48 -0800 (PST) From: Ted Lemon Message-Id: <8B24068E-6EA6-404B-AFEC-76C9A0029954@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6FB82B1A-B4F8-4B93-B738-2880351BC4F6" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 7 Feb 2017 10:18:45 -0500 In-Reply-To: To: Dave Crocker References: <148616796247.4079.7104562493351135409.idtracker@ietfa.amsl.com> <11e900d0-553e-0635-06f4-8510bd80ecfd@dcrocker.net> <4ff42a3b-1f8e-3e25-14e7-b1d3ed2f69c2@isode.com> <368f2b68-8f10-9517-1edb-d213ff10563b@dcrocker.net> <1486435969.2314063.872594064.21072F60@webmail.messagingengine.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: jmap@ietf.org, iesg , Gren Elliot , ietf@ietf.org Subject: Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 15:18:54 -0000 --Apple-Mail=_6FB82B1A-B4F8-4B93-B738-2880351BC4F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Feb 7, 2017, at 9:21 AM, Dave Crocker wrote: >> It would be nice to see config dialogs where user=E2=80=99s are asked = for >> minimal information (user name, perhaps server name) and then the = device >> discovers what is available there (Mail/Contacts/Calendar/=E2=80=A6) = and offers >> the user a way to select them and >=20 > This issue is for user interface design, not underlying protocol = design. Hence while it is extremely important in terms of usability, it = is outside the scope of the IETF. I must beg to differ. While it's true that we don't care explicitly = about UI, we certainly care about enabling UIs that work. Providing a = query that returns the information required to send mail is definitely = worth doing. Of course, that could be just allowing a message to be = uploaded, and having a command that says "deliver this message". It's = not clear to me that submission by way of SMTP is actually a win = here=E2=80=94it's really an extra step, since you probably were going to = save the draft using the mailbox protocol anyway. --Apple-Mail=_6FB82B1A-B4F8-4B93-B738-2880351BC4F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Feb 7, 2017, at 9:21 AM, Dave Crocker <dhc@dcrocker.net> = wrote:
It would be nice to see = config dialogs where user=E2=80=99s are asked for
minimal = information (user name, perhaps server name) and then the device
discovers what is available there = (Mail/Contacts/Calendar/=E2=80=A6) and offers
the user a = way to select them and

This issue is for user interface design, not = underlying protocol design.  Hence while it is extremely important = in terms of usability, it is outside the scope of the = IETF.

I must beg to differ.   While it's true that we don't = care explicitly about UI, we certainly care about enabling UIs that = work.   Providing a query that returns the information required to = send mail is definitely worth doing.   Of course, that could be = just allowing a message to be uploaded, and having a command that says = "deliver this message".   It's not clear to me that submission by = way of SMTP is actually a win here=E2=80=94it's really an extra step, = since you probably were going to save the draft using the mailbox = protocol anyway.

= --Apple-Mail=_6FB82B1A-B4F8-4B93-B738-2880351BC4F6-- From nobody Tue Feb 7 07:33:36 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 5B2F0129CB7; Tue, 7 Feb 2017 07:33:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Cw6g32d0n0eg; Tue, 7 Feb 2017 07:33:29 -0800 (PST) Received: from mail-yw0-x241.google.com (mail-yw0-x241.google.com [IPv6:2607:f8b0:4002:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B14B1129CD1; Tue, 7 Feb 2017 07:33:18 -0800 (PST) Received: by mail-yw0-x241.google.com with SMTP id l16so9692020ywb.2; Tue, 07 Feb 2017 07:33:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=XbnzsFGbqVilLiXt/HhxGtqyr9+ge9FO4HglZWeRRgw=; b=mLRkRxRJOGj5Za8O7eBJ4Rxl3YvL+kfbwFh8TdCasffNz6SEUXElO1DmG747nSL1YY sO7+dLuA29XAKRFCgw/6/bGTnlbWDLVomkdt9yaO9SCd+iGVPfzIZ0QNnyHC95B5zrGU 3ImLVoaSOQsZVbbRkEIyUrDzwBBIlPIIx3DH0pU1PCnkE0mUG4B8VedCEudsj6LaXSmt ThhdgIgj+j6+OW1Lzob8hDrKzqeI89cDJAS43XsxERNTiB6r9RjRpp8QIhPJXE4rePHO bR0xnZjlHFhKfFzwQp5JQRDVg5rVzNJSR8o/3FCsyyN8GR0991tRTLL6YCeuMO9Rk5iN Bc2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=XbnzsFGbqVilLiXt/HhxGtqyr9+ge9FO4HglZWeRRgw=; b=BtUAoI2aa5NDiPklRS7CI9D9dq0Nk6w1IAc4xBRaUK3jYiiezMuBD6h3fe4fHg0QGO ARiZIC6GMiHSjVe8Jc4imuObNJ5DqE9ax1dn3ywvEq0qJHA4EC51mnIdRSPjZ0N8LxgZ qYkvv/1+zccWSgBLDv3guo63C4TLI2eHci9n3UAhMPm/qXAwAB41TYHkPOPk+Epop3JF Eu3dcKvOBd3o5cxVAptqbJzbEL6NuaG2MyZvSwFEDsTTBWUSk2ABhVTv0GqSjRfjali6 PLCMvENsOTvU8/3oVLfneXWOMGZV8j4REJgmvVl6kF6ym+uLi5JV6IprO+UDBv9SJoDE pIJw== X-Gm-Message-State: AIkVDXK9VSPwUmRvQ5tecVFyLHlw0F83zsGo5x9gweTJBSA1CwwU2cc+78XjmiHabsjp+9JredM1D8Tkkw0iSw== X-Received: by 10.129.123.197 with SMTP id w188mr11306383ywc.267.1486481597981; Tue, 07 Feb 2017 07:33:17 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 7 Feb 2017 07:33:16 -0800 From: Gren Elliot In-Reply-To: References: <148616796247.4079.7104562493351135409.idtracker@ietfa.amsl.com> <11e900d0-553e-0635-06f4-8510bd80ecfd@dcrocker.net> <4ff42a3b-1f8e-3e25-14e7-b1d3ed2f69c2@isode.com> <368f2b68-8f10-9517-1edb-d213ff10563b@dcrocker.net> <1486435969.2314063.872594064.21072F60@webmail.messagingengine.com> X-Mailer: Airmail (397) MIME-Version: 1.0 Date: Tue, 7 Feb 2017 07:33:16 -0800 Message-ID: To: Dave Crocker , dcrocker@bbiw.net Content-Type: multipart/alternative; boundary=001a114948789cebff0547f2776e Archived-At: Cc: jmap@ietf.org, ietf@ietf.org, iesg Subject: Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 15:33:31 -0000 --001a114948789cebff0547f2776e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable From: Dave Crocker Reply: dcrocker@bbiw.net Date: 7 February 2017 at 14:21:10 To: Gren Elliot Cc: jmap@ietf.org , iesg , ietf@ietf.org Subject: Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity On 2/7/2017 3:26 AM, Gren Elliot wrote: > Just to add my voice to the call for easier configuration where we don=E2= =80=99t > force users to configure countless different things. Trying to setup a > new device for use with open protocols is a complete nightmare - you end > up needing to configure 2 things for mail (IMAP and SMTP) ... > It would be nice to see config dialogs where user=E2=80=99s are asked for > minimal information (user name, perhaps server name) and then the device > discovers what is available there (Mail/Contacts/Calendar/=E2=80=A6) and = offers > the user a way to select them and This issue is for user interface design, not underlying protocol design. Hence while it is extremely important in terms of usability, it is outside the scope of the IETF. With the current standards landscape, there is no way round the fact that users (often not tech savvy ones) need to specify separate hostnames and ports for IMAP and message submission, plus potentially URLs for CalDAV / CardDAV (the latter 2 could reasonably be combined without IETF help but sadly seldom are). Without further standardisation, no wonderful interface design can escape from that. I certainly think that it should be within the scope of the IETF to improve the standards to the point where good interface design is possible. That doesn=E2=80=99t actually require moving= to a single protocol. As mentioned before in relation to aggregated service discovery, this could be achieved by standardising a bootstrapping mechanism where the user only provides minimal information which points to a store of detailed configuration information that the user never needs to be aware of. Alternatively, or perhaps in addition, having a single protocol would achieve most of the same aims - much as ActiveSync achieves and I hope JMAP will achieve. Having these functions embedded into a single protocol implicitly requires that these different functions share the same configuration data. While such sharing might be common practice, requiring the sharing limits operational choices. Requiring sharing would indeed limit operational choices - so it shouldn=E2= =80=99t be required. I think it is important that a JMAP service should be able to offer (and advertise) whatever subset of full services it wants to. In the most common situation, a single JMAP service would provide mail access, mail submission, contacts access, calendar access etc, but there is no reason why multiple, dedicated JMAP services couldn=E2=80=99t be used, one = just doing mail access, one doing mail submission etc. In the most common situation, you would be much better off than you are now. In the other case, you would be no worse off than you are currently and at least there would be consistency in how you configure each service. Regards, Gren Elliot --001a114948789cebff0547f2776e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =
From:=C2=A0Dave Cro= cker=C2=A0<dhc@dcrocker.net><= br>Reply:=C2=A0dcrocker@bbiw.net= =C2=A0<dcrocker@bbiw.net>Date:=C2=A07 February 2017 at 14:21:10
To:=C2=A0Gren Elliot=C2=A0<fatkudu@gmail.com>
Cc:=C2=A0jmap@ietf.org=C2=A0<jmap@ietf.org>,=C2=A0iesg=C2=A0<iesg@ietf.org>,=C2=A0ietf@ietf.org=C2=A0<ietf@ietf.org= >
Subject:=C2=A0=C2=A0Re: [Jmap] WG Review: JSON Mail Access Prot= ocol (jmap) - reducing configuration complexity=C2=A0

On 2/7/2017 = 3:26 AM, Gren Elliot wrote:=C2=A0
> Just to add my voice to the call = for easier configuration where we don=E2=80=99t=C2=A0
> force users t= o configure countless different things. Trying to setup a=C2=A0
> new= device for use with open protocols is a complete nightmare - you end=C2=A0=
> up needing to configure 2 things for mail (IMAP and SMTP)=C2=A0...=C2=A0
> It would be nice to see config dialogs where user=E2=80= =99s are asked for=C2=A0
> minimal information (user name, perhaps se= rver name) and then the device=C2=A0
> discovers what is available th= ere (Mail/Contacts/Calendar/=E2=80=A6) and offers=C2=A0
> the user a = way to select them and=C2=A0


This issue is for user interface de= sign, not underlying protocol design.=C2=A0
Hence while it is extremely = important in terms of usability, it is=C2=A0
outside the scope of the IE= TF.=C2=A0

With the current standards landscape= , there is no way round the fact that users (often not tech savvy ones) nee= d to specify separate hostnames and ports for IMAP and message submission, = plus potentially URLs for CalDAV / CardDAV (the latter 2 could reasonably b= e combined without IETF help but sadly seldom are).=C2=A0 Without further s= tandardisation, no wonderful interface design can escape from that.=C2=A0 I= certainly think that it should be within the scope of the IETF to improve = the standards to the point where good interface design is possible.=C2=A0 T= hat doesn=E2=80=99t actually require moving to a single protocol.=C2=A0 As = mentioned before in relation to aggregated service discovery, this could be= achieved by standardising a bootstrapping mechanism where the user only pr= ovides minimal information which points to a store of detailed configuratio= n information that the user never needs to be aware of.=C2=A0 Alternatively= , or perhaps in addition, having a single protocol would achieve most of th= e same aims - much as ActiveSync achieves and I hope JMAP will achieve.

=
Having these functions embedde= d into a single protocol implicitly=C2=A0
requires that these different = functions share the same configuration=C2=A0
data. While such sharing mi= ght be common practice, requiring the=C2=A0
sharing limits operational c= hoices.=C2=A0

Requiring sharing would indeed limit ope= rational choices - so it shouldn=E2=80=99t be required.=C2=A0 I think it is= important that a JMAP service should be able to offer (and advertise) what= ever subset of full services it wants to.=C2=A0 In the most common situatio= n, a single JMAP service would provide mail access, mail submission, contac= ts access, calendar access etc, but there is no reason why multiple, dedica= ted JMAP services couldn=E2=80=99t be used, one just doing mail access, one= doing mail submission etc.=C2=A0 In the most common situation, you would b= e much better off than you are now.=C2=A0 In the other case, you would be n= o worse off than you are currently and at least there would be consistency = in how you configure each service.

Regards,
Gren Elliot

--001a114948789cebff0547f2776e-- From nobody Tue Feb 7 07:38:32 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 EDF7B129CB8; Tue, 7 Feb 2017 07:38:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 g8vsx-urIq7w; Tue, 7 Feb 2017 07:38:28 -0800 (PST) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D77D3129C9E; Tue, 7 Feb 2017 07:38:27 -0800 (PST) Received: by mail-yb0-x230.google.com with SMTP id w194so36351286ybe.0; Tue, 07 Feb 2017 07:38:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to; bh=fflSiA+DXbFbHui+PXMXK6LyijM3DYbrUxU3sK0wBAE=; b=D9fBZWKonB2BBodVR9bay0dD9Ly0Hcw6rTZ+2aPwACVJLjrdjDx1QD4B6GG7PXIxg7 M7lRHf8LUYcH1Ejd4KRYE3qM9rrO4JPjF7ONmpXDz4C5Kumu1QQgeTNG1z8wGMfKQvl0 6obvRAGj9xsKzaRG89PUX7XcxR5EWfh7fTwqAduv4mpkmRfhC0RO5HhT8xAehu3HtnxN Z5vd0f85VKTk3DryD84OqLQqAjNr5JcBul6fObPWKCRdHwNJKQaFPSGdIrPBMpC6dMBW PjoIccV6xqH3SjDxPfF0OzXmHaZnClTuQc5P0xats/PkNWWJoGJKHtau6rj6Z/iSv/ey NoHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=fflSiA+DXbFbHui+PXMXK6LyijM3DYbrUxU3sK0wBAE=; b=W/X1NIUIcKA0vObAVt+Um08WzoDPD0DLhoxkPFCTj2DYsNt1F/qo8YyGY2zmih/0gM uBXL7aEHUL9XjDMMT7VbhAMOrvhtO5r1vr9hPUEQ16LLa8VwXvto6bTz5lNQ72T+0Tiu fkNhPwbgWieYH0Av0DsRfX9O/soFiuruyDKRtDgZmZMl6rerdC1ikQy2dyfERH2S1eQz 7uKF8RvEvuENGZgocLerbYurZ+ksdlEu4NbHGrz/IeDmBDK3QAGp0f6+q0tx3ehw21N6 4I2+2McviI29IJ5cAbevfd8uPK15ysN//3yNfTdFPEHvXRB8vvvRkHeEdxtxO3wSWlEy 1Ysw== X-Gm-Message-State: AMke39lOtDQrhj8aSZ13/iOnRQsHePxdUmDzu7aeSl/VEF6lQ5pKpr0AsYyzMNYOBLyscy7XmCgkxJbju88BHg== X-Received: by 10.37.51.215 with SMTP id z206mr11618321ybz.88.1486481906881; Tue, 07 Feb 2017 07:38:26 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 7 Feb 2017 07:38:26 -0800 From: Gren Elliot X-Mailer: Airmail (397) MIME-Version: 1.0 Date: Tue, 7 Feb 2017 07:38:26 -0800 Message-ID: To: jmap@ietf.org, iesg@ietf.org, ietf@ietf.org Content-Type: multipart/alternative; boundary=001a1148a1180670d50547f28a95 Archived-At: Subject: [Jmap] Fwd: Re: WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 15:38:31 -0000 --001a1148a1180670d50547f28a95 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > Trying to setup a new device for use with open protocols is a complete > nightmare - you end up needing to configure 2 things for mail (IMAP > and SMTP) and now, because we will have to be backward compatible, it will be three. so that third had best be a really massive win. and i am not seeing it. what i am seeing is second system syndrome in a wrapper of whatever today 's wrapping fashion is. randy Why? You will either be using IMAP/SMTP to access your mail/submit your messages or you will be using JMAP. If you have the option of the latter, you=E2=80=99ve just halved the number of things that need configuring. Regards, Gren Elliot (forgot to include the mailing lists in reply to Randy earlier) --001a1148a1180670d50547f28a95 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =
> Trying to s= etup a new device for use with open protocols is a complete=C2=A0
> n= ightmare - you end up needing to configure 2 things for mail (IMAP=C2=A0> and SMTP)=C2=A0

and now, because we will have to be backward c= ompatible, it will be=C2=A0
three. so that third had best be a really ma= ssive win. and i am not=C2=A0
seeing it. what i am seeing is second syst= em syndrome in a wrapper of=C2=A0
whatever=C2=A0today's wrapping fashion is= .=C2=A0

randy=C2=A0

Why?=C2=A0 You will either be = using IMAP/SMTP to access your mail/submit your messages or you will be usi= ng JMAP.=C2=A0 If you have the option of the latter, you=E2=80=99ve just ha= lved the number of things that need configuring.


Regards,
Gren Elliot
(forgot to include the mailing lists in re= ply to Randy earlier)
--001a1148a1180670d50547f28a95-- From nobody Tue Feb 7 08:46:03 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 65E77129D6E; Tue, 7 Feb 2017 08:46:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=mail.ru 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 SRvk1fgl-g7q; Tue, 7 Feb 2017 08:45:54 -0800 (PST) Received: from smtp39.i.mail.ru (smtp39.i.mail.ru [94.100.177.99]) (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 219DA129D17; Tue, 7 Feb 2017 08:45:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail2; h=Content-Type:MIME-Version:Cc:To:From:Message-ID:Subject:Date; bh=Tq2PTGVbYQpzOF+5qn6FIf+dFsVpRddK+O48PwfbgzM=; b=VHhiuAX3NH+K0JmtJQzT0S2crI99Ib+BNn5yyAC5b4ob/0s2dzokw0H/9eixqGMrrUi2HBifQdE7A0DzVDHdh7Aev1aIS3NyJd78TytoieLUqQLiNy4mPAOFHs041dQSq7Sj6/MvS5FyeoAtqMkEgPzDfU0ikS/YixHJKl7vzZM=; Received: from [176.59.199.74] (port=53715 helo=[10.36.109.185]) by smtp39.i.mail.ru with esmtpa (envelope-from ) id 1cb8to-0008BX-Hf; Tue, 07 Feb 2017 19:45:50 +0300 Date: Tue, 07 Feb 2017 20:44:32 +0500 Message-ID: <0581hua7t5y0nn90evpup3xx.1486482272576@email.android.com> From: podkorytov To: dcrocker@bbiw.net, Dave Crocker , Gren Elliot MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_4311542043677622" Authentication-Results: smtp39.i.mail.ru; auth=pass smtp.auth=podkorytov@mail.ru smtp.mailfrom=podkorytov@mail.ru X-E1FCDC63: 7AEC6E04E31B87BD92FDBD0DB4DB0310DEB93F7F06BD0150 X-E1FCDC64: D6B2847E708107FE488DDBB0E30C16FE04232C72A5220BF773B1C3F9676487F4 X-Mailru-Sender: DC72CE790D2AA1408AD3CB0182DF755B3641DD201235B2E86810938DD8726441954F6CBC02544365DDDE7B70B5F5C79F X-Mras: OK Archived-At: Cc: jmap@ietf.org, ietf@ietf.org, iesg Subject: Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 16:46:00 -0000 ----_com.android.email_4311542043677622 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGksIEFsbCEKV2UgY2FuIHRha2UgaW4gbWluZCBhbGwgc3RlcHMgZm9yIGNvbXBsZXhzaXR5IG9m wqAgY29uZmlndXJhdGlvbiBTTVRQICYgSU1BUCAmIEpNQVAgYW5kIGludHJvZHVjZSBjb21tYW5k IGZvciBmZXRjaCB0aGlzIHNldHRpbmcgZnJvbSBzZXJ2ZXIgYnkgSk1BUCBjb21tYW5kIGFuZCBk ZWxpdmVyIGl0IHRvwqAgbWFpbCBjbGllbnQuCgowNyDRhNC10LLRgC4gMjAxNyDQsy4gMjA6MzMg 0L/QvtC70YzQt9C+0LLQsNGC0LXQu9GMIEdyZW4gRWxsaW90IDxmYXRrdWR1QGdtYWlsLmNvbT4g 0L3QsNC/0LjRgdCw0Ls6Cj4KPiBGcm9tOsKgRGF2ZSBDcm9ja2VywqA8ZGhjQGRjcm9ja2VyLm5l dD4KPiBSZXBseTrCoGRjcm9ja2VyQGJiaXcubmV0wqA8ZGNyb2NrZXJAYmJpdy5uZXQ+Cj4gRGF0 ZTrCoDcgRmVicnVhcnkgMjAxNyBhdCAxNDoyMToxMAo+IFRvOsKgR3JlbiBFbGxpb3TCoDxmYXRr dWR1QGdtYWlsLmNvbT4KPiBDYzrCoGptYXBAaWV0Zi5vcmfCoDxqbWFwQGlldGYub3JnPizCoGll c2fCoDxpZXNnQGlldGYub3JnPizCoGlldGZAaWV0Zi5vcmfCoDxpZXRmQGlldGYub3JnPgo+IFN1 YmplY3Q6wqDCoFJlOiBbSm1hcF0gV0cgUmV2aWV3OiBKU09OIE1haWwgQWNjZXNzIFByb3RvY29s IChqbWFwKSAtIHJlZHVjaW5nIGNvbmZpZ3VyYXRpb24gY29tcGxleGl0ecKgCj4KPj4gT24gMi83 LzIwMTcgMzoyNiBBTSwgR3JlbiBFbGxpb3Qgd3JvdGU6wqAKPj4gPiBKdXN0IHRvIGFkZCBteSB2 b2ljZSB0byB0aGUgY2FsbCBmb3IgZWFzaWVyIGNvbmZpZ3VyYXRpb24gd2hlcmUgd2UgZG9u4oCZ dMKgCj4+ID4gZm9yY2UgdXNlcnMgdG8gY29uZmlndXJlIGNvdW50bGVzcyBkaWZmZXJlbnQgdGhp bmdzLiBUcnlpbmcgdG8gc2V0dXAgYcKgCj4+ID4gbmV3IGRldmljZSBmb3IgdXNlIHdpdGggb3Bl biBwcm90b2NvbHMgaXMgYSBjb21wbGV0ZSBuaWdodG1hcmUgLSB5b3UgZW5kwqAKPj4gPiB1cCBu ZWVkaW5nIHRvIGNvbmZpZ3VyZSAyIHRoaW5ncyBmb3IgbWFpbCAoSU1BUCBhbmQgU01UUCnCoAo+ PiAuLi7CoAo+PiA+IEl0IHdvdWxkIGJlIG5pY2UgdG8gc2VlIGNvbmZpZyBkaWFsb2dzIHdoZXJl IHVzZXLigJlzIGFyZSBhc2tlZCBmb3LCoAo+PiA+IG1pbmltYWwgaW5mb3JtYXRpb24gKHVzZXIg bmFtZSwgcGVyaGFwcyBzZXJ2ZXIgbmFtZSkgYW5kIHRoZW4gdGhlIGRldmljZcKgCj4+ID4gZGlz Y292ZXJzIHdoYXQgaXMgYXZhaWxhYmxlIHRoZXJlIChNYWlsL0NvbnRhY3RzL0NhbGVuZGFyL+KA pikgYW5kIG9mZmVyc8KgCj4+ID4gdGhlIHVzZXIgYSB3YXkgdG8gc2VsZWN0IHRoZW0gYW5kwqAK Pj4KPj4KPj4gVGhpcyBpc3N1ZSBpcyBmb3IgdXNlciBpbnRlcmZhY2UgZGVzaWduLCBub3QgdW5k ZXJseWluZyBwcm90b2NvbCBkZXNpZ24uwqAKPj4gSGVuY2Ugd2hpbGUgaXQgaXMgZXh0cmVtZWx5 IGltcG9ydGFudCBpbiB0ZXJtcyBvZiB1c2FiaWxpdHksIGl0IGlzwqAKPj4gb3V0c2lkZSB0aGUg c2NvcGUgb2YgdGhlIElFVEYuwqAKPj4KPiBXaXRoIHRoZSBjdXJyZW50IHN0YW5kYXJkcyBsYW5k c2NhcGUsIHRoZXJlIGlzIG5vIHdheSByb3VuZCB0aGUgZmFjdCB0aGF0IHVzZXJzIChvZnRlbiBu b3QgdGVjaCBzYXZ2eSBvbmVzKSBuZWVkIHRvIHNwZWNpZnkgc2VwYXJhdGUgaG9zdG5hbWVzIGFu ZCBwb3J0cyBmb3IgSU1BUCBhbmQgbWVzc2FnZSBzdWJtaXNzaW9uLCBwbHVzIHBvdGVudGlhbGx5 IFVSTHMgZm9yIENhbERBViAvIENhcmREQVYgKHRoZSBsYXR0ZXIgMiBjb3VsZCByZWFzb25hYmx5 IGJlIGNvbWJpbmVkIHdpdGhvdXQgSUVURiBoZWxwIGJ1dCBzYWRseSBzZWxkb20gYXJlKS7CoCBX aXRob3V0IGZ1cnRoZXIgc3RhbmRhcmRpc2F0aW9uLCBubyB3b25kZXJmdWwgaW50ZXJmYWNlIGRl c2lnbiBjYW4gZXNjYXBlIGZyb20gdGhhdC7CoCBJIGNlcnRhaW5seSB0aGluayB0aGF0IGl0IHNo b3VsZCBiZSB3aXRoaW4gdGhlIHNjb3BlIG9mIHRoZSBJRVRGIHRvIGltcHJvdmUgdGhlIHN0YW5k YXJkcyB0byB0aGUgcG9pbnQgd2hlcmUgZ29vZCBpbnRlcmZhY2UgZGVzaWduIGlzIHBvc3NpYmxl LsKgIFRoYXQgZG9lc27igJl0IGFjdHVhbGx5IHJlcXVpcmUgbW92aW5nIHRvIGEgc2luZ2xlIHBy b3RvY29sLsKgIEFzIG1lbnRpb25lZCBiZWZvcmUgaW4gcmVsYXRpb24gdG8gYWdncmVnYXRlZCBz ZXJ2aWNlIGRpc2NvdmVyeSwgdGhpcyBjb3VsZCBiZSBhY2hpZXZlZCBieSBzdGFuZGFyZGlzaW5n IGEgYm9vdHN0cmFwcGluZyBtZWNoYW5pc20gd2hlcmUgdGhlIHVzZXIgb25seSBwcm92aWRlcyBt aW5pbWFsIGluZm9ybWF0aW9uIHdoaWNoIHBvaW50cyB0byBhIHN0b3JlIG9mIGRldGFpbGVkIGNv bmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gdGhhdCB0aGUgdXNlciBuZXZlciBuZWVkcyB0byBiZSBh d2FyZSBvZi7CoCBBbHRlcm5hdGl2ZWx5LCBvciBwZXJoYXBzIGluIGFkZGl0aW9uLCBoYXZpbmcg YSBzaW5nbGUgcHJvdG9jb2wgd291bGQgYWNoaWV2ZSBtb3N0IG9mIHRoZSBzYW1lIGFpbXMgLSBt dWNoIGFzIEFjdGl2ZVN5bmMgYWNoaWV2ZXMgYW5kIEkgaG9wZSBKTUFQIHdpbGwgYWNoaWV2ZS4K Pj4KPj4gSGF2aW5nIHRoZXNlIGZ1bmN0aW9ucyBlbWJlZGRlZCBpbnRvIGEgc2luZ2xlIHByb3Rv Y29sIGltcGxpY2l0bHnCoAo+PiByZXF1aXJlcyB0aGF0IHRoZXNlIGRpZmZlcmVudCBmdW5jdGlv bnMgc2hhcmUgdGhlIHNhbWUgY29uZmlndXJhdGlvbsKgCj4+IGRhdGEuIFdoaWxlIHN1Y2ggc2hh cmluZyBtaWdodCBiZSBjb21tb24gcHJhY3RpY2UsIHJlcXVpcmluZyB0aGXCoAo+PiBzaGFyaW5n IGxpbWl0cyBvcGVyYXRpb25hbCBjaG9pY2VzLsKgCj4KPiBSZXF1aXJpbmcgc2hhcmluZyB3b3Vs ZCBpbmRlZWQgbGltaXQgb3BlcmF0aW9uYWwgY2hvaWNlcyAtIHNvIGl0IHNob3VsZG7igJl0IGJl IHJlcXVpcmVkLsKgIEkgdGhpbmsgaXQgaXMgaW1wb3J0YW50IHRoYXQgYSBKTUFQIHNlcnZpY2Ug c2hvdWxkIGJlIGFibGUgdG8gb2ZmZXIgKGFuZCBhZHZlcnRpc2UpIHdoYXRldmVyIHN1YnNldCBv ZiBmdWxsIHNlcnZpY2VzIGl0IHdhbnRzIHRvLsKgIEluIHRoZSBtb3N0IGNvbW1vbiBzaXR1YXRp b24sIGEgc2luZ2xlIEpNQVAgc2VydmljZSB3b3VsZCBwcm92aWRlIG1haWwgYWNjZXNzLCBtYWls IHN1Ym1pc3Npb24sIGNvbnRhY3RzIGFjY2VzcywgY2FsZW5kYXIgYWNjZXNzIGV0YywgYnV0IHRo ZXJlIGlzIG5vIHJlYXNvbiB3aHkgbXVsdGlwbGUsIGRlZGljYXRlZCBKTUFQIHNlcnZpY2VzIGNv dWxkbuKAmXQgYmUgdXNlZCwgb25lIGp1c3QgZG9pbmcgbWFpbCBhY2Nlc3MsIG9uZSBkb2luZyBt YWlsIHN1Ym1pc3Npb24gZXRjLsKgIEluIHRoZSBtb3N0IGNvbW1vbiBzaXR1YXRpb24sIHlvdSB3 b3VsZCBiZSBtdWNoIGJldHRlciBvZmYgdGhhbiB5b3UgYXJlIG5vdy7CoCBJbiB0aGUgb3RoZXIg Y2FzZSwgeW91IHdvdWxkIGJlIG5vIHdvcnNlIG9mZiB0aGFuIHlvdSBhcmUgY3VycmVudGx5IGFu ZCBhdCBsZWFzdCB0aGVyZSB3b3VsZCBiZSBjb25zaXN0ZW5jeSBpbiBob3cgeW91IGNvbmZpZ3Vy ZSBlYWNoIHNlcnZpY2UuCj4KPiBSZWdhcmRzLAo+IEdyZW4gRWxsaW90Cj4K ----_com.android.email_4311542043677622 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PHAgZGlyPSJsdHIiPkhpLCBBbGwhPGJyPgpXZSBjYW4gdGFrZSBpbiBtaW5kIGFsbCBzdGVwcyBm b3IgY29tcGxleHNpdHkgb2YmIzE2MDsgY29uZmlndXJhdGlvbiBTTVRQICZhbXA7IElNQVAgJmFt cDsgSk1BUCBhbmQgaW50cm9kdWNlIGNvbW1hbmQgZm9yIGZldGNoIHRoaXMgc2V0dGluZyBmcm9t IHNlcnZlciBieSBKTUFQIGNvbW1hbmQgYW5kIGRlbGl2ZXIgaXQgdG8mbmJzcDsgbWFpbCBjbGll bnQuPC9wPgo8ZGl2IGNsYXNzPSJxdW90ZSI+MDcg0YTQtdCy0YAuIDIwMTcg0LMuIDIwOjMzINC/ 0L7Qu9GM0LfQvtCy0LDRgtC10LvRjCBHcmVuIEVsbGlvdCAmbHQ7ZmF0a3VkdUBnbWFpbC5jb20m Z3Q7INC90LDQv9C40YHQsNC7OjxiciB0eXBlPSdhdHRyaWJ1dGlvbic+PGJsb2NrcXVvdGUgY2xh c3M9InF1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mg c29saWQ7cGFkZGluZy1sZWZ0OjFleCI+PGh0bWw+PGhlYWQ+PHN0eWxlPmJvZHl7Zm9udC1mYW1p bHk6SGVsdmV0aWNhLEFyaWFsO2ZvbnQtc2l6ZToxM3B4fTwvc3R5bGU+PC9oZWFkPjxib2R5IHN0 eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+PGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCIgc3R5 bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSxBcmlhbDtmb250LXNpemU6MTNweDtjb2xvcjpyZ2Jh KDAsMCwwLDEuMCk7bWFyZ2luOjBweDtsaW5lLWhlaWdodDphdXRvIj48ZGl2IGNsYXNzPSJhaXJt YWlsX2V4dF9vbiI+RnJvbTrCoERhdmUgQ3JvY2tlcsKgPGEgaHJlZj0ibWFpbHRvOmRoY0BkY3Jv Y2tlci5uZXQiPiZsdDtkaGNAZGNyb2NrZXIubmV0Jmd0OzwvYT48YnI+UmVwbHk6wqA8YSBocmVm PSJtYWlsdG86ZGNyb2NrZXJAYmJpdy5uZXQiPmRjcm9ja2VyQGJiaXcubmV0PC9hPsKgPGEgaHJl Zj0ibWFpbHRvOmRjcm9ja2VyQGJiaXcubmV0Ij4mbHQ7ZGNyb2NrZXJAYmJpdy5uZXQmZ3Q7PC9h Pjxicj5EYXRlOsKgNyBGZWJydWFyeSAyMDE3IGF0IDE0OjIxOjEwPGJyPlRvOsKgR3JlbiBFbGxp b3TCoDxhIGhyZWY9Im1haWx0bzpmYXRrdWR1QGdtYWlsLmNvbSI+Jmx0O2ZhdGt1ZHVAZ21haWwu Y29tJmd0OzwvYT48YnI+Q2M6wqA8YSBocmVmPSJtYWlsdG86am1hcEBpZXRmLm9yZyI+am1hcEBp ZXRmLm9yZzwvYT7CoDxhIGhyZWY9Im1haWx0bzpqbWFwQGlldGYub3JnIj4mbHQ7am1hcEBpZXRm Lm9yZyZndDs8L2E+LMKgaWVzZ8KgPGEgaHJlZj0ibWFpbHRvOmllc2dAaWV0Zi5vcmciPiZsdDtp ZXNnQGlldGYub3JnJmd0OzwvYT4swqA8YSBocmVmPSJtYWlsdG86aWV0ZkBpZXRmLm9yZyI+aWV0 ZkBpZXRmLm9yZzwvYT7CoDxhIGhyZWY9Im1haWx0bzppZXRmQGlldGYub3JnIj4mbHQ7aWV0ZkBp ZXRmLm9yZyZndDs8L2E+PGJyPlN1YmplY3Q6wqDCoFJlOiBbSm1hcF0gV0cgUmV2aWV3OiBKU09O IE1haWwgQWNjZXNzIFByb3RvY29sIChqbWFwKSAtIHJlZHVjaW5nIGNvbmZpZ3VyYXRpb24gY29t cGxleGl0ecKgPGJyPjwvZGl2Pjxicj48ZGl2PjxkaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIg Y2xhc3M9ImNsZWFuX2JxIj48ZGl2PjwvZGl2PjxkaXY+T24gMi83LzIwMTcgMzoyNiBBTSwgR3Jl biBFbGxpb3Qgd3JvdGU6wqA8YnI+Jmd0OyBKdXN0IHRvIGFkZCBteSB2b2ljZSB0byB0aGUgY2Fs bCBmb3IgZWFzaWVyIGNvbmZpZ3VyYXRpb24gd2hlcmUgd2UgZG9u4oCZdMKgPGJyPiZndDsgZm9y Y2UgdXNlcnMgdG8gY29uZmlndXJlIGNvdW50bGVzcyBkaWZmZXJlbnQgdGhpbmdzLiBUcnlpbmcg dG8gc2V0dXAgYcKgPGJyPiZndDsgbmV3IGRldmljZSBmb3IgdXNlIHdpdGggb3BlbiBwcm90b2Nv bHMgaXMgYSBjb21wbGV0ZSBuaWdodG1hcmUgLSB5b3UgZW5kwqA8YnI+Jmd0OyB1cCBuZWVkaW5n IHRvIGNvbmZpZ3VyZSAyIHRoaW5ncyBmb3IgbWFpbCAoSU1BUCBhbmQgU01UUCnCoDxicj4uLi7C oDxicj4mZ3Q7IEl0IHdvdWxkIGJlIG5pY2UgdG8gc2VlIGNvbmZpZyBkaWFsb2dzIHdoZXJlIHVz ZXLigJlzIGFyZSBhc2tlZCBmb3LCoDxicj4mZ3Q7IG1pbmltYWwgaW5mb3JtYXRpb24gKHVzZXIg bmFtZSwgcGVyaGFwcyBzZXJ2ZXIgbmFtZSkgYW5kIHRoZW4gdGhlIGRldmljZcKgPGJyPiZndDsg ZGlzY292ZXJzIHdoYXQgaXMgYXZhaWxhYmxlIHRoZXJlIChNYWlsL0NvbnRhY3RzL0NhbGVuZGFy L+KApikgYW5kIG9mZmVyc8KgPGJyPiZndDsgdGhlIHVzZXIgYSB3YXkgdG8gc2VsZWN0IHRoZW0g YW5kwqA8YnI+PGJyPjxicj5UaGlzIGlzc3VlIGlzIGZvciB1c2VyIGludGVyZmFjZSBkZXNpZ24s IG5vdCB1bmRlcmx5aW5nIHByb3RvY29sIGRlc2lnbi7CoDxicj5IZW5jZSB3aGlsZSBpdCBpcyBl eHRyZW1lbHkgaW1wb3J0YW50IGluIHRlcm1zIG9mIHVzYWJpbGl0eSwgaXQgaXPCoDxicj5vdXRz aWRlIHRoZSBzY29wZSBvZiB0aGUgSUVURi7CoDxicj48YnI+PC9kaXY+PC9ibG9ja3F1b3RlPjxw PldpdGggdGhlIGN1cnJlbnQgc3RhbmRhcmRzIGxhbmRzY2FwZSwgdGhlcmUgaXMgbm8gd2F5IHJv dW5kIHRoZSBmYWN0IHRoYXQgdXNlcnMgKG9mdGVuIG5vdCB0ZWNoIHNhdnZ5IG9uZXMpIG5lZWQg dG8gc3BlY2lmeSBzZXBhcmF0ZSBob3N0bmFtZXMgYW5kIHBvcnRzIGZvciBJTUFQIGFuZCBtZXNz YWdlIHN1Ym1pc3Npb24sIHBsdXMgcG90ZW50aWFsbHkgVVJMcyBmb3IgQ2FsREFWIC8gQ2FyZERB ViAodGhlIGxhdHRlciAyIGNvdWxkIHJlYXNvbmFibHkgYmUgY29tYmluZWQgd2l0aG91dCBJRVRG IGhlbHAgYnV0IHNhZGx5IHNlbGRvbSBhcmUpLsKgIFdpdGhvdXQgZnVydGhlciBzdGFuZGFyZGlz YXRpb24sIG5vIHdvbmRlcmZ1bCBpbnRlcmZhY2UgZGVzaWduIGNhbiBlc2NhcGUgZnJvbSB0aGF0 LsKgIEkgY2VydGFpbmx5IHRoaW5rIHRoYXQgaXQgc2hvdWxkIGJlIHdpdGhpbiB0aGUgc2NvcGUg b2YgdGhlIElFVEYgdG8gaW1wcm92ZSB0aGUgc3RhbmRhcmRzIHRvIHRoZSBwb2ludCB3aGVyZSBn b29kIGludGVyZmFjZSBkZXNpZ24gaXMgcG9zc2libGUuwqAgVGhhdCBkb2VzbuKAmXQgYWN0dWFs bHkgcmVxdWlyZSBtb3ZpbmcgdG8gYSBzaW5nbGUgcHJvdG9jb2wuwqAgQXMgbWVudGlvbmVkIGJl Zm9yZSBpbiByZWxhdGlvbiB0byBhZ2dyZWdhdGVkIHNlcnZpY2UgZGlzY292ZXJ5LCB0aGlzIGNv dWxkIGJlIGFjaGlldmVkIGJ5IHN0YW5kYXJkaXNpbmcgYSBib290c3RyYXBwaW5nIG1lY2hhbmlz bSB3aGVyZSB0aGUgdXNlciBvbmx5IHByb3ZpZGVzIG1pbmltYWwgaW5mb3JtYXRpb24gd2hpY2gg cG9pbnRzIHRvIGEgc3RvcmUgb2YgZGV0YWlsZWQgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiB0 aGF0IHRoZSB1c2VyIG5ldmVyIG5lZWRzIHRvIGJlIGF3YXJlIG9mLsKgIEFsdGVybmF0aXZlbHks IG9yIHBlcmhhcHMgaW4gYWRkaXRpb24sIGhhdmluZyBhIHNpbmdsZSBwcm90b2NvbCB3b3VsZCBh Y2hpZXZlIG1vc3Qgb2YgdGhlIHNhbWUgYWltcyAtIG11Y2ggYXMgQWN0aXZlU3luYyBhY2hpZXZl cyBhbmQgSSBob3BlIEpNQVAgd2lsbCBhY2hpZXZlLjwvcD48YmxvY2txdW90ZSB0eXBlPSJjaXRl IiBjbGFzcz0iY2xlYW5fYnEiPkhhdmluZyB0aGVzZSBmdW5jdGlvbnMgZW1iZWRkZWQgaW50byBh IHNpbmdsZSBwcm90b2NvbCBpbXBsaWNpdGx5wqA8YnI+cmVxdWlyZXMgdGhhdCB0aGVzZSBkaWZm ZXJlbnQgZnVuY3Rpb25zIHNoYXJlIHRoZSBzYW1lIGNvbmZpZ3VyYXRpb27CoDxicj5kYXRhLiBX aGlsZSBzdWNoIHNoYXJpbmcgbWlnaHQgYmUgY29tbW9uIHByYWN0aWNlLCByZXF1aXJpbmcgdGhl wqA8YnI+c2hhcmluZyBsaW1pdHMgb3BlcmF0aW9uYWwgY2hvaWNlcy7CoDwvYmxvY2txdW90ZT48 L2Rpdj48cD5SZXF1aXJpbmcgc2hhcmluZyB3b3VsZCBpbmRlZWQgbGltaXQgb3BlcmF0aW9uYWwg Y2hvaWNlcyAtIHNvIGl0IHNob3VsZG7igJl0IGJlIHJlcXVpcmVkLsKgIEkgdGhpbmsgaXQgaXMg aW1wb3J0YW50IHRoYXQgYSBKTUFQIHNlcnZpY2Ugc2hvdWxkIGJlIGFibGUgdG8gb2ZmZXIgKGFu ZCBhZHZlcnRpc2UpIHdoYXRldmVyIHN1YnNldCBvZiBmdWxsIHNlcnZpY2VzIGl0IHdhbnRzIHRv LsKgIEluIHRoZSBtb3N0IGNvbW1vbiBzaXR1YXRpb24sIGEgc2luZ2xlIEpNQVAgc2VydmljZSB3 b3VsZCBwcm92aWRlIG1haWwgYWNjZXNzLCBtYWlsIHN1Ym1pc3Npb24sIGNvbnRhY3RzIGFjY2Vz cywgY2FsZW5kYXIgYWNjZXNzIGV0YywgYnV0IHRoZXJlIGlzIG5vIHJlYXNvbiB3aHkgbXVsdGlw bGUsIGRlZGljYXRlZCBKTUFQIHNlcnZpY2VzIGNvdWxkbuKAmXQgYmUgdXNlZCwgb25lIGp1c3Qg ZG9pbmcgbWFpbCBhY2Nlc3MsIG9uZSBkb2luZyBtYWlsIHN1Ym1pc3Npb24gZXRjLsKgIEluIHRo ZSBtb3N0IGNvbW1vbiBzaXR1YXRpb24sIHlvdSB3b3VsZCBiZSBtdWNoIGJldHRlciBvZmYgdGhh biB5b3UgYXJlIG5vdy7CoCBJbiB0aGUgb3RoZXIgY2FzZSwgeW91IHdvdWxkIGJlIG5vIHdvcnNl IG9mZiB0aGFuIHlvdSBhcmUgY3VycmVudGx5IGFuZCBhdCBsZWFzdCB0aGVyZSB3b3VsZCBiZSBj b25zaXN0ZW5jeSBpbiBob3cgeW91IGNvbmZpZ3VyZSBlYWNoIHNlcnZpY2UuPC9wPjwvZGl2Pjwv ZGl2PiA8ZGl2IGlkPSJibG9vcF9zaWduXzE0ODY0Nzk2NTY5MDkwMzkxMDQiIGNsYXNzPSJibG9v cF9zaWduIj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTpoZWx2ZXRpY2EsYXJpYWw7Zm9udC1zaXpl OjEzcHgiPlJlZ2FyZHMsPC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6aGVsdmV0aWNhLGFy aWFsO2ZvbnQtc2l6ZToxM3B4Ij5HcmVuIEVsbGlvdDxicj48L2Rpdj48L2Rpdj4gPGRpdiBjbGFz cz0iYWlybWFpbF9leHRfb24iIHN0eWxlPSJjb2xvcjpibGFjayI+PGJyPjwvZGl2PjwvYm9keT48 L2h0bWw+DQo8L2Jsb2NrcXVvdGU+PC9kaXY+ ----_com.android.email_4311542043677622-- From nobody Tue Feb 7 08:55:09 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 1628B129D6D; Tue, 7 Feb 2017 08:55:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=mail.ru 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 xcVYDwNGMVLO; Tue, 7 Feb 2017 08:55:04 -0800 (PST) Received: from smtp36.i.mail.ru (smtp36.i.mail.ru [94.100.177.96]) (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 2F361129D6F; Tue, 7 Feb 2017 08:55:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail2; h=Content-Type:MIME-Version:Cc:To:From:Message-ID:Subject:Date; bh=Br8O/oZHJano5rhieJzHr9x3PDGlvJnfgrqXLVLT3tw=; b=Df824uOmQZ8e7PuIlsM5t6ohPx5yLnlK3aPIemJFvYdF7Zll68G4zuXsXT5zlDzRoPuST1rEFEW6wKymjEGu00hLhdxG+pBdlKqBt4DyQYLz3N/MMSBQhPV2OM5zJoaLuLbjDhgXsRzRdk50L/4FHvUcTMHaF1iKhm6NEjLY7jI=; Received: from [176.59.199.74] (port=47085 helo=[10.36.109.185]) by smtp36.i.mail.ru with esmtpa (envelope-from ) id 1cb92i-0005E5-EL; Tue, 07 Feb 2017 19:55:01 +0300 Date: Tue, 07 Feb 2017 21:54:54 +0500 Message-ID: From: podkorytov To: dcrocker@bbiw.net, Dave Crocker , Gren Elliot MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_4317060067944103" Authentication-Results: smtp36.i.mail.ru; auth=pass smtp.auth=podkorytov@mail.ru smtp.mailfrom=podkorytov@mail.ru X-E1FCDC63: 7AEC6E04E31B87BD92D2D42BF11EAD064B72E82432766FBE X-E1FCDC64: D6B2847E708107FE83B8D6356E4914A801EED8DA67EB6A04E68A12C53AD7410A X-Mailru-Sender: DC72CE790D2AA1408AD3CB0182DF755B97D55ED2E582E8FCB170BAC85C1005C9B3950B0ED0D261EAADAB024B4846C063 X-Mras: OK Archived-At: Cc: jmap@ietf.org, ietf@ietf.org, iesg Subject: Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 16:55:07 -0000 ----_com.android.email_4317060067944103 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Q29uZmlndXJhdGlvbiBmb3IgU01UUCAmIElNQVAgaW4gb3RoZXIgaGFuZCBkb2VzJ3QgaGF2ZSBh IHNlcmlvdXMgc2Vuc2UgLCBTTVRQIGFuZCBJTUFQIHdvcmtzIG9uIHNlcnZlciBzaWRlIGFuZCBt YXkgYmUgY29uZmlndXJlZCBhdCBvbmNlIGJ5IGl0IGFkbWluaXN0cmF0b3IuIApKTUFQIHdvcmtz IG9uIHRvcCBvZiBTTVRQICYgSU1BUCBhbmQgY2xpZW50IG1heSBhbmQgcHJvYmFibHkgbXVzdCBs aXZlIHdpdGggemVybyBrbm93bGVkZ2UgYWJvdXQgbG93IGxldmVsIGxheWVycyBzdWNoIGFzIFNN VFAgJiBJTUFQIGFuZCBpdCBjb25maWd1cmF0aW9uLgoKMDcg0YTQtdCy0YAuIDIwMTcg0LMuIDIw OjMzINC/0L7Qu9GM0LfQvtCy0LDRgtC10LvRjCBHcmVuIEVsbGlvdCA8ZmF0a3VkdUBnbWFpbC5j b20+INC90LDQv9C40YHQsNC7Ogo+Cj4gRnJvbTrCoERhdmUgQ3JvY2tlcsKgPGRoY0BkY3JvY2tl ci5uZXQ+Cj4gUmVwbHk6wqBkY3JvY2tlckBiYml3Lm5ldMKgPGRjcm9ja2VyQGJiaXcubmV0Pgo+ IERhdGU6wqA3IEZlYnJ1YXJ5IDIwMTcgYXQgMTQ6MjE6MTAKPiBUbzrCoEdyZW4gRWxsaW90wqA8 ZmF0a3VkdUBnbWFpbC5jb20+Cj4gQ2M6wqBqbWFwQGlldGYub3JnwqA8am1hcEBpZXRmLm9yZz4s wqBpZXNnwqA8aWVzZ0BpZXRmLm9yZz4swqBpZXRmQGlldGYub3JnwqA8aWV0ZkBpZXRmLm9yZz4K PiBTdWJqZWN0OsKgwqBSZTogW0ptYXBdIFdHIFJldmlldzogSlNPTiBNYWlsIEFjY2VzcyBQcm90 b2NvbCAoam1hcCkgLSByZWR1Y2luZyBjb25maWd1cmF0aW9uIGNvbXBsZXhpdHnCoAo+Cj4+IE9u IDIvNy8yMDE3IDM6MjYgQU0sIEdyZW4gRWxsaW90IHdyb3RlOsKgCj4+ID4gSnVzdCB0byBhZGQg bXkgdm9pY2UgdG8gdGhlIGNhbGwgZm9yIGVhc2llciBjb25maWd1cmF0aW9uIHdoZXJlIHdlIGRv buKAmXTCoAo+PiA+IGZvcmNlIHVzZXJzIHRvIGNvbmZpZ3VyZSBjb3VudGxlc3MgZGlmZmVyZW50 IHRoaW5ncy4gVHJ5aW5nIHRvIHNldHVwIGHCoAo+PiA+IG5ldyBkZXZpY2UgZm9yIHVzZSB3aXRo IG9wZW4gcHJvdG9jb2xzIGlzIGEgY29tcGxldGUgbmlnaHRtYXJlIC0geW91IGVuZMKgCj4+ID4g dXAgbmVlZGluZyB0byBjb25maWd1cmUgMiB0aGluZ3MgZm9yIG1haWwgKElNQVAgYW5kIFNNVFAp wqAKPj4gLi4uwqAKPj4gPiBJdCB3b3VsZCBiZSBuaWNlIHRvIHNlZSBjb25maWcgZGlhbG9ncyB3 aGVyZSB1c2Vy4oCZcyBhcmUgYXNrZWQgZm9ywqAKPj4gPiBtaW5pbWFsIGluZm9ybWF0aW9uICh1 c2VyIG5hbWUsIHBlcmhhcHMgc2VydmVyIG5hbWUpIGFuZCB0aGVuIHRoZSBkZXZpY2XCoAo+PiA+ IGRpc2NvdmVycyB3aGF0IGlzIGF2YWlsYWJsZSB0aGVyZSAoTWFpbC9Db250YWN0cy9DYWxlbmRh ci/igKYpIGFuZCBvZmZlcnPCoAo+PiA+IHRoZSB1c2VyIGEgd2F5IHRvIHNlbGVjdCB0aGVtIGFu ZMKgCj4+Cj4+Cj4+IFRoaXMgaXNzdWUgaXMgZm9yIHVzZXIgaW50ZXJmYWNlIGRlc2lnbiwgbm90 IHVuZGVybHlpbmcgcHJvdG9jb2wgZGVzaWduLsKgCj4+IEhlbmNlIHdoaWxlIGl0IGlzIGV4dHJl bWVseSBpbXBvcnRhbnQgaW4gdGVybXMgb2YgdXNhYmlsaXR5LCBpdCBpc8KgCj4+IG91dHNpZGUg dGhlIHNjb3BlIG9mIHRoZSBJRVRGLsKgCj4+Cj4gV2l0aCB0aGUgY3VycmVudCBzdGFuZGFyZHMg bGFuZHNjYXBlLCB0aGVyZSBpcyBubyB3YXkgcm91bmQgdGhlIGZhY3QgdGhhdCB1c2VycyAob2Z0 ZW4gbm90IHRlY2ggc2F2dnkgb25lcykgbmVlZCB0byBzcGVjaWZ5IHNlcGFyYXRlIGhvc3RuYW1l cyBhbmQgcG9ydHMgZm9yIElNQVAgYW5kIG1lc3NhZ2Ugc3VibWlzc2lvbiwgcGx1cyBwb3RlbnRp YWxseSBVUkxzIGZvciBDYWxEQVYgLyBDYXJkREFWICh0aGUgbGF0dGVyIDIgY291bGQgcmVhc29u YWJseSBiZSBjb21iaW5lZCB3aXRob3V0IElFVEYgaGVscCBidXQgc2FkbHkgc2VsZG9tIGFyZSku wqAgV2l0aG91dCBmdXJ0aGVyIHN0YW5kYXJkaXNhdGlvbiwgbm8gd29uZGVyZnVsIGludGVyZmFj ZSBkZXNpZ24gY2FuIGVzY2FwZSBmcm9tIHRoYXQuwqAgSSBjZXJ0YWlubHkgdGhpbmsgdGhhdCBp dCBzaG91bGQgYmUgd2l0aGluIHRoZSBzY29wZSBvZiB0aGUgSUVURiB0byBpbXByb3ZlIHRoZSBz dGFuZGFyZHMgdG8gdGhlIHBvaW50IHdoZXJlIGdvb2QgaW50ZXJmYWNlIGRlc2lnbiBpcyBwb3Nz aWJsZS7CoCBUaGF0IGRvZXNu4oCZdCBhY3R1YWxseSByZXF1aXJlIG1vdmluZyB0byBhIHNpbmds ZSBwcm90b2NvbC7CoCBBcyBtZW50aW9uZWQgYmVmb3JlIGluIHJlbGF0aW9uIHRvIGFnZ3JlZ2F0 ZWQgc2VydmljZSBkaXNjb3ZlcnksIHRoaXMgY291bGQgYmUgYWNoaWV2ZWQgYnkgc3RhbmRhcmRp c2luZyBhIGJvb3RzdHJhcHBpbmcgbWVjaGFuaXNtIHdoZXJlIHRoZSB1c2VyIG9ubHkgcHJvdmlk ZXMgbWluaW1hbCBpbmZvcm1hdGlvbiB3aGljaCBwb2ludHMgdG8gYSBzdG9yZSBvZiBkZXRhaWxl ZCBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uIHRoYXQgdGhlIHVzZXIgbmV2ZXIgbmVlZHMgdG8g YmUgYXdhcmUgb2YuwqAgQWx0ZXJuYXRpdmVseSwgb3IgcGVyaGFwcyBpbiBhZGRpdGlvbiwgaGF2 aW5nIGEgc2luZ2xlIHByb3RvY29sIHdvdWxkIGFjaGlldmUgbW9zdCBvZiB0aGUgc2FtZSBhaW1z IC0gbXVjaCBhcyBBY3RpdmVTeW5jIGFjaGlldmVzIGFuZCBJIGhvcGUgSk1BUCB3aWxsIGFjaGll dmUuCj4+Cj4+IEhhdmluZyB0aGVzZSBmdW5jdGlvbnMgZW1iZWRkZWQgaW50byBhIHNpbmdsZSBw cm90b2NvbCBpbXBsaWNpdGx5wqAKPj4gcmVxdWlyZXMgdGhhdCB0aGVzZSBkaWZmZXJlbnQgZnVu Y3Rpb25zIHNoYXJlIHRoZSBzYW1lIGNvbmZpZ3VyYXRpb27CoAo+PiBkYXRhLiBXaGlsZSBzdWNo IHNoYXJpbmcgbWlnaHQgYmUgY29tbW9uIHByYWN0aWNlLCByZXF1aXJpbmcgdGhlwqAKPj4gc2hh cmluZyBsaW1pdHMgb3BlcmF0aW9uYWwgY2hvaWNlcy7CoAo+Cj4gUmVxdWlyaW5nIHNoYXJpbmcg d291bGQgaW5kZWVkIGxpbWl0IG9wZXJhdGlvbmFsIGNob2ljZXMgLSBzbyBpdCBzaG91bGRu4oCZ dCBiZSByZXF1aXJlZC7CoCBJIHRoaW5rIGl0IGlzIGltcG9ydGFudCB0aGF0IGEgSk1BUCBzZXJ2 aWNlIHNob3VsZCBiZSBhYmxlIHRvIG9mZmVyIChhbmQgYWR2ZXJ0aXNlKSB3aGF0ZXZlciBzdWJz ZXQgb2YgZnVsbCBzZXJ2aWNlcyBpdCB3YW50cyB0by7CoCBJbiB0aGUgbW9zdCBjb21tb24gc2l0 dWF0aW9uLCBhIHNpbmdsZSBKTUFQIHNlcnZpY2Ugd291bGQgcHJvdmlkZSBtYWlsIGFjY2Vzcywg bWFpbCBzdWJtaXNzaW9uLCBjb250YWN0cyBhY2Nlc3MsIGNhbGVuZGFyIGFjY2VzcyBldGMsIGJ1 dCB0aGVyZSBpcyBubyByZWFzb24gd2h5IG11bHRpcGxlLCBkZWRpY2F0ZWQgSk1BUCBzZXJ2aWNl cyBjb3VsZG7igJl0IGJlIHVzZWQsIG9uZSBqdXN0IGRvaW5nIG1haWwgYWNjZXNzLCBvbmUgZG9p bmcgbWFpbCBzdWJtaXNzaW9uIGV0Yy7CoCBJbiB0aGUgbW9zdCBjb21tb24gc2l0dWF0aW9uLCB5 b3Ugd291bGQgYmUgbXVjaCBiZXR0ZXIgb2ZmIHRoYW4geW91IGFyZSBub3cuwqAgSW4gdGhlIG90 aGVyIGNhc2UsIHlvdSB3b3VsZCBiZSBubyB3b3JzZSBvZmYgdGhhbiB5b3UgYXJlIGN1cnJlbnRs eSBhbmQgYXQgbGVhc3QgdGhlcmUgd291bGQgYmUgY29uc2lzdGVuY3kgaW4gaG93IHlvdSBjb25m aWd1cmUgZWFjaCBzZXJ2aWNlLgo+Cj4gUmVnYXJkcywKPiBHcmVuIEVsbGlvdAo+Cg== ----_com.android.email_4317060067944103 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PHAgZGlyPSJsdHIiPkNvbmZpZ3VyYXRpb24gZm9yIFNNVFAgJmFtcDsgSU1BUCBpbiBvdGhlciBo YW5kIGRvZXMndCBoYXZlIGEgc2VyaW91cyBzZW5zZSAsIFNNVFAgYW5kIElNQVAgd29ya3Mgb24g c2VydmVyIHNpZGUgYW5kIG1heSBiZSBjb25maWd1cmVkIGF0IG9uY2UgYnkgaXQgYWRtaW5pc3Ry YXRvci4gPGJyPgpKTUFQIHdvcmtzIG9uIHRvcCBvZiBTTVRQICZhbXA7IElNQVAgYW5kIGNsaWVu dCBtYXkgYW5kIHByb2JhYmx5IG11c3QgbGl2ZSB3aXRoIHplcm8ga25vd2xlZGdlIGFib3V0IGxv dyBsZXZlbCBsYXllcnMgc3VjaCBhcyBTTVRQICZhbXA7IElNQVAgYW5kIGl0IGNvbmZpZ3VyYXRp b24uPGJyPgogPC9wPgo8ZGl2IGNsYXNzPSJxdW90ZSI+MDcg0YTQtdCy0YAuIDIwMTcg0LMuIDIw OjMzINC/0L7Qu9GM0LfQvtCy0LDRgtC10LvRjCBHcmVuIEVsbGlvdCAmbHQ7ZmF0a3VkdUBnbWFp bC5jb20mZ3Q7INC90LDQv9C40YHQsNC7OjxiciB0eXBlPSdhdHRyaWJ1dGlvbic+PGJsb2NrcXVv dGUgY2xhc3M9InF1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4 ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+PGh0bWw+PGhlYWQ+PHN0eWxlPmJvZHl7Zm9u dC1mYW1pbHk6SGVsdmV0aWNhLEFyaWFsO2ZvbnQtc2l6ZToxM3B4fTwvc3R5bGU+PC9oZWFkPjxi b2R5IHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+PGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9u dCIgc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSxBcmlhbDtmb250LXNpemU6MTNweDtjb2xv cjpyZ2JhKDAsMCwwLDEuMCk7bWFyZ2luOjBweDtsaW5lLWhlaWdodDphdXRvIj48ZGl2IGNsYXNz PSJhaXJtYWlsX2V4dF9vbiI+RnJvbTrCoERhdmUgQ3JvY2tlcsKgPGEgaHJlZj0ibWFpbHRvOmRo Y0BkY3JvY2tlci5uZXQiPiZsdDtkaGNAZGNyb2NrZXIubmV0Jmd0OzwvYT48YnI+UmVwbHk6wqA8 YSBocmVmPSJtYWlsdG86ZGNyb2NrZXJAYmJpdy5uZXQiPmRjcm9ja2VyQGJiaXcubmV0PC9hPsKg PGEgaHJlZj0ibWFpbHRvOmRjcm9ja2VyQGJiaXcubmV0Ij4mbHQ7ZGNyb2NrZXJAYmJpdy5uZXQm Z3Q7PC9hPjxicj5EYXRlOsKgNyBGZWJydWFyeSAyMDE3IGF0IDE0OjIxOjEwPGJyPlRvOsKgR3Jl biBFbGxpb3TCoDxhIGhyZWY9Im1haWx0bzpmYXRrdWR1QGdtYWlsLmNvbSI+Jmx0O2ZhdGt1ZHVA Z21haWwuY29tJmd0OzwvYT48YnI+Q2M6wqA8YSBocmVmPSJtYWlsdG86am1hcEBpZXRmLm9yZyI+ am1hcEBpZXRmLm9yZzwvYT7CoDxhIGhyZWY9Im1haWx0bzpqbWFwQGlldGYub3JnIj4mbHQ7am1h cEBpZXRmLm9yZyZndDs8L2E+LMKgaWVzZ8KgPGEgaHJlZj0ibWFpbHRvOmllc2dAaWV0Zi5vcmci PiZsdDtpZXNnQGlldGYub3JnJmd0OzwvYT4swqA8YSBocmVmPSJtYWlsdG86aWV0ZkBpZXRmLm9y ZyI+aWV0ZkBpZXRmLm9yZzwvYT7CoDxhIGhyZWY9Im1haWx0bzppZXRmQGlldGYub3JnIj4mbHQ7 aWV0ZkBpZXRmLm9yZyZndDs8L2E+PGJyPlN1YmplY3Q6wqDCoFJlOiBbSm1hcF0gV0cgUmV2aWV3 OiBKU09OIE1haWwgQWNjZXNzIFByb3RvY29sIChqbWFwKSAtIHJlZHVjaW5nIGNvbmZpZ3VyYXRp b24gY29tcGxleGl0ecKgPGJyPjwvZGl2Pjxicj48ZGl2PjxkaXY+PGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2xhc3M9ImNsZWFuX2JxIj48ZGl2PjwvZGl2PjxkaXY+T24gMi83LzIwMTcgMzoyNiBB TSwgR3JlbiBFbGxpb3Qgd3JvdGU6wqA8YnI+Jmd0OyBKdXN0IHRvIGFkZCBteSB2b2ljZSB0byB0 aGUgY2FsbCBmb3IgZWFzaWVyIGNvbmZpZ3VyYXRpb24gd2hlcmUgd2UgZG9u4oCZdMKgPGJyPiZn dDsgZm9yY2UgdXNlcnMgdG8gY29uZmlndXJlIGNvdW50bGVzcyBkaWZmZXJlbnQgdGhpbmdzLiBU cnlpbmcgdG8gc2V0dXAgYcKgPGJyPiZndDsgbmV3IGRldmljZSBmb3IgdXNlIHdpdGggb3BlbiBw cm90b2NvbHMgaXMgYSBjb21wbGV0ZSBuaWdodG1hcmUgLSB5b3UgZW5kwqA8YnI+Jmd0OyB1cCBu ZWVkaW5nIHRvIGNvbmZpZ3VyZSAyIHRoaW5ncyBmb3IgbWFpbCAoSU1BUCBhbmQgU01UUCnCoDxi cj4uLi7CoDxicj4mZ3Q7IEl0IHdvdWxkIGJlIG5pY2UgdG8gc2VlIGNvbmZpZyBkaWFsb2dzIHdo ZXJlIHVzZXLigJlzIGFyZSBhc2tlZCBmb3LCoDxicj4mZ3Q7IG1pbmltYWwgaW5mb3JtYXRpb24g KHVzZXIgbmFtZSwgcGVyaGFwcyBzZXJ2ZXIgbmFtZSkgYW5kIHRoZW4gdGhlIGRldmljZcKgPGJy PiZndDsgZGlzY292ZXJzIHdoYXQgaXMgYXZhaWxhYmxlIHRoZXJlIChNYWlsL0NvbnRhY3RzL0Nh bGVuZGFyL+KApikgYW5kIG9mZmVyc8KgPGJyPiZndDsgdGhlIHVzZXIgYSB3YXkgdG8gc2VsZWN0 IHRoZW0gYW5kwqA8YnI+PGJyPjxicj5UaGlzIGlzc3VlIGlzIGZvciB1c2VyIGludGVyZmFjZSBk ZXNpZ24sIG5vdCB1bmRlcmx5aW5nIHByb3RvY29sIGRlc2lnbi7CoDxicj5IZW5jZSB3aGlsZSBp dCBpcyBleHRyZW1lbHkgaW1wb3J0YW50IGluIHRlcm1zIG9mIHVzYWJpbGl0eSwgaXQgaXPCoDxi cj5vdXRzaWRlIHRoZSBzY29wZSBvZiB0aGUgSUVURi7CoDxicj48YnI+PC9kaXY+PC9ibG9ja3F1 b3RlPjxwPldpdGggdGhlIGN1cnJlbnQgc3RhbmRhcmRzIGxhbmRzY2FwZSwgdGhlcmUgaXMgbm8g d2F5IHJvdW5kIHRoZSBmYWN0IHRoYXQgdXNlcnMgKG9mdGVuIG5vdCB0ZWNoIHNhdnZ5IG9uZXMp IG5lZWQgdG8gc3BlY2lmeSBzZXBhcmF0ZSBob3N0bmFtZXMgYW5kIHBvcnRzIGZvciBJTUFQIGFu ZCBtZXNzYWdlIHN1Ym1pc3Npb24sIHBsdXMgcG90ZW50aWFsbHkgVVJMcyBmb3IgQ2FsREFWIC8g Q2FyZERBViAodGhlIGxhdHRlciAyIGNvdWxkIHJlYXNvbmFibHkgYmUgY29tYmluZWQgd2l0aG91 dCBJRVRGIGhlbHAgYnV0IHNhZGx5IHNlbGRvbSBhcmUpLsKgIFdpdGhvdXQgZnVydGhlciBzdGFu ZGFyZGlzYXRpb24sIG5vIHdvbmRlcmZ1bCBpbnRlcmZhY2UgZGVzaWduIGNhbiBlc2NhcGUgZnJv bSB0aGF0LsKgIEkgY2VydGFpbmx5IHRoaW5rIHRoYXQgaXQgc2hvdWxkIGJlIHdpdGhpbiB0aGUg c2NvcGUgb2YgdGhlIElFVEYgdG8gaW1wcm92ZSB0aGUgc3RhbmRhcmRzIHRvIHRoZSBwb2ludCB3 aGVyZSBnb29kIGludGVyZmFjZSBkZXNpZ24gaXMgcG9zc2libGUuwqAgVGhhdCBkb2VzbuKAmXQg YWN0dWFsbHkgcmVxdWlyZSBtb3ZpbmcgdG8gYSBzaW5nbGUgcHJvdG9jb2wuwqAgQXMgbWVudGlv bmVkIGJlZm9yZSBpbiByZWxhdGlvbiB0byBhZ2dyZWdhdGVkIHNlcnZpY2UgZGlzY292ZXJ5LCB0 aGlzIGNvdWxkIGJlIGFjaGlldmVkIGJ5IHN0YW5kYXJkaXNpbmcgYSBib290c3RyYXBwaW5nIG1l Y2hhbmlzbSB3aGVyZSB0aGUgdXNlciBvbmx5IHByb3ZpZGVzIG1pbmltYWwgaW5mb3JtYXRpb24g d2hpY2ggcG9pbnRzIHRvIGEgc3RvcmUgb2YgZGV0YWlsZWQgY29uZmlndXJhdGlvbiBpbmZvcm1h dGlvbiB0aGF0IHRoZSB1c2VyIG5ldmVyIG5lZWRzIHRvIGJlIGF3YXJlIG9mLsKgIEFsdGVybmF0 aXZlbHksIG9yIHBlcmhhcHMgaW4gYWRkaXRpb24sIGhhdmluZyBhIHNpbmdsZSBwcm90b2NvbCB3 b3VsZCBhY2hpZXZlIG1vc3Qgb2YgdGhlIHNhbWUgYWltcyAtIG11Y2ggYXMgQWN0aXZlU3luYyBh Y2hpZXZlcyBhbmQgSSBob3BlIEpNQVAgd2lsbCBhY2hpZXZlLjwvcD48YmxvY2txdW90ZSB0eXBl PSJjaXRlIiBjbGFzcz0iY2xlYW5fYnEiPkhhdmluZyB0aGVzZSBmdW5jdGlvbnMgZW1iZWRkZWQg aW50byBhIHNpbmdsZSBwcm90b2NvbCBpbXBsaWNpdGx5wqA8YnI+cmVxdWlyZXMgdGhhdCB0aGVz ZSBkaWZmZXJlbnQgZnVuY3Rpb25zIHNoYXJlIHRoZSBzYW1lIGNvbmZpZ3VyYXRpb27CoDxicj5k YXRhLiBXaGlsZSBzdWNoIHNoYXJpbmcgbWlnaHQgYmUgY29tbW9uIHByYWN0aWNlLCByZXF1aXJp bmcgdGhlwqA8YnI+c2hhcmluZyBsaW1pdHMgb3BlcmF0aW9uYWwgY2hvaWNlcy7CoDwvYmxvY2tx dW90ZT48L2Rpdj48cD5SZXF1aXJpbmcgc2hhcmluZyB3b3VsZCBpbmRlZWQgbGltaXQgb3BlcmF0 aW9uYWwgY2hvaWNlcyAtIHNvIGl0IHNob3VsZG7igJl0IGJlIHJlcXVpcmVkLsKgIEkgdGhpbmsg aXQgaXMgaW1wb3J0YW50IHRoYXQgYSBKTUFQIHNlcnZpY2Ugc2hvdWxkIGJlIGFibGUgdG8gb2Zm ZXIgKGFuZCBhZHZlcnRpc2UpIHdoYXRldmVyIHN1YnNldCBvZiBmdWxsIHNlcnZpY2VzIGl0IHdh bnRzIHRvLsKgIEluIHRoZSBtb3N0IGNvbW1vbiBzaXR1YXRpb24sIGEgc2luZ2xlIEpNQVAgc2Vy dmljZSB3b3VsZCBwcm92aWRlIG1haWwgYWNjZXNzLCBtYWlsIHN1Ym1pc3Npb24sIGNvbnRhY3Rz IGFjY2VzcywgY2FsZW5kYXIgYWNjZXNzIGV0YywgYnV0IHRoZXJlIGlzIG5vIHJlYXNvbiB3aHkg bXVsdGlwbGUsIGRlZGljYXRlZCBKTUFQIHNlcnZpY2VzIGNvdWxkbuKAmXQgYmUgdXNlZCwgb25l IGp1c3QgZG9pbmcgbWFpbCBhY2Nlc3MsIG9uZSBkb2luZyBtYWlsIHN1Ym1pc3Npb24gZXRjLsKg IEluIHRoZSBtb3N0IGNvbW1vbiBzaXR1YXRpb24sIHlvdSB3b3VsZCBiZSBtdWNoIGJldHRlciBv ZmYgdGhhbiB5b3UgYXJlIG5vdy7CoCBJbiB0aGUgb3RoZXIgY2FzZSwgeW91IHdvdWxkIGJlIG5v IHdvcnNlIG9mZiB0aGFuIHlvdSBhcmUgY3VycmVudGx5IGFuZCBhdCBsZWFzdCB0aGVyZSB3b3Vs ZCBiZSBjb25zaXN0ZW5jeSBpbiBob3cgeW91IGNvbmZpZ3VyZSBlYWNoIHNlcnZpY2UuPC9wPjwv ZGl2PjwvZGl2PiA8ZGl2IGlkPSJibG9vcF9zaWduXzE0ODY0Nzk2NTY5MDkwMzkxMDQiIGNsYXNz PSJibG9vcF9zaWduIj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTpoZWx2ZXRpY2EsYXJpYWw7Zm9u dC1zaXplOjEzcHgiPlJlZ2FyZHMsPC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6aGVsdmV0 aWNhLGFyaWFsO2ZvbnQtc2l6ZToxM3B4Ij5HcmVuIEVsbGlvdDxicj48L2Rpdj48L2Rpdj4gPGRp diBjbGFzcz0iYWlybWFpbF9leHRfb24iIHN0eWxlPSJjb2xvcjpibGFjayI+PGJyPjwvZGl2Pjwv Ym9keT48L2h0bWw+DQo8L2Jsb2NrcXVvdGU+PC9kaXY+ ----_com.android.email_4317060067944103-- From nobody Tue Feb 7 12:12:51 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 2B876129579; Tue, 7 Feb 2017 12:12:43 -0800 (PST) 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, 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 HQ_uBgjY1rsJ; Tue, 7 Feb 2017 12:12:42 -0800 (PST) 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 0700E1294AB; Tue, 7 Feb 2017 12:12:42 -0800 (PST) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v17KEJQ6017221 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 7 Feb 2017 12:14:20 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1486498460; bh=EMgmRx/oNDJcCwpoixrc4Ot1rtspvWSaST1Qe839Ztg=; h=Subject:To:References:Reply-To:Cc:From:Date:In-Reply-To:From; b=kscXkCpr103bHivOHbi1QchPGIRnfYU9MM4oPaZhq04DVMA2mB1k8ZBjht76bgjl5 a3M0fZKZYXO4IdVbuZ4Lhge6+qDhL6x7vNCvCThpHMj6NMmSZxviku05aY5YRz3M3U yN4uSBs80dui1w4PqQLNm9YSzK4GvAPaiTeHjiPc= To: Gren Elliot , ietf@ietf.org References: From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Tue, 7 Feb 2017 12:12:31 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: jmap@ietf.org, iesg@ietf.org Subject: Re: [Jmap] Fwd: Re: WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 20:12:43 -0000 On 2/7/2017 7:38 AM, Gren Elliot wrote: > You will either be using IMAP/SMTP to access your mail/submit your > messages or you will be using JMAP. If you have the option of the > latter, you’ve just halved the number of things that need configuring. The primary argument being put forward here is simplification of end-user configuration effort. While that has an intuitive appeal, a basic question for any effort to replace and existing technology is how big the benefit will be and for how much of the market? In this case, for most people, the configuration effort is quite rare. So while it might be a bit of a hassle, it has no effect on daily life. Well, ok, there are some folk who have to make this change more often, due to Draconian and misguided local policies -- the current advice about password changes, from the UX community, is not to make changes often, since this becomes a serious attack surface. But how large a community is this and why is this problem not mitigated simply by having the user interface take one password specification and map it to the two, underlying (and existing) protocols? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Feb 7 13:42:06 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 F0DBE1295E2 for ; Tue, 7 Feb 2017 13:42:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=fastmail.fm header.b=Y9ptz3SP; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=fBs5ZNKp 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 UJphZhCmRlhL for ; Tue, 7 Feb 2017 13:42:02 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42A9A1294D7 for ; Tue, 7 Feb 2017 13:42:02 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A9CAB20C67 for ; Tue, 7 Feb 2017 16:42:01 -0500 (EST) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Tue, 07 Feb 2017 16:42:01 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=F+3uqhqWA/RFYW8iJKMgfXTAe/ g=; b=Y9ptz3SPyTREJ6Wz9dJI+EyMHOm8KQVG2qIoE0w5Jev/VnzJtzI4pyvRuX b66tlurz7ctQh+ID26xuyj/MG5CtLUljFrch+mQChBJkg+M4fHk06GYSWv5ZTDbC 3e0jGBXVDkm8iGfijpByPLfux3qUQQwCQVbIVO8YBeZRl0Lw0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=smtpout; bh=F+ 3uqhqWA/RFYW8iJKMgfXTAe/g=; b=fBs5ZNKpddjJX/ZYY3vnJNtMRFe/i8mdVx b/NOyHN12QZLQWDtSBlDAPlC5bOGXpjFf8lzas1L/Yam/Sm57U/oE6YahpbhPdl/ 7PNJgy1WOoDd/EVpwHgcxQY7d1ka+B0t37OeI1eailvJYe8c18oVipj7rgoTHDp5 gkskRC7lk= X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 862A8BAB4B; Tue, 7 Feb 2017 16:42:01 -0500 (EST) Message-Id: <1486503721.3211662.873633208.51003F86@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-4a450d19 In-Reply-To: References: Date: Wed, 08 Feb 2017 08:42:01 +1100 Archived-At: Subject: Re: [Jmap] Fwd: Re: WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 21:42:05 -0000 On Wed, 8 Feb 2017, at 07:12, Dave Crocker wrote: > On 2/7/2017 7:38 AM, Gren Elliot wrote: > > You will either be using IMAP/SMTP to access your mail/submit your > > messages or you will be using JMAP. If you have the option of the > > latter, you=E2=80=99ve just halved the number of things that need confi= guring. >=20 >=20 > The primary argument being put forward here is simplification of=20 > end-user configuration effort. It really is a significant benefit, though saving bandwidth by only uploadi= ng the message once (don't get me started on BURL, you can see by its adopt= ion rates that it's not resonating with real world users) and reducing hard= -to-debug failure modes are real advantages too. > While that has an intuitive appeal, a basic question for any effort to=20 > replace and existing technology is how big the benefit will be and for=20 > how much of the market? The benefit per person at config stage looks relatively small, though a sin= gle protocol has the added support benefit of full-on or full-off. IMAP+SM= TP leads to situtations where due to firewalling or temporary endpoint fail= ures, users more often see a partial failure where sending works but saving= to the Sent folder fails, or mail management works, but sending fails. Thi= s is confusing to the vast majority of non-technical users in a way that to= tal disconnection isn't. The mental model for "the internet is down" is pr= etty simple, but the mental model for "my SMTP has been firewalled" isn't. > In this case, for most people, the configuration effort is quite rare.=20 > So while it might be a bit of a hassle, it has no effect on daily life. This may be true for each individual user, but when you multiply the hassle= over billions of people, that adds up to a lot of accumulated un-necessary= pain. Also, don't discount the advantages of low initial friction. The setup pha= se is the very first interaction that people have with a protocol or a clie= nt application, and that first interaction sets a lot of their feeling abou= t it. Easy initial configuration makes a big difference to success and sat= isfaction. > Well, ok, there are some folk who have to make this change more often,=20 > due to Draconian and misguided local policies -- the current advice=20 > about password changes, from the UX community, is not to make changes=20 > often, since this becomes a serious attack surface. Agree here, there's nothing to win from forcing frequent password changes. = Still - in the case of a stolen password you need to go changing a lot of = places at once. As an individual user the pain is fleeting, but remembered= for a lot longer than it needs to be. As an aside, my credit card number was stolen recently, and I needed to upd= ate it everywhere that I have it automatically used for billing. For my te= lco where it's used to bill all the family phones, I updated it once and ap= plied the new payment method to all the subscriptions. For the public tran= sport card auto-topup, I had to go into each transport card separately, mak= e an initial payment with the new credit card to register it, apply the cha= nge across, and then guess what - I couldn't do the second one because ther= e was still a "pending change on the account". Yeah, their interface sucks= , but even if it hadn't - re-entering the credit card details 7 times and w= aiting for their slow server... I wasted a lot of time on this while going = through my entire list of places I'd used the card. A user who re-used their password in lots of places (that's 90+% of people,= let's be honest) and finds that their passwords has been compromised is go= ing to be doing a similar thing, working through every place they remember = it being used and updating it. Making that process as simple as possible i= s going to give them warm feelings towards your protocol/application. Thes= e small things add up over all the users in all the world to making the wor= ld a slightly better place. > But how large a community is this and why is this problem not mitigated=20 > simply by having the user interface take one password specification and=20 > map it to the two, underlying (and existing) protocols? That would be most non-technical users in most of the world, who almost inv= ariably have the same username and password for all the services that their= client needs to connect to. Best case, they just have to enter a bit more= information once. Worst case, they spend hours trying to figure out how t= o make all the things work. The success of ActiveSync over open standards in the mobile space shows tha= t there is a clear demand for simpler configuration. It takes a pretty int= ransigent viewpoint to look at the relative success of non-open standards a= nd the number of new protocols being developed to provide good mail experie= nce and conclude that the underlying cause is that client authors just don'= t know how to write a good client that presents the existing standards to t= he user in a simpler way. Regards, Bron. --=20 Bron Gondwana brong@fastmail.fm From nobody Tue Feb 7 13:42:41 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 C31E8129630; Tue, 7 Feb 2017 13:42:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 WBE8gwe9m0mf; Tue, 7 Feb 2017 13:42:30 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE28C1294D7; Tue, 7 Feb 2017 13:42:29 -0800 (PST) Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.4 (Build 5913)) with SMTP id <0000958230@smtp.qbik.com>; Wed, 08 Feb 2017 10:42:27 +1300 From: "Adrien de Croy" To: "dcrocker@bbiw.net" , "Gren Elliot" , "ietf@ietf.org" Date: Tue, 07 Feb 2017 21:42:27 +0000 Message-Id: In-Reply-To: User-Agent: eM_Client/6.0.24928.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "jmap@ietf.org" , "iesg@ietf.org" Subject: Re: [Jmap] Fwd: Re: WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Adrien de Croy List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 21:42:33 -0000 I've dealt with a lot of customer support issues relating to inability=20 to send mail where reading was available. the first point I'd make is that most users wouldn't imagine in a=20 million years that you would have a different system for sending mail vs= =20 reading it, and they are often incredulous when we point that out. I=20 actually have a lot of sympathy for that POV. Apart from that, the main issues we see people battling are, in no=20 particular order * issues with ISPs. Common to block port 25, many admins don't know=20 about Submit port (587) * issues with firewalls, need to open / map additional ports * issues with incorrect user data entry due to double the configuration * various client software issues exacerbated by this We (since our SMTP + IMAP is integrated) don't see so many issues=20 relating to dealing with 2 different products (or more) to support mail=20 (e.g. separate vendor for SMTP vs IMAP), but I would expect those would=20 come with admin problems as well, especially if they use locked-in user=20 databases that other products can't access, different support for=20 different auth methods, different support for different crypto=20 algorithms (recent changes to OpenSSL to deprecate RC4 and 3-DES=20 highlighted some of these). In short, managing 1 port and endpoint requires work. Managing 2=20 requires more. I don't know how many people get SMTP and IMAP from the same place, but=20 I would expect it to be the majority of users. It would be interesting=20 if someone could get some answers on that. Adrien ------ Original Message ------ From: "Dave Crocker" To: "Gren Elliot" ; "ietf@ietf.org" Cc: "jmap@ietf.org" ; "iesg@ietf.org" Sent: 8/02/2017 9:12:31 AM Subject: Re: [Jmap] Fwd: Re: WG Review: JSON Mail Access Protocol (jmap)= =20 - reducing configuration complexity >On 2/7/2017 7:38 AM, Gren Elliot wrote: >>You will either be using IMAP/SMTP to access your mail/submit your >>messages or you will be using JMAP. If you have the option of the >>latter, you=E2=80=99ve just halved the number of things that need configu= ring. > > >The primary argument being put forward here is simplification of=20 >end-user configuration effort. > >While that has an intuitive appeal, a basic question for any effort to=20 >replace and existing technology is how big the benefit will be and for=20 >how much of the market? > >In this case, for most people, the configuration effort is quite rare.=20 >So while it might be a bit of a hassle, it has no effect on daily life. > >Well, ok, there are some folk who have to make this change more often,=20 >due to Draconian and misguided local policies -- the current advice=20 >about password changes, from the UX community, is not to make changes=20 >often, since this becomes a serious attack surface. > >But how large a community is this and why is this problem not mitigated= =20 >simply by having the user interface take one password specification and= =20 >map it to the two, underlying (and existing) protocols? > >d/ > >-- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > >_______________________________________________ >Jmap mailing list >Jmap@ietf.org >https://www.ietf.org/mailman/listinfo/jmap From nobody Tue Feb 7 13:49:44 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 3DC10129629 for ; Tue, 7 Feb 2017 13:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=fastmail.fm header.b=q36AkSQz; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=HgjoNH39 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 bb3kV84Ouxzf for ; Tue, 7 Feb 2017 13:49:41 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E93751294D7 for ; Tue, 7 Feb 2017 13:49:40 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 2D75520A68 for ; Tue, 7 Feb 2017 16:49:40 -0500 (EST) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Tue, 07 Feb 2017 16:49:40 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=6NVCMaIPA4ZbjCLya5DJ2ZyJtP M=; b=q36AkSQzdErr4fNjxsSXYKzknbm1w7XuyGq5SkgcbB7bFn8OrUY818Qccr JCPEvloUAw/qDNxnMh2uyAnRUYUyVsrRRglqTmo2qc9RW349LPvFzmTVCip6px+y f+SvtstgOHqmEQX9Qyn47hXox/kUtOEbEnz256CCBBPLeSHPc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=smtpout; bh=6N VCMaIPA4ZbjCLya5DJ2ZyJtPM=; b=HgjoNH39KcL2mKwnfCtc81vzuRGbxmn/8O rLTxWnwQutCcKu53PTbo4L3Xy2Mz1TrFbcqYYSS9I6tEYU7Vb7+oRNaRCtg0qNsx 581wiYNDn56fC4fg5rLGtvo6H6jGnOB5gIik3c6ms6ginlWkX0elMVaOn+QFl77t UsMq+K1hU= X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 0F20ABAB4B; Tue, 7 Feb 2017 16:49:40 -0500 (EST) Message-Id: <1486504179.3213069.873654632.4001B565@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-4a450d19 Date: Wed, 08 Feb 2017 08:49:39 +1100 In-Reply-To: References: <148616796247.4079.7104562493351135409.idtracker@ietfa.amsl.com> <11e900d0-553e-0635-06f4-8510bd80ecfd@dcrocker.net> <4ff42a3b-1f8e-3e25-14e7-b1d3ed2f69c2@isode.com> <368f2b68-8f10-9517-1edb-d213ff10563b@dcrocker.net> <1486435969.2314063.872594064.21072F60@webmail.messagingengine.com> Archived-At: Subject: Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 21:49:42 -0000 On Wed, 8 Feb 2017, at 01:21, Dave Crocker wrote: > On 2/7/2017 3:26 AM, Gren Elliot wrote: > > Just to add my voice to the call for easier configuration where we don= =E2=80=99t > > force users to configure countless different things. Trying to setup a > > new device for use with open protocols is a complete nightmare - you end > > up needing to configure 2 things for mail (IMAP and SMTP) > ... > > It would be nice to see config dialogs where user=E2=80=99s are asked f= or > > minimal information (user name, perhaps server name) and then the device > > discovers what is available there (Mail/Contacts/Calendar/=E2=80=A6) an= d offers > > the user a way to select them and >=20 >=20 > This issue is for user interface design, not underlying protocol design.= =20 > Hence while it is extremely important in terms of usability, it is=20 > outside the scope of the IETF. This reasoning is why so many non-IETF protocols have been gaining marketsh= are in the client space. The underlying protocols need to support usable i= nterface design, and be simple enough to implement that somebody who wants = to write a great new email client doesn't spend their first 6 months fighti= ng the protocols and then give up. > Having these functions embedded into a single protocol implicitly=20 > requires that these different functions share the same configuration=20 > data. While such sharing might be common practice, requiring the=20 > sharing limits operational choices. As others have already said, there's nothing stopping individual JMAP accou= nts from offering different facilities (except for sending and receiving ma= il, where the sending at least needs to be tied to an account which support= s an Outbox - I guess in theory you could just make the email disappear fro= m the Outbox after sending and have no facility to fetch new mail, though y= ou'd want a Draft folder as well with storage capability, and you also need= storage capability for uploaded attachments.) That said, if all you want to do is sent email with no access to read, JMAP= is probably the wrong choice for this very specific thing. That's fine, J= MAP isn't trying to solve every problem in a compromised way, it's trying t= o solve a very common use case very well. Making things much harder for 99= .9% of users so that they're a little easier for 0.1% of users is far too c= ommon a failure mode of designing standards that try to be everything for e= verybody. --=20 Bron Gondwana brong@fastmail.fm From nobody Tue Feb 7 13:50:00 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 0847A1288B8 for ; Tue, 7 Feb 2017 13:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 W4llkYPtNZB0 for ; Tue, 7 Feb 2017 13:49:54 -0800 (PST) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (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 5819512950A for ; Tue, 7 Feb 2017 13:49:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1486504191; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Ass4ghwNJiSXB5439qtfdLaSRE6vltu7jl6LbO1tOKw=; b=TLn7EarDpfipDr/YA/q9tK5DdBgFtVY+Y/bXTm566Hnx5IwGm9//gjuL+VrMlVwo U8clbqG+FR5uf4s0pxshVwf8687HTLJGU5tP4V9RWszNu481HnmMD6uZgCAYDMmV 11jiRg7Kb4nSN35iQR5Ny9biiYY/UXtqtRCvTNvZ7GLlZn9TtusgVtVm/UH3DSYc T4QQZHNWbIYBO5M1BoRv5WHnPa5A6WM/2oVLZEpT/eS+AXxatg//GPFbHhHugGoJ cKewHAEMPbnoVyso6UEwBPSMfJXyP47DZ2RY5Ee3u+Zt23zDZ5sPi7FJw0RAzO4X nm8JfdXegRhYZrHuSTe76g==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id DA.64.10104.EF04A985; Tue, 7 Feb 2017 13:49:51 -0800 (PST) X-AuditID: 11973e12-5adff70000002778-af-589a40fe050d Received: from mailex13.apple.com (nwk-mbx16p-w02.pex.exch.apple.com [17.146.17.21]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id 21.2E.12381.DF04A985; Tue, 7 Feb 2017 13:49:49 -0800 (PST) Received: from nwk-mbx16p-w01.pex.exch.apple.com (17.146.17.20) by nwk-mbx16p-w02.pex.exch.apple.com (17.146.17.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.27; Tue, 7 Feb 2017 13:49:48 -0800 Received: from nwk-mbx16p-w01.pex.exch.apple.com ([17.146.17.20]) by nwk-mbx16p-w01.pex.exch.apple.com ([17.146.17.20]) with mapi id 15.01.0544.027; Tue, 7 Feb 2017 13:49:48 -0800 From: Neil Jhaveri To: "dcrocker@bbiw.net" Thread-Topic: [Jmap] WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity Thread-Index: AQHSgYwaHBfYLmOncEKXZixKGs2vHQ== Date: Tue, 7 Feb 2017 21:49:48 +0000 Message-ID: <2042C2E0-7F86-47AA-800B-3E4E50E66259@apple.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [17.202.38.69] Content-Type: text/plain; charset="utf-8" Content-ID: <6DA6D5E99794E44A862D66B7DDE35E19@pex.exch.apple.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBIsWRmVeSWpSXmKPExsUi2FCYpvvfYVaEwY8dLBa/P31gs3jwdyaL xYw/E5ktnm2cz2LRe38GmwOrx6WdJ9k8ds66y+6xZMlPpgDmKC6blNSczLLUIn27BK6MF79P sRd8E6mYs42ngXGDSBcjJ4eEgInE1Kt7WLsYuTiEBPYxSqxYep8JJnF75k82iMQiJomP704w QzjtTBIHuzdBOdsZJebumcPexcjBwSagLrH5XBpIt4iAtsS9/leMIDXMAh2MEtMnnGcHSQgL pErMmfWbEaIoTWLnt4vMELaexJxbf8BWswioSPT8+cIGYvMK2Ehc7jjPArGsjVFi4b4+sEGc Ag4SSy7tACtiFBCT+H5qDVgzs4C4xK0n86F+EJBYsuc8M4QtKvHy8T9WCFtH4uz1J4wQtoJE y8bnjCAPMAtoSqzfpQ8xxlHi5vppzBC2osSU7ofsEPcISpyc+QTsHgmBfnaJnf/amCYwSs9C snoWwqhZSEbNQjJqFpJRCxhZVzEK5SZm5uhm5pnoJRYU5KTqJefnbmIERf10O6EdjKdWWR1i FOBgVOLhzeiYESHEmlhWXJl7iFGag0VJnFfIZGaEkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6p BkaLCf9EUy5fU90b9WC32vIvLpLv25/KNuo8T+/93yRWYzq3Le/v4qLwTdOld0nGXH5VyfFC KKxu5zkuh4f3Nq2WFN+61cYmPubjVu8181pSfn23/JrZtM+4UVdUZsZ1hkuXNr/utz8bteYr yxfngLk3WQxvx63/uXuD4PRyns1Lf+pY3724/vIVJZbijERDLeai4kQA6Ye+fNsCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOIsWRmVeSWpSXmKPExsUiOElQVPevw6wIg1uN1ha/P31gs3jwdyaL xYw/E5ktnm2cz2LRe38GmwOrx6WdJ9k8ds66y+6xZMlPpgDmKC6blNSczLLUIn27BK6MF79P sRd8E6mYs42ngXGDSBcjJ4eEgInE7Zk/2SBsMYkL99YD2VwcQgKLmCQ+vjvBDOG0M0kc7N4E 5WxnlJi7Zw57FyMHB5uAusTmc2kg3SIC2hL3+l8xgtQwC3QwSkyfcJ4dJCEskCoxZ9ZvRoii NImd3y4yQ9h6EnNu/WECsVkEVCR6/nwBO4NXwEbicsd5FohlbYwSC/f1gQ3iFHCQWHJpB1gR I9Ct30+tAWtmFhCXuPVkPhPEDwISS/acZ4awRSVePv7HCmHrSJy9/oQRwlaQaNn4nBHkAWYB TYn1u/QhxjhK3Fw/jRnCVpSY0v2QHeIeQYmTM5+wTGCUnIVk2yyE7llIumch6Z6FpHsBI+sq RoGi1JzESgu9xIKCnFS95PzcTYyg6G0oTNvB2LTc6hCjAAejEg9vRseMCCHWxLLiytxDjBIc zEoivJe0Z0UI8aYkVlalFuXHF5XmpBYfYpTmYFES5/XcD1QtkJ5YkpqdmlqQWgSTZeLglGpg bON/8PPCigehbB8zm/kErpY8advS6K2rbqS6TmnT3nNnl61/qdr3wv2wzqRzh2p1mAN9tsfO /bVWtOduT5iDh9Csok173QW99a98djrsNT/n3B0d8b7FV5milVZJ1iYt/Tz38znxQgupTrXt xs/i7uu2vvyq1v8ppqL32dq+F3MrbZf7XqyZpsRSnJFoqMVcVJwIAOYsUbTaAgAA Archived-At: Cc: "jmap@ietf.org" , "ietf@ietf.org" , Gren Elliot , "iesg@ietf.org" Subject: Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 21:49:55 -0000 PiBPbiBGZWIgNywgMjAxNywgYXQgMTI6MTIgUE0sIERhdmUgQ3JvY2tlciA8ZGhjQGRjcm9ja2Vy Lm5ldD4gd3JvdGU6DQo+IA0KPiBCdXQgaG93IGxhcmdlIGEgY29tbXVuaXR5IGlzIHRoaXMgYW5k IHdoeSBpcyB0aGlzIHByb2JsZW0gbm90IG1pdGlnYXRlZCBzaW1wbHkgYnkgaGF2aW5nIHRoZSB1 c2VyIGludGVyZmFjZSB0YWtlIG9uZSBwYXNzd29yZCBzcGVjaWZpY2F0aW9uIGFuZCBtYXAgaXQg dG8gdGhlIHR3bywgdW5kZXJseWluZyAoYW5kIGV4aXN0aW5nKSBwcm90b2NvbHM/DQoNCg0KSSBh Z3JlZSB0aGF0IHRoaXMgY2FuIGdvIGEgbG9uZyB3YXkuICBPbiBpT1MgYW5kIG1hY09TLCB3ZSd2 ZSBkb25lIHRoaXMgdG8gYSBsaW1pdGVkIGRlZ3JlZSwgYnkgYnVpbGRpbmcgYSBjZW50cmFsIGRh dGFiYXNlIG9mIGFjY291bnRzIHRoYXQgZWFjaCBhcHAgdXNlcy4g4oCcQnJhbmRlZCBwYXJ0bmVy 4oCdIGFjY291bnRzIGxpa2UgR29vZ2xlL1lhaG9vIS9Bb2wvZXRjIGhhdmUgdGhlIGNyZWRlbnRp YWxzIGNlbnRyYWxseSBzdG9yZWQsIGFuZCBjaGlsZCBhY2NvdW50cyAoSU1BUCwgU01UUCwgZXRj KSBpbmhlcml0IHRoZW0sIHdpdGggYSBzaW5nbGUgVUkgZnJhbWV3b3JrIHRvIHJlLWF1dGhlbnRp Y2F0ZS4NCg0KVW5mb3J0dW5hdGVseSwgcmVndWxhciBhY2NvdW50cyBzdGlsbCBkb27igJl0IGhh dmUgdGhpcyB0cmVhdG1lbnQsIGFuZCBpdCBzdGlsbCBkcml2ZXMgYSBsb3Qgb2YgY2FsbHMgdG8g QXBwbGVDYXJlLiBUaGVyZSBhcmUgYSBidW5jaCBvZiByZWFzb25zIHdoeSwgYnV0IG9uZSBpcyB0 aGF0IGl04oCZcyB0cmlja3kgdG8gYmUgc3VyZSB0aGF0IHRoZSB2YXJpb3VzIHByb3RvY29scy9o b3N0bmFtZXMgaGF2ZSBiZWVuIGFwcHJvcHJpYXRlbHkgYnVuZGxlZCB0b2dldGhlciBpbnRvIHdo YXQgaXMgdHJ1bHkgdGhlIHNhbWUgc2VydmljZSwgd2hlcmUgdGhlIHNhbWUgdXNlcm5hbWUvcGFz c3dvcmQgdHJ1bHkgYXBwbGllcywgYW5kIHRoZXJlIGlzbuKAmXQgYSBzZWN1cml0eSBpc3N1ZSBm cm9tIHRha2luZyB5b3VyIHVzZXItdXBkYXRlZCBJTUFQIHBhc3N3b3JkIGFuZCBzZW5kaW5nIGl0 IG9mZiB0byBhIENhbERBViBzZXJ2ZXIgd2l0aCBhIGRpZmZlcmVudCBob3N0bmFtZS4gVGhpcyBk b2VzIHNlZW0gbGlrZSBhbiBpbmNyZW1lbnRhbGx5IHNvbHZhYmxlIHByb2JsZW0sIHRob3VnaCwg d2l0aCBzb21lIG9mIHRoZSBvdGhlciB3b3JrIGJlaW5nIGRvbmUgaW4gdGhlIGFjY291bnQgY29u ZmlndXJhdGlvbiBzcGFjZS4NCg0KSG93ZXZlciwgdGhlcmUgYXJlIHN0aWxsIHNvbWUgb3BlcmF0 aW9uYWwgaXNzdWVzIHRoYXQgYXJpc2UsIGV2ZW4gd2l0aCB0aGlzIGtpbmQgb2YgVUksIGZvciBl eGFtcGxlOg0KKGEpIFR3byBkaWZmZXJlbnQgcHJvdG9jb2xzL3NlcnZlcnMgb2Z0ZW4gbGVhZCB0 byB2ZXJ5IGNvbmZ1c2luZyBwYXJ0aWFsIGZhaWx1cmVzIChJIGNhbiBjaGVjayBmb3IgbXkgTWFp bCwgYnV0IEkgY2Fu4oCZdCBzZW5kIGFueSkuDQooYikgUG9ydCBmaXJlLXdhbGxpbmcuIEl0IHdh cyBhIG1vcmUgY29tbW9uIHN1cHBvcnQgaXNzdWUgZm9yIHVzIDgtMTAgeWVhcnMgYWdvLCBidXQg aGFzIHN1YnNpZGVkIGluIHJlY2VudCB5ZWFycy4NCg0KVGhhdCBhbGwgYmVpbmcgc2FpZCwgSSB0 aGluayB0aGVyZSBhcmUgc29tZSB2ZXJ5IGNvbXBlbGxpbmcgYXNwZWN0cyBoZXJlLCBwYXJ0aWN1 bGFybHkgdGhlIHN0YXRlbGVzcyBuYXR1cmUgb2YgdGhlIHByb3RvY29sLCBhbmQgdXNpbmcgSFRU UCB1bmRlcm5lYXRoLiBGcm9tIGEgY2xpZW504oCZcyBwZXJzcGVjdGl2ZSwgSSBjYW4gc2F5IHRo YXQgdGhpcyB3b3VsZCBsZWFkIHRvIGEgZmFyIHNpbXBsZXIgaW1wbGVtZW50YXRpb24sIHdpdGgg cHJlLWV4aXN0aW5nIEVXUy9FQVMgaW1wbGVtZW50YXRpb25zIGJlaW5nIHRoZSBiYWNraW5nIG9m IHRoYXQgc3RhdGVtZW50Lg== From nobody Tue Feb 7 15:02:58 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 D59751294F9; Tue, 7 Feb 2017 15:02:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ZvOciXkoJVkS; Tue, 7 Feb 2017 15:02:55 -0800 (PST) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EEDB1294EF; Tue, 7 Feb 2017 15:02:55 -0800 (PST) Received: by mail-yb0-x235.google.com with SMTP id 123so40167746ybe.3; Tue, 07 Feb 2017 15:02:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=bKxMHOQmQma/B3fuAIlsHWChl4v1bRpJBBRMpN4xX88=; b=cjheKVYx0JA8d7gI6o9MshIsHOdZbs3fzcOwVlEXiVmrx9psge0LqICP8LcSnAVmX7 c1o3oWeA6PuUhCArfFiq/1ZlM6ZCiSiEFCtbwLmg7YzE/qNM7vXp9NbYld5gSAfV6hCJ Ut/Fha4v/E6ho7oM6L2032QPX5IF5dikG5owYNnXGhZ8YaGU1Z4SJohHW7OjmSONqyN8 QMVyANfX0ijG1t9XZ8jISjaHlA6GCZ6crZD4bn2kGkIlFcmzVZ0Cc/FXgUb2xSDyQ8Od YsQLPLiU8Cty0aoByaujd4yn3yGBtKQXbSp7NvaOleivSz2XVjx0nU0DaRzKaTfrX7O6 nCPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=bKxMHOQmQma/B3fuAIlsHWChl4v1bRpJBBRMpN4xX88=; b=Uh97TyEPwBXkW5OXnKgDdf8ZNLrpHOk+/k56vz/be3gVKFE5jFTjsCLx6heIWDYQDk FgGLpYnanE1fRXgNwZk4f94yTR39hLL6gOc+UfkVzXStzX3+8mgCu4kDUTv8NIjlahcb ni1CTXI8aMeWfxt6DZwOSp54EbSdYyupD59DehGNcDQb/V+dfxObvJANwB66sXGtqF8p PshC0udCpdQZIZDdiorx8HZd7d9IvCzFP3aFAj/S3ihtgg7Sx2vAvC2514PIoxXkaaKR 7BXX6ABsfljtXlf/6GRCMJa0KdeDgaljWvPd7k2KLBrxT5sQ0Y7VN6Vdx1VBt+0RYdwa k2CQ== X-Gm-Message-State: AMke39kWGajfkmTi232tJVAuleJvj1GsJPTbgmHhk6AzxZk9SgIZ/AoexjzLXJTw1vtgP9PiJOUAXzWGyVhE4A== X-Received: by 10.37.173.83 with SMTP id l19mr13330026ybe.84.1486508574695; Tue, 07 Feb 2017 15:02:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.250.7 with HTTP; Tue, 7 Feb 2017 15:02:53 -0800 (PST) Received: by 10.13.250.7 with HTTP; Tue, 7 Feb 2017 15:02:53 -0800 (PST) In-Reply-To: References: From: Gren Elliot Date: Tue, 7 Feb 2017 23:02:53 +0000 Message-ID: To: dcrocker@bbiw.net Content-Type: multipart/alternative; boundary=f403045ec9f88d03930547f8bf74 Archived-At: Cc: jmap@ietf.org, iesg@ietf.org, ietf@ietf.org Subject: Re: [Jmap] Fwd: Re: WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: fatkudu@gmail.com List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 23:02:57 -0000 --f403045ec9f88d03930547f8bf74 Content-Type: text/plain; charset=UTF-8 In answer to the UI question below, for the simple reason that you don't know whether the same password applies, because the standards have deliberately separated them and there is no standard provided which can convey the information that in this case, they're the same. You could perhaps just try the same credentials for each service but that would be a clear leak of private information if they weren't the same. On 7 Feb 2017 20:12, "Dave Crocker" wrote: But how large a community is this and why is this problem not mitigated simply by having the user interface take one password specification and map it to the two, underlying (and existing) protocols? --f403045ec9f88d03930547f8bf74 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In answer to the UI question below, for the simple r= eason that you don't know whether the same password applies, because th= e standards have deliberately separated them and there is no standard provi= ded which can convey the information that in this case, they're the sam= e. You could perhaps just try the same credentials for each service but tha= t would be a clear leak of private information if they weren't the same= .=C2=A0

On 7 F= eb 2017 20:12, "Dave Crocker" <dhc@dcrocker.net> wrote:
=C2=A0
But how large a community is this and why is this problem not mitigated sim= ply by having the user interface take one password specification and map it= to the two, underlying (and existing) protocols?
<= /div>



--f403045ec9f88d03930547f8bf74-- From nobody Tue Feb 7 18:47:55 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 DD7111294FF for ; Tue, 7 Feb 2017 18:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 kIrElFHdt8Qq for ; Tue, 7 Feb 2017 18:47:43 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1BBD12009C for ; Tue, 7 Feb 2017 18:47:43 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id 11so109180320qkl.3 for ; Tue, 07 Feb 2017 18:47:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=19rU2uFz7E8ta5+oxsfnGd3N0oDEUhpXukm5KKLE5s4=; b=OS2G/77OX0pQjAOtIjiOw/5Kbk8TJxy5CQZ+zPS7VuX3EaGI1240yvdTfgPi+pca1k QVXqJFcPPwudXtCL6drU5PmIVrSslY0e4Xj871pMhIlTgOk56mWKq+sBLNzg6oEAhccu ixqF7qWQ42ZBK1UMsfW9Z8P5vsRku3qlAtx2hHuWL7byuqeiQojt6ZJSMSyaOFHjifKZ F6+1HAb/lrSAA821vv3eCG2QuKnwG/tO/coTL3eMyhUDv76ayuV8N9XYElUYdLaHhhDX +eJdLInUeg8jN6LuhdlsBtYRa8oivzIUFxr0YV2a38gaY8vGe66mn3qXoOSaIHV0VU7j kNgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=19rU2uFz7E8ta5+oxsfnGd3N0oDEUhpXukm5KKLE5s4=; b=KqnwViOkFHedlaHcgSCek146hYtGZ+cdgy4zcecQoxALek6fwis9wDwG+hRl65Rg0/ gyAU4yI9ss4bo6pedRj0SLmxBHxSnpb6zexIPIFqRuuAeraQCr6G3vnQ33aNhZc958Ec 6lWNvGyOlSYdqLh+48VXU8an+59RZSaUJBx3dS701QQfHgQV0YZHcRTA84VJIo0WUWdw BZ90H9CwZwkShE8yTWg7YxmSjnyI54wenEZoNpCjgHRIEWhk6F10eAo2Yc9hCKwtn+H4 CKy7vuU+D37joq/fqluDiLTdvulCcWXz4IZh/A4koJYOteiexpNIqC4RVSHArVnkKA3e J1NA== X-Gm-Message-State: AMke39lBtsH6j8g08dunnjN3wuvXQzVZcjD1n+FOOTz+Ix+2cY4zT1lD2A8yMAEyjGRdqA== X-Received: by 10.55.83.71 with SMTP id h68mr16800259qkb.259.1486522062855; Tue, 07 Feb 2017 18:47:42 -0800 (PST) Received: from [10.0.20.229] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id e3sm5071948qtg.7.2017.02.07.18.47.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Feb 2017 18:47:41 -0800 (PST) From: Ted Lemon Message-Id: <3A1DFD1E-E675-47CB-AE54-756C6CD5FF2E@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7F01E586-A2EB-4970-8B1A-4FCAFFB4BACD" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 7 Feb 2017 21:47:39 -0500 In-Reply-To: <1A1381DB-DF79-4FC8-88F4-60A0AF4FE3CA@cursive.net> To: Joe Hildebrand References: <9D66E5E7619E1C55F1DEB959@PSB> <1A1381DB-DF79-4FC8-88F4-60A0AF4FE3CA@cursive.net> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: jmap@ietf.org, IESG , IETF discussion list Subject: Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 02:47:46 -0000 --Apple-Mail=_7F01E586-A2EB-4970-8B1A-4FCAFFB4BACD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 7, 2017, at 8:47 PM, Joe Hildebrand wrote: > TL;DR summary: Just say 'yes'. +1 If this winds up having a clean design, it will probably be enough of an = improvement to be well worth deploying. That's what it takes for a = protocol to be successful. I am not yet convinced that it will be a = clean design, but if we don't try to design it, it won't matter. --Apple-Mail=_7F01E586-A2EB-4970-8B1A-4FCAFFB4BACD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Feb 7, 2017, at 8:47 PM, Joe Hildebrand <hildjj@cursive.net> = wrote:
TL;DR summary: Just say 'yes'.

+1

If= this winds up having a clean design, it will probably be enough of an = improvement to be well worth deploying.   That's what it takes for = a protocol to be successful.   I am not yet convinced that it will = be a clean design, but if we don't try to design it, it won't = matter.

= --Apple-Mail=_7F01E586-A2EB-4970-8B1A-4FCAFFB4BACD-- From nobody Tue Feb 7 18:58:37 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 280F51297A8; Tue, 7 Feb 2017 18:58:37 -0800 (PST) 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, LOTS_OF_MONEY=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 T0dDtQqTboGy; Tue, 7 Feb 2017 18:58:36 -0800 (PST) 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 59D5B1297A7; Tue, 7 Feb 2017 18:58:36 -0800 (PST) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v1830E9I028997 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 7 Feb 2017 19:00:14 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1486522814; bh=kSvBHNwcNmc5k6QghzGQvAZ5H7ThFj286B1DeB2b0WQ=; h=Subject:To:References:From:Reply-To:Cc:Date:In-Reply-To:From; b=X9s9XltL0zbSkYNmB9/SjdHX4+sqV1SxE449M7UtVdsaJDVDG0tEkq38xHJksdtQt TuYYXorqgl35BdWWFAnPJYHiL/Ua3GBNhYfHOwC/3EXAvUfIiBHZmGvM55N584Vvn/ LrkW/xwSIt1eb45tzRBbSBzB9ILuEMhIyyBVovow= To: Joe Hildebrand References: <9D66E5E7619E1C55F1DEB959@PSB> <1A1381DB-DF79-4FC8-88F4-60A0AF4FE3CA@cursive.net> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Tue, 7 Feb 2017 18:58:25 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <1A1381DB-DF79-4FC8-88F4-60A0AF4FE3CA@cursive.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: jmap@ietf.org, IESG , IETF discussion list Subject: Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 02:58:37 -0000 On 2/7/2017 5:47 PM, Joe Hildebrand wrote: >> On Feb 7, 2017, at 1:54 PM, John C Klensin >> wrote: >> >> TL;DR summary: Just say 'no'. > > No hats, personal opinion only, and in response to several of the > messages in this thread, not directly to John. > > > Will it ever be possible for new work to be proposed at the IETF > without drowning out a chorus of nitpickers? You may not want to > help standardize it. You may not want to implement it. You may not > want to deploy it. You may not want to use it. Joe, Sorry, no. Basic questions about basic utility are not nitpicking. Basic questions about the justifications for basic technical choices are not nitpicking. And authorizing an IETF working group is not free. Even the most modest IETF working group standards effort had an aggregate cost of around US$1M, back when I did a calculation more than 20 years ago, and I would love to see someone formulate a claim that it has gone down since then... So here's an entirely un-novel suggestion: get the organizations who are expecting to implement and deploy this to say so. From that we can get a measure of likely uptake. Get them also to explain what benefits they expect to accrue from this work. Standards work cannot be a random walk through arbitrary features, no matter how intuitively appealing those features might be There needs to be clear and legitimate justifications for each effort and a clear indication that there is a market out there wanting the work. A mild sense that something is benign is not nearly good enough. Given the actual costs of such work. > This work won't hurt the Internet, particularly if done with A statement like that ignores issues such as opportunity costs. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Feb 7 19:15:11 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 AB0B51293E9; Tue, 7 Feb 2017 19:15:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.com header.b=OiNy+Tkt; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=MQPxv+7j 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 T2XBjF_H4ts6; Tue, 7 Feb 2017 19:15:05 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7B2D1293E8; Tue, 7 Feb 2017 19:15:05 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 219CB209AE; Tue, 7 Feb 2017 22:15:05 -0500 (EST) Received: from betaweb1 ([10.202.2.10]) by compute1.internal (MEProxy); Tue, 07 Feb 2017 22:15:05 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=DQ8juEuzi3EJV2P7hqohPwh0eX I=; b=OiNy+TktU/tDNVBTU34pmiVQNfjPam94XDirtZEgNg18qzA10mmRKJcjkj TXPXyePAyabWFcwVnfMTFu/PhmMoE49wr6Zwfk0LeXFj1oYe5meqMeo3ytRVVQRL aZmHU/PaFlIBOkj/NZy4OP7AuhV95VestJr7E0Pm/yvDVD/7w= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=smtpout; bh=DQ 8juEuzi3EJV2P7hqohPwh0eXI=; b=MQPxv+7j28OBx9cCZLjiqu4M0JmJCsUFg4 wc4I8AMIBo5KkzEedD/UwHaRA4qQ8oZIi6vNUiXIVWRgQhjBXq9O4N4JBPhI93Vx hyg70RGxtEMGLKfsWHLNCKDZBgNypmdyAOodgKZ1ihMrlcziG+zPZbB3LN5HGr82 //aHIPc5o= X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id D37AEE2406; Tue, 7 Feb 2017 22:15:04 -0500 (EST) Message-Id: <1486523704.3711423.873904592.78C4EAA8@webmail.messagingengine.com> From: Neil Jenkins To: jmap@ietf.org, IESG , IETF discussion list MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_148652370437114232" X-Mailer: MessagingEngine.com Webmail Interface - ajax-fdb7c997 Date: Wed, 08 Feb 2017 14:15:04 +1100 References: <9D66E5E7619E1C55F1DEB959@PSB> <1A1381DB-DF79-4FC8-88F4-60A0AF4FE3CA@cursive.net> In-Reply-To: Archived-At: Subject: Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 03:15:07 -0000 This is a multi-part message in MIME format. --_----------=_148652370437114232 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Wed, 8 Feb 2017, at 01:58 PM, Dave Crocker wrote: > So here's an entirely un-novel suggestion: get the organizations who > are expecting to implement and deploy this to say so. Sure! So, FastMail[1], Atmail[2], Linagora[3] are all developing clients and server based around the current draft proposed to the IETF. There is implementation work happening in both Cyrus[4] and Dovecot[5] the two largest open-source IMAP servers. So far in this thread we've had representatives from Apple and Zimbra both expressing positive interest in JMAP. The other side of this, which I mentioned earlier, is the many proprietary protocols that are popping up, invariably HTTP/JSON based, to replace the need for IMAP/SMTP (submission). Things like Nylas[6], Context.io[7] and the Gmail API[8]. There are many benefits to the work we're proposing over IMAP/SMTP submission; the current thread seems to have got a bit hung up on the configuration bit, but while this is certainly an improvement it's just one of many[9]. You may think IMAP/SMTP are great solutions to this problem space, but it would appear industry disagrees. Neil. Links: 1. https://www.fastmail.com/ 2. https://www.atmail.com/ 3. https://www.linagora.com/ 4. https://cyrusimap.org/ 5. https://www.dovecot.org/ 6. https://nylas.com/cloud/docs 7. Context.iohttps://context.io/docs/lite 8. https://developers.google.com/gmail/api/v1/reference/ 9. http://jmap.io/#why-is-jmap-better-than-imap? --_----------=_148652370437114232 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Wed, 8 Feb 2017, at 01:58 PM, Dave Crocker wrote:
So here's an entirely un-novel suggestion:  get the organizations who
are expecting to implement and deploy this to say so.

Sure! So, FastMail, Atmail, Linagora are all developing clients and server based around the current draft proposed to the IETF. There is implementation work happening in both Cyrus and Dovecot the two largest open-source IMAP servers. So far in this thread we've had representatives from Apple and Zimbra both expressing positive interest in JMAP.

The other side of this, which I mentioned earlier, is the many proprietary protocols that are popping up, invariably HTTP/JSON based, to replace the need for IMAP/SMTP (submission). Things like Nylas, Context.io and the Gmail API.

There are many benefits to the work we're proposing over IMAP/SMTP submission; the current thread seems to have got a bit hung up on the configuration bit, but while this is certainly an improvement it's just one of many.

You may think IMAP/SMTP are great solutions to this problem space, but it would appear industry disagrees.

Neil.
--_----------=_148652370437114232-- From nobody Tue Feb 7 23:27:12 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 A39181295DA; Tue, 7 Feb 2017 23:27:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 xlsZffoIV6SB; Tue, 7 Feb 2017 23:27:05 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3FC7129410; Tue, 7 Feb 2017 23:27:04 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id v77so179931639wmv.0; Tue, 07 Feb 2017 23:27:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=dwBNSVc30dT6T9Piy0u9rs8uvXuvqUcSZpihtM+wJTM=; b=eEczFjFCd7h/jgtgO+CP4fXV/E6o5viWXyME8iuR+ow1dBGDpUySuCsgTLYtTSHDT3 AeJk/f2kMQUyZEhdbfSxWM/kWPVrpk5GRw6IL8Ee89kjbE0wqrasz/VAj/EiDoefjRzS 1ll+9tP6sudQ9eSYqclM0ES+jwZE/UxWYJIKiMRKgm1JsGIiHfb/kEcxmjAHZJbgSrOi SzZ+8urYPw8xdTgq/TcZP4j6DZB15PeZLOuxMFMxkvSM0FbGHrPdbcsB9DCxHg8FsZMW HHEAkdtz7sN6ElhcIikzlFCu0bm3sqEVYcsm4Zm51zyGsN1ndP2bnVPKUfWNds2MpIae o9BA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=dwBNSVc30dT6T9Piy0u9rs8uvXuvqUcSZpihtM+wJTM=; b=QvVVks32zRHqyhgpP1v7TnKuLrfkfw32wGARI+du3t2VOJOApkPRw060ZE5W8I6GRy UxEs8uXOHI09yRadrNGclck6efrMKUDtX4n+4ysA/ICLLfaXG3S3NnFG8eUwwQnq7VEA QfHEo629JksbE9zK4vMyhRlNN8mZdRJ8bdxaMX5lAGwkw1miY5T13GE4a2UCs9ZK6BFZ 1Yi7gkPlvKhYv8+Zo0TKS4rlY/1+SvF/hroSy1bK5ue28G+njaabH3bw5HB6qfY2jt+a 5SA/X2fQHjIxhmI912SypJaGr1qfUynhIBrsQYUF9k8SLWPKaYrK7nZH5Hk6bNkI5P3h QPYQ== X-Gm-Message-State: AMke39kiT9xKQOYYmXPZ1Bi2VfEVZ8KQM0QGJc/c6uoXO6sOBXksacD5r+W/fQN24IIh4A== X-Received: by 10.28.129.5 with SMTP id c5mr15197229wmd.23.1486538823297; Tue, 07 Feb 2017 23:27:03 -0800 (PST) Received: from users-mbp.mshome.net ([109.253.228.86]) by smtp.gmail.com with ESMTPSA id i73sm1736875wmd.11.2017.02.07.23.27.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Feb 2017 23:27:02 -0800 (PST) From: Yoav Nir Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_270DA9F7-9C3C-4A95-8F28-D48A7D005EF8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 8 Feb 2017 09:26:59 +0200 In-Reply-To: <1486523704.3711423.873904592.78C4EAA8@webmail.messagingengine.com> To: Neil Jenkins References: <9D66E5E7619E1C55F1DEB959@PSB> <1A1381DB-DF79-4FC8-88F4-60A0AF4FE3CA@cursive.net> <1486523704.3711423.873904592.78C4EAA8@webmail.messagingengine.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: jmap@ietf.org, IESG , IETF discussion list Subject: Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 07:27:06 -0000 --Apple-Mail=_270DA9F7-9C3C-4A95-8F28-D48A7D005EF8 Content-Type: multipart/alternative; boundary="Apple-Mail=_B9BE9959-459A-4FDE-B40B-60E950A887FA" --Apple-Mail=_B9BE9959-459A-4FDE-B40B-60E950A887FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 8 Feb 2017, at 5:15, Neil Jenkins wrote: >=20 > On Wed, 8 Feb 2017, at 01:58 PM, Dave Crocker wrote: >> So here's an entirely un-novel suggestion: get the organizations who >> are expecting to implement and deploy this to say so. >=20 > Sure! So, FastMail , Atmail = , Linagora are all = developing clients and server based around the current draft proposed to = the IETF. There is implementation work happening in both Cyrus = and Dovecot the two = largest open-source IMAP servers. So far in this thread we've had = representatives from Apple and Zimbra both expressing positive interest = in JMAP. That=E2=80=99s good to know. I=E2=80=99m wondering if implementing a = generic email client (rather than a specific =E2=80=9Cgmail=E2=80=9D or = =E2=80=9Clive=E2=80=9D client) isn=E2=80=99t becoming ever harder. With = so many older and newer services, a client has to support pop3, imap, = smtp, EWS, ActiveSync, and maybe a few of the others you mentioned. This = effort proposes to add yet another one. Same for a server. A server (even a corporate server, but also public = ones like gmail) exposes all kinds of protocols: SMTP, IMAP, POP3 and = some proprietary ones. This is yet another one, and it comes with the = additional support headache. What do you do if the JMAP clients get = disconnected but the IMAP works fine and we can=E2=80=99t get that one = POP3 guy on the phone to say if that one is working. And you can=E2=80=99t= just =E2=80=9Cpick one=E2=80=9D unless it=E2=80=99s pop3, because of = older clients out there. Not saying that this is not a worthy effort, but it has costs not just = for the people doing the actual work. Yoav --Apple-Mail=_B9BE9959-459A-4FDE-B40B-60E950A887FA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 8 Feb 2017, at 5:15, Neil Jenkins <neilj@fastmail.com> = wrote:

On Wed, 8 Feb 2017, at 01:58 PM, Dave = Crocker wrote:
So here's an = entirely un-novel suggestion:  get the organizations who
are expecting to implement and deploy this to say so.

Sure! So, FastMail, Atmail, Linagora are all developing clients and server based = around the current draft proposed to the IETF. There is implementation = work happening in both Cyrus and Dovecot the two largest open-source IMAP servers. So far = in this thread we've had representatives from Apple and Zimbra both = expressing positive interest in JMAP.

That=E2=80=99s good to know. I=E2=80=99m = wondering if implementing a generic email client (rather than a specific = =E2=80=9Cgmail=E2=80=9D or =E2=80=9Clive=E2=80=9D client) isn=E2=80=99t = becoming ever harder. With so many older and newer services, a client = has to support pop3, imap, smtp, EWS, ActiveSync, and maybe a few of the = others you mentioned. This effort proposes to add yet another one.

Same for a server. A = server (even a corporate server, but also public ones like gmail) = exposes all kinds of protocols: SMTP, IMAP, POP3 and some proprietary = ones. This is yet another one, and it comes with the additional support = headache. What do you do if the JMAP clients get disconnected but the = IMAP works fine and we can=E2=80=99t get that one POP3 guy on the phone = to say if that one is working. And you can=E2=80=99t just =E2=80=9Cpick = one=E2=80=9D unless it=E2=80=99s pop3, because of older clients out = there.

Not = saying that this is not a worthy effort, but it has costs not just for = the people doing the actual work.

Yoav

= --Apple-Mail=_B9BE9959-459A-4FDE-B40B-60E950A887FA-- --Apple-Mail=_270DA9F7-9C3C-4A95-8F28-D48A7D005EF8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJYmshEAAoJELhJCxUKWMyZhrUH/2MaP4S6rwV45ZYEuuFCA2So e7Jipdl6ZgB5E8wDrNnW9c0FGVnYupsH8W9qyex3nAuQZCsRQsgV4wGZxDRrQpoc xca1dAWlTuSQnWzUYBUGotfdcUHF2H7ZLFnPiuLfg4KqD5szgNKe/S8xYzagywwT 2IjLJhMTJS87w3k2HtYGPD8Lvr0sGa2eRfY3JYX1lYMCn4/t+4j0pb2qX+zBQhyp ZNMSNnw9/bTuCaRibkQfMaG/9LGvTEP1ZuzJ+GrpBl/OI0GS5MTyzxRVg326k/E9 y6p9apmneipqbyxBaqu0oMfncKykb2sCMo1bhO7OrceoXee4alLBAl9cQRidjZc= =VOF0 -----END PGP SIGNATURE----- --Apple-Mail=_270DA9F7-9C3C-4A95-8F28-D48A7D005EF8-- From nobody Wed Feb 8 04:45:51 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 7E589126BF6; Fri, 3 Feb 2017 16:26:02 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148616796247.4079.7104562493351135409.idtracker@ietfa.amsl.com> Date: Fri, 03 Feb 2017 16:26:02 -0800 Archived-At: X-Mailman-Approved-At: Wed, 08 Feb 2017 04:45:50 -0800 Cc: jmap@ietf.org Subject: [Jmap] WG Review: JSON Mail Access Protocol (jmap) 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: Sat, 04 Feb 2017 00:26:02 -0000 A new IETF WG has been proposed in the Applications and Real-Time Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2017-02-13. JSON Mail Access Protocol (jmap) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: TBD 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 representations of email 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 can not send new messages). This is further exacerbated if the different protocols are authenticated separately. The JMAP working group will specify a mechanism to allow clients to both view and send email from a server over a single stateless 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. 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. 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. The working group will coordinate with the Security Area on credential management and authentication. Input to working group discussions shall include: - 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 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, and operating over a stateless connection such as HTTPS. - 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. Milestones: From nobody Wed Feb 8 04:45:55 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 A25DA1294D7; Mon, 6 Feb 2017 13:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 3KWVXtxjUBey; Mon, 6 Feb 2017 13:02:01 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F16FA1293F9; Mon, 6 Feb 2017 13:02:00 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id v77so131945995wmv.0; Mon, 06 Feb 2017 13:02:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=cbJLfx0dw+3Oudf2DAt7k9Xm83PCNGCdn5QV1ZMbElU=; b=YFxD7s9tDLOK3IyvWli6l29kTI/kA9T2E6NzJiA2DVmLQZc7NGFnxUEsS0mxCf2Qjv Uof22cypfACdonQ27OD+LQpVj1a3sxBaz+TMGLNW6e8XMMWEe0t10eiLYffMaKAAHzpf 4MWxrHiFtn2w+zNqUCbGvA0hJVr9BCFQwiLEMvuFvVkVgvrVrytF6lPRa5KaL1WPPLGX yY/Hf08gdg+RzwNWTOKkRUfsrFcRaVXND/SvLDhdfu19nu+mIvaFhqfZ8kW8tt6rxqwv /VOmPajB0rgYEfeqWgQ6xR7yA1e9pY5LQFFntCNo+PtNT9O+4IDgKDBFOGB2BK8TnaTJ n2Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=cbJLfx0dw+3Oudf2DAt7k9Xm83PCNGCdn5QV1ZMbElU=; b=YisjFDtAnWhRr+7HAxs4FQncCpMT6xfjbgkwzHtaDXeqZd+rqV+Tt7vSpE57R/s8bT VFr+h+x/kINHpjHgpcvPTSKN8UdyGj5nOzfXmiW7s4N/+9aTn0jwKNotrvenz3XBvLNG v5Qwi5+NPs7h4GJrw7Nv09gduII/nU935xWUmr9+6wsG36y4VAFoYCqbd/R9ja7fJGKR YBQmAi/XG+VurIywUyJnsOl3QouI3B3kRdV99bxe7nPjzNvGPEqXNTyfHtOqQIc9OkOL 4CB33HMM8k2q98vtthq/i3gMDTqEwB0piFuIJXOrWZy1W5xrH2Ud4oK/e8eNhLIaK51U 717Q== X-Gm-Message-State: AIkVDXLulhl13fUklwDi1k417iN+HcbeJtL3iIiX7Lmo7t4orMCG4H5FotgCjuggs9vx5vAjUU3v6QM2eWnuXQ== X-Received: by 10.223.135.43 with SMTP id a40mr12489937wra.197.1486414919391; Mon, 06 Feb 2017 13:01:59 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.194.221.6 with HTTP; Mon, 6 Feb 2017 13:01:58 -0800 (PST) In-Reply-To: References: <4ff42a3b-1f8e-3e25-14e7-b1d3ed2f69c2@isode.com> From: Phillip Hallam-Baker Date: Mon, 6 Feb 2017 16:01:58 -0500 X-Google-Sender-Auth: saIxC86FeK_DimMlnFpn5B8I6A4 Message-ID: To: Adrien de Croy Content-Type: multipart/alternative; boundary=001a114981324260c60547e2f196 Archived-At: X-Mailman-Approved-At: Wed, 08 Feb 2017 04:45:49 -0800 Cc: "jmap@ietf.org" , Alexey Melnikov , iesg , "dcrocker@bbiw.net" , "ietf@ietf.org" Subject: Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 21:02:02 -0000 --001a114981324260c60547e2f196 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Feb 6, 2017 at 3:04 PM, Adrien de Croy wrote: > > > > Adding to this: >>> >>> HTTP/HTTPS are not stateless, since they are connection-based. >>> >> A lot of the people on the HTTP WG would have an issue with this > statement. > > In fact there has been a lot of discussion about the evils of > connection-oriented anything in regard to HTTP, especially around > authentication (e.g. NTLM). > > There are proxies that reuse upstream connections between different > clients, the protocol (1.1 at least) is designed to be stateless in terms > of each message being independent of others, whether on the same connecti= on > or not. > > So I wouldn't start a new protocol based on the presumption that > HTTP/HTTPS is connection-oriented and not stateless. > =E2=80=8B+1 I was hoping we could go a different route here: 1) Write the QUIC protocol. Gives us a multiplexed TCP capability 2) Write a thin shim on QUIC for Web services to replace HTTP presentation 3) Use the result and JSON encoding as the presentation layer for AppsNG=E2= =80=8B =E2=80=8BDoing JMAP on QUIC right now is error 32: Research on Research. Bu= t doing JMAP on HTTP means inventing a second MUX layer. Also bad.=E2=80=8B =E2=80=8BThere is clearly potential =E2=80=8Bto improve on IMAP user experi= ence. GMAIL isn't very much different but it is a lot more responsive because the protocol does things like return the overviews for the 20 latest headers that the app is trying to present to the user rather than the client going into hyperspace as it downloads 15 years of messages. Yes, I know it is possible to do some of the same stuff if the application's IMAP foo is really good. But being able to optimize the round trips because you control both ends of the protocol is very powerful. HTTP has a lot of cruft in it to support browsers running on the 1990s Internet when the whole continent of Australia was connected by a 56Kb dialup and T1 was considered lightning fast. And one of the problems with that sort of cruft is that no matter how rubbish it is or how many problems it creates, there will always be people who squeak if you try to take it out. I am profoundly unimpressed by arguments about using HTTP features like caching in Web services. If HTTP caching works for your Web Service it is probably because what you are doing is re-implementing HTTP in HTTP badly. --001a114981324260c60547e2f196 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Fe= b 6, 2017 at 3:04 PM, Adrien de Croy <adrien@qbik.com> wrote:<= br>



Adding to this:

=C2=A0 =C2=A0HTTP/HTTPS are not stateless, since they are connection-based.=
A lot of the people on the HTTP WG would have an issue with this statement.=

In fact there has been a lot of discussion about the evils of connection-or= iented anything in regard to HTTP, especially around authentication (e.g. N= TLM).

There are proxies that reuse upstream connections between different clients= , the protocol (1.1 at least) is designed to be stateless in terms of each = message being independent of others, whether on the same connection or not.=

So I wouldn't start a new protocol based on the presumption that HTTP/H= TTPS is connection-oriented and not stateless.

=E2=80=8B+1

I was hoping we could go a different route here:

1) Write the QUIC protocol= . Gives us a multiplexed TCP capability
2) Write a thin shim on QUIC for Web services to r= eplace HTTP presentation
3) Use the result and JSON encoding as the presentation layer for= AppsNG=E2=80=8B

=E2=80=8BDoing JMAP on QUIC right now is error 32: Researc= h on Research. But doing JMAP on HTTP means inventing a second MUX layer. A= lso bad.=E2=80=8B

=E2=80=8BThere is clearly potential =E2=80=8Bto improve o= n IMAP user experience. GMAIL isn't very much different but it is a lot= more responsive because the protocol does things like return the overviews= for the 20 latest headers that the app is trying to present to the user ra= ther than the client going into hyperspace as it downloads 15 years of mess= ages.

Yes, I know it is p= ossible to do some of the same stuff if the application's IMAP foo is r= eally good. But being able to optimize the round trips because you control = both ends of the protocol is very powerful.

HTTP has a lot of cruft in it to support browsers runn= ing on the 1990s Internet when the whole continent of Australia was connect= ed by a 56Kb dialup and T1 was considered lightning fast. And one of the pr= oblems with that sort of cruft is that no matter how rubbish it is or how m= any problems it creates, there will always be people who squeak if you try = to take it out.

I a= m profoundly unimpressed by arguments about using HTTP features like cachin= g in Web services. If HTTP caching works for your Web Service it is probabl= y because what you are doing is re-implementing HTTP in HTTP badly.

--001a114981324260c60547e2f196-- From nobody Wed Feb 8 04:45:59 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 6D365129C42; Tue, 7 Feb 2017 06:11:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 g8Qj-hMwumwF; Tue, 7 Feb 2017 06:11:45 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4803129C38; Tue, 7 Feb 2017 06:11:45 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cb6Uh-00007t-HB; Tue, 07 Feb 2017 14:11:43 +0000 Date: Tue, 07 Feb 2017 23:11:41 +0900 Message-ID: From: Randy Bush To: Gren Elliot In-Reply-To: References: <148616796247.4079.7104562493351135409.idtracker@ietfa.amsl.com> <11e900d0-553e-0635-06f4-8510bd80ecfd@dcrocker.net> <4ff42a3b-1f8e-3e25-14e7-b1d3ed2f69c2@isode.com> <368f2b68-8f10-9517-1edb-d213ff10563b@dcrocker.net> <1486435969.2314063.872594064.21072F60@webmail.messagingengine.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: X-Mailman-Approved-At: Wed, 08 Feb 2017 04:45:50 -0800 Cc: jmap@ietf.org, iesg , ietf@ietf.org Subject: Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 14:11:47 -0000 > Trying to setup a new device for use with open protocols is a complete > nightmare - you end up needing to configure 2 things for mail (IMAP > and SMTP) and now, because we will have to be backward compatible, it will be three. so that third had best be a really massive win. and i am not seeing it. what i am seeing is second system syndrome in a wrapper of whatever today's wrapping fashion is. randy From nobody Wed Feb 8 04:46:04 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 25DE7129E80; Tue, 7 Feb 2017 12:03:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 mxeOFI-kjpWt; Tue, 7 Feb 2017 12:03:47 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1866A129E7B; Tue, 7 Feb 2017 12:03:47 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cbBzN-0001oH-GX; Tue, 07 Feb 2017 20:03:45 +0000 Date: Wed, 08 Feb 2017 05:03:42 +0900 Message-ID: From: Randy Bush To: Gren Elliot In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Wed, 08 Feb 2017 04:45:50 -0800 Cc: jmap@ietf.org, iesg@ietf.org, ietf@ietf.org Subject: Re: [Jmap] Fwd: Re: WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 20:03:48 -0000 >> Trying to setup a new device for use with open protocols is a >> complete nightmare - you end up needing to configure 2 things for >> mail (IMAP and SMTP) >=20 > and now, because we will have to be backward compatible, it will be > three. so that third had best be a really massive win. and i am not > seeing it. what i am seeing is second system syndrome in a wrapper of > whatever today 's > wrapping fashion is. >=20 > randy >=20 > Why? You will either be using IMAP/SMTP to access your mail/submit > your messages or you will be using JMAP. If you have the option of > the latter, you=A2ve just halved the number of things that need > configuring. how does the server forward the submitted mail to the global internet? how does the server migrate 200 or 2,000 imap users at human speed, i.e. over months? yet another protocol that requires a flag day. that has worked out so well for ipv6. randy From nobody Wed Feb 8 04:46:06 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 61AE1129613; Tue, 7 Feb 2017 12:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 TABe48b23GSS; Tue, 7 Feb 2017 12:54:19 -0800 (PST) Received: from bsa2.jck.com (ns.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 AE56B1294A5; Tue, 7 Feb 2017 12:54:19 -0800 (PST) Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1cbCmG-000NRc-9V; Tue, 07 Feb 2017 15:54:16 -0500 Date: Tue, 07 Feb 2017 15:54:09 -0500 From: John C Klensin To: Randy Bush , Gren Elliot Message-ID: <9D66E5E7619E1C55F1DEB959@PSB> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.70 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: X-Mailman-Approved-At: Wed, 08 Feb 2017 04:45:50 -0800 Cc: jmap@ietf.org, iesg@ietf.org, ietf@ietf.org Subject: Re: [Jmap] Fwd: Re: WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 20:54:21 -0000 I agree with most of Dave Crocker's comments and don't have much time to spend on a proposal that, if approved, I believe (for reasons that overlap those he cites) will, like many of its predecessors, die a quiet death after wasting a lot of time. However, the exchange surrounding one of Randy's comments prompts a further remark or two... --On Wednesday, February 8, 2017 05:03 +0900 Randy Bush wrote: >> Why? You will either be using IMAP/SMTP to access your >> mail/submit your messages or you will be using JMAP. If you >> have the option of the latter, you=CA=BCve just halved the = number >> of things that need configuring. >=20 > how does the server forward the submitted mail to the global > internet? >=20 > how does the server migrate 200 or 2,000 imap users at human > speed, i.e. over months? So, suppose I have a mail server that, because it is configured in the real world, has to support SMTP and IMAP (and maybe POP3) for existing users while trying to support new MUAs that use this JMAP stuff. Randy suggests that requires configuring three kinds of systems. I suggest that he underestimates the problem. First, there is not just "configuring" but "supporting". Working with configurations may be an infrequent activity. Providing support is a continuing one and takes time, even if one's idea of support is saying "what do you want for nothing, figure it out yourself" in a firm tone and at frequent intervals. A change from an IMAP/SMTP base to supporting a new model or representation and systems that provide it vastly increases that job, and increases it by at least a factor of three (old one, new one, people considering or trying to make the transition). Second, there is an issue that Randy and Dave both hinted at in different ways. Unless the proposal is to use Jmap end to end, replacing SMTP, conversion issues have to be worked out. The community made a series of decisions around the time MIME was adopted that essentially require that the SMTP payload be either unstructured messages (essentially conformant to 822) or MIME. The previous (albeit controversial) idea that, other than trace fields inserted by SMTP MTAs, SMTP could treat the message as header-free and opaque and carry material that was not at least 822-conformant is history. That means one needs to configure, maintain, support, and debug: SMTP IMAP JMAP SMTP/Standard Message Headers -> JMAP for inbound messages JMAP -> Message Submission for outbound messages. That is a big deal. There better be a lot of added value to justify it or it will go nowhere (a slightly different negative analogy to the rapid and overwhelming success of IPv6 is perhaps obvious), just as a variety of grand solutions to real or imagined problems with email have gone nowhere. With this proposal, I see some small incremental improvements for systems that are working in JSON environments anyway, but nothing that would justify widespread implementation and deployment. The answer might be different for a mail system that assumed that all users would be using the same mail store and either webmail or JSON-based clients/MUAs. But such mail systems exist only in proprietary walled gardens and should not be IETF topics except possibly for mail gateways to and from them. And those gateway raise most of the issues outlined above. TL;DR summary: Just say 'no'. john From nobody Wed Feb 8 04:46:09 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 9308112955D for ; Tue, 7 Feb 2017 17:47:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=cursive.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 It_okBHUsz86 for ; Tue, 7 Feb 2017 17:47:48 -0800 (PST) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43FAB126D73 for ; Tue, 7 Feb 2017 17:47:48 -0800 (PST) Received: by mail-it0-x22e.google.com with SMTP id r185so93455048ita.0 for ; Tue, 07 Feb 2017 17:47:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cursive.net; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=CBzYPuRG/ZoOo9uik6vekkUrTMoVWccit0mfMc0nJHE=; b=M1bRQ73QRnJzGeAhqA5sKtAZXT06pJFN5KNAXZ3NCImuqacipSpJ8S0Noml7MAj4IG JreVOUxBb0nd7wFUgPyx2FdtFKMmCOjWgYYfc/tuu/1uXyQB3Sf6a3tF6Yhy1Aim1gCQ HS2iTPhCl2Ce92ryJU0QZAY3N4srI+yvR6xqI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=CBzYPuRG/ZoOo9uik6vekkUrTMoVWccit0mfMc0nJHE=; b=h5T+EsiucM12uKUZFAgV8oi5O7jyBPaXDZpkiyyHb3JUbQd3wnC38gmSOlmoZOlxib G1CVNJLAJgSRnDHeFcn1JSSG/PbTIO+pk+kvzR5hexYCkD2trQYD9FUTNwH7v0gaYunL aDL05IWCY9nEx8HgIipiEZTHrHp5JbaCkvSs2vPJMuO8JZQXVjVBJfrCRap+nEE4kq4X 97tLNG4ofKzvbT7Ct8IjX+mjT1wV6pv+iD0T7y0Gb2ocsFa25eNwxjDn++HC7Wb2s3Ko ZloV22tUHvOgjIeS2v3Msm1IT73SYt1uin59IV3kOca+5IIMhChBXPMng3+AY6d0ylg9 1nbQ== X-Gm-Message-State: AMke39maPSPwko2Gd80LVMOvI+mhW8xEY2l5gLn4zoR1rvfTVbXMZ5s5sw8qu18fGXHSsQ== X-Received: by 10.36.206.2 with SMTP id v2mr6145218itg.74.1486518467593; Tue, 07 Feb 2017 17:47:47 -0800 (PST) Received: from ?IPv6:2601:282:200:9150:dc3e:edc3:f0b5:a0dd? ([2601:282:200:9150:dc3e:edc3:f0b5:a0dd]) by smtp.gmail.com with ESMTPSA id y42sm10517806ioi.21.2017.02.07.17.47.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Feb 2017 17:47:46 -0800 (PST) From: Joe Hildebrand Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 7 Feb 2017 18:47:45 -0700 References: <9D66E5E7619E1C55F1DEB959@PSB> To: jmap@ietf.org, IESG , IETF discussion list In-Reply-To: <9D66E5E7619E1C55F1DEB959@PSB> Message-Id: <1A1381DB-DF79-4FC8-88F4-60A0AF4FE3CA@cursive.net> X-Mailer: Apple Mail (2.3259) Archived-At: X-Mailman-Approved-At: Wed, 08 Feb 2017 04:45:49 -0800 Subject: Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 01:47:49 -0000 > On Feb 7, 2017, at 1:54 PM, John C Klensin wrote: >=20 > TL;DR summary: Just say 'no'. No hats, personal opinion only, and in response to several of the = messages in this thread, not directly to John. Will it ever be possible for new work to be proposed at the IETF without = drowning out a chorus of nitpickers? You may not want to help = standardize it. You may not want to implement it. You may not want to = deploy it. You may not want to use it. So don't. This work won't hurt the Internet, particularly if done with productive = input from a couple of people with experience in the existing system, = and some cross-area review. You may not like that all application developers want to use HTTPS (and = derivatives like QUIC), WebSockets, JSON, etc. However, forcing = everyone who wants to standardize a modern protocol to justify their = desire to use a set of modern building blocks has gotten tiring, and = makes people avoid bringing good technical work to the IETF that would = benefit from cross-area review. Every time we make this sort of work difficult at the IETF, we reinforce = the message that the IETF only exists to pay homage to the protocols of = our forefathers. When it comes to email in particular, the system that = accreted over the years is baroque at best. We should not stand in the = way of any attempt to simplify the steaming pile of cruft we preside = over because the work might be hard. Several of the concerns that have been raised in this thread are = interesting, useful, and might make the work better over time. Had they = not been phrased with an implied "so therefore your whole idea is dumb = and you should go away", I probably would have been able to keep myself = from writing this note. TL;DR summary: Just say 'yes'. =E2=80=94=20 Joe Hildebrand From nobody Wed Feb 8 04:46:15 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 2FD0D129A05 for ; Wed, 8 Feb 2017 04:39:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cridland.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 sJLZp5wIQrF8 for ; Wed, 8 Feb 2017 04:39:41 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED0541294FA for ; Wed, 8 Feb 2017 04:31:04 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id v77so188699386wmv.0 for ; Wed, 08 Feb 2017 04:31:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=LwDgrJGQ+kH1QTxJnMZiIzUp5zyfao20oFw9nMa7WLo=; b=kNt0pfyHVXO4ZWE3b6gef0zNIoQ9lXaM1DOZ2MV9p6u7zhapRUMqgGW8PQiPJyqQZ4 FK/TyqKq5dFL5Tb7ew87HTmSg4afxPt2cLQ+FgcoxoM09Lc1PgnntAWBNK04SDC2M4tn S0Wwxmks9N0NYfUZQpjmia4XR/YxB+4o2pcyY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=LwDgrJGQ+kH1QTxJnMZiIzUp5zyfao20oFw9nMa7WLo=; b=BHbt1T47U+mCFetFEAkIh/c6DNPmyC/L59IAvWoe/hadKofTdRQivDojiIJbguB7OS nvYBTVCkBFj5+wjftlfwz3CwzEq4mzM9qZeNytKTkVsTiErWWtGzB0+ozfrIpM+/hAZF 7ddQFL0S+Xc3HVJxXSajsFa7cGBO7xkFsEQ2BlVL0IrWoetDmQSWE4Ajf9dEVX+j8Ad7 JMpsLFR6byyhFSQ+yUClVEfwsFqkq8v/3mc/WY8Xst6dZ1CRpf6RioYTr44WYOWx+NA6 SARbm7JjB52ex1tmvNKtMF6JFiA0wiFsuEpsgQZMIwJ3GBixyollKR65x6euKVMCpM5s GOgA== X-Gm-Message-State: AMke39mwGXxqp+wLaKK7UmsTWRR6x8Yiy5Tl2P53TRPXttkXE/89uh1jphBOUoRYgiSq3rZXcPY+FETQ0W5qnZ1q X-Received: by 10.28.191.79 with SMTP id p76mr16948651wmf.21.1486557063415; Wed, 08 Feb 2017 04:31:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.136.199 with HTTP; Wed, 8 Feb 2017 04:31:02 -0800 (PST) In-Reply-To: References: <9D66E5E7619E1C55F1DEB959@PSB> <1A1381DB-DF79-4FC8-88F4-60A0AF4FE3CA@cursive.net> <1486523704.3711423.873904592.78C4EAA8@webmail.messagingengine.com> From: Dave Cridland Date: Wed, 8 Feb 2017 12:31:02 +0000 Message-ID: To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Wed, 08 Feb 2017 04:45:49 -0800 Cc: jmap@ietf.org, Neil Jenkins , IESG , IETF discussion list Subject: Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 12:39:42 -0000 On 8 February 2017 at 07:26, Yoav Nir wrote: > That=E2=80=99s good to know. I=E2=80=99m wondering if implementing a gene= ric email client > (rather than a specific =E2=80=9Cgmail=E2=80=9D or =E2=80=9Clive=E2=80=9D= client) isn=E2=80=99t becoming ever > harder. With so many older and newer services, a client has to support po= p3, > imap, smtp, EWS, ActiveSync, and maybe a few of the others you mentioned. > This effort proposes to add yet another one. > It does; but as someone who has had to implement IMAP from both sides, I think it's worthwhile to revisit IMAP's space and look at a green-field rewrite. JMAP works well particularly for web-based, client-centric development; that's a space I've seen a lot of, and particularly a considerable amount of more innovative deployments of existing protocol work (such as XMPP, which is also very web-friendly). I would suspect that if we can pull JMAP together and see reasonable deployment, we'll see an increasing demand for its use for all manner of things we have yet to think of. It seems to be well-thought through for mobile, too. While I agree, with feeling, that writing a generic desktop MUA has become increasingly hard in recent years, I also note that this isn't what consumers seem to want either. Consumers respond much better to Web and/or Mobile - and JMAP makes it considerably simpler to write either. TL;DR: Yes. Dave. From nobody Wed Feb 8 04:57:01 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 1CD4A129A16 for ; Wed, 8 Feb 2017 04:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.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 a9SxKIIOoRgw for ; Wed, 8 Feb 2017 04:56:57 -0800 (PST) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84B5512951B for ; Wed, 8 Feb 2017 04:56:57 -0800 (PST) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 5EC33CEC00C; Wed, 8 Feb 2017 12:56:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1486558615; bh=bANChjy0L0N+Ao3iUcIF1RiibF47k0HaAC6Id6zRmBk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=cMmMZ0KTN0OtqgUpYRvz9aaJbwS3R4BKzjlZ+6AW9lHXo4/QcXRSE+PwY1OBkMfM/ y4K4preyCxKZrA68h25jeSO0bIZ61kobWZ/f+jM4jz2o36/MyyogmCujGk74Vdop5p 7G7+ypXQVq15EZvxDyHWaGH8Owi4Dv6rejcLEz/o= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1486558614-2178-25938/11/11; Wed, 8 Feb 2017 12:56:54 +0000 From: Arnt Gulbrandsen To: jmap@ietf.org Date: Wed, 8 Feb 2017 12:56:54 +0000 User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Devuan GNU/Linux 1.0 (jessie) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [Jmap] Fwd: Re: WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 12:57:00 -0000 Randy Bush writes: > yet another protocol that requires a flag day. that has worked out > so well for ipv6. JMAP does not, AFAICT, require a flag day, any more than IMAP required a flag day over POP. If Fastmail's deployment of JMAP-in-spe was noticed by its customers, the noise certainly hasn't been loud enough that I've heard about it. Arnt From nobody Wed Feb 8 05:11:52 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 9EE08129A24 for ; Wed, 8 Feb 2017 05:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.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 OsMoORQgb9nB for ; Wed, 8 Feb 2017 05:11:49 -0800 (PST) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B107A126DFB for ; Wed, 8 Feb 2017 05:11:49 -0800 (PST) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 5A360CEC00C; Wed, 8 Feb 2017 13:11:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1486559508; bh=NMzHbhxGcFeP9YbAq6DAAGMJC3AHeQNks0V9nhW2P+4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=fSkMdDMQBc87f/Z9G1SkLPIwQzw1Q6dU0uB6Lf2jMJd7NLUfrH3NKmccPoEh1E9gS lyEYHfPZRyj2rTsL6OuCfKibuqIArRYdJ35CtMoVpNwb8eKk055HIuu/JkVgsOuZsU s9rpLYndxcyeDgdt5PrE5jm3xzZc8WXKFtnkJGnQ= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1486559507-14518-25938/11/4; Wed, 8 Feb 2017 13:11:47 +0000 From: Arnt Gulbrandsen To: jmap@ietf.org Date: Wed, 8 Feb 2017 13:11:46 +0000 User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Devuan GNU/Linux 1.0 (jessie) Mime-Version: 1.0 Message-Id: <75b30a3d-5364-4d84-a36e-efaa8821767f@gulbrandsen.priv.no> In-Reply-To: <1486504179.3213069.873654632.4001B565@webmail.messagingengine.com> References: <148616796247.4079.7104562493351135409.idtracker@ietfa.amsl.com> <11e900d0-553e-0635-06f4-8510bd80ecfd@dcrocker.net> <4ff42a3b-1f8e-3e25-14e7-b1d3ed2f69c2@isode.com> <368f2b68-8f10-9517-1edb-d213ff10563b@dcrocker.net> <1486435969.2314063.872594064.21072F60@webmail.messagingengine.com> <1486504179.3213069.873654632.4001B565@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 13:11:50 -0000 Bron Gondwana writes: > This reasoning is why so many non-IETF protocols have been > gaining marketshare in the client space. The underlying > protocols need to support usable interface design, and be simple > enough to implement that somebody who wants to write a great new > email client doesn't spend their first 6 months fighting the > protocols and then give up. This, +1. There are things I don't like about the JMAP document. Noone seems to bring any of them up. Instead we get things like "IETF protocols in this space must support having one password for sending mail and another for reading". Bleh. Arnt From nobody Wed Feb 8 05:35:17 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 E61B0129A38; Wed, 8 Feb 2017 05:35:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 o7RnXlMSy-UY; Wed, 8 Feb 2017 05:35:14 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 811D0129A21; Wed, 8 Feb 2017 05:35:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1486560913; d=isode.com; s=june2016; i=@isode.com; bh=vO6lDZmEov1k+sdWXvpEYmOBvYU6jdAVFLd+udMlg5I=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=drMEImk78QlDE4RSNCWkhM8UwrZcw+jkHVlZHtkGaPGJtbnWj0RsoOZa0vq6z+lZCg84n2 SRruXNGx0Os8rDE2IllzrvBxofXwXI4hGRNsvK7JZ8qKgRMcmrUemLRe+RaBQt0gZDRZYd J7NjnqGx8wRF2ReilbzPd7lIL8Xq1FA=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 8 Feb 2017 13:35:13 +0000 To: dcrocker@bbiw.net References: <148616796247.4079.7104562493351135409.idtracker@ietfa.amsl.com> <11e900d0-553e-0635-06f4-8510bd80ecfd@dcrocker.net> <4ff42a3b-1f8e-3e25-14e7-b1d3ed2f69c2@isode.com> <368f2b68-8f10-9517-1edb-d213ff10563b@dcrocker.net> From: Alexey Melnikov Message-ID: <125d54fa-eb60-cf14-db93-0c5602be58ad@isode.com> Date: Wed, 8 Feb 2017 13:34:55 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 In-Reply-To: <368f2b68-8f10-9517-1edb-d213ff10563b@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: jmap@ietf.org, ietf@ietf.org, iesg Subject: Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 13:35:16 -0000 Hi Dave, On 06/02/2017 20:11, Dave Crocker wrote: > Alexey, thanks for the quick followup. > > inline... > > On 2/6/2017 11:41 AM, Alexey Melnikov wrote: > >> There also needs to be clarity about the relationship between the JSON > >> encodings and the encodings in 'native' Internet Mail. >> See drafts (and above). > > Drafts? What drafts? Perhaps you mean: > > https://tools.ietf.org/html/draft-jenkins-jmap > > Except that no draft is cited in the charter. I realized that I accidentally deleted an important sentence from the Charter while doing editing. One of the paragraphs should have read: The work of this group is limited to developing a protocol for a client synchronising data with a server. The work will be based on draft-jenkins-jmap and draft-jenkins-jmapmail. Any server-to-server issues are out of scope for this working group. 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. Best Regards, Alexey From nobody Wed Feb 8 05:39:40 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 2371D129A59; Wed, 8 Feb 2017 05:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 tIhBRsBp4vjX; Wed, 8 Feb 2017 05:39:37 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id A16AF129A4F; Wed, 8 Feb 2017 05:39:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1486561176; d=isode.com; s=june2016; i=@isode.com; bh=ySc+N2mjFStBNxbV36zhF2B+70IKXZoQLLMuVWIxJ2Q=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Df4YdHNvtugxgGzrL8MF+PXEi/S3iqJ2iJWFNUVE50q4hgNSUHYEtVw6Y9ExnlwMu88ORi OwKcPLpaG7L3yxV1BoRFpysjeQGEr2yY0LSCwm98P7Fy7BVxyX252t8Q5dG5a5JeixXQIU wjHYUVQ4RpoJe4F1+kD3M/lFm3/WeV8=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 8 Feb 2017 13:39:36 +0000 To: dcrocker@bbiw.net References: <148616796247.4079.7104562493351135409.idtracker@ietfa.amsl.com> <11e900d0-553e-0635-06f4-8510bd80ecfd@dcrocker.net> <4ff42a3b-1f8e-3e25-14e7-b1d3ed2f69c2@isode.com> <368f2b68-8f10-9517-1edb-d213ff10563b@dcrocker.net> From: Alexey Melnikov Message-ID: <03152892-3987-145c-8206-e3ccfe3a7510@isode.com> Date: Wed, 8 Feb 2017 13:39:19 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 In-Reply-To: <368f2b68-8f10-9517-1edb-d213ff10563b@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: jmap@ietf.org, ietf@ietf.org, iesg Subject: Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 13:39:39 -0000 Dave, On 06/02/2017 20:11, Dave Crocker wrote: > Alexey, thanks for the quick followup. > > inline... > > On 2/6/2017 11:41 AM, Alexey Melnikov wrote: >>> Working groups need task serialization. So I'll suggest that >>> having an effort to standardize an JSON representation of an >>> RFC5322/MIME object would be the highest-leverage first task. >> I don't think there is intent to specify full mapping of RFC5322/MIME to >> JSON. IMAP has BODYSTRUCTURE element that contains parsed representation >> of message structure and most commonly used header fields for different >> body parts. The intent is to do the same here. >> Additionally, it is still possible to retrieve full RFC5322/MIME >> payloads over JMAP. > > This highlights the need to have far more clarity about what specific > work is to be done and what is not. The existing text has some > generic out-of-scope text, but nothing as frankly useful as your above > comment. Given that comment, I can't text what parts of the resulting > jmap service will use 'native' Internet Mail technical details and > what parts will be new-for-JSON. > > >> I have tried to reflect your comments in the Charter, but I struggled a >> bit. If you can suggest how to make the above clearer, that would be >> much appreciated. > > I make a point of offering candidate text when I think I understand > the context and needs well enough. Unfortunately I don't have that > here. Hence, questions and general suggestions is the best I can > offer. Sorry. > > >>> Adding to this: >>> >>> JSON is a meta-format. It isn't a 'protocol'. Something encoded in >>> JSON is a format, not a protocol. Hence one of the tasks apparently >>> being chartered would be to create a new message access protocol, >>> encoded in JSON. While that might be worth doing, there needs to be >>> clarity that this is more than a 'representation'. >> No, it is a representation. See above. > > As soon as one says that the task is client/server interaction, one is > declaring the goal of a protocol. So it is more than just a format > (representation.) > > > >> There also needs to be clarity about the relationship between the JSON > >> encodings and the encodings in 'native' Internet Mail. >> See drafts (and above). > > Drafts? What drafts? Perhaps you mean: > > https://tools.ietf.org/html/draft-jenkins-jmap > > Except that no draft is cited in the charter. > > >>>> 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. >>> >>> From my November comments: >>> >>> There is no justification given for this approach. For each >>> activity, there needs to be a clear and solid need documented, based >>> on actual industry activities or at least industry statements. >>> Besides clarifying /what/ needs doing, it should serve to indicate >>> likely industry uptake after the work is done. >> >> I am not sure what kind of justification is needed. This is a clear >> deployment problem. > > As I said, there was a year-long, serious and diligent debate about > this in the IETF and it came to a different conclusion. So it's not > nearly as 'clear' as you are asserting. > > >>> Adding to this: >>> >>> The IETF email technical community looked at the question of making >>> email submission part of IMAP or keeping it separate. It took an >>> entire year to debate this point extensively and (imo) constructively, >>> and decided to keep them separate. The current charter draft appears >>> to have decided otherwise, but offers only the barest of >>> justifications, which I suspect has not factored in the earlier >>> evaluation. >> There was a followup discussion about doing an IMAP extension for >> submission and how it should look like to remain compatible with SMTP >> Submission. I don't think this is an attempt to just ignore earlier >> discussions. > > Discussion is different than deployment. The fact that it isn't used > now suggests that the benefit(s) you are asserting aren't as clear-cut > as is being implied here. To the extent that the current proposal > does indeed represent a consideration of the prior, extended IETF work > in this realm, the charter should indicate the basis for making a > different choice here, in terms of the points considered earlier. > > > >>>> 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, and operating over >>>> a stateless connection such as HTTPS. >>> >>> 'flood control'? what does this mean, since I assume the target >>> protocol won't be using a flooding algorithm. If it really means >>> 'congestion control', that's not typically part of an application >>> protocol, so why would it be an issue here? >>> >>> From the November comments >>> >>> Since client/server email access typically benefits from having >>> the server retain state about the client's activities, I can't tell >>> whether this actually means stateless lower-level transport or whether >>> it really does mean a stateless email protocol. >> >> Stateless lower level transport. The addition of "such as HTTPS" was >> trying to make this clearer. > > Didn't succeed, given that HTTP runs over TCP. The protocol is HTTP version agnostic, for the most part. The original thought was that it is less stateful than IMAP, which requires a mailbox to be opened for some operation. But the server still needs to maintain state (for example to track flag modifications). So saying "stateless" is incorrect, so I deleted it in 2 places in the Charter. [...] >>> Adding to this: >>> >>> HTTP/HTTPS are not stateless, since they are connection-based. >> Yeah, I struggled with this a bit. Each request/response can be sent on >> a separate connection and it is stateless in that sense. > > In other words, jmap will be stateless. That's what the charter > should say. > > ...Except that that seems odd, since it means that every exchange > would have to self-identify and self-authorize. True. > I suspect that's not what's going to be defined. So, really, it isn't > obvious to me at all what will be stateless. As you pointed out, saying stateless is not really correct. Best Regards, Alexey From nobody Wed Feb 8 05:49:15 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 1ABFD129A9B for ; Wed, 8 Feb 2017 05:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 rfKtjevVfqjy for ; Wed, 8 Feb 2017 05:49:13 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 26BA4129A9A for ; Wed, 8 Feb 2017 05:49:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1486561752; d=isode.com; s=june2016; i=@isode.com; bh=9fXnFMYNMMh9QOvWcO3mHGYfck7BvAFHtDqlBJoblMM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=KzRFy5CMUJ1ylE9WxPfIVtsTsum1bC/TWCB1wSubYFMuIB/rynKsdxzSbWe/AYchg9rRjG 7r3XVHZPFjEQc8GMPockaxrrRpvP5UfBmjmi2uDNlWpQw281QTgPKB2UqNRi174n4sSa8r 1jfOtCF7ydVlJRQmg3Fn6XLamHRGK54=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 8 Feb 2017 13:49:12 +0000 To: Arnt Gulbrandsen , jmap@ietf.org References: From: Alexey Melnikov Message-ID: <3b955910-12d0-2c56-0dc2-30279f98aea5@isode.com> Date: Wed, 8 Feb 2017 13:48:54 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Jmap] Fwd: Re: WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 13:49:14 -0000 On 08/02/2017 12:56, Arnt Gulbrandsen wrote: > Randy Bush writes: >> yet another protocol that requires a flag day. that has worked out >> so well for ipv6. > > JMAP does not, AFAICT, require a flag day, any more than IMAP required > a flag day over POP. If Fastmail's deployment of JMAP-in-spe was > noticed by its customers, the noise certainly hasn't been loud enough > that I've heard about it. Agreed. JMAP and IMAP are likely to co-exist for long time. From nobody Wed Feb 8 07:52:58 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 81B70129BC8 for ; Wed, 8 Feb 2017 07:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 s_xtVzdPhQMv for ; Wed, 8 Feb 2017 07:52:49 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 522AA129BF7 for ; Wed, 8 Feb 2017 07:52:48 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id x49so168758074qtc.2 for ; Wed, 08 Feb 2017 07:52:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=z1m5EOclSmibcd7g+cl87DhdXOZ7GOFKiabw6NyhULg=; b=JFXm4CR4kHbGWJ8Qp9ERxuwjOvLyhxIHY5JO9tMiEhEsyGQj+XTcDtdP4omDxwKlO2 InDxtl2lU5/PIpkbK0FPbifDyz52mEqFbR6KfSMu5ikNU4+pa61LGGVixK//HN4wgnFh XIOLAudmx9zJ/LurY1fK0hJtVOEIu/PZsuo9+J8lIbKb2CGp36hZ/jMCioROGgmsq/jW Vg7f4meSRSpv1QQU9BnngU5f6oNR2SpQZd4vfCleqTzItdizdp7JakCbdZaT3e03MGNk klg79OxffGNkUfr0CHk3cszCtFWcBKseHR1lfGW3pSsChD2K0qTP1DX5vv0SAhjwxaC+ dYoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=z1m5EOclSmibcd7g+cl87DhdXOZ7GOFKiabw6NyhULg=; b=PAJnIixYf/KIjlDbwgkuyFbw4EjCLk1yP4FCNNRki063TLQa6z6fjlNT70MjNF06Sf U6PMiQIOuYjdQ/rdZJj7pg5sifb6SG4ZSBxKcH1fuPbPHoZoKlk5VgLExA54wZkRzqiD HrY8ororEHQ914V0muyXmXeen9rbeZQsRZDzuYZ92ft0B/IsEqn42ioR7j1EQUNFkQ+b 0CLULapdQr8gW585C49ZrRv7dpJZUwT/s0R5HnKHadt3DCaA9VvkGbARj4ldSWfQDG99 dkGy34HeYULEZyLTv69k+H0Cf75ZIhEdtSYbPyZZkH4o46/LyfRVEhD/qUtddvgkNPZs DnQQ== X-Gm-Message-State: AMke39lg6hr5t3B2+Ljw19GHMKRAtZGqXcYyuSl5+qQp/rumcHG2dpOnCH7VTFKY/RMlRg== X-Received: by 10.237.38.65 with SMTP id z59mr20099565qtc.5.1486569167387; Wed, 08 Feb 2017 07:52:47 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id s20sm6451027qtc.39.2017.02.08.07.52.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Feb 2017 07:52:46 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ted Lemon In-Reply-To: Date: Wed, 8 Feb 2017 10:52:44 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9D66E5E7619E1C55F1DEB959@PSB> <1A1381DB-DF79-4FC8-88F4-60A0AF4FE3CA@cursive.net> <1486523704.3711423.873904592.78C4EAA8@webmail.messagingengine.com> To: Yoav Nir X-Mailer: Apple Mail (2.3259) Archived-At: Cc: jmap@ietf.org, Neil Jenkins , IESG , IETF discussion list Subject: Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 15:52:50 -0000 On Feb 8, 2017, at 2:26 AM, Yoav Nir wrote: > That=E2=80=99s good to know. I=E2=80=99m wondering if implementing a = generic email client (rather than a specific =E2=80=9Cgmail=E2=80=9D or = =E2=80=9Clive=E2=80=9D client) isn=E2=80=99t becoming ever harder. With = so many older and newer services, a client has to support pop3, imap, = smtp, EWS, ActiveSync, and maybe a few of the others you mentioned. This = effort proposes to add yet another one. The protocol and database backend parts of implementing a mail client = are only difficult in the sense that ActiveSync is not a standard. = IMAP, SMTP and POP protocol implementations are readily available. The = problem is not that they are hard to implement. It's that they don't = work very well. SMTP works great, don't get me wrong, but IMAP and POP = both use the wrong data abstraction, and consequently are very hard to = get right, and generally aren't gotten right. So a new protocol that has the data abstraction right is actually a = substantial improvement. I don't know if that's the case with = JMAP=E2=80=94if it's the same data abstraction as IMAP, it's not worth = bothering with, but that's something that at least in theory can be = discussed. What JMAP does afford is the opportunity to have an embedded web client = that doesn't suck, and a way to escape it if you want something more = stateful. Doing IMAP in a web browser is painful. I've seen it done. = It wasn't pretty, and the company that did it corkscrewed in and left = a crater. So practically speaking, if you want to do email that way, = you are already implementing something like JMAP, but you are doing it = by yourself, and it's not standard, so your customers are stuck with = what you did. Even if the data abstraction is wrong in JMAP, you still get a = substantial win from that one improvement. From nobody Wed Feb 8 09:29:03 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 1DBB2129CC0 for ; Wed, 8 Feb 2017 09:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mail.ru 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 gcZ6sDIDi62G for ; Wed, 8 Feb 2017 09:28:58 -0800 (PST) Received: from smtp58.i.mail.ru (smtp58.i.mail.ru [217.69.128.38]) (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 459C2129CC1 for ; Wed, 8 Feb 2017 09:28:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail2; h=Content-Type:MIME-Version:To:From:Message-ID:Subject:Date; bh=Hj0n3MY3PPWt8X2p6ek+pBt8IKNCyrGJo5WVLKyvE+I=; b=tvBU2Zp/xgfMASXEbeLTJuwxTOgT5HfPzzzqzqG1QqtOW0UHwxRdSms+sJdrZHwgk6XkPfNIlnVTkU2zLc/jXk/pNvW7d0+WEfyoUiqk6myPFiTOM4hWQuU1omf58PU1v8ukgKWWEpDr2SgN0ob3AuOeWjjY7pviaQrCdb7jFaQ=; Received: from [176.59.205.124] (port=38654 helo=[10.38.99.97]) by smtp58.i.mail.ru with esmtpa (envelope-from ) id 1cbW34-0005PA-5I for jmap@ietf.org; Wed, 08 Feb 2017 20:28:54 +0300 Date: Wed, 08 Feb 2017 22:28:48 +0500 Message-ID: From: podkorytov To: jmap@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_283888514375122" Authentication-Results: smtp58.i.mail.ru; auth=pass smtp.auth=podkorytov@mail.ru smtp.mailfrom=podkorytov@mail.ru X-E1FCDC63: 4545FA44942FE8DD9EBB7D673DC460D8 X-E1FCDC64: 9DDFE3E4DFA4299295F766CFDDEE45230E53E65140CC2AE8221106CF127E2562 X-Mailru-Sender: 5D67B58A54B5C5CD025A4498BA765EDD256F0CAF0B0909F495650275A1269A1AB563E0FD049BBE8F224C9A2F61B97637 X-Mras: OK Archived-At: Subject: [Jmap] JMAP security X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 17:29:02 -0000 ----_com.android.email_283888514375122 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGVsbG8sIHdoYXQgYWJvdXQgSk1BUCBjbGllbnQgc2VjdXJpdHkgPyAKSWYgaXQgd2lsbCB3b3Jr cyBpbnNpZGUgd2ViIGJyb3dzZXIgaXQgY2FuIGluaGVyaXQgaXQgdnVsbmVyaWFiaWxpdGllcyBh bmQgam9pbiBvd24sIApBbnkgYnJvd3NlciBwbHVnaW5zIHN1Y2ggYXMgQWRvYmUncyBvciBzb21l dGhpbmcgZWxzZSBtYXkgYmUgcG90ZW5jaWFsIGhvbGUgYW5kIHRhcmdldHMgZm9yIGF0dGFja3Mu IApQcm9iYWJseSBpdCBxdWVzdGlvbiBvdXQgb2YgZnJhbWVzIG9mIHByb3RvY29sIGRyYWZ0ICwg YnV0IGl0IHByYWN0aWNhbCB0aGluZyBhbmcgbWF5IHRvIGluZmx1ZW5jZSBvbiBKTUFQIHN1Y2Nl c3Mgb3IgZmFpbC4gSXQgd2lsbCB3b3JrcyBpbnNpZGUgYnJvd3NlciB3aXRoIG1hbnkgb3RoZXJz IHdlYiBhcHBsaWNhdGlvbnMgYW5kIHBsdWdpbnNlcy4K ----_com.android.email_283888514375122 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PHAgZGlyPSJsdHIiPkhlbGxvLCB3aGF0IGFib3V0IEpNQVAgY2xpZW50IHNlY3VyaXR5ID8gPGJy PgpJZiBpdCB3aWxsIHdvcmtzIGluc2lkZSB3ZWIgYnJvd3NlciBpdCBjYW4gaW5oZXJpdCBpdCB2 dWxuZXJpYWJpbGl0aWVzIGFuZCBqb2luIG93biwgPGJyPgpBbnkgYnJvd3NlciBwbHVnaW5zIHN1 Y2ggYXMgQWRvYmUncyBvciBzb21ldGhpbmcgZWxzZSBtYXkgYmUgcG90ZW5jaWFsIGhvbGUgYW5k IHRhcmdldHMgZm9yIGF0dGFja3MuIDxicj4KUHJvYmFibHkgaXQgcXVlc3Rpb24gb3V0IG9mIGZy YW1lcyBvZiBwcm90b2NvbCBkcmFmdCAsIGJ1dCBpdCBwcmFjdGljYWwgdGhpbmcgYW5nIG1heSB0 byBpbmZsdWVuY2Ugb24gSk1BUCBzdWNjZXNzIG9yIGZhaWwuIEl0IHdpbGwgd29ya3MgaW5zaWRl IGJyb3dzZXIgd2l0aCBtYW55IG90aGVycyB3ZWIgYXBwbGljYXRpb25zIGFuZCBwbHVnaW5zZXMu PGJyPjwvcD4K ----_com.android.email_283888514375122-- From nobody Wed Feb 8 11:02:00 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 97538129D89 for ; Wed, 8 Feb 2017 11:01:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 7t3VxdMsRQOT for ; Wed, 8 Feb 2017 11:01:58 -0800 (PST) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C388129DAE for ; Wed, 8 Feb 2017 11:01:15 -0800 (PST) Received: by mail-wr0-x230.google.com with SMTP id 89so66195445wrr.2 for ; Wed, 08 Feb 2017 11:01:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ecwogFJ19KNXtOIy3bbv5LiOmhPotfoGvRedOv47hA0=; b=rnogPB6QRdNqBM7bjJdn/LNh6WWIBWx95hEMfLyGr1dUtxauxvlgi+OyAprJ2qjXM6 CkkFAeltOylkhIfnHAPriqhlIMOD1QQZCVgRInhBGbawUH4oESk/svTIDD13Dy8lPPnS qbTJlstqrjGLoqT24POlnbxMUUM89oHfEmMwfWHO4DeZUaxyqv2bi0zaTNXXDo4mzIw0 rHmYzU/tgHubRjNe2lcioKOG7c5ky9KXbOQNbjGEMez3yhHw4oo2TtacgGewEGJHL+tq xWThB7XYH8jnPX0WcCSP1sOVUA6fEgm3qye089k6HFW8qU1WTSg3pBatPWtv3MspPD5m uj4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ecwogFJ19KNXtOIy3bbv5LiOmhPotfoGvRedOv47hA0=; b=HmpVNPbcNEdQRNwzbrv9f7ojrEXfGfm70b6nyR5ghJ6Eq9fMVHMn98L2cKwO98vHKa Pn8M4PuxLliQWsHrGhhjJTksYrjltd2BZOyIu2/eSDzdF6iRKBn5H/lOg8bDrxhJCNJS uXbuw3B2JFoEhPTteDco1ZFeqvnC9g5ZDhBZCBizq54QwXy2ndw7DL26BwdjdEFp0B23 I5kJOFowqqRMScUSDyudqya7TDX7UZzfH2jsptwA5epHPCwyAbG6X7gw0jFJG6EZr/lo rJGcXbAjjPwD1uECiqIMKYiv5bmylECNqf5whdMtV3WeP45c5DapiGdXSsJDf3T8ogQ0 r/Zw== X-Gm-Message-State: AIkVDXI0NxmUf5bY3wcGtpcmrAXstV3W6tRX11ZK/tOLWZdyyAdmGgeRNeCqE65O2/Gm0Q== X-Received: by 10.223.136.197 with SMTP id g5mr20106246wrg.56.1486580473526; Wed, 08 Feb 2017 11:01:13 -0800 (PST) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id e16sm14491658wra.36.2017.02.08.11.01.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Feb 2017 11:01:12 -0800 (PST) From: Yoav Nir Message-Id: <4ABF6702-BFC7-4530-95FD-C61C06F2E6AB@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_8CB0707C-D6D1-43D4-B391-4258F8BACBA1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 8 Feb 2017 21:01:10 +0200 In-Reply-To: To: podkorytov References: X-Mailer: Apple Mail (2.3259) Archived-At: Cc: jmap@ietf.org Subject: Re: [Jmap] JMAP security X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 19:01:59 -0000 --Apple-Mail=_8CB0707C-D6D1-43D4-B391-4258F8BACBA1 Content-Type: multipart/alternative; boundary="Apple-Mail=_107C2BEB-1FD6-418B-9AD6-92AB1B372D03" --Apple-Mail=_107C2BEB-1FD6-418B-9AD6-92AB1B372D03 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 8 Feb 2017, at 19:28, podkorytov wrote: > Hello, what about JMAP client security ? > If it will works inside web browser it can inherit it vulneriabilities = and join own, >=20 JMAP is (will be?) a protocol. It can be implemented in Javascript in a = browser; it can be implemented as part of a desktop or mobile MUA; it = can be implemented as a library for use by servers that send email. > Any browser plugins such as Adobe's or something else may be potencial = hole and targets for attacks. >=20 Since we do expect browser use, that is definitely something to = consider. Preventing plug-ins and scripts running in other tabs from = sending requests on behalf of the user should certainly be a goal for = the protocol. There are some ways of doing that: authenticating each = HTTP request with something better than session cookies, making the = resource names unpredictable, etc. That is definitely part of the = design. > Probably it question out of frames of protocol draft , but it = practical thing ang may to influence on JMAP success or fail. It will = works inside browser with many others web applications and plug-ins >=20 Security considerations are part of every IETF document and discussion = of security vulnerabilities within the operating environment are very = much in scope. Yoav --Apple-Mail=_107C2BEB-1FD6-418B-9AD6-92AB1B372D03 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On 8 Feb 2017, at 19:28, podkorytov <podkorytov@mail.ru> wrote:

Hello, what about JMAP client security ?
If it will works inside web browser it can inherit it vulneriabilities and join own,

JMAP is (will be?) a protocol. It can be implemented in Javascript in a browser; it can be implemented as part of a desktop or mobile MUA; it can be implemented as a library for use by servers that send email.

Any browser plugins such as Adobe's or something else may be potencial hole and targets for attacks.

Since we do expect browser use, that is definitely something to consider.  Preventing plug-ins and scripts running in other tabs from sending requests on behalf of the user should certainly be a goal for the protocol.  There are some ways of doing that: authenticating each HTTP request with something better than session cookies, making the resource names unpredictable, etc. That is definitely part of the design.

Probably it question out of frames of protocol draft , but it practical thing ang may to influence on JMAP success or fail. It will works inside browser with many others web applications and plug-ins

Security considerations are part of every IETF document and discussion of security vulnerabilities within the operating environment are very much in scope.

Yoav

--Apple-Mail=_107C2BEB-1FD6-418B-9AD6-92AB1B372D03-- --Apple-Mail=_8CB0707C-D6D1-43D4-B391-4258F8BACBA1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJYm2r2AAoJELhJCxUKWMyZw8oIAK+/k36JpEom1lG/t/An6isu V2nqOf0OQpY9+glB2zgcwSEO0rgtDK0SL41I0GCYMvpKxy5+9BpqPYOrXrVHtRNy M5L46XOpLjobyw2xMHufaE5vppMuDHbfdZWGmOxt1SdR0slCP0Aoi/QGNs1cgnV3 NR68CXn9+5ZkMJ7BU+TBj9wpVvr+7YjjdYK6fIrGxBFgOuSUGJmZedXfJj9aq2Gy dxhbD1Pe/qizacMnd7hhnrhk78f9C5xPcn0lSGzxcpYw5gys7LrLz63mGXF0dgBN EYEJt5L8OTmnwZ5M4OkQI2J70TxwfAwY0zAIziy6yljLFasF3Tnp/M2tKgNbe7o= =NdqW -----END PGP SIGNATURE----- --Apple-Mail=_8CB0707C-D6D1-43D4-B391-4258F8BACBA1-- From nobody Thu Feb 9 08:33:55 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 1B847129BBD for ; Thu, 9 Feb 2017 08:33:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=mail.ru 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 NNjDa8Yd2zmL for ; Thu, 9 Feb 2017 08:33:51 -0800 (PST) Received: from f105.i.mail.ru (f105.i.mail.ru [94.100.178.74]) (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 47C5F129BB1 for ; Thu, 9 Feb 2017 08:33:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail2; h=References:In-Reply-To:Content-Type:Message-ID:Reply-To:Date:MIME-Version:Subject:Cc:To:From; bh=s9a99Mc1TN10vPHB8T1cBqRCKYAM30kO3JJEhKqo1+E=; b=puNDZPoLC5+8MC5vwXbQHIkVDbIMXPdbALRhbD+Qtow2YhO7hDETIKREb6/dWlucddLuDlpj2/PzPEXFP91JquhQ37apohsKNGLtOmEwUYj6GjxguI6/3oKU28MCsO4G8jwdUzt5xgp9QxcRvIqeix4m8gI7jfUdJyq1l8VA/3o=; Received: from [85.233.150.58] (ident=mail) by f105.i.mail.ru with local (envelope-from ) id 1cbrfI-0006a8-2g; Thu, 09 Feb 2017 19:33:48 +0300 Received: from [85.233.150.58] by e.mail.ru with HTTP; Thu, 09 Feb 2017 19:33:48 +0300 From: =?UTF-8?B?0JTQvNC40YLRgNC40Lkg0J/QvtC00LrQvtGA0YvRgtC+0LI=?= To: =?UTF-8?B?WW9hdiBOaXI=?= MIME-Version: 1.0 X-Mailer: Mail.Ru Mailer 1.0 Date: Thu, 09 Feb 2017 19:33:48 +0300 X-Priority: 3 (Normal) Message-ID: <1486658028.81835495@f105.i.mail.ru> Content-Type: multipart/alternative; boundary="--ALT--bF7beVup5mC6TtbgiRrOsj8oOIVLvtnn1486658028" Authentication-Results: f105.i.mail.ru; auth=pass smtp.auth=podkorytov@mail.ru smtp.mailfrom=podkorytov@mail.ru X-E1FCDC63: 91BC95D06DB20CF7134CEEF3156B42B74C6784DEA8096F07 X-E1FCDC64: 14EA137241501AD66E2D44ACC8086B5E8F0BFC4104A0E32C798653E96080BF19 X-Mailru-Sender: D41D38B29617681108C6F16C124CCB60C6496B83B5065A6C00CB9CEA573BBBF532ECDF61101237DF660823B2EEFD31DC X-Mras: OK X-Spam: undefined In-Reply-To: <4ABF6702-BFC7-4530-95FD-C61C06F2E6AB@gmail.com> References: <4ABF6702-BFC7-4530-95FD-C61C06F2E6AB@gmail.com> Archived-At: Cc: jmap@ietf.org Subject: Re: [Jmap] =?utf-8?q?JMAP_security?= X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: =?UTF-8?B?0JTQvNC40YLRgNC40Lkg0J/QvtC00LrQvtGA0YvRgtC+0LI=?= List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 16:33:54 -0000 ----ALT--bF7beVup5mC6TtbgiRrOsj8oOIVLvtnn1486658028 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGVsbG8sIFlvYXYuCgo+0KfQtdGC0LLQtdGA0LMsICA5INGE0LXQstGA0LDQu9GPIDIwMTcsIDA6 MDEgKzA1OjAwINC+0YIgWW9hdiBOaXIgPHluaXIuaWV0ZkBnbWFpbC5jb20+Ogo+Cj4KPk9uIDgg RmViIDIwMTcsIGF0IDE5OjI4LCBwb2Rrb3J5dG92IDwgcG9ka29yeXRvdkBtYWlsLnJ1ID4gd3Jv dGU6Cj4+SGVsbG8sIHdoYXQgYWJvdXQgSk1BUCBjbGllbnQgc2VjdXJpdHkgPyAKPj5JZiBpdCB3 aWxsIHdvcmtzIGluc2lkZSB3ZWIgYnJvd3NlciBpdCBjYW4gaW5oZXJpdCBpdCB2dWxuZXJpYWJp bGl0aWVzIGFuZCBqb2luIG93biwgCj5KTUFQIGlzICh3aWxsIGJlPykgYSBwcm90b2NvbC4gSXQg Y2FuIGJlIGltcGxlbWVudGVkIGluIEphdmFzY3JpcHQgaW4gYSBicm93c2VyOyBpdCBjYW4gYmUg aW1wbGVtZW50ZWQgYXMgcGFydCBvZiBhIGRlc2t0b3Agb3IgbW9iaWxlIE1VQTsgaXQgY2FuIGJl IGltcGxlbWVudGVkIGFzIGEgbGlicmFyeSBmb3IgdXNlIGJ5IHNlcnZlcnMgdGhhdCBzZW5kIGVt YWlsLgpSaWdodCwgY2xpZW50IGZvciBKTUFQIGNhbiBiZSBkZXNpZ25lZCBpbsKgIGRpZmZlcmVu dCBzdHlsZXMsIGJ1dCBmb3Igd29ya2luZyBvdmVyIEhUVFAgCix0byBiZSBmcmFuayzCoCBpcyBt b3JlIGVhc3kgdG8gZ2V0IHNvbWV0aGluZyBsaWtlIGJyb3dzZXIgb3Igd2VsbCBrbm93biBIVFRQ IGxpYnMgYW5kIHJlbW92ZSB1c2VsZXNzIGNvZGUgZnJvbSBpdC4KwqAgTyB0aGVyd2lzZSAsIHdy aXRpbmcgY29tbXVuaWNhdGluZyBieSBIVFRQL0hUVFBTIGZyb20gZ3JvdW5kIGxldmVsIG1heSBi ZSBtb3JlIGRpZmZpY3VsdCAsIHRoYW4gd3JpdGluZyBmcm9tIHplcm8gbGV2ZWwgSU1BUCBvciBQ T1AzIGNsaWVudC4KCj4+QW55IGJyb3dzZXIgcGx1Z2lucyBzdWNoIGFzIEFkb2JlJ3Mgb3Igc29t ZXRoaW5nIGVsc2UgbWF5IGJlIHBvdGVuY2lhbCBob2xlIGFuZCB0YXJnZXRzIGZvciBhdHRhY2tz LiAKPlNpbmNlIHdlIGRvIGV4cGVjdCBicm93c2VyIHVzZSwgdGhhdCBpcyBkZWZpbml0ZWx5IHNv bWV0aGluZyB0byBjb25zaWRlci4gwqBQcmV2ZW50aW5nIHBsdWctaW5zIGFuZCBzY3JpcHRzIHJ1 bm5pbmcgaW4gb3RoZXIgdGFicyBmcm9tIHNlbmRpbmcgcmVxdWVzdHMgb24gYmVoYWxmIG9mIHRo ZSB1c2VyIHNob3VsZCBjZXJ0YWlubHkgYmUgYSBnb2FsIGZvciB0aGUgcHJvdG9jb2wuIMKgVGhl cmUgYXJlIHNvbWUgd2F5cyBvZiBkb2luZyB0aGF0OiBhdXRoZW50aWNhdGluZyBlYWNoIEhUVFAg cmVxdWVzdCB3aXRoIHNvbWV0aGluZyBiZXR0ZXIgdGhhbiBzZXNzaW9uIGNvb2tpZXMsIG1ha2lu ZyB0aGUgcmVzb3VyY2UgbmFtZXMgdW5wcmVkaWN0YWJsZSwgZXRjLiBUaGF0IGlzIGRlZmluaXRl bHkgcGFydCBvZiB0aGUgZGVzaWduLgo+PlByb2JhYmx5IGl0IHF1ZXN0aW9uIG91dCBvZiBmcmFt ZXMgb2YgcHJvdG9jb2wgZHJhZnQgLCBidXQgaXQgcHJhY3RpY2FsIHRoaW5nIGFuZyBtYXkgdG8g aW5mbHVlbmNlIG9uIEpNQVAgc3VjY2VzcyBvciBmYWlsLiBJdCB3aWxsIHdvcmtzIGluc2lkZSBi cm93c2VyIHdpdGggbWFueSBvdGhlcnMgd2ViIGFwcGxpY2F0aW9ucyBhbmQgcGx1Zy1pbnMKPlNl Y3VyaXR5IGNvbnNpZGVyYXRpb25zIGFyZSBwYXJ0IG9mIGV2ZXJ5IElFVEYgZG9jdW1lbnQgYW5k IGRpc2N1c3Npb24gb2Ygc2VjdXJpdHkgdnVsbmVyYWJpbGl0aWVzIHdpdGhpbiB0aGUgb3BlcmF0 aW5nIGVudmlyb25tZW50IGFyZSB2ZXJ5IG11Y2ggaW4gc2NvcGUuClN0YXRlbGVzcyBwcm90b2Nv bHMgc29tZXRpbWVzIG1heSBiZSBvbiBNSVRNIGF0dGFjaywgc29tZWJvZHkgaXMgYWJsZSB0byBj YXRjaCBUQ1AgcGFja2V0IGZyb20gSk1BUCBjbGllbnQgYW5kIHJlcGVhdCBpdCBtYW55IHRpbWVz LiAKQWxsIG5lZWRlZCBmb3IgYXV0aG9yaXphdGlvbiBhbHJlYWR5IGluc2lkZSB0aGlzIHNpbmds ZSBwYWNrZXQsIHJpZ2h0ID8KRGVzdGluYXRpb24gaW4gdGhpcyBjYXNlIHdpbGwgYmUgdW5kZXIg RG9TIGF0dGFjay4gV2hhdCBpcyBwbGFubmluZyBpbiBKTUFQIGZvciBwcmV2ZW50aW5nIHN1Y2gg dGhpbmdzID8KTWF5YmUgcmFuZG9tIGZpZWxkIGluIEpTT04gc3RydWN0dXJlIG9yIHRpbWUgc3Rh bXAgd2l0aCBoaWdoIHByZWNpc2lvbj8KCj4KPllvYXYKPgo+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KPkptYXAgbWFpbGluZyBsaXN0Cj5KbWFwQGlldGYu b3JnCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ptYXAKCgpEbWl0cmlp IFBvZGtvcnl0b3YK ----ALT--bF7beVup5mC6TtbgiRrOsj8oOIVLvtnn1486658028 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 CjxIVE1MPjxCT0RZPkhlbGxvLCBZb2F2Ljxicj48YnI+PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl ci1sZWZ0OjFweCBzb2xpZCAjMDg1N0E2OyBtYXJnaW46MTBweDsgcGFkZGluZzowIDAgMCAxMHB4 OyI+CgnQp9C10YLQstC10YDQsywgIDkg0YTQtdCy0YDQsNC70Y8gMjAxNywgMDowMSArMDU6MDAg 0L7RgiBZb2F2IE5pciAmbHQ7eW5pci5pZXRmQGdtYWlsLmNvbSZndDs6PGJyPjxicj48ZGl2IGlk PSIiPjxkaXYgY2xhc3M9ImpzLWhlbHBlciBqcy1yZWFkbXNnLW1zZyI+PGRpdj48ZGl2IGlkPSJz dHlsZV8xNDg2NTgwNTI3MDAwMDAwMDg5MF9CT0RZIj48YnI+PGRpdj48ZGl2Pk9uIDggRmViIDIw MTcsIGF0IDE5OjI4LCBwb2Rrb3J5dG92ICZsdDs8YSBocmVmPSJtYWlsdG86cG9ka29yeXRvdkBt YWlsLnJ1Ij5wb2Rrb3J5dG92QG1haWwucnU8L2E+Jmd0OyB3cm90ZTo8L2Rpdj48YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj48ZGl2PjxwIGRpcj0ibHRyIj5IZWxsbywgd2hhdCBhYm91dCBKTUFQIGNs aWVudCBzZWN1cml0eSA/IDxicj4KSWYgaXQgd2lsbCB3b3JrcyBpbnNpZGUgd2ViIGJyb3dzZXIg aXQgY2FuIGluaGVyaXQgaXQgdnVsbmVyaWFiaWxpdGllcyBhbmQgam9pbiBvd24sIDxicj48L3A+ PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+Sk1BUCBpcyAod2lsbCBiZT8pIGEgcHJvdG9jb2wuIEl0 IGNhbiBiZSBpbXBsZW1lbnRlZCBpbiBKYXZhc2NyaXB0IGluIGEgYnJvd3NlcjsgaXQgY2FuIGJl IGltcGxlbWVudGVkIGFzIHBhcnQgb2YgYSBkZXNrdG9wIG9yIG1vYmlsZSBNVUE7IGl0IGNhbiBi ZSBpbXBsZW1lbnRlZCBhcyBhIGxpYnJhcnkgZm9yIHVzZSBieSBzZXJ2ZXJzIHRoYXQgc2VuZCBl bWFpbC48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGJy PlJpZ2h0LCBjbGllbnQgZm9yIEpNQVAgY2FuIGJlIGRlc2lnbmVkIGluJm5ic3A7IGRpZmZlcmVu dCBzdHlsZXMsIGJ1dCBmb3Igd29ya2luZyBvdmVyIEhUVFAgPGJyPix0byBiZSBmcmFuaywmbmJz cDsgaXMgbW9yZSBlYXN5IHRvIGdldCBzb21ldGhpbmcgbGlrZSBicm93c2VyIG9yIHdlbGwga25v d24gSFRUUCBsaWJzIGFuZCByZW1vdmUgdXNlbGVzcyBjb2RlIGZyb20gaXQuPGJyPiZuYnNwOyBP PHNwYW4gY2xhc3M9InJlZl9yZXN1bHQiPnRoZXJ3aXNlPC9zcGFuPiwgd3JpdGluZyBjb21tdW5p Y2F0aW5nIGJ5IEhUVFAvSFRUUFMgZnJvbSBncm91bmQgbGV2ZWwgbWF5IGJlIG1vcmUgZGlmZmlj dWx0ICwgdGhhbiB3cml0aW5nIGZyb20gemVybyBsZXZlbCBJTUFQIG9yIFBPUDMgY2xpZW50Ljxi cj48YnI+PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlci1sZWZ0OjFweCBzb2xpZCAjMDg1N0E2OyBt YXJnaW46MTBweDsgcGFkZGluZzowIDAgMCAxMHB4OyI+PGRpdiBpZD0iIj48ZGl2IGNsYXNzPSJq cy1oZWxwZXIganMtcmVhZG1zZy1tc2ciPjxkaXY+PGRpdiBpZD0ic3R5bGVfMTQ4NjU4MDUyNzAw MDAwMDA4OTBfQk9EWSI+PGRpdj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2PjxwIGRpcj0i bHRyIj4KQW55IGJyb3dzZXIgcGx1Z2lucyBzdWNoIGFzIEFkb2JlJ3Mgb3Igc29tZXRoaW5nIGVs c2UgbWF5IGJlIHBvdGVuY2lhbCBob2xlIGFuZCB0YXJnZXRzIGZvciBhdHRhY2tzLiA8YnI+PC9w PjwvZGl2PjwvYmxvY2txdW90ZT5TaW5jZSB3ZSBkbyBleHBlY3QgYnJvd3NlciB1c2UsIHRoYXQg aXMgZGVmaW5pdGVseSBzb21ldGhpbmcgdG8gY29uc2lkZXIuICZuYnNwO1ByZXZlbnRpbmcgcGx1 Zy1pbnMgYW5kIHNjcmlwdHMgcnVubmluZyBpbiBvdGhlciB0YWJzIGZyb20gc2VuZGluZyByZXF1 ZXN0cyBvbiBiZWhhbGYgb2YgdGhlIHVzZXIgc2hvdWxkIGNlcnRhaW5seSBiZSBhIGdvYWwgZm9y IHRoZSBwcm90b2NvbC4gJm5ic3A7VGhlcmUgYXJlIHNvbWUgd2F5cyBvZiBkb2luZyB0aGF0OiBh dXRoZW50aWNhdGluZyBlYWNoIEhUVFAgcmVxdWVzdCB3aXRoIHNvbWV0aGluZyBiZXR0ZXIgdGhh biBzZXNzaW9uIGNvb2tpZXMsIG1ha2luZyB0aGUgcmVzb3VyY2UgbmFtZXMgdW5wcmVkaWN0YWJs ZSwgZXRjLiBUaGF0IGlzIGRlZmluaXRlbHkgcGFydCBvZiB0aGUgZGVzaWduLjxicj48YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj48ZGl2PjxwIGRpcj0ibHRyIj4KUHJvYmFibHkgaXQgcXVlc3Rpb24g b3V0IG9mIGZyYW1lcyBvZiBwcm90b2NvbCBkcmFmdCAsIGJ1dCBpdCBwcmFjdGljYWwgdGhpbmcg YW5nIG1heSB0byBpbmZsdWVuY2Ugb24gSk1BUCBzdWNjZXNzIG9yIGZhaWwuIEl0IHdpbGwgd29y a3MgaW5zaWRlIGJyb3dzZXIgd2l0aCBtYW55IG90aGVycyB3ZWIgYXBwbGljYXRpb25zIGFuZCBw bHVnLWluczxicj48L3A+PC9kaXY+PC9ibG9ja3F1b3RlPlNlY3VyaXR5IGNvbnNpZGVyYXRpb25z IGFyZSBwYXJ0IG9mIGV2ZXJ5IElFVEYgZG9jdW1lbnQgYW5kIGRpc2N1c3Npb24gb2Ygc2VjdXJp dHkgdnVsbmVyYWJpbGl0aWVzIHdpdGhpbiB0aGUgb3BlcmF0aW5nIGVudmlyb25tZW50IGFyZSB2 ZXJ5IG11Y2ggaW4gc2NvcGUuPC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9ibG9ja3F1 b3RlPjxicj5TdGF0ZWxlc3MgcHJvdG9jb2xzIHNvbWV0aW1lcyBtYXkgYmUgb24gTUlUTSBhdHRh Y2ssIHNvbWVib2R5IGlzIGFibGUgdG8gY2F0Y2ggVENQIHBhY2tldCBmcm9tIEpNQVAgY2xpZW50 IGFuZCByZXBlYXQgaXQgbWFueSB0aW1lcy4gPGJyPkFsbCBuZWVkZWQgZm9yIGF1dGhvcml6YXRp b24gYWxyZWFkeSBpbnNpZGUgdGhpcyBzaW5nbGUgcGFja2V0LCByaWdodCA/PGJyPkRlc3RpbmF0 aW9uIGluIHRoaXMgY2FzZSB3aWxsIGJlIHVuZGVyIERvUyBhdHRhY2suIFdoYXQgaXMgcGxhbm5p bmcgaW4gSk1BUCBmb3IgcHJldmVudGluZyBzdWNoIHRoaW5ncyA/PGJyPk1heWJlIHJhbmRvbSBm aWVsZCBpbiBKU09OIHN0cnVjdHVyZSBvciB0aW1lIHN0YW1wIHdpdGggaGlnaCBwcmVjaXNpb24/ PGJyPjxicj48YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyLWxlZnQ6MXB4IHNvbGlkICMwODU3QTY7 IG1hcmdpbjoxMHB4OyBwYWRkaW5nOjAgMCAwIDEwcHg7Ij48ZGl2IGlkPSIiPjxkaXYgY2xhc3M9 ImpzLWhlbHBlciBqcy1yZWFkbXNnLW1zZyI+PGRpdj48ZGl2IGlkPSJzdHlsZV8xNDg2NTgwNTI3 MDAwMDAwMDg5MF9CT0RZIj48ZGl2Pjxicj48L2Rpdj48ZGl2PllvYXY8L2Rpdj48ZGl2Pjxicj48 L2Rpdj48L2Rpdj48ZGl2Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPgpKbWFwIG1haWxpbmcgbGlzdDxicj48YSBocmVmPSJtYWlsdG86Sm1hcEBpZXRm Lm9yZyI+Sm1hcEBpZXRmLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9qbWFwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9qbWFwPC9hPjxicj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48 L2Jsb2NrcXVvdGU+Cjxicj4KPGJyPkRtaXRyaWkgUG9ka29yeXRvdjxicj48L0JPRFk+PC9IVE1M Pgo= ----ALT--bF7beVup5mC6TtbgiRrOsj8oOIVLvtnn1486658028-- From nobody Thu Feb 9 08:45:22 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 D3885129B77 for ; Thu, 9 Feb 2017 08:45:20 -0800 (PST) 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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 bovZ2MkRFnr5 for ; Thu, 9 Feb 2017 08:45:20 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id D438C129421 for ; Thu, 9 Feb 2017 08:45:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1486658719; d=isode.com; s=june2016; i=@isode.com; bh=fGTmqu8bRXrWm/PEKGJJY1WxlEtz50xVniyf45xymp4=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Qtb2vHSeOAuELzJ6AMw/2wi5B2R2qN7ugSG0IQy/2lfNADAySFOYPEorLp8Rs+BkQIdzq9 idIEjaegzofhIKOpO8HiIdEVcSbeEP+6rwwAZFTA1j9J3SkrJdmLApkM3uA+rsZl+rpE4/ j/zhrAiJ6n2+lwKOQuJDXjkJfk+WPCM=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 9 Feb 2017 16:45:18 +0000 To: =?UTF-8?B?0JTQvNC40YLRgNC40Lkg0J/QvtC00LrQvtGA0YvRgtC+0LI=?= , Yoav Nir References: <4ABF6702-BFC7-4530-95FD-C61C06F2E6AB@gmail.com> <1486658028.81835495@f105.i.mail.ru> From: Alexey Melnikov Message-ID: Date: Thu, 9 Feb 2017 16:44:57 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 In-Reply-To: <1486658028.81835495@f105.i.mail.ru> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------095397E0D3243FB21725746C" Archived-At: Cc: jmap@ietf.org Subject: Re: [Jmap] JMAP security X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 16:45:21 -0000 --------------095397E0D3243FB21725746C Content-Type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: quoted-printable Hi =D0=94=D0=BC=D0=B8=D1=82=D1=80=D0=B8=D0=B9, On 09/02/2017 16:33, =D0=94=D0=BC=D0=B8=D1=82=D1=80=D0=B8=D0=B9 =D0=9F=D0=BE= =D0=B4=D0=BA=D0=BE=D1=80=D1=8B=D1=82=D0=BE=D0=B2 wrote: > Hello, Yoav. > > =D0=A7=D0=B5=D1=82=D0=B2=D0=B5=D1=80=D0=B3, 9 =D1=84=D0=B5=D0=B2=D1=80= =D0=B0=D0=BB=D1=8F 2017, 0:01 +05:00 =D0=BE=D1=82 Yoav Nir > : > > > On 8 Feb 2017, at 19:28, podkorytov > wrote: > >> Any browser plugins such as Adobe's or something else may be >> potencial hole and targets for attacks. >> > Since we do expect browser use, that is definitely something to > consider. Preventing plug-ins and scripts running in other tabs > from sending requests on behalf of the user should certainly be a > goal for the protocol. There are some ways of doing that: > authenticating each HTTP request with something better than > session cookies, making the resource names unpredictable, etc. > That is definitely part of the design. >> >> Probably it question out of frames of protocol draft , but it >> practical thing ang may to influence on JMAP success or fail. It >> will works inside browser with many others web applications and >> plug-ins >> > Security considerations are part of every IETF document and > discussion of security vulnerabilities within the operating > environment are very much in scope. > > > Stateless protocols sometimes may be on MITM attack, somebody is able=20 > to catch TCP packet from JMAP client and repeat it many times. > All needed for authorization already inside this single packet, right ? > Destination in this case will be under DoS attack. What is planning in=20 > JMAP for preventing such things ? > Maybe random field in JSON structure or time stamp with high precision? JMAP should be running over HTTPS, which should make it much more difficult. Best Regards, Alexey --------------095397E0D3243FB21725746C Content-Type: text/html; charset=UTF-8 Content-transfer-encoding: quoted-printable

Hi =D0=94=D0=BC=D0=B8=D1=82=D1=80=D0=B8=D0=B9,


On 09/02/2017 16:33, =D0=94=D0=BC=D0=B8= =D1=82=D1=80=D0=B8=D0=B9 =D0=9F=D0=BE=D0=B4=D0=BA=D0=BE=D1=80=D1=8B=D1=82=D0= =BE=D0=B2 wrote:
Hello, Yoav.

=D0=A7=D0=B5=D1=82=D0=B2=D0=B5=D1=80=D0=B3, 9 = =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2017, 0:01 +05:00 =D0=BE=D1=82 Yoav Nir <ynir.ietf@gmail.com>:


On 8 Feb 2017, at 19:28, podkorytov <podkorytov@mail.ru<= /a>> wrote:


Any browser plugins such as Adobe's or something else may be potencial hole and targets for attacks.

Since we do expect browser use, that is definitely something to consider. =C2=A0Preventing plug-ins and scripts running in other tabs from sending requests on behalf of the user should certainly be a goal for the protocol. =C2=A0There are some ways of doing that: authenticating each HTTP request with something better than session cookies, making the resource names unpredictable, etc. That is definitely part of the design.

Probably it question out of frames of protocol draft , but it practical thing ang may to influence on JMAP success or fail. It will works inside browser with many others web applications and plug-ins

Security considerations are part of every IETF document and discussion of security vulnerabilities within the operating environment are very much in scope.

Stateless protocols sometimes may be on MITM attack, somebody is able to catch TCP packet from JMAP client and repeat it many times.
All needed for authorization already inside this single packet, right ?
Destination in this case will be under DoS attack. What is planning in JMAP for preventing such things ?
Maybe random field in JSON structure or time stamp with high precision?
JMAP should be running over HTTPS, which should make it much more difficult.

Best Regards,
Alexey

--------------095397E0D3243FB21725746C-- From nobody Thu Feb 9 09:05:37 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 382D8129C06; Thu, 9 Feb 2017 09:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 nEZUpSvEb0fc; Thu, 9 Feb 2017 09:05:35 -0800 (PST) Received: from mail-yw0-x243.google.com (mail-yw0-x243.google.com [IPv6:2607:f8b0:4002:c05::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAADA129C1A; Thu, 9 Feb 2017 09:05:21 -0800 (PST) Received: by mail-yw0-x243.google.com with SMTP id l16so735222ywb.2; Thu, 09 Feb 2017 09:05:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=NRN2xol7PfmEIbEWh3SAjpAM0aRz5WBDEBe4N/Y6mHQ=; b=smQBCeEfaT5v+fi+9uugZGBBTU/nVKhEOXZ415CXUNB+cao48/AmQ0GLmWhzjsn/tD KGFJJMJYQhylEfUy6fjXY622dIQitqom55FjR/k+cPgXJRBA8xtvyffS4s+PTfQ6mdFE viYMilcZLlN1Q0qz1/m8tenKRWBUpvBML07vApz4ZwIGt3qVhqWJn8ePGZBZJDam8FuY V9UoF+O4iLC+Aov27IIRiVOTiTGuHW5KAAH6Vt1zglFxxmR2AIlRTXwRtZugm8t2kI2y SLCzcKsQs4MWDKuLweHYRj2C6gIiDCHZq9e+Ev5RykGGyumCLc8DMf9HPW1FDK+f00Nl BFfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=NRN2xol7PfmEIbEWh3SAjpAM0aRz5WBDEBe4N/Y6mHQ=; b=oasFJgO9ctGdLRkAIAX8D/Csb6cpg83A0rHDeNY6/jirxkIRAssG4alzgMBO2pk6x2 +QEeNsVVIywz5ywxi2VzMxFH7L3ts8nN9rLlWeL4bpxkFDTM1T2zA+UlIBlsLPsM/Pql fnwxib+gQep7eYzn5CfmCn8Pv8BABdFf2yD5V7sshzDilT6qZMJvWikh1d/UsS2Jfyvg prgYuz2MyfS34wfBUG0ZJtjUD/KnPVt+yxu0ybAKX1VDWJCXSWosXvQ/8A5xSYfpsH5T uOT/pUZF/0+WFPzI+sEubkiYiy2IWKS8mKjGx2dGhXpS3ee4wsB+ecXdy4OBqfVa7MvM A1eA== X-Gm-Message-State: AMke39lCPqUpi70ob558XxWMx8f9qesU6GEqxi2iVU6vx8TDaxYEMtk9h4FmI/jPRAZIUCUaM1BEiUCmmMgBbg== X-Received: by 10.13.213.22 with SMTP id x22mr2966889ywd.165.1486659920857; Thu, 09 Feb 2017 09:05:20 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.83.17.213 with HTTP; Thu, 9 Feb 2017 09:05:20 -0800 (PST) In-Reply-To: <03152892-3987-145c-8206-e3ccfe3a7510@isode.com> References: <148616796247.4079.7104562493351135409.idtracker@ietfa.amsl.com> <11e900d0-553e-0635-06f4-8510bd80ecfd@dcrocker.net> <4ff42a3b-1f8e-3e25-14e7-b1d3ed2f69c2@isode.com> <368f2b68-8f10-9517-1edb-d213ff10563b@dcrocker.net> <03152892-3987-145c-8206-e3ccfe3a7510@isode.com> From: Phillip Hallam-Baker Date: Thu, 9 Feb 2017 12:05:20 -0500 X-Google-Sender-Auth: 5VU0znrrUn4yHuHewMbuKjBW_b8 Message-ID: To: Alexey Melnikov Content-Type: multipart/alternative; boundary=001a114fbfca7c10a505481bfc99 Archived-At: Cc: iesg , jmap@ietf.org, Dave CROCKER , IETF Discussion Mailing List Subject: Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 17:05:36 -0000 --001a114fbfca7c10a505481bfc99 Content-Type: text/plain; charset=UTF-8 One big improvement on the status quo would be to combine the functionality of IMAP and SUBMIT. Having two different protocols doesn't work folk. Particularly since authentication remains a bad joke in SMTP and IMAP. I just sent three copies of the same message to my CEO because my mail app thought it hadn't been sent at all and kept retrying. --001a114fbfca7c10a505481bfc99 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One= big improvement on the status quo would be to combine the functionality of= IMAP and SUBMIT.=C2=A0

H= aving two different protocols doesn't work folk. Particularly since aut= hentication remains a bad joke in SMTP and IMAP. I just sent three copies o= f the same message to my CEO because my mail app thought it hadn't been= sent at all and kept retrying.
--001a114fbfca7c10a505481bfc99-- From nobody Thu Feb 9 09:07:50 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 447DE129C01 for ; Thu, 9 Feb 2017 09:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 I-Nn1Ai8Tq2d for ; Thu, 9 Feb 2017 09:07:47 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7C06129C00 for ; Thu, 9 Feb 2017 09:07:46 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id v186so87595783wmd.0 for ; Thu, 09 Feb 2017 09:07:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=VvSRPIxxFzQ1bCyFMAHbaoYT+MxJ7/YN7WWpfnIKMk8=; b=BOOQUvr9QrFvbGsVPgGWTH9NsSu5DWbm1s50lTUDXsN6CLyNMt921fATKbioGusBpJ MLvIMCqLWwYILlIit0RMeLIWLGbRE0Q4RaIsqxMtd24XcHMuCy2TWkE3ds+8By34f2Ws X3Pglv84/UgkVCNPPpTor1q63WpGY8hL2Uvh7Lew7xN5kMgSK2EmVahqVtJ8ZHIghxKu BSm/tBpSn2a8TtextgXjW9jJcaDWJO+jO6wJYprk+LOWIJcyFNPqz9VEnwdB2UuF+d7C SjZIgu0Eceb3RdCi4PVw3IklxKacuat/MfUQTMp85IY/JYmVlGFpD3AC9VZRbsJGdW0S w2Hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=VvSRPIxxFzQ1bCyFMAHbaoYT+MxJ7/YN7WWpfnIKMk8=; b=DFwrJD2OfyS5LXIpkVr3BEBzFDshP+6XeDCeHtMlMLjgreYFa6aXYRzMZLPFleVx60 13a0/o8k0UReTNqhX9eohMRJZ0nKJIxv+QC1dmpklZxOwOfNLbBgCLjyfMhvL3MSGqfm ac15L2eqhRqA4Ws0sdImiHC+kF4lCC7XNsQWLOEPLh3IqHqdTn9JgI09WH1LCG5l1I0N FL4czBSn7rOpe3kbE46kR7yrU1Rj7tMgtzN+DX850WWjMiEw//AlvTl76/UxEObJPC6f DD0YlYkJ0Undmd/KjrVLFUwbrS1TJJwbmgGfSEFrxxSts/pgBEFqjCEaatsDpeXrjH+n T+Mg== X-Gm-Message-State: AMke39kAeuKKvfkuxJ8lL3mM2tTYFPBwaUHifbfZeRFRPKsJQH0QsRkFLrh0+Fugm9RU0A== X-Received: by 10.28.0.2 with SMTP id 2mr3982960wma.141.1486660064157; Thu, 09 Feb 2017 09:07:44 -0800 (PST) Received: from users-mbp.mshome.net ([176.13.20.218]) by smtp.gmail.com with ESMTPSA id z90sm19501199wrc.24.2017.02.09.09.07.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Feb 2017 09:07:43 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_FD5FD189-255C-4732-A81A-37F51E8E2BAC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Yoav Nir X-Priority: 3 (Normal) In-Reply-To: <1486658028.81835495@f105.i.mail.ru> Date: Thu, 9 Feb 2017 19:07:40 +0200 Message-Id: References: <4ABF6702-BFC7-4530-95FD-C61C06F2E6AB@gmail.com> <1486658028.81835495@f105.i.mail.ru> To: =?utf-8?B?0JTQvNC40YLRgNC40Lkg0J/QvtC00LrQvtGA0YvRgtC+0LI=?= X-Mailer: Apple Mail (2.3259) Archived-At: Cc: jmap@ietf.org Subject: Re: [Jmap] JMAP security X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 17:07:48 -0000 --Apple-Mail=_FD5FD189-255C-4732-A81A-37F51E8E2BAC Content-Type: multipart/alternative; boundary="Apple-Mail=_E3D6641B-5254-4FCC-8D18-D8553A2891D1" --Apple-Mail=_E3D6641B-5254-4FCC-8D18-D8553A2891D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Dmitry. On 9 Feb 2017, at 18:33, =D0=94=D0=BC=D0=B8=D1=82=D1=80=D0=B8=D0=B9 = =D0=9F=D0=BE=D0=B4=D0=BA=D0=BE=D1=80=D1=8B=D1=82=D0=BE=D0=B2 = wrote: > Hello, Yoav. >=20 > =D0=A7=D0=B5=D1=82=D0=B2=D0=B5=D1=80=D0=B3, 9 =D1=84=D0=B5=D0=B2=D1=80=D0= =B0=D0=BB=D1=8F 2017, 0:01 +05:00 =D0=BE=D1=82 Yoav Nir = : >=20 >=20 > On 8 Feb 2017, at 19:28, podkorytov > wrote: >> Hello, what about JMAP client security ? >> If it will works inside web browser it can inherit it = vulneriabilities and join own, >>=20 > JMAP is (will be?) a protocol. It can be implemented in Javascript in = a browser; it can be implemented as part of a desktop or mobile MUA; it = can be implemented as a library for use by servers that send email. >=20 > Right, client for JMAP can be designed in different styles, but for = working over HTTP > ,to be frank, is more easy to get something like browser or well = known HTTP libs and remove useless code from it. > Otherwise, writing communicating by HTTP/HTTPS from ground level may = be more difficult , than writing from zero level IMAP or POP3 client. Developers are not faced with the choice of either in-browser or writing = on top of libc. I wouldn=E2=80=99t write it from the ground up. If using = python I=E2=80=99d use the urllib, json, and ssl modules and then all = that remains for me is constructing the objects according to the = standard. In C++ I might use libcurl and jsoncpp. Other languages have = their equivalents. The session maintenance and request authentication mechanisms that will = be in JMAP may or may not be mechanisms that are already implemented in = these libraries, but this is true regardless of platform. Developers = will choose a platform based on what they want to develop, not based on = what platform is marginally easier. EWS works fine in desktop MUAs. >> Any browser plugins such as Adobe's or something else may be = potencial hole and targets for attacks. >>=20 > Since we do expect browser use, that is definitely something to = consider. Preventing plug-ins and scripts running in other tabs from = sending requests on behalf of the user should certainly be a goal for = the protocol. There are some ways of doing that: authenticating each = HTTP request with something better than session cookies, making the = resource names unpredictable, etc. That is definitely part of the = design. >> Probably it question out of frames of protocol draft , but it = practical thing ang may to influence on JMAP success or fail. It will = works inside browser with many others web applications and plug-ins >>=20 > Security considerations are part of every IETF document and discussion = of security vulnerabilities within the operating environment are very = much in scope. >=20 > Stateless protocols sometimes may be on MITM attack, somebody is able = to catch TCP packet from JMAP client and repeat it many times. > All needed for authorization already inside this single packet, right = ? Those are addressed by TLS. JMAP has to run over HTTPS, and not just = because of these attacks. It=E2=80=99s email. Privacy is not optional. > Destination in this case will be under DoS attack. What is planning in = JMAP for preventing such things ? > Maybe random field in JSON structure or time stamp with high = precision? A JMAP server is subject to all the DoS attacks that any other HTTPS = server is subject to. In fact, I don=E2=80=99t think SMTP or IMAP are = any different if they=E2=80=99re using TLS. Yoav --Apple-Mail=_E3D6641B-5254-4FCC-8D18-D8553A2891D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, Dmitry.

On 9 Feb 2017, at 18:33, =D0=94=D0=BC=D0=B8=D1=82=D1=80=D0=B8=D0= =B9 =D0=9F=D0=BE=D0=B4=D0=BA=D0=BE=D1=80=D1=8B=D1=82=D0=BE=D0=B2 <podkorytov@mail.ru> = wrote:

Hello, Yoav.

=D0=A7=D0=B5=D1=82=D0=B2=D0=B5=D1=80=D0=B3, 9 =D1=84=D0=B5=D0=B2=D1= =80=D0=B0=D0=BB=D1=8F 2017, 0:01 +05:00 =D0=BE=D1=82 Yoav Nir <ynir.ietf@gmail.com>:


On 8 Feb 2017, at 19:28, = podkorytov <podkorytov@mail.ru> wrote:

Hello, = what about JMAP client security ?
If it will works inside web browser it can inherit it vulneriabilities = and join own,

JMAP = is (will be?) a protocol. It can be implemented in Javascript in a = browser; it can be implemented as part of a desktop or mobile MUA; it = can be implemented as a library for use by servers that send = email.

Right, client for JMAP can be designed in  different = styles, but for working over HTTP
,to be frank,  is = more easy to get something like browser or well known HTTP libs and = remove useless code from it.
  Otherwise, writing communicating by = HTTP/HTTPS from ground level may be more difficult , than writing from = zero level IMAP or POP3 client.

Developers = are not faced with the choice of either in-browser or writing on top of = libc. I wouldn=E2=80=99t write it from the ground up. If using python = I=E2=80=99d use the urllib, json, and ssl modules and then all that = remains for me is constructing the objects according to the standard. In = C++ I might use libcurl and jsoncpp.  Other languages have their = equivalents. 

The session = maintenance and request authentication mechanisms that will be in JMAP = may or may not be mechanisms that are already implemented in these = libraries, but this is true regardless of platform. Developers will = choose a platform based on what they want to develop, not based on what = platform is marginally easier. EWS works fine in desktop MUAs.

Any browser plugins such as Adobe's or something else may be potencial = hole and targets for attacks.

Since = we do expect browser use, that is definitely something to consider. =  Preventing plug-ins and scripts running in other tabs from sending = requests on behalf of the user should certainly be a goal for the = protocol.  There are some ways of doing that: authenticating each = HTTP request with something better than session cookies, making the = resource names unpredictable, etc. That is definitely part of the = design.

Probably it question out of frames of protocol draft , but it practical = thing ang may to influence on JMAP success or fail. It will works inside = browser with many others web applications and plug-ins

Security considerations are part of = every IETF document and discussion of security vulnerabilities within = the operating environment are very much in = scope.

Stateless = protocols sometimes may be on MITM attack, somebody is able to catch TCP = packet from JMAP client and repeat it many times.
All = needed for authorization already inside this single packet, right ?

Those are = addressed by TLS. JMAP has to run over HTTPS, and not just because of = these attacks. It=E2=80=99s email. Privacy is not = optional.

Destination in this case will = be under DoS attack. What is planning in JMAP for preventing such things = ?
Maybe random field in JSON structure or time stamp with = high precision?

A JMAP server is subject to all the DoS attacks that = any other HTTPS server is subject to. In fact, I don=E2=80=99t think = SMTP or IMAP are any different if they=E2=80=99re using = TLS.

Yoav

= --Apple-Mail=_E3D6641B-5254-4FCC-8D18-D8553A2891D1-- --Apple-Mail=_FD5FD189-255C-4732-A81A-37F51E8E2BAC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJYnKHdAAoJELhJCxUKWMyZdIcH/0L5SL2H9CXLOZmbFHHy3w3i ktj0FdSr8HqvdilqFBSdsP62emFOiRtAolu3cElRsh+vPGLlA3j16JXmIUHa4MX0 BeP7SJReUF48dImLPD5MU+8hMN23Te8yZFcblV9npOaxU8SJ3a/RHySMyMazrHeZ 1NmkiIaivKFy8wTHskWtlxR9Akvj6ccqk1oLcAooKDgI0Hfv5ChgDs81uoQpTmqy k/3xg+G89XnCnB8Ba0D/NwZJA3ULMYzLH6bSgXon5CgHKjl9vr1/IDS7upbAbeJ0 /LbDFRfW9s8HChRsX42urOO5azxGpxrvt6HmP2o3vhmjcBX1idDDb7TmaP2T6oE= =Kpyd -----END PGP SIGNATURE----- --Apple-Mail=_FD5FD189-255C-4732-A81A-37F51E8E2BAC-- From nobody Thu Feb 9 09:32:49 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 21573129C25 for ; Thu, 9 Feb 2017 09:32:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.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 GpSqM1faz9Og for ; Thu, 9 Feb 2017 09:32:42 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0C23129C29 for ; Thu, 9 Feb 2017 09:32:41 -0800 (PST) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 486C4CEC00C; Thu, 9 Feb 2017 17:32:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1486661559; bh=9iUT0w0H15Q7FgO6j8mNITt/7R1EDbemN+usB2lmgdQ=; h=From:To:Subject:Date:References:From; b=CZajRQrCzGs2xyjBK3NqFVLnpFkJq9Efm6HTuxi36HWkB+8o4Y5LKOiC9LQdtjmuc t8bIH4ovQbddFM/A15ZLkx8TIJBDS8MCFt576ZmztfBVsf5lKGXvsR2hnv5svFRUqS ukGfzXkX0AlS+k2QLA5IVpZ5kYG4cjcO4p3PI7z4= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1486661558-2178-25938/12/5; Thu, 9 Feb 2017 17:32:38 +0000 From: Arnt Gulbrandsen To: jmap@ietf.org, Yoav Nir , Alexey Melnikov , =?KOI8-R?b?5M3J1NLJyiDwz8TLz9LZ1M/X?= Date: Thu, 9 Feb 2017 18:32:36 +0100 Message-Id: References: <4ABF6702-BFC7-4530-95FD-C61C06F2E6AB@gmail.com> <1486658028.81835495@f105.i.mail.ru> Mime-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Jmap] JMAP security X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 17:32:44 -0000 It sounds like a straightforward origin problem. Perhaps the security considerations should mention the origin headers. Or they may do already, that is the kind of near-boilerplate I would hardly even notice. Arnt From nobody Fri Feb 10 08:05:30 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 6A88B129E42; Wed, 8 Feb 2017 13:09:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.022 X-Spam-Level: X-Spam-Status: No, score=-7.022 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com 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 9IejeTjJQLUt; Wed, 8 Feb 2017 13:09:34 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A0901294C7; Wed, 8 Feb 2017 13:09:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1486588173; x=1518124173; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=TQdbDC1CauWtGC4Qdc6wIWzATiXEji2tj4Up325uGDQ=; b=RRIr8vWDdOU4OlSfVg+Z8s+8iC68RwbbB/7rEkBsZgQFOobr9jJm+Oru wW+JKzzXdKEM3iAhmaPTEFm9x6in3x/ov0/AIt8/mXInVbM0aMy2CGXjh CSkkRVVSL7eUPwPd42S3cyXqv9700qtaMbIxx6z3SxAprrBHKXYXPfJuK M=; X-IronPort-AV: E=Sophos;i="5.35,348,1484035200"; d="scan'208";a="261249695" Received: from unknown (HELO Ironmsg04-R.qualcomm.com) ([10.53.140.108]) by wolverine01.qualcomm.com with ESMTP; 08 Feb 2017 13:09:33 -0800 X-IronPort-AV: E=McAfee;i="5800,7501,8433"; a="1359869645" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 08 Feb 2017 13:09:32 -0800 Received: from [10.64.115.82] (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 8 Feb 2017 13:09:32 -0800 From: Pete Resnick To: Ted Lemon Date: Wed, 8 Feb 2017 15:09:30 -0600 Message-ID: <7822918B-0312-4EC5-A8F0-3F9BFEF54BBB@qti.qualcomm.com> In-Reply-To: References: <9D66E5E7619E1C55F1DEB959@PSB> <1A1381DB-DF79-4FC8-88F4-60A0AF4FE3CA@cursive.net> <1486523704.3711423.873904592.78C4EAA8@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5344) X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01F.na.qualcomm.com (10.85.0.32) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: X-Mailman-Approved-At: Fri, 10 Feb 2017 08:05:29 -0800 Cc: jmap@ietf.org, Neil Jenkins , IESG , Yoav Nir , IETF discussion list Subject: Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 21:09:35 -0000 On 8 Feb 2017, at 9:52, Ted Lemon wrote: > IMAP and POP both use the wrong data abstraction, and consequently are > very hard to get right, and generally aren't gotten right. > > So a new protocol that has the data abstraction right is actually a > substantial improvement. I don't know if that's the case with > JMAP—if it's the same data abstraction as IMAP, it's not worth > bothering with, but that's something that at least in theory can be > discussed. > > What JMAP does afford is the opportunity to have an embedded web > client that doesn't suck, and a way to escape it if you want something > more stateful. Yep, this is the bit that convinces me that this effort should go forward. IMAP's problem has always been its combination of semantic bottleneck and leakage: It constrained the semantics that you could communicate across the pipe in some ways (hence the myriad of extensions required to have a workable IMAP implementation), but leaked a bunch of server-specific semantics (e.g., the storage model, the constraints on network resources) through to the client instead of having a clean protocol. Putting a rich and leak-free protocol in front of IMAP is an improvement, and being able to remove IMAP from the equation eventually is a laudable goal. Yes, there are transition and conversion issues. But I haven't heard anyone come up with a solution to the problems inherent in IMAP that doesn't involve transition pain. The answer can't simply be, "Never attempt to solve the IMAP implementation problems" or "Only solve IMAP implementation problems within IMAP". Neither one of those answers leads to a solution. (BTW: The submission issue seems a rather boring one to me. There's never been good deployment of BURL and the other LEMONADE mechanisms to make it happen. If this work just creates a decent protocol interface to those submission mechanisms, more power to them. I don't think there's anything magical here.) I have no objection to clarifying the charter in many of the ways suggested to make clear what the motivations are and what the constraints are on the work, but overall I think this effort should go forward. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Sun Feb 12 11:57:39 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 B3CA0129B05 for ; Sun, 12 Feb 2017 11:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 nJ4MRQz1tCol for ; Sun, 12 Feb 2017 11:57:35 -0800 (PST) Received: from mail.netassist.ua (mail.netassist.ua [IPv6:2001:67c:1874:5::2]) (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 5B73C129AB6 for ; Sun, 12 Feb 2017 11:57:35 -0800 (PST) Received: from [2a01:d0:305:1eaf::46] by mail.netassist.ua with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85 and XAMS 0.0.13) id 1cd0cp-0002rk-8m for jmap@ietf.org; Sun, 12 Feb 2017 22:20:05 +0200 To: jmap@ietf.org From: Philippe Duke Organization: NetAssist LLC Message-ID: <48ea211a-5022-2fc1-8d66-9bedde8a1953@netassist.ua> Date: Sun, 12 Feb 2017 21:56:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="moPCXEIAiea9laseHxihGEnlLSlo9g1OJ" Archived-At: Subject: [Jmap] JMAP protocol: transport X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 19:57:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --moPCXEIAiea9laseHxihGEnlLSlo9g1OJ Content-Type: multipart/mixed; boundary="D36DOCLqAcUlgSflWwl9ebWRtN1DKrcov"; protected-headers="v1" From: Philippe Duke To: jmap@ietf.org Message-ID: <48ea211a-5022-2fc1-8d66-9bedde8a1953@netassist.ua> Subject: JMAP protocol: transport --D36DOCLqAcUlgSflWwl9ebWRtN1DKrcov Content-Type: multipart/mixed; boundary="------------18EB011FFF0FF62AB297B0DD" This is a multi-part message in MIME format. --------------18EB011FFF0FF62AB297B0DD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello members of JMAP WG, I would like to join your discussion to help create a new email fetch protocol. I would like to ask is what is the current state of design? How do you plan to implement notifications? What would transport SHOULD be used? Will the protocol be TCP-independent and work only on top of HTTP like RFC6455? What is your view on special mailboxes (like Inbox, Drafts, Trash, Spam and so on) already done by [RFC6154]? So many clients have a mess with IMAP LIST special folders. As far as I realize, the base approach of the JMAP is to make mail access available from browser applications without need to interop on IMAP. What is your approach for WebSocket [RFC6455]? --=20 Philippe Duke Network software engineer System-level developer NetAssist LLC Ukraine Khreshchatyk Street, 10B, office 8 AS29632 http://netassist.ua Our GitHub Repository: https://github.com/netassist-ua --------------18EB011FFF0FF62AB297B0DD Content-Type: application/pgp-keys; name="0x97A6A441.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x97A6A441.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFiYeaABEACYyS1T2sjp9VV4ANLkCy2zL677GThQQM3RqD5EoGsT6y/wg8xI W4uoNjW8mmDg+DtweFgPdCSNCnBgeNB0q64zF1u8KB0TcuX9PWdKigiPSAkyMBq2 wWGCKjk7DYR4NF0S/Koe3NkogL3ipD6+/BXGYpJNrDuP7sZtp1OaSd4jcJg49o9X 4Oexjyec1dqVQYpLQYAZj1xFLxTZHVL/kl+tkH2E98vmTfeNekaVgJtev9bLFF9o NuFTT7h3tHTbOzs0t46bxZ4DOUYICUUrW+mXm3UbLvpoEUv8zKR+TSfkmyYhocVp y5BqiIPfMShzXBYo+j014rpZd3V3AxJvikSZ7uY5GMWHV1zM/wSA0KTmmjQxofqQ 4Tsq+aEzudkwujo5uSiR74P7aQGv7OKeDLh+69vgDhrIb0rcSP2runp398F9BaGw jRjiFNNbz+8bkQ9i0qmT2Fos30cxB198oFgLNrslAdBBnVXf8N18nAMj6/61Aibl IZwu9P1SRVXbItFh1/pOgzAoHuC0/Xu0ANSM5IIbndU1hBVTR9fvcLYQIZiFWaU9 ri9JZpcH8bzDoRpD++K6iHHocZTbW66brjqdPWaMeYcybd0W/JYI8M96uorLZ9aB /M5n7xYna0ZRx17XkXKfrY+rbk1f1i3vdfSDwPVTYTjhPW3pjysK0iHCjwARAQAB tCdQaGlsaXBwZSBEdWtlIDxwaGlsaXBwZTQ2QG5ldGFzc2lzdC51YT6JAj8EEwEI ACkFAliYeaACGyMFCQlmAYAHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRD1 AfQul6akQUXUD/9JSr8NVhxa5uoiIRf/XNrS46+cxOSbjR9wLliQTNOuOFXFsscR 57wFe6Z/uC7Dt6lAHV9N/CBM01FkVT5qNlbI0E2ejtRQC7hLtZEz+EwDcGsmDQFd fIr+3rVly+4jE9exWbqhU8aHmoTIEeLcX6HBLO9PwN3hcS1td61AJuVHLPFItZOa nbXW/4+QszUKtDarLsjs9zNkI4Ij90WcxVMQ+QnjpgKYQ5LcAy3qobabOMf8n24s nuCP5iNOhvfCRcKXtxVIwGCrIjWD902XjX//TK9zchD/6y91+wwTvCp9QYl26s8L RPHA+ELNSPZOfe4x8gAv1DEFanPSSuBNsrTPa2ZzNjUWxmaT396HlSxAxlRE8T4c jBqoYN/GWIBwsQVKUe1SAniIWPmQo63zxeO2+7h6Pb7ARSpxNuu+VsqLWCsZICSp 4mKkOoie90hxvPyO4uxOq8uQC7CK94dDdDw0O04Dj3IztzGrorUs27vGeeOii5O6 Ed33OpRDIAIrMp6CG1JFLiYUWWec6NiAkzE0AzhGDJ79A6I76Az5sCVYPwVeRVtY ImT/AW+/Mdj+D+XCL5KHQVtrRBEwV6aGQt87POFKNmhgcVGwgnr21fD2wNlnwIL0 neNBWeS9NCVzaAKp0likODxfuDZuFFqENDCr/YBAs2GIl/suqneZigNsjLkCDQRY mHmgARAAra7Ri6LKA1fZvlqj2I9GaeG/jgxXfyygMieZ0JscX6wE6OBlGlsk5P34 /W5st6v8t84pO+/GLHoVkKl28L7VD290UjEJBmt/UeS1vrPnIa/TvPDyYLAk5brF k6jJgNDeUAQWHiQYvM2GZrLO0diDnso03Y56uyil6mDEMCCkSLagBRfom+VKwgVt zsR4yhQRUmYZYKFfpaU1c9RatJ6McYh+fm9Npwd4UqQ10PYAUUkXbco0FOcGGFgZ 59Rds7PfGTA8foBN1Oiit57pMN2fFof7SxdTcnL0yB6veIN/WKZHEetcT2eEBE/X hzvpAsjobIOnf/rISGDREGJaezdxJPd345B75gf1XbthjB23XVMfqk1EGRG/VYxX Kw+jiUnvxuKCXaYp8Zk/jLalywkbum7lPh7TYTRmKPd4qTLERHrykCqx9v+hqBKs Co4euZChXBAmORCGEQOK5ct2FPNJ+JbTi7HAoBwJnMTj3Eah4OKvPkVw2bKZlr1c EhAjzOp8Opn+9UW710SRe8+ZnvVlz+yHu5Y7jUFoqFENl9SmEvAG0v0CJFah8egQ mfHv6h1xN9WMKQE1UKi42uauIvLURSE7rLsuAtOA3XkohmYqQ2u6J7ogNcYE64y8 JaTem/lDTZ/qo1IsQeTDz1voX/D54muDN6Ll9BaRIRtxKiAftkkAEQEAAYkCJQQY AQgADwUCWJh5oAIbDAUJCWYBgAAKCRD1AfQul6akQVVTD/90UekFT02RHjDUkP/7 kiacffFPmvrDjNofdg6zzimSw8BAhU6fEdvx4o/H+Dm5iLhaSBaGkHu0oUje1cjw SuE5pzvEdPtKqHNNQL8YXL9llQHHPwT+RcvsiEkyNL90HKzsWIFgEZUWOuGVVp0K e1j7Bx/vbGXT41Uft3Zp5kdCHw36tMzUJ87keXTzvRhN/46ATLbwJ2a0lIsWSMCA fqtKjVQ6kkHFgZaEG8lzMBHBT26OmSMVYqjWCbYbRc/W7VAqohNr+OSedN5rG8ag 3ZO2T7QTzGfWpN1zVlfAxUkkuec508iKbg5oOuuc3agmlNt3Ul+E41WI1tLJNpr8 n4IDIjCRoZDxqgf2OqWKEro421RCdvffJYbDo7Z5gmr0aGHwCdjW2aiKluoOmmQA NUKuH5nJqM7NA/Uyv9DwW7thC1b+wkX160MnYqd9DOLT0ij04ubVBUZZsfSwBI1T BycLNTvNqYQFFYX+eXLiomgXVDz1GERSmONU4aZhoJOWSMxkSB6Qhc12X7qc/tMO +PODGx5NtpnT3ZVV8+R8l8SFKHeULdT58USTA+AoEOoHmWXbI1YfMicC+71/0Ljq o0UwyP5/rTN9x/dj985v7ft9zad3ZFeYPoEOHv0XqgXPa6FlLvfJko3vuSuZNFhs yWGQqkwJowx3eMBWrZd1bk8NTA=3D=3D =3DnV+P -----END PGP PUBLIC KEY BLOCK----- --------------18EB011FFF0FF62AB297B0DD-- --D36DOCLqAcUlgSflWwl9ebWRtN1DKrcov-- --moPCXEIAiea9laseHxihGEnlLSlo9g1OJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE1It1vYb5UTjRCVHK9QH0LpempEEFAligvewACgkQ9QH0Lpem pEEnYw/8CsukfQLOqeSCTlR53bUAIwO5rvdkCO2YE14hCe+3ZhoNvdQYFzafxYnH 3LUnFIhMuru+qjhxBDmYxoJoyquHch420xqItqkregHKfYecKXK6TTwas8h/S+Pr fN/ok0Ddx/EP+FvmPYSxkcwRF2eBoLe3b/paUz4+A3QldlHeK5Ybm4xgxSnKKzz2 e31N9uuMf9mrpRTRYvnxbbzNvbiWGekYelERob2csjkMbpnE4K2Mud8EZ6oBWtxk Q16tIEJSrwUc7U+bHwH8VvA3lXAqgwB+zt2vF2pb1jgXeCT0CDAxUWaplOTDkEif w5B04LK124XSRJ/R6wdEPD/O85fmDJu8MjOIHVZkF/I6Dqbd+Fc/NwzjPtYOk4HN 57o/pQg2U/qPCQ0jBVtPWKQVWRZ661FGhJCZEIlIrYqLLjkETaoaUnxaseNa3Tmv QnAD6Y4d3v5fcgw0MDyO4Y/coP/fCLNGI0mUaDkQwzlqcNKVunFWmU8+/QYE3ZWR GsD378PHhvcKvlujbjS1ioNAKnEHhSGc4V8PlkBeBetIRFe1r8IS1Zo93IX7mkO4 H7Z3vPoHGeb/DCRzJSu+1Z/K4r6de3rSTdm0LnjHyIK+bY/yNu9TZMf2HjM9TYXD 6dudvjKNp1VHPJjOfku4HG0ObyNDRKC0jFZhUB/LjNb9hSPsX4U= =89OF -----END PGP SIGNATURE----- --moPCXEIAiea9laseHxihGEnlLSlo9g1OJ-- From nobody Sun Feb 12 22:45:00 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 6B81B1294D8 for ; Sun, 12 Feb 2017 22:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 kQLU1EvfkJA7 for ; Sun, 12 Feb 2017 22:44:57 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42692126FDC for ; Sun, 12 Feb 2017 22:44:56 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id v186so150375811wmd.0 for ; Sun, 12 Feb 2017 22:44:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=TuSHMS+w8XGzZsE4EiPOswnAqor1ZpdkHODtxZNNJAY=; b=DfqJMCwOu1i7E/I3rrjjvsw971n17LfFJrJn5gWHX2VJ7jwsafrWBZUUmWBT1nRis3 owYIKVvVSxZZ/pRKzPmseRxVAXHy76/knSpMVNQnzXWNagJHhH7xcTuKE3K3Uub84BfR WjY4uDqbdWq4ZeupGFF1QIoT0abccOX+4oYFzK2TQhSE6nzBdx2RorFByDRFEjVsR5XT Ktx/0q9eJfD5YTI7Ed1KGY5CLsQQgZAfrfKeNGwRa74rx0OOF/CDV/R7M6ve4vEW3XXs l6fnhd8mlpT54OCkAAA/0SfHpnV1AbFXHHNRBizxMM+8hYQlDVgNPXgtBEr9KmYgIy8O +4Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=TuSHMS+w8XGzZsE4EiPOswnAqor1ZpdkHODtxZNNJAY=; b=QC/63keuyFLke4zZSD3RtSGIUUOQHSIwtOzG0mOd8cNLSnAtRSm2iBPHWPV/KADLkU jyUtjHHTFjnI3eycLSDrcbr7jMzfMn4/hCrR11kXF3SHtbyZZ292GAlClMveRduR+drg Zna/4ckvZn3OOWZ9EUGvepgIB/vfGp3IuV46Sy+z3WI5aBLWyldV4ttNUsrkq2nQZiUr Le+2aNJA5CIJSnwEBCK0eT5tlyPlls9KZYB5jrS2VFK3a0rR17QP6qj2ARui3xOTqtWM vluoY3A8EiKxXBdXpVopLiNtvyMnwOabgHwTsRdXFjJhNP8SpVx1t/lAdqsmmPkmfuSe q8MA== X-Gm-Message-State: AMke39mdg4s4uXih2aHnn4jlZBg1+DcQs60wgP+KPGTvlG2S//uOd/vCuM1HpT8FarFGbQ== X-Received: by 10.28.0.2 with SMTP id 2mr17438558wma.141.1486968295209; Sun, 12 Feb 2017 22:44:55 -0800 (PST) Received: from [192.168.137.219] ([109.253.200.31]) by smtp.gmail.com with ESMTPSA id z90sm12563594wrc.24.2017.02.12.22.44.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Feb 2017 22:44:53 -0800 (PST) From: Yoav Nir Message-Id: <55B4EC7F-74B0-4C96-8EC4-47F677C26067@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_20762686-38B6-4534-9F9C-F27C2C306CBE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 13 Feb 2017 08:44:48 +0200 In-Reply-To: <48ea211a-5022-2fc1-8d66-9bedde8a1953@netassist.ua> To: Philippe Duke References: <48ea211a-5022-2fc1-8d66-9bedde8a1953@netassist.ua> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: jmap@ietf.org Subject: Re: [Jmap] JMAP protocol: transport X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 06:44:59 -0000 --Apple-Mail=_20762686-38B6-4534-9F9C-F27C2C306CBE Content-Type: multipart/alternative; boundary="Apple-Mail=_2C38A698-12B7-4E54-BBC0-34AA6C90DC8F" --Apple-Mail=_2C38A698-12B7-4E54-BBC0-34AA6C90DC8F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Philippe On 12 Feb 2017, at 21:56, Philippe Duke wrote: > Hello members of JMAP WG, >=20 > I would like to join your discussion to help create a new email fetch > protocol. I would like to ask is what is the current state of design? The current state is that there is a mailing list and a proposed charter = for a working group. There are also two drafts that have the current design by Neil Jenkins = from FastMail: https://tools.ietf.org/html/draft-jenkins-jmap-00 = https://tools.ietf.org/html/draft-jenkins-jmapmail-00 = Of course, if and when a working group is formed, all change control = goes to the group, and if the group decides to replace the JSON with DER = and OOB attachments with in-band RFC3252-encoded attachments, then that = what is going to be (although that would be regrettable) > How do you plan to implement notifications? What would transport = SHOULD > be used? Will the protocol be TCP-independent and work only on top of > HTTP like RFC6455? Current design is a web service on top of HTTPS. > What is your view on special mailboxes (like Inbox, Drafts, Trash, > Spam and so on) already done by [RFC6154]? So many clients have a mess > with IMAP LIST special folders. There is some info on that in section 2 of = https://tools.ietf.org/html/draft-jenkins-jmapmail-00 = > As far as I realize, the base approach of the JMAP is to make mail > access available from browser applications without need to interop on > IMAP. What is your approach for WebSocket [RFC6455]? When you use email from a browser application, you=E2=80=99re really = downloading the application from the mail provider. You don=E2=80=99t = really need standardization to have a gmail client provided by Google = talk to the gmail servers. The protocol=E2=80=99s aim (see this: = https://www.ietf.org/mail-archive/web/imapext/current/msg05820.html = ) = is to allow you to =E2=80=9Cwrite a good MUA=E2=80=9D, so not = necessarily a browser. Perhaps not even primarily a browser. HTH Yoav --Apple-Mail=_2C38A698-12B7-4E54-BBC0-34AA6C90DC8F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, Philippe

On 12 Feb 2017, at 21:56, Philippe Duke <philippe46@netassist.ua> wrote:
Hello members of JMAP WG,

I would like to join your discussion to help create a new = email fetch
protocol. I would like to ask is what is the = current state of design?

The current state is that there is a mailing list = and a proposed charter for a working group.

There are also two drafts that have the current = design by Neil Jenkins from FastMail:

How do you plan to implement notifications? What would = transport SHOULD
be used? Will the protocol be = TCP-independent and work only on top of
HTTP like = RFC6455?

Current design is a web service on top of = HTTPS.

 What is your view on special =  mailboxes (like Inbox, Drafts, Trash,
Spam and so = on) already done by [RFC6154]? So many clients have a mess
with IMAP LIST special folders.

There is = some info on that in section 2 of https://tools.ietf.org/html/draft-jenkins-jmapmail-00
=

As far as I realize, the base approach of the = JMAP is to make mail
access available from browser = applications without need to interop on
IMAP. What is your = approach for WebSocket [RFC6455]?

When you use email from a browser application, you=E2=80=99re = really downloading the application from the mail provider. You don=E2=80=99= t really need standardization to have a gmail client provided by Google = talk to the gmail servers. The protocol=E2=80=99s aim (see this: https://www.ietf.org/mail-archive/web/imapext/current/msg05820.= html ) is to allow you to =E2=80=9Cwrite a good MUA=E2=80=9D, = so not necessarily a browser. Perhaps not even primarily a = browser.

HTH

Yoav

= --Apple-Mail=_2C38A698-12B7-4E54-BBC0-34AA6C90DC8F-- --Apple-Mail=_20762686-38B6-4534-9F9C-F27C2C306CBE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJYoVXhAAoJELhJCxUKWMyZTfMH+wUJjGUlUNOH278YSflnfnNU n1y3k+7lFHfvaKw701kVdcvaHuesmcjQYq3zbhi24Pf3PD2/53n4fCazMg5GSnXp qKXeW/GYqoW4kSEbsiPezzqoM9e2tUV1sqhtIamK17E0mI68M0YEYM4am2paglZS TnZ61x86n5T5r3xkzQgzmoJ2J5Kv6iJABZyvOalbPDlrs8aZUpouQXRk6xFzWcdh NrlXttvLyC7rL7Hv6dOggKktHrGiPDYw7shToh8hqHj2Cp1DzRd3kRyDpyQs9/vn y9rs0dzWh3lGsg5wrcCiinqWZIEeRFH9ihnBBKxcpPaibEsr4GJXvfjov4NCanw= =JjUe -----END PGP SIGNATURE----- --Apple-Mail=_20762686-38B6-4534-9F9C-F27C2C306CBE-- From nobody Wed Feb 15 06:31:58 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 4F9BD129494; Wed, 15 Feb 2017 06:31:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148716911729.17277.15371202023742081890.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2017 06:31:57 -0800 Archived-At: Cc: jmap@ietf.org, jmap-chairs@ietf.org Subject: [Jmap] Spencer Dawkins' No Objection on charter-ietf-jmap-00-08: (with COMMENT) 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: Wed, 15 Feb 2017 14:31:57 -0000 Spencer Dawkins has entered the following ballot position for charter-ietf-jmap-00-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-jmap/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm going to ballot No Objection now, but I know there are still discussions underway that may result in text improvements, and I'm assuming they'll converge before we announce approval. From nobody Wed Feb 15 11:07:08 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 21A4912940A; Wed, 15 Feb 2017 11:04:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148718546010.28194.17391329766613826626.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2017 11:04:20 -0800 Archived-At: X-Mailman-Approved-At: Wed, 15 Feb 2017 11:07:07 -0800 Cc: jmap@ietf.org, cmorgan@amsl.com, jmap-chairs@ietf.org, aamelnikov@fastmail.fm Subject: [Jmap] jmap - New Meeting Session Request 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: Wed, 15 Feb 2017 19:04:20 -0000 A new meeting session request has just been submitted by Cindy Morgan, on behalf of the jmap working group. --------------------------------------------------------- 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: ---------------------------------------------------------