From nobody Mon Jul 3 00:30:27 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 962AD12441E for ; Mon, 3 Jul 2017 00:30:26 -0700 (PDT) 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 gZmGBSw_TFTM for ; Mon, 3 Jul 2017 00:30:25 -0700 (PDT) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 26F0812426E for ; Mon, 3 Jul 2017 00:30:25 -0700 (PDT) Received: from [10.217.110.125] (officewifi.dovecot.fi [193.209.119.110]) by mail.dovecot.fi (Postfix) with ESMTPSA id 3D1912B3CC5 for ; Mon, 3 Jul 2017 10:30:51 +0300 (EEST) To: jmap@ietf.org References: <1498017178.1304756.1016181400.0FCF0683@webmail.messagingengine.com> From: Aki Tuomi Organization: Dovecot Oy Message-ID: Date: Mon, 3 Jul 2017 10:30:23 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <1498017178.1304756.1016181400.0FCF0683@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Jmap] JMAP Conceptual Decisions X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 07:30:27 -0000 On 21.06.2017 06:52, Neil Jenkins wrote: > The short answer is it's good enough, widely understood and it's by > far the easiest thing for developers to adopt. There's support in > basically all OSes and programming languages. It's easy to read and debug. Hi! A comment about HTTP+JSON. When finalizing this decision, one should consider the point that it would be a really good idea to consider compability with swagger. Big businesses use swagger (and it's kind) to generate thin client APIs, and choosing format that is not readily mappable to these will reduce the business appeal to this API, or requires someone to produce java/python/ruby/whatever binding(s). We provide doveadm HTTP API using the current JMAP syntax, and this has been one of the most frequent concern with the data structure from our customers. Aki Tuomi Dovecot oy From nobody Mon Jul 3 02:13: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 B81E212EC15 for ; Mon, 3 Jul 2017 02:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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=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 SuVpLTWMz4Wt for ; Mon, 3 Jul 2017 02:13:49 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id A0F9113153F for ; Mon, 3 Jul 2017 02:13:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1499073215; d=isode.com; s=june2016; i=@isode.com; bh=yXON7eoOdgNYbyYLZ8w3fvH3EPxbewTT5LM0R95FGlo=; 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=j8oC3uJsuAqvEV/MVdsjGT5rSavFq20OqqM0ck5H0K3IybYRU6WiZWphU83VZOQqUBNH64 yY5dSkFQPoSn/qsUZWId8XEhkhC/1iJM50kqoOe+renqjnSskDcGYYa/BWAOJXFeqOlhXB vRZ4ePKifM7wYe4MDUxF2T49VLlDFiU=; Received: from [10.217.148.170] ((unknown) [185.69.145.90]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 3 Jul 2017 10:13:35 +0100 X-SMTP-Protocol-Errors: NORDNS PIPELINING From: Alexey Melnikov X-Mailer: iPhone Mail (13G35) In-Reply-To: Date: Mon, 3 Jul 2017 10:33:18 +0100 Cc: jmap@ietf.org Message-Id: <04327CC4-3EB0-4C06-8CDF-774575D2C4C8@isode.com> References: <1498017178.1304756.1016181400.0FCF0683@webmail.messagingengine.com> To: Aki Tuomi MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jmap] JMAP Conceptual Decisions X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 09:13:50 -0000 Hi Aki, On 3 Jul 2017, at 08:30, Aki Tuomi wrote: >> On 21.06.2017 06:52, Neil Jenkins wrote: >> The short answer is it's good enough, widely understood and it's by >> far the easiest thing for developers to adopt. There's support in >> basically all OSes and programming languages. It's easy to read and debug= . > Hi! >=20 > A comment about HTTP+JSON. When finalizing this decision, one should > consider the point that it would be a really good idea to consider > compability with swagger. Big businesses use swagger (and it's kind) to > generate thin client APIs, and choosing format that is not readily > mappable to these will reduce the business appeal to this API, or > requires someone to produce java/python/ruby/whatever binding(s). For people like me who never used swagger, can you elaborate on what the res= trictions are, so that the group can evaluate specific requirements? Thank you, Alexey From nobody Mon Jul 3 02:35:43 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 1FD55131550 for ; Mon, 3 Jul 2017 02:35:42 -0700 (PDT) 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 tVDFnjfe6eWG for ; Mon, 3 Jul 2017 02:35:40 -0700 (PDT) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 8CAC313153F for ; Mon, 3 Jul 2017 02:35:40 -0700 (PDT) Received: from [10.217.110.125] (officewifi.dovecot.fi [193.209.119.110]) by mail.dovecot.fi (Postfix) with ESMTPSA id 7469D2B3CC5; Mon, 3 Jul 2017 12:36:07 +0300 (EEST) To: Alexey Melnikov Cc: jmap@ietf.org References: <1498017178.1304756.1016181400.0FCF0683@webmail.messagingengine.com> <04327CC4-3EB0-4C06-8CDF-774575D2C4C8@isode.com> From: Aki Tuomi Organization: Dovecot Oy Message-ID: <5bb947f1-738d-0dc1-781d-5e22750b94f7@dovecot.fi> Date: Mon, 3 Jul 2017 12:35:39 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <04327CC4-3EB0-4C06-8CDF-774575D2C4C8@isode.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Jmap] JMAP Conceptual Decisions X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 09:35:42 -0000 On 03.07.2017 12:33, Alexey Melnikov wrote: > Hi Aki, > > On 3 Jul 2017, at 08:30, Aki Tuomi wrote: > >>> On 21.06.2017 06:52, Neil Jenkins wrote: >>> The short answer is it's good enough, widely understood and it's by >>> far the easiest thing for developers to adopt. There's support in >>> basically all OSes and programming languages. It's easy to read and debug. >> Hi! >> >> A comment about HTTP+JSON. When finalizing this decision, one should >> consider the point that it would be a really good idea to consider >> compability with swagger. Big businesses use swagger (and it's kind) to >> generate thin client APIs, and choosing format that is not readily >> mappable to these will reduce the business appeal to this API, or >> requires someone to produce java/python/ruby/whatever binding(s). > For people like me who never used swagger, can you elaborate on what the restrictions are, so that the group can evaluate specific requirements? > > Thank you, > Alexey The problem is, I guess, that most of these tools are geared into JSON object concept. So each reply or request contains one or more JSON objects. Not array of string,something,string tuple. I am not sure if the problem with HTTP+JSON is so horrible with performance that it requires bulking the requests, and to me it feels bit like premature optimization. For more detailed explanation, see https://swagger.io/docs/specification/basic-structure/ Aki From nobody Mon Jul 3 05:46: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 DCB161315D7 for ; Mon, 3 Jul 2017 05:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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_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=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 U0-dDvJUaYBo for ; Mon, 3 Jul 2017 05:46:41 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 3C3BC129B19 for ; Mon, 3 Jul 2017 05:46:41 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id 32so142184542qtv.1 for ; Mon, 03 Jul 2017 05:46:41 -0700 (PDT) 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=GYfSWEgPae91sIdwmkrI4dqfBpKCbPeLW/HJNxKzJAQ=; b=x56iUvgiBGGyQuz41e9MXVYvdEiVHRaY+xNBV36aDinHSbLCgZ5nm4IyfR3QIoz3Ur xqQOs2GstWJ3WOThlk9BvTQiAzOmOGRKHcpUsC91esYIZFdoUp+HeHPvtteN3aZKy3cB RxrkDIFBLrQq/lfl/hwUQa0X0Yq7SZXYnAE1RIDwcMIZ13bfLg5HWcKQJ2hSh2XFCBEs p3ikacye5X3rsaPbquiLrMHjGhRl0C5b7aZNNIVLSRsGrZ00YAWAsQDO+OiLQFCPWasf YEplrmANQ1o+FyE+UbsDSwfFVT2rZudnya9r1MTICxwMTkU62XrToE5Yo+PzGbfYfIs1 norQ== 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=GYfSWEgPae91sIdwmkrI4dqfBpKCbPeLW/HJNxKzJAQ=; b=Udk38czwb5MHxszCrSCWMruPpIgl22AjXs87Be3kkRamLD1IxwaD+335eh99wvLwjV 8VpSoMWmHoThqH5Gb3GYwEx6xVjgzNpHCl67aQFFYc5azbsSKppzZhj3m0YGwXhWlafi zAC+6G60AYUPOzR1eRkAQkPz+ArgCJcPAjqeYMrLZgoitc2+mZK52CcyR6HZxXxfpoet wtjLW09LaR3g6GI1XkaWvySELq9wjuBprpszyCUbxfcOskD8ffnZfG3oQNfQBi7HZotf H4X9MKTpgUJav8uUdwvcmkF8EXL0jCjoSD0e6bKGBk/CgBa/SlOGgIQgQwXegK2hc0va 8sbA== X-Gm-Message-State: AIVw111HWYwH3HVXaknVK31iaJUzjT4OtnuLI9rHynQjPpyOjp0cZvRb 10XcgqD3axyPGW+B X-Received: by 10.200.43.58 with SMTP id 55mr11982312qtu.202.1499086000370; Mon, 03 Jul 2017 05:46:40 -0700 (PDT) Received: from [10.0.30.153] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id v34sm12493289qtg.31.2017.07.03.05.46.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Jul 2017 05:46:39 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_1D96746A-AD61-4429-B2A0-72E06A4E9921" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 3 Jul 2017 08:46:37 -0400 In-Reply-To: <5bb947f1-738d-0dc1-781d-5e22750b94f7@dovecot.fi> Cc: Alexey Melnikov , jmap@ietf.org To: Aki Tuomi References: <1498017178.1304756.1016181400.0FCF0683@webmail.messagingengine.com> <04327CC4-3EB0-4C06-8CDF-774575D2C4C8@isode.com> <5bb947f1-738d-0dc1-781d-5e22750b94f7@dovecot.fi> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Jmap] JMAP Conceptual Decisions X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 12:46:43 -0000 --Apple-Mail=_1D96746A-AD61-4429-B2A0-72E06A4E9921 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 3, 2017, at 5:35 AM, Aki Tuomi wrote: > I am not sure if the problem with HTTP+JSON is so horrible with > performance that it requires bulking the requests, and to me it feels > bit like premature optimization. It sounds from what you are saying as though swagger compatibility would = preclude this optimization. --Apple-Mail=_1D96746A-AD61-4429-B2A0-72E06A4E9921 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jul 3, 2017, at 5:35 AM, Aki Tuomi <aki.tuomi@dovecot.fi> wrote:
I am not sure if the problem with = HTTP+JSON is so horrible with
performance that it = requires bulking the requests, and to me it feels
bit like premature = optimization.

It sounds from what you are saying as though swagger = compatibility would preclude this = optimization.

= --Apple-Mail=_1D96746A-AD61-4429-B2A0-72E06A4E9921-- From nobody Mon Jul 3 06:29: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 2519A129B34 for ; Mon, 3 Jul 2017 06:29:52 -0700 (PDT) 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 fmtbMDkblwTa for ; Mon, 3 Jul 2017 06:29:50 -0700 (PDT) Received: from smtp.dovecot.fi (smtp.dovecot.fi [193.209.119.8]) (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 5675D129AF4 for ; Mon, 3 Jul 2017 06:29:50 -0700 (PDT) Received: from null (unknown [87.191.39.187]) by smtp.dovecot.fi (Halon) with ESMTPSA id aa8620f9-5ff3-11e7-8799-3d447e05304f; Mon, 03 Jul 2017 16:29:40 +0300 (EEST) Date: Mon, 3 Jul 2017 16:29:33 +0300 (EEST) From: Aki Tuomi To: Ted Lemon Cc: Alexey Melnikov , jmap@ietf.org Message-ID: <1487660969.1051.1499088574043@appsuite-dev.open-xchange.com> In-Reply-To: References: <1498017178.1304756.1016181400.0FCF0683@webmail.messagingengine.com> <04327CC4-3EB0-4C06-8CDF-774575D2C4C8@isode.com> <5bb947f1-738d-0dc1-781d-5e22750b94f7@dovecot.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.8.4-Rev3 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [Jmap] JMAP Conceptual Decisions X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 13:29:52 -0000 > On July 3, 2017 at 3:46 PM Ted Lemon wrote: > > > On Jul 3, 2017, at 5:35 AM, Aki Tuomi wrote: > > I am not sure if the problem with HTTP+JSON is so horrible with > > performance that it requires bulking the requests, and to me it feels > > bit like premature optimization. > > It sounds from what you are saying as though swagger compatibility would preclude this optimization. > >From what I've gathered there is no simple way to express the current API in Swagger. This is itself not a blocker, one can write connectors without swagger too. The current JSON format looks like it has been designed to benefit jmap<->imap connector. I am not convinced at the moment that "request bulking" actually provides such grand benefits, other than when you are making such connector where the order of requests makes a difference when sent to an IMAP server using IMAP protocol. Concurrent access should not be a problem for a well-designed server, so one cannot really argue for ordering the requests either. I would have raised these concerns earlier, but I was under the impression that the JSON format was already decided. Aki From nobody Mon Jul 3 22:40: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 B1F9B12EC54 for ; Mon, 3 Jul 2017 22:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, 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 (2048-bit key) header.d=fastmailteam.com header.b=K6liZe8o; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SzaeD4/t 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 zcSAd5MGZ2yG for ; Mon, 3 Jul 2017 22:39:58 -0700 (PDT) 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 9F36E1200C5 for ; Mon, 3 Jul 2017 22:39:58 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 13441208A3 for ; Tue, 4 Jul 2017 01:39:58 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Tue, 04 Jul 2017 01:39:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=AkYgg+N5x/5wm++6jGImB/ADbS5W2rb5NA/RjyCFK k8=; b=K6liZe8ogNCI60OIDkqoyTg+SLupKUb2kDl4jJOWYBngWEDSVeQNlfxNu rzfB5lrlIoTrneaFWX0CEJFZnpFGfgkH4R0yPyHuS7EGAWtfRBIG6eQSuf1Lmcxj yqvlpEY2+QkYkJONiM5yZYM4KjKCUgCL77/tpYAChiUwYDqXyMybvMxvnqOpt/5G SQhMprcYbggc4uaWB0TTu3Wya2MjGN8byq7ChO7TF5DJOpUVzJ1m4g6r6uHIcWcg G4UGrTxMN5fVS2aHYJl2ejHx2yP5yntPKEtXKAE7xGyrZBHRbPiOV4EUO1rk6OON +Vs/ji0GHJe+bAcXkO7/FwnwP6whg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=AkYgg+N5x/5wm++6jGImB/ADbS5W2 rb5NA/RjyCFKk8=; b=SzaeD4/tIfL/Y28IB/yyTTzVL2e19Q5vQCIf067pKt2iA SZ3G3SN8/ahlBsTk5VkP1TYLyQMQe3b6VdiQptFXhxSPiV2bqBQ0A9R7snpnK6aE hL0Gr/S4N/ZNvhQYET7UcRd9JRiWX0KtuR9+Nv2ObDSJzCu7S4+5wVxh9RmhiZGV 3gusV+n6GN7A17geO0sS2f4yOp89x9KJEELG1NTsQXu4W8By4oVghccbCrgpSnHl I9u6fvSr7ewJIVrw/JjqXyPkh6/Cx8MFCLfyFYEDi7EXXPj7Yt0nNuRmj0/xJEmN 1eqeQB/7e/0Vw3xfDC7TGuu62VZ9vawA1gK5tIF/w== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id B8594E2602; Tue, 4 Jul 2017 01:39:57 -0400 (EDT) Message-Id: <1499146797.2319096.1029695160.34130D2D@webmail.messagingengine.com> From: Neil Jenkins To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_149914679723190961" X-Mailer: MessagingEngine.com Webmail Interface - ajax-c528b28b Date: Tue, 04 Jul 2017 15:39:57 +1000 Archived-At: Subject: [Jmap] New message sending API proposal X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 05:40:02 -0000 This is a multi-part message in MIME format. --_----------=_149914679723190961 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi all, Hopefully we can get this area resolved by the end of the Prague meeting, s= o I'm sending through a first draft for initial discussion. I think the pro= posal addresses the concerns that were raised by various people on the list= , while remaining consistent with the rest of JMAP. *Sending a message* The core idea is the introduction of a new MessageDelivery object type. To = send a message, you create a new MessageDelivery, which has the following p= roperties: * *id*: String The id of the message delivery. This is server-set and immutable. * *messageId*: String The id of the message to send. This is immutable. The message being sent does not have to be a draft, for example when =E2=80=9Credirecting=E2=80=9D an existing message to a different email a= ddress. * *threadId*: String The thread id of the message to send. This is immutable and set by the server to the *threadId* property of the message referenced by the *messageId*. * *envelope*: Envelope|null Information for use when sending via SMTP. This is immutable. An *Envelope* object has the following properties: * *mailFrom*: String The email address to use as the return address in the SMTP delivery. This may be the empty string. * *rcptTo*: String[] An array of email addresses to send the message to. If the *envelope* property is null or omitted on creation, the server MUST generate this from the referenced message as follows: * *mailFrom*: The email in the *From* header, if present. * *rcptTo*: The deduplicated list of emails from the *To*, *Cc* and *Bcc* headers, if present. * *sendAt*: Date|Duration|null The date to release the message for delivery. This is immutable. The server MUST override this property to the current date-time if the value given by the client is omitted, null, or in the past, or if the server does not support delayed sending. If a duration is specified, the server MUST set this property to the time of this duration from =E2=80=9Cnow=E2=80= =9D. * *maybeCanUnsend*: Boolean If true, attempting to unsend the message by destroying the MessageDelivery object, *might* succeed. This is server set. On systems that do not support unsending, this will always be false. On systems that do this, it will start as true, and MAY transition to false when the server knows it definitely cannot recall the message, but MAY just remain true. Simple SMTP proxies would not store these objects, but more advanced server= s would allow you to retrieve them later, for example a client might fetch = a list of all the MessageDelivery objects with maybeCanUnsend =3D=3D true, = to present to the user messages they can still possibly cancel. The MessageDelivery object also seems an ideal place to be able to put deli= very status for servers that support this, so clients can query for each em= ail address the message was sent to, what happened (delivered? If not, what= was the error? Has it been read?). Any thoughts on whether this is a good = idea and what pieces of information should be represented? *Unsending a message* To unsend a message, you destroy the MessageDelivery object, using standard= JMAP commands. If this succeeds, the delivery was successfully cancelled. = Otherwise you get an error. *Updating the message if the send/unsend is successful* We really want the ability to include in the same API command an update to = perform on the message if the send/unsend succeeds (i.e. the MessageDeliver= y object is successfully created/destroyed). For example, remove the $Draft= flag and move the message to the sent folder. Without this, you would need two round trips (the client would need to wait= to see if the send was successful before updating the message), which incr= eases the likelihood of the send succeeding but the client losing the conne= ction for whatever reason and so never updating the message. At the moment, this is enabled by extra onCreateUpdateMessage and onDestroy= UpdateMessage arguments to the setMessageDeliveries method. They work like = this:For each successful create/destroy, the server should see if there is = an entry with the same id in the onCreateUpdateMessage/onDestroyUpdateMessa= ge properties respectively. If so, add an entry to an (initially empty) *up= date* object, with the key being the *messageId* on the MessageDelivery obj= ect that was created/destroyed, and the value being the value from the onCr= eateUpdateMessage/onDestroyUpdateMessage object.After the *messagesDeliveri= esSet* response is emitted, if the *update* object is not empty, an implici= t call is made to *setMessages*, with the following arguments: * *accountId*: Same as for the call to *setMessageDeliveries*. * *update*: The *update* object as calculated above. This is a little awkward, but I haven't managed to come up with a better wa= y of representing this ability. Any thoughts? Ideas for improvements? The full diff to the spec is available at https://github.com/jmapio/jmap/pu= ll/99. Looking forward to getting this worked out and done! Cheers, Neil. --_----------=_149914679723190961 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Hi all,

Hopefully we can get this area resolved by the end of the Prague meeti= ng, so I'm sending through a first draft for initial discussion. I think th= e proposal addresses the concerns that were raised by various people on the= list, while remaining consistent with the rest of JMAP.

Sending a message

The core idea is the introduction of a new MessageDelivery object type= . To send a message, you create a new MessageDelivery, which has the follow= ing properties:

  • id: String
    The id of the message delivery. This is server-set and immutable.
    <= /div>
  • messageId: String
    The id of the message to send. This is immutable. The message being se= nt does not have to be a draft, for example when =E2=80=9Credirecting=E2=80= =9D an existing message to a different email address.
  • threadId: String
    The thread id of the message to send. This is immutable and set by the= server to the threadId property of the message referenced by the messageId.

  • envelope: Envelope|null

    Informa= tion for use when sending via SMTP. This is immutable.

    An Envelope object has the following properties:

    • <= div>mailFrom: String
      The email address to use as the return address in the SMTP delivery. T= his
      may be the empty string.
    • rcptTo: String[]
      An array of email addresses to send the message to.

    If the envelope property is null or omitte= d on creation, the server MUST generate this from the referenced message as= follows:

    • mailFrom: The email in the From head= er, if present.
    • rcptTo: The deduplicated list of em= ails from the To, Cc and Bcc
      headers, if present.

  • sendAt: Date|Duration|null

    The date to release the message for delivery. This is immutable. The = server MUST override this property to the current date-time if the value gi= ven by the client is omitted, null, or in the past, or if the = server does not support delayed sending. If a duration is specified, the se= rver MUST set this property to the time of this duration from =E2=80=9Cnow= =E2=80=9D.
  • maybeCanUnsend: Boolean
    If true, attempting to unsend the message by destroying t= he MessageDelivery object, might succeed. This is server set. On sys= tems that do not support unsending, this will always be false.= On systems that do this, it will start as true, and MAY trans= ition to false when the server knows it definitely cannot reca= ll the message, but MAY just remain true.

Simple SMTP proxies would not store these objects, but more advanced s= ervers would allow you to retrieve them later, for example a client might f= etch a list of all the MessageDelivery objects with maybeCanUnsend =3D=3D t= rue, to present to the user messages they can still possibly cancel.

The MessageDelivery object also seems an ideal place to be able to put= delivery status for servers that support this, so clients can query for ea= ch email address the message was sent to, what happened (delivered? If not,= what was the error? Has it been read?). Any thoughts on whether this is a good = idea and what pieces of information should be represented?

Unsending a message

To unsend a message, you destroy the MessageDelivery object, using sta= ndard JMAP commands. If this succeeds, the delivery was successfully cancel= led. Otherwise you get an error.

Updating the message if the send/unsend is successful

We really want the ability to include in the same API command an updat= e to perform on the message if the send/unsend succeeds (i.e. the MessageDe= livery object is successfully created/destroyed). For example, remove the $= Draft flag and move the message to the sent folder.

Without this, you would need two round trips (the client would need to= wait to see if the send was successful before updating the message), which= increases the likelihood of the send succeeding but the client losing the = connection for whatever reason and so never updating the message.

At the moment, this is enabled by extra onCreateUpdateMessage and=  onDestroyUpdateMessage arguments to the setMessageDeliveries method. = They work like this:

For each successful create/destroy, the server should see if there is an= entry with the same id in the onCreateUpdateMessage/onDestroyUpdateMessage= properties respectively. If so, add an entry to an (initially empty) up= date object, with the key being the messageId on the MessageDeli= very object that was created/destroyed, and the value being the value from = the onCreateUpdateMessage/onDestroyUpdateMessage object.

After th= e messagesDeliveriesSet response is emitted, if the update ob= ject is not empty, an implicit call is made to setMessages, with the= following arguments:

  • accountId: Same as for the call= to setMessageDeliveries.
  • update: The update object as calculated above.

This is a= little awkward, but I haven't managed to come up with a better way of repr= esenting this ability. Any thoughts? Ideas for improvements?

The full diff to the spec is available at https://github.com/jmapio/jmap/pull/99. Loo= king forward to getting this worked out and done!

Cheers,
Neil.
--_----------=_149914679723190961-- From neilj@fastmailteam.com Mon Jul 3 18:38:48 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 6BF08131614 for ; Mon, 3 Jul 2017 18:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, 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 (2048-bit key) header.d=fastmailteam.com header.b=InpFA5pU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AKHHGJZh 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 UbGNtIWPDiW5 for ; Mon, 3 Jul 2017 18:38:46 -0700 (PDT) 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 B9C0712FEAA for ; Mon, 3 Jul 2017 18:38:46 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 11E6A20ADA for ; Mon, 3 Jul 2017 21:38:46 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Mon, 03 Jul 2017 21:38:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.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=fm1; bh=8Q2MDAzTtJAWRiIfF /nARHB+W7QSPGUfzqWEDm8QTNI=; b=InpFA5pU4h3Gy+51pFj3uJLL4t8y955Qj K7LwRwO77jM52Dt8YiNxQQHb/agIUEK09wL+OlN43Awfk6OjJjxnq/h8iDDzlfCz jwiMy8Dd2keafUYb5Z+OlWbXY+5f2kcQyo/w5QYslZQHbP82Sw1mnLcZJ9UZqre6 Qwx2cddy5lzCWOwYRC1Ep6/kqUMCXg63J93j8oyzhwXFEDDeyGTk8znHWYyF+L8w /E+zrqp2lqbX7c3fq8svP16oWAjV8G1umXzXz0R3E6xd9Htk73hg8refFqQQTds9 81rUxL+qaiZ0aQN3RRc903/v7TVrLL3IfMhIR4ZP40cQKHJT3YNpA== DKIM-Signature: v=1; a=rsa-sha256; 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=fm1; bh=8Q2MDA zTtJAWRiIfF/nARHB+W7QSPGUfzqWEDm8QTNI=; b=AKHHGJZhQRjMQc6qboVpxp KxwTPdeB/kNjAkuQx1DBenTW00v4VqqdwWuJmjMPmjnOigDAuzEfcMQjvRdOm3cR x59+oBBK0B9soTWvka1RBGnyW2rURj7mlq5OclueXGYRwfQUNjLEX6qkN2nEZwFY pbq7i7V9dMxGSF6U/OWMy2Xgullg0UV+StFhX6df35Rk5aLNrOA91USYRxsRredI iStSZe0u34sx5Po9w1OqBBKaRKhf5LJwcgIpcptZkJKq1KAkd+090jqlaEuIzqbg q6qpAM6jm+naKhKGya8RVdkkCiqWVD6GL8CktGd7hHXEiCamUU2b/DmyDkFNrf+g == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id D5804E2602; Mon, 3 Jul 2017 21:38:45 -0400 (EDT) Message-Id: <1499132325.2084597.1029563384.73833120@webmail.messagingengine.com> From: Neil Jenkins To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_149913232520845971" X-Mailer: MessagingEngine.com Webmail Interface - ajax-c528b28b In-Reply-To: <1487660969.1051.1499088574043@appsuite-dev.open-xchange.com> References: <1498017178.1304756.1016181400.0FCF0683@webmail.messagingengine.com> <04327CC4-3EB0-4C06-8CDF-774575D2C4C8@isode.com> <5bb947f1-738d-0dc1-781d-5e22750b94f7@dovecot.fi> <1487660969.1051.1499088574043@appsuite-dev.open-xchange.com> Date: Tue, 04 Jul 2017 11:38:45 +1000 Archived-At: X-Mailman-Approved-At: Mon, 03 Jul 2017 22:44:07 -0700 Subject: Re: [Jmap] JMAP Conceptual Decisions X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 01:39:24 -0000 This is a multi-part message in MIME format. --_----------=_149913232520845971 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Mon, 3 Jul 2017, at 11:29 PM, Aki Tuomi wrote: > The current JSON format looks like it has been designed to benefit jmap<->imap connector. No, it was primarily designed to minimise round trips and connection overhead, while maintaining consistency and usability. > I am not convinced at the moment that "request > bulking" actually provides such grand benefits, other than when you are> making such connector where the order of requests makes a difference when> sent to an IMAP server using IMAP protocol. In the "Structure of a request/response" section of my original email in this thread I gave an example where certain actions need to happen in a specific order to get the results the client wants. Round trip times (i.e. latency) make a huge difference in perceived performance, especially on mobile where even with good infrastructure your latency is higher. > Concurrent access should not be a problem for a well-designed server, so> one cannot really argue for ordering the requests either. Concurrent access is allowed with JMAP already. The issue is when you need to guarantee the order, as in the example above. Also, if you don't have HTTP2 you would be killed with the connection overhead at this point (you could easily get up to 100 requests needed just to show a list of the first 30 items in your Inbox once you have a separate one for each thread object, each mailbox object, each message in the threads etc.). Autogenerated java/python/ruby/whatever bindings would be nice, but I'm reasonably confident that people will write them anyway once JMAP is a full RFC; it would not be difficult to do so. Dealing with the performance problems of a protocol that assumes clients are always within 10ms RTT of the server though would be much harder. Neil. --_----------=_149913232520845971 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Mon, 3 Jul 2017, at 11:29 PM, Aki Tuomi wrote:
The current JSON format looks like it has been designed to benefit jmap<->imap connector.

No, it was primarily designed to minimise round trips and connection overhead, while maintaining consistency and usability.

I am not convinced at the moment that "request
bulking" actually provides such grand benefits, other than when you are
making such connector where the order of requests makes a difference when
sent to an IMAP server using IMAP protocol.

In the "Structure of a request/response" section of my original email in this thread I gave an example where certain actions need to happen in a specific order to get the results the client wants. Round trip times (i.e. latency) make a huge difference in perceived performance, especially on mobile where even with good infrastructure your latency is higher.

Concurrent access should not be a problem for a well-designed server, so
one cannot really argue for ordering the requests either.

Concurrent access is allowed with JMAP already. The issue is when you need to guarantee the order, as in the example above. Also, if you don't have HTTP2 you would be killed with the connection overhead at this point (you could easily get up to 100 requests needed just to show a list of the first 30 items in your Inbox once you have a separate one for each thread object, each mailbox object, each message in the threads etc.).

Autogenerated java/python/ruby/whatever bindings would be nice, but I'm reasonably confident that people will write them anyway once JMAP is a full RFC; it would not be difficult to do so. Dealing with the performance problems of a protocol that assumes clients are always within 10ms RTT of the server though would be much harder.

Neil.
--_----------=_149913232520845971-- From nobody Tue Jul 4 00:15:27 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 4EBB913193F for ; Tue, 4 Jul 2017 00:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.434 X-Spam-Level: * X-Spam-Status: No, score=1.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 OCmQ-CJ1Y2r7 for ; Tue, 4 Jul 2017 00:15:22 -0700 (PDT) Received: from smtp-out10-fallback.linagora.com (smtp-out10-fallback.linagora.com [109.197.179.15]) by ietfa.amsl.com (Postfix) with ESMTP id F10691318F5 for ; Tue, 4 Jul 2017 00:15:21 -0700 (PDT) Received: from smtp.linagora.com (smtp.linagora.dc1 [172.16.18.53]) by smtp-out10-fallback.linagora.com (Postfix) with ESMTP id 220AC1005DD2 for ; Tue, 4 Jul 2017 09:15:20 +0200 (CEST) Received: from [192.168.11.172] (unknown [118.70.135.8]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.linagora.com (Postfix) with ESMTPSA id 7EC9865B for ; Tue, 4 Jul 2017 09:15:18 +0200 (CEST) To: jmap@ietf.org References: <1499146797.2319096.1029695160.34130D2D@webmail.messagingengine.com> From: Benoit Tellier Message-ID: Date: Tue, 4 Jul 2017 14:15:15 +0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <1499146797.2319096.1029695160.34130D2D@webmail.messagingengine.com> Content-Type: multipart/alternative; boundary="------------827083EF0B7B8A86969805E7" Content-Language: en-US Archived-At: Subject: Re: [Jmap] New message sending API proposal X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 07:15:25 -0000 This is a multi-part message in MIME format. --------------827083EF0B7B8A86969805E7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Neil, First thank you for your great proposal, and also for your pull request on the specs. My answers will be inlined. Cheers, Benoit Le 04/07/2017 à 12:39, Neil Jenkins a écrit : > Hi all, > > Hopefully we can get this area resolved by the end of the Prague > meeting, so I'm sending through a first draft for initial discussion. > I think the proposal addresses the concerns that were raised by > various people on the list, while remaining consistent with the rest > of JMAP. > > *Sending a message* > > The core idea is the introduction of a new MessageDelivery object > type. To send a message, you create a new MessageDelivery, which has > the following properties: > > * > *id*: |String| > The id of the message delivery. This is server-set and immutable. > * > *messageId*: |String| > The id of the message to send. This is immutable. The message > being sent does not have to be a draft, for example when > “redirecting” an existing message to a different email address. > * > *threadId*: |String| > The thread id of the message to send. This is immutable and set by > the server to the /threadId/ property of the message referenced by > the /messageId/. > * > > *envelope*: |Envelope|null| > > Information for use when sending via SMTP. This is immutable. > > An *Envelope* object has the following properties: > > o > *mailFrom*: |String| > The email address to use as the return address in the SMTP > delivery. This > may be the empty string. > o > *rcptTo*: |String[]| > An array of email addresses to send the message to. > > If the /envelope/ property is |null| or omitted on creation, the > server MUST generate this from the referenced message as follows: > > o *mailFrom*: The email in the /From/ header, if present. > o > *rcptTo*: The deduplicated list of emails from the /To/, /Cc/ > and /Bcc/ > headers, if present. > * > > *sendAt*: |Date|Duration|null| > > The date to release the message for delivery. This is immutable. > The server MUST override this property to the current date-time if > the value given by the client is omitted, |null|, or in the past, > or if the server does not support delayed sending. If a duration > is specified, the server MUST set this property to the time of > this duration from “now”. > * > *maybeCanUnsend*: |Boolean| > If |true|, attempting to unsend the message by destroying the > MessageDelivery object, /might/ succeed. This is server set. On > systems that do not support unsending, this will always be > |false|. On systems that do this, it will start as |true|, and MAY > transition to |false| when the server knows it definitely cannot > recall the message, but MAY just remain |true|. > > > Simple SMTP proxies would not store these objects, but more advanced > servers would allow you to retrieve them later, for example a client > might fetch a list of all the MessageDelivery objects with > maybeCanUnsend == true, to present to the user messages they can still > possibly cancel. > > The MessageDelivery object also seems an ideal place to be able to put > delivery status for servers that support this, so clients can query > for each email address the message was sent to, what happened > (delivered? If not, what was the error? Has it been read?). Any > thoughts on whether this is a good idea and what pieces of information > should be represented? We need to specify in my opinion the *identity* we should use as a sender (http://jmap.io/spec-mail.html#identities) > > *Unsending a message* > > To unsend a message, you destroy the MessageDelivery object, using > standard JMAP commands. If this succeeds, the delivery was > successfully cancelled. Otherwise you get an error. > > *Updating the message if the send/unsend is successful* > > We really want the ability to include in the same API command an > update to perform on the message if the send/unsend succeeds (i.e. the > MessageDelivery object is successfully created/destroyed). For > example, remove the $Draft flag and move the message to the sent folder. > > Without this, you would need two round trips (the client would need to > wait to see if the send was successful before updating the message), > which increases the likelihood of the send succeeding but the client > losing the connection for whatever reason and so never updating the > message. > > At the moment, this is enabled by extra onCreateUpdateMessage > and onDestroyUpdateMessage arguments to the setMessageDeliveries > method. They work like this: > > For each successful create/destroy, the server should see if there is > an entry with the same id in the > onCreateUpdateMessage/onDestroyUpdateMessage properties respectively. > If so, add an entry to an (initially empty) /update/ object, with the > key being the /messageId/ on the MessageDelivery object that was > created/destroyed, and the value being the value from the > onCreateUpdateMessage/onDestroyUpdateMessage object. > > After the /messagesDeliveriesSet/ response is emitted, if the /update/ > object is not empty, an implicit call is made to /setMessages/, with > the following arguments: > > * *accountId*: Same as for the call to /setMessageDeliveries/. > * *update*: The /update/ object as calculated above. > > > This is a little awkward, but I haven't managed to come up with a > better way of representing this ability. Any thoughts? Ideas for > improvements? IMO overall OK, we just need to be also able to expose a method allowing the client to destroy a message sent successfully/sent fail > > The full diff to the spec is available > at https://github.com/jmapio/jmap/pull/99. Looking forward to getting > this worked out and done! > > Cheers, > Neil. > > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap --------------827083EF0B7B8A86969805E7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Neil,

First thank you for your great proposal, and also for your pull request on the specs.

My answers will be inlined.

Cheers,

Benoit


Le 04/07/2017 à 12:39, Neil Jenkins a écrit :
Hi all,

Hopefully we can get this area resolved by the end of the Prague meeting, so I'm sending through a first draft for initial discussion. I think the proposal addresses the concerns that were raised by various people on the list, while remaining consistent with the rest of JMAP.

Sending a message

The core idea is the introduction of a new MessageDelivery object type. To send a message, you create a new MessageDelivery, which has the following properties:

  • id: String
    The id of the message delivery. This is server-set and immutable.
  • messageId: String
    The id of the message to send. This is immutable. The message being sent does not have to be a draft, for example when “redirecting” an existing message to a different email address.
  • threadId: String
    The thread id of the message to send. This is immutable and set by the server to the threadId property of the message referenced by the messageId.

  • envelope: Envelope|null

    Information for use when sending via SMTP. This is immutable.

    An Envelope object has the following properties:

    • mailFrom: String
      The email address to use as the return address in the SMTP delivery. This
      may be the empty string.
    • rcptTo: String[]
      An array of email addresses to send the message to.

    If the envelope property is null or omitted on creation, the server MUST generate this from the referenced message as follows:

    • mailFrom: The email in the From header, if present.
    • rcptTo: The deduplicated list of emails from the To, Cc and Bcc
      headers, if present.

  • sendAt: Date|Duration|null

    The date to release the message for delivery. This is immutable. The server MUST override this property to the current date-time if the value given by the client is omitted, null, or in the past, or if the server does not support delayed sending. If a duration is specified, the server MUST set this property to the time of this duration from “now”.
  • maybeCanUnsend: Boolean
    If true, attempting to unsend the message by destroying the MessageDelivery object, might succeed. This is server set. On systems that do not support unsending, this will always be false. On systems that do this, it will start as true, and MAY transition to false when the server knows it definitely cannot recall the message, but MAY just remain true.

Simple SMTP proxies would not store these objects, but more advanced servers would allow you to retrieve them later, for example a client might fetch a list of all the MessageDelivery objects with maybeCanUnsend == true, to present to the user messages they can still possibly cancel.

The MessageDelivery object also seems an ideal place to be able to put delivery status for servers that support this, so clients can query for each email address the message was sent to, what happened (delivered? If not, what was the error? Has it been read?). Any thoughts on whether this is a good idea and what pieces of information should be represented?

We need to specify in my opinion the identity we should use as a sender (http://jmap.io/spec-mail.html#identities)

Unsending a message

To unsend a message, you destroy the MessageDelivery object, using standard JMAP commands. If this succeeds, the delivery was successfully cancelled. Otherwise you get an error.

Updating the message if the send/unsend is successful

We really want the ability to include in the same API command an update to perform on the message if the send/unsend succeeds (i.e. the MessageDelivery object is successfully created/destroyed). For example, remove the $Draft flag and move the message to the sent folder.

Without this, you would need two round trips (the client would need to wait to see if the send was successful before updating the message), which increases the likelihood of the send succeeding but the client losing the connection for whatever reason and so never updating the message.

At the moment, this is enabled by extra onCreateUpdateMessage and onDestroyUpdateMessage arguments to the setMessageDeliveries method. They work like this:

For each successful create/destroy, the server should see if there is an entry with the same id in the onCreateUpdateMessage/onDestroyUpdateMessage properties respectively. If so, add an entry to an (initially empty) update object, with the key being the messageId on the MessageDelivery object that was created/destroyed, and the value being the value from the onCreateUpdateMessage/onDestroyUpdateMessage object.

After the messagesDeliveriesSet response is emitted, if the update object is not empty, an implicit call is made to setMessages, with the following arguments:

  • accountId: Same as for the call to setMessageDeliveries.
  • update: The update object as calculated above.

This is a little awkward, but I haven't managed to come up with a better way of representing this ability. Any thoughts? Ideas for improvements?
IMO overall OK, we just need to be also able to expose a method allowing the client to destroy a message sent successfully/sent fail

The full diff to the spec is available at https://github.com/jmapio/jmap/pull/99. Looking forward to getting this worked out and done!

Cheers,
Neil.


_______________________________________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/mailman/listinfo/jmap

--------------827083EF0B7B8A86969805E7-- From nobody Tue Jul 4 01:49:46 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 76C85131B9B for ; Tue, 4 Jul 2017 01:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 D9tT8WUiq0tf for ; Tue, 4 Jul 2017 01:49:42 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 91B06131B9A for ; Tue, 4 Jul 2017 01:49:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1499158180; d=isode.com; s=june2016; i=@isode.com; bh=/WjegB0uzBfRCKMk+YxWt6o0KmH7S2LJXkyS8vB136c=; 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=oIfNb8P/wqmMowj9eHsvIFALmTO923jBzD/d9UH5miMo/SioaHnQhmfxYHjW9wvXVdzaLm +065gWIizl8awJsXaXPGGOkLjKzmyyASurVq7KFuNFMnwR5fPBx0GNAWAOxNFuhzAmbHHJ mZeEUG6P1AsW8w2AWEC+0wOfirjjI4A=; 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 ; Tue, 4 Jul 2017 09:49:40 +0100 To: Neil Jenkins , jmap@ietf.org References: <1499146797.2319096.1029695160.34130D2D@webmail.messagingengine.com> From: Alexey Melnikov Message-ID: Date: Tue, 4 Jul 2017 09:49:28 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 In-Reply-To: <1499146797.2319096.1029695160.34130D2D@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------A5E843C3DD6ED24ED73A9888" Content-Language: en-US Archived-At: Subject: Re: [Jmap] New message sending API proposal X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 08:49:45 -0000 --------------A5E843C3DD6ED24ED73A9888 Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable Hi Neil, Mostly good. A few minor comments below: On 04/07/2017 06:39, Neil Jenkins wrote: > Hi all, > > Hopefully we can get this area resolved by the end of the Prague=20 > meeting, so I'm sending through a first draft for initial discussion.=20 > I think the proposal addresses the concerns that were raised by=20 > various people on the list, while remaining consistent with the rest=20 > of JMAP. > > *Sending a message* > > The core idea is the introduction of a new MessageDelivery object=20 > type. To send a message, you create a new MessageDelivery, which has=20 > the following properties: > > * > *id*: |String| > The id of the message delivery. This is server-set and immutable. > * > *messageId*: |String| > The id of the message to send. This is immutable. The message > being sent does not have to be a draft, for example when > =E2=80=9Credirecting=E2=80=9D an existing message to a different email= address. > * > *threadId*: |String| > The thread id of the message to send. This is immutable and set by > the server to the /threadId/ property of the message referenced by > the /messageId/. > This is not very clear to me. Are replies to earlier messages share=20 threadid with them? > > * > > *envelope*: |Envelope|null| > > Information for use when sending via SMTP. This is immutable. > > An *Envelope* object has the following properties: > > o > *mailFrom*: |String| > The email address to use as the return address in the SMTP > delivery. This > may be the empty string. > o > *rcptTo*: |String[]| > An array of email addresses to send the message to. > > If the /envelope/ property is |null| or omitted on creation, the > server MUST generate this from the referenced message as follows: > > o *mailFrom*: The email in the /From/ header, if present. > I think this is the email from the Sender header field, if present.=20 Falling back to the From otherwise. We probably need to say something=20 about multiple From addresses here. > > * > o > *rcptTo*: The deduplicated list of emails from the /To/, /Cc/ > and /Bcc/ > headers, if present. > * > > *sendAt*: |Date|Duration|null| > > The date to release the message for delivery. This is immutable. > The server MUST override this property to the current date-time if > the value given by the client is omitted, |null|, or in the past, > or if the server does not support delayed sending. If a duration > is specified, the server MUST set this property to the time of > this duration from =E2=80=9Cnow=E2=80=9D. > * > *maybeCanUnsend*: |Boolean| > If |true|, attempting to unsend the message by destroying the > MessageDelivery object, /might/ succeed. This is server set. On > systems that do not support unsending, this will always be > |false|. On systems that do this, it will start as |true|, and MAY > transition to |false| when the server knows it definitely cannot > recall the message, but MAY just remain |true|. > > > Simple SMTP proxies would not store these objects, but more advanced=20 > servers would allow you to retrieve them later, for example a client=20 > might fetch a list of all the MessageDelivery objects with=20 > maybeCanUnsend =3D=3D true, to present to the user messages they can still= =20 > possibly cancel. > > The MessageDelivery object also seems an ideal place to be able to put=20 > delivery status for servers that support this, so clients can query=20 > for each email address the message was sent to, what happened=20 > (delivered? If not, what was the error? Has it been read?). Any=20 > thoughts on whether this is a good idea and what pieces of information=20 > should be represented? I think it would be useful. Information that would be useful: SMTP error=20 code (per each recipient or a global one for the whole message (e.g. if=20 MAIL FROM was rejected), SMTP Enhanced Status codes (if available),=20 Error text. Some of these can also be synthesized by the JMAP server,=20 for example if a recipient's domain can't be resolved using DNS. --------------A5E843C3DD6ED24ED73A9888 Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

Hi Neil,

Mostly good. A few minor comments below:


On 04/07/2017 06:39, Neil Jenkins wrote:
Hi all,

Hopefully we can get this area resolved by the end of the Prague meeting, so I'm sending through a first draft for initial discussion. I think the proposal addresses the concerns that were raised by various people on the list, while remaining consistent with the rest of JMAP.

Sending a message

The core idea is the introduction of a new MessageDelivery object type. To send a message, you create a new MessageDelivery, which has the following properties:

  • id: String
    The id of the message delivery. This is server-set and immutable.
  • messageId: String
    The id of the message to send. This is immutable. The message being sent does not have to be a draft, for example when =E2=80=9Credirecting=E2=80=9D an existing message to a diff= erent email address.
  • threadId: String
    The thread id of the message to send. This is immutable and set by the server to the threadId property of the message referenced by the messageId.
This is not very clear to me. Are replies to earlier messages share threadid with them?

  • envelope: Envelope|null

    Information for use when sending via SMTP. This is immutable.

    An Envelope object has the following properties:

    • mailFrom: String
      The email address to use as the return address in the SMTP delivery. This
      may be the empty string.
    • rcptTo: String[]
      An array of email addresses to send the message to.

    If the envelope property is null or omitted on creation, the server MUST generate this from the referenced message as follows:

    • mailFrom: The email in the From header, if present.
I think this is the email from the Sender header field, if present. Falling back to the From otherwise. We probably need to say something about multiple From addresses here.
    • rcptTo: The deduplicated list of emails from the To, Cc and Bcc
      headers, if present.

  • sendAt: Date|Duration|null

    The date to release the message for delivery. This is immutable. The server MUST override this property to the current date-time if the value given by the client is omitted, null, or in the past, or if the server does not support delayed sending. If a duration is specified, the server MUST set this property to the time of this duration from =E2=80=9Cnow=E2=80=9D.
  • maybeCanUnsend: Boolean
    If true, attempting to unsend the message by destroying the MessageDelivery object, might succeed. This is server set. On systems that do not support unsending, this will always be false. On systems that do this, it will start as true, and MAY transition to false when the server knows it definitely cannot recall the message, but MAY just remain true.

Simple SMTP proxies would not store these objects, but more advanced servers would allow you to retrieve them later, for example a client might fetch a list of all the MessageDelivery objects with maybeCanUnsend =3D=3D true, to present to the user messages they can still possibly cancel.

The MessageDelivery object also seems an ideal place to be able to put delivery status for servers that support this, so clients can query for each email address the message was sent to, what happened (delivered? If not, what was the error? Has it been read?). Any thoughts on whether this is a good idea and what pieces of information should be represented?

I think it would be useful. Information that would be useful: SMTP error code (per each recipient or a global one for the whole message (e.g. if MAIL FROM was rejected), SMTP Enhanced Status codes (if available), Error text. Some of these can also be synthesized by the JMAP server, for example if a recipient's domain can't be resolved using DNS.

--------------A5E843C3DD6ED24ED73A9888-- From nobody Tue Jul 4 18:53:21 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 AA2D01204DA for ; Tue, 4 Jul 2017 18:14:16 -0700 (PDT) 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, 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 2k3NCSMk-dLX for ; Tue, 4 Jul 2017 18:14:15 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (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 935621242F7 for ; Tue, 4 Jul 2017 18:14:14 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id b207so125719139lfg.2 for ; Tue, 04 Jul 2017 18:14:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=tKsIXlb9phcfIGepU3a9AkIcVEoToTxu+sXlN+fb//g=; b=V5XN5KPycsq3VMvo3O+uVqJmXASgwWQ3eR+U2/gRC/k96Q8iqQdDNJkGED7j4/WAtB YpWdlrYd4afz/NXcR/Vu+M8xd4ry1CeHLpZJrtmFmMJW4qckfEBdoKrocfXOrwij+kGw +NTqK5lSMCPlUuEGWZwIGRFFbmVv3xLAMEhHAG6yt3EoSKZd1t4yI6wUOQee1tJXCc4a 2XNsOq5XV0EKbUtTuU/Fpiip2VNYAQr/gefZ6WP9/fEgcfWq9FKl5Ml/zUVEXqFFVxb1 V+1u7Bb4ksq9dFk77YwdPDcklA39EvfZqU6D4zPj+tjG8nwHwrg6ktgDCFCCk+rEstYb Te6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=tKsIXlb9phcfIGepU3a9AkIcVEoToTxu+sXlN+fb//g=; b=EJ+TPl0ySUyaH05bUm+ma4/M7nwcK0rl8sP421Iafb6mXQBpn92Do3Oift4+DJ8MQj KIM8KlY7MRSftvCgiaRMqDWUnza5qIJQhK/E461hTbdqT8eq4R95st9KhyeRPLxqarBk TzAAW/0lOALzDDBGeoSSV9bv2VW+Ft+CN3awS9hrJQbxUQzGWqAkQDZbslp3y+xpdq4u of0OMHnnJHZexCQN0+rcsIy4BZFIkcxemGmg/TnV/65Extq0teYyP9yTSJpLByaxMP4M 43t+YNXqi7nktR4xmYLZEvcmhfkkizk64ic8/hz61Txggw/FWTZmajeddJu05yaY0hsY E3TQ== X-Gm-Message-State: AKS2vOzUpyRDEEvbyU/TAXvxElIxWztEONRJsEsv+lbBYzR+Xv63DFF+ VH9+bkUEhKEtdv0C3B75uzB2eh1UX7E7LUE= X-Received: by 10.25.29.16 with SMTP id d16mr14075774lfd.50.1499217252581; Tue, 04 Jul 2017 18:14:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.69.84 with HTTP; Tue, 4 Jul 2017 18:14:12 -0700 (PDT) From: Martin Thomson Date: Wed, 5 Jul 2017 11:14:12 +1000 Message-ID: To: jmap@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: X-Mailman-Approved-At: Tue, 04 Jul 2017 18:53:20 -0700 Subject: [Jmap] Feedback on draft-ietf-jmap-core X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 01:14:17 -0000 This is an enormous document. I think that the working group would do well to remember that the size of a document is inversely proportional to the chance that it will be completed, or implemented, or even implemented correctly, or especially implemented interoperably. I can see several ways in which this might be reduced in different ways. 1. Remove the bespoke authentication process. HTTP has several options available and many APIs don't require the use of those methods to operate correctly. I was shocked to see that the scheme defined in the document even includes request signing, which has not been successfully standardized yet. (I can go into the long history of these failures separately.) 2. Specify actions in terms of document formats and the semantics of the fields. See (for example) https://www.mnot.net/blog/2017/05/11/status_codes for more information on why the extensive reinterpretation of HTTP status codes that the current draft does is inadvisable. 3. Use HTTP. This has many aspects, but the most immediate concern is the use of a RPC-like structure for making requests. I was told when this group was being chartered that this had good reasons for existence. I don't remember precisely, but I think that it was something about having requests that depended on other requests and that performance was bad. Either way, we should discuss these constraints more and see if there isn't a better solution. 4. Don't use EventSource. Use HTTP/2 push if you need this sort of functionality, or simple long polling. Those things no longer cost what they used to. 5. Don't use callbacks. Client reachability isn't consistent. Finally, I think that there is little benefit to having a "core" protocol definition for JMAP. Many of the functions that are provided in the document are better provided with native HTTP functions. For instance, there are well established patterns for providing CRUD semantics in HTTP. You can look at the WebDAV or even Atompub specifications for worked examples. From nobody Tue Jul 4 21:57: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 76294124C27 for ; Tue, 4 Jul 2017 21:57:34 -0700 (PDT) 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, 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 (2048-bit key) header.d=fastmailteam.com header.b=OI9VtDGS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ocBTvr6g 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 8qNPD_7buV7T for ; Tue, 4 Jul 2017 21:57:31 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57C50126C23 for ; Tue, 4 Jul 2017 21:57:31 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 997022098B for ; Wed, 5 Jul 2017 00:57:30 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Wed, 05 Jul 2017 00:57:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.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=fm1; bh=0adNyhyXxa0WNGpWP PfcF8RhY+lvLFR7GXCwBpLOvb8=; b=OI9VtDGSz7KSrAPClUhMQqrW4hmn8TQx5 LRUQ1hIQs81PoOw+3bV3FbtVVlrwrhRgTgQIiu2oD6mkCbbCEO8O/vIU8oA91VgG 8AtAowkaJcKF4m8TfO25BHuAruFbQ/KKelxEIU04cyRTcV54qQXhLNQAnzdthPxd ecsQrMq4eWDrjx9M9gKbimV9IiPLezpTnKr73nIWwCiysic68RLlVKlkkRmdWKsj TGKWQZtOyjruOV/MOmxt4GQTex3vTXVReT+z9wbFknIxIoIpOH/8hja63YxpOzbP 8fCnZc0OTintrna+hxmFd48E3gHJKHML7RP3KQevOhiWeo/HIAg3g== DKIM-Signature: v=1; a=rsa-sha256; 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=fm1; bh=0adNyh yXxa0WNGpWPPfcF8RhY+lvLFR7GXCwBpLOvb8=; b=ocBTvr6gZkAW+eKUULhBX/ 4c0Dh4/qToL7olxTfBtDMAdwczkmh/+718251oq8H0ZyqTaRfGMTqq8y9NJPgVCL RAy75xCj47ZB00fp4QdzWP9O/dPgkdAkNH98MZ4kjAmF0hMTVSJ8zXCydWtRnQYK gMTxE82QAUcLeGaP0B0SkBwJ6++rs+EqoRnhgcSh7y8lPXx445p5I+TNhB9HCR4n oNgoKRv5WKX5JkNSUEUgXXT0F9EBk6fgQAmAeiES+7xZLK5EBMN2Xfs5Tzxyicd9 iuq3/d73oaf2stX27VSjY6Kbky+pGI/eA1IG6TFFBBkjjkV+PEg3PoQk51zCmSqg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 46D90E26A2; Wed, 5 Jul 2017 00:57:30 -0400 (EDT) Message-Id: <1499230650.3642220.1030669400.4800D481@webmail.messagingengine.com> From: Neil Jenkins To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_149923065036422203" X-Mailer: MessagingEngine.com Webmail Interface - ajax-c528b28b In-Reply-To: References: Date: Wed, 05 Jul 2017 14:57:30 +1000 Archived-At: Subject: Re: [Jmap] Feedback on draft-ietf-jmap-core X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 04:57:34 -0000 This is a multi-part message in MIME format. --_----------=_149923065036422203 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi Martin > This is an enormous document. I think that the working group would do> w= ell to remember that the size of a document is inversely proportional> to t= he chance that it will be completed, or implemented, or even > implemented correctly There are already several fairly complete implementations of the draft that= I'm aware of. Length is not necessarily a proxy for complexity (the additi= on of further examples will lengthen the document, but make it quicker to g= rok). I believe the plan for a test suite to accompany the spec is likely t= o have far more relevance to correct/interoperable implementations than pur= ely the length of the spec. > 1. Remove the bespoke authentication process. HTTP has several options a= vailable The trouble is: * Basic auth: is essentially deprecated in this space. Gmail, FastMail, iC= loud and I'm sure a growing number of others do not allow users to log in t= o IMAP (for example) with just a regular username/password. * OAuth: generally requires clients to register with each service in advan= ce before you can have an authentication flow. This is fine if you are writ= ing a Twitter client for the Twitter API, but impossible to do for the mill= ions of different mail services out there, any one of which a random user e= xpects to be able to connect to. This is possibly addressed by OAuth 2.0 Dy= namic Client Registration Protocol (RFC7591[1]); I'll have to read more of = the details, but I'm dubious this reduces complexity for implementors. Ideally, I think the authentication scheme needs to meet the following crit= eria: * Is session based (creates an authentication token rather than allowing u= sername/password directly). * Does not require the client writer to have manually registered with the = JMAP server. * Allows common 2FA factors to be used (e.g. TOTP, U2F). * Be extensible with further authentication mechanisms in the future. * Doesn't require a browser in order to preform authentication. If you have a suggestion of an existing authentication scheme that meets th= ese criteria, we should look at that. > I was shocked to see that the scheme defined in the document even include= s request signing, which has not been> successfully standardized yet. (I c= an go into the long history of these failures separately.) This is only used to allow UAs to issue GET requests for blobs (files, atta= chments etc.) without setting an Authorization header. This allows you to b= uild a full JMAP client in a browser (where for example you cannot add an A= uthorization header to the HTTP request resulting from setting a src attrib= ute on an ), and probably simplifies other environments too. The request signing uses JWTs as specified in RFC7519; I was not aware ther= e is separate work going on to standardise the combination of this with URL= s, which seems possibly overkill given it's fairly simple scheme. If you believe the specified method does not provide the desired functional= ity, or has a security issue that needs to be addressed, then this would be= valuable feedback. Making vague references about being shocked is not. > 2. Specify actions in terms of document formats and the semantics of > the fields. [=E2=80=A6] > 3. Use HTTP. This has many aspects, but the most immediate concern is> t= he use of a RPC-like structure for making requests. I explained the technical decisions behind this in the "Structure of a requ= est/response" part of my email "JMAP Conceptual Decisions", a few weeks ago= . If you missed it, a plain-text copy is available in the IETF archive at h= ttps://mailarchive.ietf.org/arch/msg/jmap/SfCe3UJPEEUdeomeso_-PAzP5tQ =E2= =80=93 please address the rationale/example there directly. > 4. Don't use EventSource. Use HTTP/2 push if you need this sort of > functionality, or simple long polling. Those things no longer cost > what they used to. The EventSource part can easily be made to support long-polling instead at = the option of the client (the only difference being it closes the connectio= n after every push). Having a direct way for clients that are able to hold = open connections get push notifications without requiring their own push se= rver (see below) is still a good thing to have IMO. > 5. Don't use callbacks. Client reachability isn't consistent. I presume this is referring to the Web Hook part of the push section of the= spec, as this is the only place this word is mentioned. I'm not sure exact= ly what you mean by "client reachability isn't consistent", but the intenti= on here (with a few header changes still required) is that the JMAP server = is an RFC8030 compliant "Application Server". UAs can (with their own Push = Server) use the rest of 8030 to provide push, or integrate their own mechan= ism with this to receive push notifications (for example Apple last time I = spoke to them were not interested in using 8030 directly, but could still i= ntegrate this with their APNS system). Regards, Neil. Links: 1. https://tools.ietf.org/html/rfc7591 --_----------=_149923065036422203 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Hi Martin

This is an enormous document.  I think = that the working group would do
well to remember that the size of a document is inversely proportional=
to the chance that it will be completed, or implemented, or even
implemented correctly

There are already several fairly complete implementations of the draft= that I'm aware of. Length is not necessarily a proxy for complexity (the a= ddition of further examples will lengthen the document, but make it quicker= to grok). I believe the plan for a test suite to accompany the spec is lik= ely to have far more relevance to correct/interoperable implementations tha= n purely the length of the spec.

1. Remove the bespoke authentication process= .  HTTP has several options available

The trouble is:
  • Basic auth: is essentially deprecated in this space. Gmail, FastMai= l, iCloud and I'm sure a growing number of others do not allow users to log= in to IMAP (for example) with just a regular username/password.
    • OAuth: generally requires clients to register with each service in advanc= e before you can have an authentication flow. This is fine if you are writi= ng a Twitter client for the Twitter API, but impossible to do for the milli= ons of different mail services out there, any one of which a random user ex= pects to be able to connect to. This is possibly addressed by OAuth 2.0 Dyn= amic Client Registration Protocol (RFC7591); I'll have to read more of the details, but I'm dubiou= s this reduces complexity for implementors.

Ideally, I think the authentication scheme needs to meet the following= criteria:
  • Is session based (creates an authentication token rather than allow= ing username/password directly).
  • Does not require the client wr= iter to have manually registered with the JMAP server.
  • Allows c= ommon 2FA factors to be used (e.g. TOTP, U2F).
  • Be extensible wi= th further authentication mechanisms in the future.
  • Doesn't req= uire a browser in order to preform authentication.

If you have a suggestion of an existing authentication scheme that mee= ts these criteria, we should look at that.

I was shocked to see that the scheme defined= in the document even includes request signing, which has not been
successfully standardized yet.  (I can go into the long history o= f these failures separately.)

This is only used to allow UAs to issue GET requests for blobs (files,= attachments etc.) without setting an Authorization header. This allows you= to build a full JMAP client in a browser (where for example you cannot add= an Authorization header to the HTTP request resulting from setting a src a= ttribute on an <img>), and probably simplifies other environments too= .

The request signing uses JWTs as specified in RFC7519; I was not aware= there is separate work going on to standardise the combination of this wit= h URLs, which seems possibly overkill given it's fairly simple scheme.
<= /div>

If you believe the specified method does not provide the desired funct= ionality, or has a security issue that needs to be addressed, then this wou= ld be valuable feedback. Making vague references about being shocked is not= .

2. Specify actions in terms of document form= ats and the semantics of
the fields. [=E2=80=A6]
3. Use HTTP.  This has many aspects, but the most immediate conce= rn is
the use of a RPC-like structure for making requests.

I explained the technical decisions behind this in the "Structure of a= request/response" part of my email "JMAP Conceptual Decisions", a few week= s ago. If you missed it, a plain-text copy is available in the IETF archive= at https://mailarchive.ietf.org/arch/msg/jmap/SfCe3UJPEEUdeom= eso_-PAzP5tQ =E2=80=93 please address the rationale/example there = directly.

4. Don't use EventSource.  Use HTTP/2 p= ush if you need this sort of
functionality, or simple long polling.  Those things no longer co= st
what they used to.

The EventSource part can easily be made to support long-polling instea= d at the option of the client (the only difference being it closes the conn= ection after every push). Having a direct way for clients that are able to = hold open connections get push notifications without requiring their own pu= sh server (see below) is still a good thing to have IMO.

5. Don't use callbacks.  Client reachab= ility isn't consistent.

I presume this is referring to the Web Hook part of the push section o= f the spec, as this is the only place this word is mentioned. I'm not sure = exactly what you mean by "client reachability isn't consistent", but the in= tention here (with a few header changes still required) is that the JMAP se= rver is an RFC8030 compliant "Application Server". UAs can (with their own = Push Server) use the rest of 8030 to provide push, or integrate their own m= echanism with this to receive push notifications (for example Apple last ti= me I spoke to them were not interested in using 8030 directly, but could st= ill integrate this with their APNS system).

Regards,
Neil.
--_----------=_149923065036422203-- From nobody Tue Jul 4 23:18:19 2017 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB03129B8C for ; Tue, 4 Jul 2017 23:18:18 -0700 (PDT) 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, 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=fastmailteam.com header.b=WQ01Qn1e; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BTyaPYdT 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 gk7qQmp8Kz4t for ; Tue, 4 Jul 2017 23:18:15 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D117128B88 for ; Tue, 4 Jul 2017 23:18:15 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 686BE20950 for ; Wed, 5 Jul 2017 02:18:14 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Wed, 05 Jul 2017 02:18:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.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=fm1; bh=wI5mZBc2wlIKL1rUY olO1YryaZfVgxuIGORSFNlfhLs=; b=WQ01Qn1eewJ02URkmRNiKOEqRO/cFyJD3 TIcAL0TG4T+1SGjY+6G59vElFxmUY9fHi/qiF6ApnAonKzLpk6Gp2Wfe7eLI5a9u Ungg0h8PwpXUyG0Uj5DAZFswx1iWCs0pEJqMYjiZjCLWH8tbt4tKLPNTIqhlETOx mYjF1vqZzmZfdwZbVNnib3f9A2nQCWUrk6xZ5OiL4ncSGMQ/ZtbU2ActGNRyUyAD QsiF45G1r5VGJb4fZ9/HVqb/PU2Y3HOx8DzIkEqNVQQCPmK5JNAAAwQCwkhkrbWE QDELCdpXqB7f20xDQ4U2V/goddYuosFW0PX2bToe5u/f9DR5KFtuQ== DKIM-Signature: v=1; a=rsa-sha256; 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=fm1; bh=wI5mZB c2wlIKL1rUYolO1YryaZfVgxuIGORSFNlfhLs=; b=BTyaPYdTycz3MgPqims5VE x4A9AG1rOL6hcJ0B/5t/tQFMOojmB1x+msz1hembuogRXPCSDvSTULjz8xt0K7Wj /B327aaK63RlGDdGF48w3kRBLDsA1ArOQj1DezNrCdXBlW0tJBof9OOXF3vm1SjO xslkJDgUcqvHP621covtRlsbVmaiePLp7xfoDNmRiQ/lEf9fkuQzXaIsqsJTz1bL 940Vq0mAPAFUEgbRCB8MFzfv2Hqre0hp91VKU3zEfxxL2PM5LXGWOpVmAnG7jpWN hG9OE9FUKV5WXGdxBev1gsaxY0mzFFpozZJQ5W6j25Fq5qQW1V0i3NpiZ/b+BS8g == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 16FB0E20E7; Wed, 5 Jul 2017 02:18:14 -0400 (EDT) Message-Id: <1499235493.3723325.1030693648.59277255@webmail.messagingengine.com> From: Neil Jenkins To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_149923549437233251" X-Mailer: MessagingEngine.com Webmail Interface - ajax-c528b28b References: <1499146797.2319096.1029695160.34130D2D@webmail.messagingengine.com> In-Reply-To: Date: Wed, 05 Jul 2017 16:18:13 +1000 Archived-At: Subject: Re: [Jmap] New message sending API proposal X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 06:18:18 -0000 This is a multi-part message in MIME format. --_----------=_149923549437233251 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Tue, 4 Jul 2017, at 05:15 PM, Benoit Tellier wrote: > We need to specify in my opinion the identity we should use as a sender (http://jmap.io/spec-mail.html#identities) I think I agree, although I'm not sure whether this should be optional? At the moment, none of the properties on the Identity object affect how the server handles the message; they just let the client know what email addresses the user has, and what defaults to use for various properties in a new message from those identities. However, some servers may end up doing different things depending on the identity, and matching just based on the From address is not necessarily possible if there are multiple identities that match the address. There's also the case of redirecting mail (although how long this will be possible for in our DMARC future I don't know). In this case you didn't write the message, and so none of the identities really make sense. For now, I've made it optional, but interested in feedback here. > IMO overall OK, we just need to be also able to expose a method allowing the client to destroy a message sent successfully Yeh, this doesn't currently allow that. I agree this is going to be a thing clients want to do, so how to represent it? Bron suggested an update of the "id" property to `null` for delete, but I'm not a huge fan of the idea. On Tue, 4 Jul 2017, at 06:49 PM, Alexey Melnikov wrote: >> * *threadId*: String >> The thread id of the message to send. This is immutable and set by the server to the *threadId* property of the message referenced by the *messageId*.> This is not very clear to me. Are replies to earlier messages share threadid with them? So the threadId is assigned by the server. When you create a message (i.e. the draft) in the mailstore, the server will assign it a message id and a thread id. If the message has reply-to/references headers set etc. this should result in the threadId being the same as the message being replied to, yes. The property is only really needed in the MessageDelivery object because I think it will be useful for filtering when getting a MessageDeliveryList. We could omit it, but it then requires potentially more work for the client to fetch thread if presenting a view of recent sent messages and their status. > I think this is the email from the Sender header field, if present. Falling back to the From otherwise. We probably need to say something about multiple From addresses here. Agreed, I'll fix that. Now reads: * *mailFrom*: The email in the *Sender* header, if present, otherwise the *From* header, if present, otherwise the empty string. If multiple addresses are present in one of these headers, or there is more than one *Sender*/*From* header, the server SHOULD reject the message as invalid but otherwise MUST take the first email address in the last *Sender*/*From* header in the [RFC5322] version of the message.>> The MessageDelivery object also seems an ideal place to be able to put delivery status for servers that support this, so clients can query for each email address the message was sent to, what happened (delivered? If not, what was the error? Has it been read?). Any thoughts on whether this is a good idea and what pieces of information should be represented?> > I think it would be useful. Information that would be useful: SMTP error code (per each recipient or a global one for the whole message (e.g. if MAIL FROM was rejected), SMTP Enhanced Status codes (if available), Error text. Some of these can also be synthesized by the JMAP server, for example if a recipient's domain can't be resolved using DNS. Sounds reasonable. Here's a first draft; comments welcome: *deliveryStatus*: String[DeliveryStatus]|null This is a map from the email address of each recipient of the message, to the most recent SMTP reply code/text known. The code/text MUST be the response to the RCPT TO stage, unless this was accepted and the message as a whole rejected at the end of the DATA stage, in which case the message rejection code and status text MUST be used instead. This property is server set and MAY not be supported by all servers, in which case it will remain null. Servers that support it SHOULD update the MessageDelivery object each time the status of one of the recipients changes, even if some recipients are still being retried. The *isFinal* property allows clients to know if the status may still change further. A *DeliveryStatus* object has the following properties: * *code*: Number The SMTP reply code returned for this recipient when the server last tried to relay it. See [RFC5321], section 4.2.3 for a list of codes. * *text*: String The text returned by the server along with this code. This will normally being with an SMTP Enhanced Mail System Status Code, as defined in [@!RFC3463], with a registry defined in [RFC5248]. * *isFinal*: Boolean This is false if the server is still trying to send the message to this recipient (and so the code/text could still change), otherwise true.Cheers, Neil. --_----------=_149923549437233251 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Tue, 4 Jul 2017, at 05:15 PM, Benoit Tellier wrote:
We need to specify in my opinion the identity we should use as a sender (http://jmap.io/spec-mail.html#identities)

I think I agree, although I'm not sure whether this should be optional? At the moment, none of the properties on the Identity object affect how the server handles the message; they just let the client know what email addresses the user has, and what defaults to use for various properties in a new message from those identities. However, some servers may end up doing different things depending on the identity, and matching just based on the From address is not necessarily possible if there are multiple identities that match the address.

There's also the case of redirecting mail (although how long this will be possible for in our DMARC future I don't know). In this case you didn't write the message, and so none of the identities really make sense.

For now, I've made it optional, but interested in feedback here.

IMO overall OK, we just need to be also able to expose a method allowing the client to destroy a message sent successfully

Yeh, this doesn't currently allow that. I agree this is going to be a thing clients want to do, so how to represent it? Bron suggested an update of the "id" property to `null` for delete, but I'm not a huge fan of the idea.

On Tue, 4 Jul 2017, at 06:49 PM, Alexey Melnikov wrote:
  • threadId: String
    The thread id of the message to send. This is immutable and set by the server to the threadId property of the message referenced by the messageId.
This is not very clear to me. Are replies to earlier messages share threadid with them?

So the threadId is assigned by the server. When you create a message (i.e. the draft) in the mailstore, the server will assign it a message id and a thread id. If the message has reply-to/references headers set etc. this should result in the threadId being the same as the message being replied to, yes.

The property is only really needed in the MessageDelivery object because I think it will be useful for filtering when getting a MessageDeliveryList. We could omit it, but it then requires potentially more work for the client to fetch thread if presenting a view of recent sent messages and their status.

I think this is the email from the Sender header field, if present. Falling back to the From otherwise. We probably need to say something about multiple From addresses here.

Agreed, I'll fix that. Now reads:

  • mailFrom: The email in the Sender header, if present, otherwise
    the From header, if present, otherwise the empty string.

    If multiple addresses are present in one of these headers, or there is more than one Sender/From header, the server SHOULD reject the message as invalid but otherwise MUST take the first email address in the last Sender/From header in the [RFC5322] version of the message.

The MessageDelivery object also seems an ideal place to be able to put delivery status for servers that support this, so clients can query for each email address the message was sent to, what happened (delivered? If not, what was the error? Has it been read?). Any thoughts on whether this is a good idea and what pieces of information should be represented?

I think it would be useful. Information that would be useful: SMTP error code (per each recipient or a global one for the whole message (e.g. if MAIL FROM was rejected), SMTP Enhanced Status codes (if available), Error text. Some of these can also be synthesized by the JMAP server, for example if a recipient's domain can't be resolved using DNS.

Sounds reasonable. Here's a first draft; comments welcome:

deliveryStatus: String[DeliveryStatus]|null

This is a map from the email address of each recipient of the message, to the most recent SMTP reply code/text known. The code/text MUST be the response to the RCPT TO stage, unless this was accepted and the message as a whole rejected at the end of the DATA stage, in which case the message rejection code and status text MUST be used instead.

This property is server set and MAY not be supported by all servers, in which case it will remain null. Servers that support it SHOULD update the MessageDelivery object each time the status of one of the recipients changes, even if some recipients are still being retried. The isFinal property allows clients to know if the status may still change further.

A DeliveryStatus object has the following properties:
  • code: Number
    The SMTP reply code returned for this recipient when the server last tried to relay it. See [RFC5321], section 4.2.3 for a list of codes.
  • text: String
    The text returned by the server along with this code. This will normally being with an SMTP Enhanced Mail System Status Code, as defined in [@!RFC3463], with a registry defined in [RFC5248].
  • isFinal: Boolean
    This is false if the server is still trying to send the message to this
    recipient (and so the code/text could still change), otherwise true.

Cheers,
Neil.
--_----------=_149923549437233251-- From nobody Tue Jul 4 23:50:43 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 A03B113170C for ; Tue, 4 Jul 2017 23:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.782 X-Spam-Level: ** X-Spam-Status: No, score=2.782 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_SBL_CSS=3.335, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 PkRdLMHievqb for ; Tue, 4 Jul 2017 23:50:37 -0700 (PDT) Received: from smtp-out10-fallback.linagora.com (smtp-out10-fallback.linagora.com [109.197.179.15]) by ietfa.amsl.com (Postfix) with ESMTP id ADA551316E6 for ; Tue, 4 Jul 2017 23:50:36 -0700 (PDT) Received: from smtp.linagora.com (smtp.linagora.dc1 [172.16.18.53]) by smtp-out10-fallback.linagora.com (Postfix) with ESMTP id 459281005DC3 for ; Wed, 5 Jul 2017 08:50:34 +0200 (CEST) Received: from [192.168.11.172] (unknown [118.70.135.8]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.linagora.com (Postfix) with ESMTPSA id CAC6964F for ; Wed, 5 Jul 2017 08:50:32 +0200 (CEST) To: jmap@ietf.org References: <1499146797.2319096.1029695160.34130D2D@webmail.messagingengine.com> <1499235493.3723325.1030693648.59277255@webmail.messagingengine.com> From: Benoit Tellier Message-ID: <100e9e50-a508-cded-aebd-97ff4bfc6bf3@linagora.com> Date: Wed, 5 Jul 2017 13:50:28 +0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <1499235493.3723325.1030693648.59277255@webmail.messagingengine.com> Content-Type: multipart/alternative; boundary="------------CE216180084BCCD219AB3239" Content-Language: en-US Archived-At: Subject: Re: [Jmap] New message sending API proposal X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 06:50:41 -0000 This is a multi-part message in MIME format. --------------CE216180084BCCD219AB3239 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Again, answers inlined Le 05/07/2017 à 13:18, Neil Jenkins a écrit : > On Tue, 4 Jul 2017, at 05:15 PM, Benoit Tellier wrote: > > We need to specify in my opinion the identity we should use as a > sender (http://jmap.io/spec-mail.html#identities) > > > I think I agree, although I'm not sure whether this should be > optional? At the moment, none of the properties on the Identity object > affect how the server handles the message; they just let the client > know what email addresses the user has, and what defaults to use for > various properties in a new message from those identities. However, > some servers may end up doing different things depending on the > identity, and matching just based on the From address is not > necessarily possible if there are multiple identities that match the > address. > The way I would implement that is using default mail address for the account... It seems counter intuitive to me to add Identities and not use them.... > There's also the case of redirecting mail (although how long this will > be possible for in our DMARC future I don't know). In this case you > didn't write the message, and so none of the identities really make sense. If I forward, then I am at the origin of the actions, it seems logic to use one of my available emails... > > For now, I've made it optional, but interested in feedback here. > >> IMO overall OK, we just need to be also able to expose a method >> allowing the client to destroy a message sent successfully > > Yeh, this doesn't currently allow that. I agree this is going to be a > thing clients want to do, so how to represent it? Bron suggested an > update of the "id" property to `null` for delete, but I'm not a huge > fan of the idea. IMO the more explicit choice is add **onDestroyDestroyMessages** Set[ReferenceId]. Null should be avoided in my opinion. > > On Tue, 4 Jul 2017, at 06:49 PM, Alexey Melnikov wrote: >>> >>> * >>> *threadId*: |String| >>> The thread id of the message to send. This is immutable and set >>> by the server to the /threadId/ property of the message >>> referenced by the /messageId/. >>> >> This is not very clear to me. Are replies to earlier messages share >> threadid with them? > > So the threadId is assigned by the server. When you create a message > (i.e. the draft) in the mailstore, the server will assign it a message > id and a thread id. If the message has reply-to/references headers set > etc. this should result in the threadId being the same as the message > being replied to, yes. > > The property is only really needed in the MessageDelivery object > because I think it will be useful for filtering when getting a > MessageDeliveryList. We could omit it, but it then requires > potentially more work for the client to fetch thread if presenting a > view of recent sent messages and their status. > >> I think this is the email from the Sender header field, if present. >> Falling back to the From otherwise. We probably need to say something >> about multiple From addresses here. > > Agreed, I'll fix that. Now reads: > > * > *mailFrom*: The email in the /Sender/ header, if present, otherwise > the /From/ header, if present, otherwise the empty string. > > If multiple addresses are present in one of these headers, or > there is more than one /Sender///From/ header, the server SHOULD > reject the message as invalid but otherwise MUST take the first > email address in the last /Sender///From/ header in the [RFC5322] > version of the message. > >>> The MessageDelivery object also seems an ideal place to be able to >>> put delivery status for servers that support this, so clients can >>> query for each email address the message was sent to, what happened >>> (delivered? If not, what was the error? Has it been read?). Any >>> thoughts on whether this is a good idea and what pieces of >>> information should be represented? >> >> I think it would be useful. Information that would be useful: SMTP >> error code (per each recipient or a global one for the whole message >> (e.g. if MAIL FROM was rejected), SMTP Enhanced Status codes (if >> available), Error text. Some of these can also be synthesized by the >> JMAP server, for example if a recipient's domain can't be resolved >> using DNS. > > Sounds reasonable. Here's a first draft; comments welcome: > > *deliveryStatus*: |String[DeliveryStatus]|null| > > This is a map from the email address of each recipient of the message, > to the most recent SMTP reply code/text known. The code/text MUST be > the response to the RCPT TO stage, unless this was accepted and the > message as a whole rejected at the end of the DATA stage, in which > case the message rejection code and status text MUST be used instead. > > This property is server set and MAY not be supported by all servers, > in which case it will remain |null|. Servers that support it SHOULD > update the MessageDelivery object each time the status of one of the > recipients changes, even if some recipients are still being retried. > The /isFinal/ property allows clients to know if the status may still > change further. > > A *DeliveryStatus* object has the following properties: > > * *code*: |Number| > The SMTP reply code returned for this recipient when the server > last tried to relay it. See [RFC5321], section 4.2.3 for a list of > codes. > * *text*: |String| > The text returned by the server along with this code. This will > normally being with an SMTP Enhanced Mail System Status Code, as > defined in [@!RFC3463], with a registry defined in [RFC5248]. > * *isFinal*: |Boolean| > This is |false| if the server is still trying to send the message > to this > recipient (and so the code/text could still change), otherwise |true|. > > Cheers, > Neil. > > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap --------------CE216180084BCCD219AB3239 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Again, answers inlined


Le 05/07/2017 à 13:18, Neil Jenkins a écrit :
On Tue, 4 Jul 2017, at 05:15 PM, Benoit Tellier wrote:
We need to specify in my opinion the identity we should use as a sender (http://jmap.io/spec-mail.html#identities)

I think I agree, although I'm not sure whether this should be optional? At the moment, none of the properties on the Identity object affect how the server handles the message; they just let the client know what email addresses the user has, and what defaults to use for various properties in a new message from those identities. However, some servers may end up doing different things depending on the identity, and matching just based on the From address is not necessarily possible if there are multiple identities that match the address.

The way I would implement that is using default mail address for the account... It seems counter intuitive to me to add Identities and not use them....
There's also the case of redirecting mail (although how long this will be possible for in our DMARC future I don't know). In this case you didn't write the message, and so none of the identities really make sense.
If I forward, then I am at the origin of the actions, it seems logic to use one of my available emails...

For now, I've made it optional, but interested in feedback here.

IMO overall OK, we just need to be also able to expose a method allowing the client to destroy a message sent successfully

Yeh, this doesn't currently allow that. I agree this is going to be a thing clients want to do, so how to represent it? Bron suggested an update of the "id" property to `null` for delete, but I'm not a huge fan of the idea.
IMO the more explicit choice is add **onDestroyDestroyMessages** Set[ReferenceId].

Null should be avoided in my opinion.

On Tue, 4 Jul 2017, at 06:49 PM, Alexey Melnikov wrote:
  • threadId: String
    The thread id of the message to send. This is immutable and set by the server to the threadId property of the message referenced by the messageId.
This is not very clear to me. Are replies to earlier messages share threadid with them?

So the threadId is assigned by the server. When you create a message (i.e. the draft) in the mailstore, the server will assign it a message id and a thread id. If the message has reply-to/references headers set etc. this should result in the threadId being the same as the message being replied to, yes.

The property is only really needed in the MessageDelivery object because I think it will be useful for filtering when getting a MessageDeliveryList. We could omit it, but it then requires potentially more work for the client to fetch thread if presenting a view of recent sent messages and their status.

I think this is the email from the Sender header field, if present. Falling back to the From otherwise. We probably need to say something about multiple From addresses here.

Agreed, I'll fix that. Now reads:

  • mailFrom: The email in the Sender header, if present, otherwise
    the From header, if present, otherwise the empty string.

    If multiple addresses are present in one of these headers, or there is more than one Sender/From header, the server SHOULD reject the message as invalid but otherwise MUST take the first email address in the last Sender/From header in the [RFC5322] version of the message.

The MessageDelivery object also seems an ideal place to be able to put delivery status for servers that support this, so clients can query for each email address the message was sent to, what happened (delivered? If not, what was the error? Has it been read?). Any thoughts on whether this is a good idea and what pieces of information should be represented?

I think it would be useful. Information that would be useful: SMTP error code (per each recipient or a global one for the whole message (e.g. if MAIL FROM was rejected), SMTP Enhanced Status codes (if available), Error text. Some of these can also be synthesized by the JMAP server, for example if a recipient's domain can't be resolved using DNS.

Sounds reasonable. Here's a first draft; comments welcome:

deliveryStatus: String[DeliveryStatus]|null

This is a map from the email address of each recipient of the message, to the most recent SMTP reply code/text known. The code/text MUST be the response to the RCPT TO stage, unless this was accepted and the message as a whole rejected at the end of the DATA stage, in which case the message rejection code and status text MUST be used instead.

This property is server set and MAY not be supported by all servers, in which case it will remain null. Servers that support it SHOULD update the MessageDelivery object each time the status of one of the recipients changes, even if some recipients are still being retried. The isFinal property allows clients to know if the status may still change further.

A DeliveryStatus object has the following properties:
  • code: Number
    The SMTP reply code returned for this recipient when the server last tried to relay it. See [RFC5321], section 4.2.3 for a list of codes.
  • text: String
    The text returned by the server along with this code. This will normally being with an SMTP Enhanced Mail System Status Code, as defined in [@!RFC3463], with a registry defined in [RFC5248].
  • isFinal: Boolean
    This is false if the server is still trying to send the message to this
    recipient (and so the code/text could still change), otherwise true.

Cheers,
Neil.


_______________________________________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/mailman/listinfo/jmap

--------------CE216180084BCCD219AB3239-- From nobody Wed Jul 5 01:16: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 71CC7131AFE for ; Wed, 5 Jul 2017 01:16:49 -0700 (PDT) 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, 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 ifLAe9AZjNw4 for ; Wed, 5 Jul 2017 01:16:47 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::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 CAB40131B02 for ; Wed, 5 Jul 2017 01:16:43 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id t72so20146865lff.1 for ; Wed, 05 Jul 2017 01:16:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Qq3ocmscNwoOUg01NE9epD1MSPp/tf6d3BRsSvgdFkc=; b=aOIcJV6nfViBi24V1dzW7sLxwcut3mSAhs/7me6okkwvfLpH4xAOckoB1NOj64m1/q uroHPkjYurjcl9340u8CsWoIneeHWiiphqD5sg7OeiAozDKh7t5f2PQv4z6Gcj9HZcUe HkTVH9uDcLQymammsB+3bK1rfGt5wY1/1kfrAI4npYcm4flOIr1aWV30/59TMGUY1SSK Lmc/V1lFWPloDEAUtKiRkNphop0R8iWWD3B5Ne3Uho7LUxyJnKdLAeJPBjvl/uYDbHcW 2l6/iDZXb39Na96IbIxSATaqsZNVYmZoheyqdzzywX7I7cqEakZSj3Rg6ojJgTnBVNfE +WtA== 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; bh=Qq3ocmscNwoOUg01NE9epD1MSPp/tf6d3BRsSvgdFkc=; b=Cb+y1wF/7BdDNFpPRTkGLE8X9EirAkXpCK4E76mjW5nkwgjI5FdPzRgjNQRixRnIKe W5dZC+b+DxZr8Sdtjza5rmjLBSDKNx6Kp1sePKavGPfuTaJS/dFgaMU9C81DcJZ+NYQ4 GhXHFNY2hYVeBEfKDY9bKFh8xONbeKThGit7kL84NzaTrrFZgcqqoUr+VkauYa0D1FY1 VplhnmQKbrMzNdt6w2OnlBIKubccooIoPHINvN+qO+wnIPJpenufbS4iVAjrXch8ZPqL lc2c3HXuHIVPV4rnHUnPPHUJ1KsUs5NBaO9Mw2xtwFFY8FxID7eiaFKUNvouMDzTCUdV cacQ== X-Gm-Message-State: AKS2vOzF9GuiD0jSfwcadRozOhrDPJ+f4icbLEvuN4RYr9+BWQEtpPBY eWR97AvjSLiYAV12Mlc7HX0mHkJKcK2yqHM= X-Received: by 10.25.29.16 with SMTP id d16mr14610677lfd.50.1499242601815; Wed, 05 Jul 2017 01:16:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.69.84 with HTTP; Wed, 5 Jul 2017 01:16:40 -0700 (PDT) In-Reply-To: <1499230650.3642220.1030669400.4800D481@webmail.messagingengine.com> References: <1499230650.3642220.1030669400.4800D481@webmail.messagingengine.com> From: Martin Thomson Date: Wed, 5 Jul 2017 18:16:40 +1000 Message-ID: To: Neil Jenkins Cc: jmap@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Jmap] Feedback on draft-ietf-jmap-core X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 08:16:49 -0000 Hi Neil, My MTA seems to have lost your nicely decorated quoting, sorry. Who would have thought that that would still be a problem. On 5 July 2017 at 14:57, Neil Jenkins wrote: > If you have a suggestion of an existing authentication scheme that meets > these criteria, we should look at that. I appreciate that HTTP authentication is (badly) challenged, but it will depend greatly on what context you are operating in. For instance, if you are assuming that there can't be a user and web browser involved in the onboarding process, that makes things pretty challenging. You really need to motivate that more strongly than you have: account creation is an exceptional process and covering that makes something arbitrarily complex. There are many questions that you can avoid by assuming the presence of a user with a browser: do you need CAPTCHA? do you need to setup 2FA? if there is a password, what are the policies on those? The problem with the current document is that you spend 11ish pages on defining a new authentication scheme. That's a huge amount of work that distracts from your main task: making a mail access protocol. Also, from experience with these things, 11 pages is far from enough information to describe an authentication scheme, particularly one with this level of complexity. For example, I don't think that the "totp" scheme is specified in sufficient detail to implement interoperable implementations. The IETF chartered a working group that concentrates on this exact problem. I know that you don't want to create dependencies on other groups, but that is where this is currently headed. I would encourage you to talk to the folks in the OAUTH and HTTPAUTH working groups to see if they have solutions for your problems. There's a lot going on there. > I explained the technical decisions behind this in the "Structure of a > request/response" part of my email "JMAP Conceptual Decisions", a few weeks > ago. If you missed it, a plain-text copy is available in the IETF archive at > https://mailarchive.ietf.org/arch/msg/jmap/SfCe3UJPEEUdeomeso_-PAzP5tQ Since I only just now joined this list, I will reply here. I think that you can achieve your goals within the same framework. As an aside, I'm accepting for the moment that your performance goals cannot be met by the simple use of HTTP that you discredit in that thread. I'm not an expert in this area, other than also having long ping times to servers that many in this organization assume are close, and I know very well the value of cutting round trips, but I'm not convinced that the performance constraints are so severe that they demand this much contortion. If they are indeed that severe, even then I would prefer if you explored alternative options that would be less opaque to HTTP. Have you considered creating explicit dependencies between requests just in your request bodies? That would allow you to send the requests concurrently. It's possible that a generic facility like that would be valuable in HTTP for use with transactional APIs. Or there is the pattern of transactional resources. In this you create a resource. That can be done ahead of the need to use it so that you avoid spending the round trips on setup. You then populate that resource (in this case, with the actions you wish to take), then you execute the transaction. This model has other virtues in that the non-idempotent requests cause minimal side-effects and the final transaction commit can use an idempotent method. You might have already considered these approaches and found them wanting, or maybe you need more information before you can decide. I'd like to hear why some time. >> 4. Don't use EventSource. > The EventSource part can easily be made to support long-polling instead at > the option of the client (the only difference being it closes the connection > after every push). Having a direct way for clients that are able to hold > open connections get push notifications without requiring their own push > server (see below) is still a good thing to have IMO. The people who designed EventSource tell me that it's basically abandoned. It was replaced by thewebsocketprotocol, which has been largely superceded by the facilities that HTTP/2 provides (though I will concede that of those facilities, only long-polling is a viable option today; push still a work in progress). That said, you actually have *two* goals here. One is for an asynchronous communications channel that you can use while there are ongoing interactions between client and server. For that, I generally recommend long-polling, though that can lead to generic event streams, which can easily become the locus of a huge pile of technical debt. The other is the need to send messages when the client is effectively offline. For that, you negatively want something that you manage yourself. It's a battery drain. It's hard to ensure that you don't end up with a dead connection as a result of middlebox shenanigans. Maintaining an open connection is either prohibited or strongly discouraged on many operating systems for those reasons. The messages that traverse those two paths are likely different. Push messages are considerably more limited in what they can carry. > I presume this is referring to the Web Hook part of the push section of the > spec, as this is the only place this word is mentioned. I'm not sure exactly > what you mean by "client reachability isn't consistent", but the intention > here (with a few header changes still required) is that the JMAP server is > an RFC8030 compliant "Application Server". I had no idea that that was your intention from reading the draft. If your intent was to act as an application server and actually use the Push API, then it needs to be explicit. From nobody Sun Jul 9 23:40:21 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 E605E126DC2 for ; Sun, 9 Jul 2017 23:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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=fastmailteam.com header.b=DaISwbUm; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ivR5qfpT 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 gdTF1vzwjUzq for ; Sun, 9 Jul 2017 23:40:16 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB910126CBF for ; Sun, 9 Jul 2017 23:40:16 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id EF610209F1 for ; Mon, 10 Jul 2017 02:40:15 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Mon, 10 Jul 2017 02:40:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.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=fm1; bh=olNOXMO9flXTP9FAd bt9qhFaNiUvyURu4CFHnniqkBo=; b=DaISwbUm8JA4M4f1C7te//p4xE8mvwQTS VWxQhWYpAZo4prHwzU4puyov/AQORAQfytZWlu8+qNzrkwE8iWS7vFMvpWZDD5Ua CY7oeVQnQUqiAjagsGuNJk03oTGWesYcb0rVd2mE7Rd77eA3vNpqoImNUQEyqmhG 3IJLfeg5N+2P+7JldUJfdndTPBis02Arhdg/iQb2BZvY2sAfy+R/CecjLUl+7PT7 gnUVUCnTfYvW+vptYcj8aI1Dh0M6xk6EHYad+vJVYclF+bbfmYBg62yNyOz2/3tN EerJlXXwFZsZqTepjfDx0fKhsHRDAP5h/6hbr6ete2+YIuhRJZ5tA== DKIM-Signature: v=1; a=rsa-sha256; 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=fm1; bh=olNOXM O9flXTP9FAdbt9qhFaNiUvyURu4CFHnniqkBo=; b=ivR5qfpTJFSUtzHEwqOZ4m R6nqxHpoVsdFhJzfw4Hus3QkuIX4DaLEW+AWsqWiahp3czgIMusLVtABvVAeqU0f ESoyNBVR8PGYpEKpXU0GRbb50k7QJUOrio+xZlb9a5x/rfA2trK1RlhtQPL3F5aC omBXTjdbPx4yKG1wmBWZGfJdQzrOTL93ymAJk9Mc98T4jOYZIs9Av7b0Aw81lU3S qbLwOsYkxq5hzA7Va7TdPkGcugBTyeshMRLMNBlu3q/1B4Tl3CI4pftDR5HDtJg2 DoC2xS9KXZe2EUUMVYDusnvuGCRRPw9cpNUXlegeMSLCQjY5zAmKO+Uk51liydBA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id C1F15627A2; Mon, 10 Jul 2017 02:40:15 -0400 (EDT) Message-Id: <1499668815.2785610.1035612384.2A160C5C@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_149966881527856101" X-Mailer: MessagingEngine.com Webmail Interface - ajax-6ef673f5 In-Reply-To: References: <1499230650.3642220.1030669400.4800D481@webmail.messagingengine.com> Date: Mon, 10 Jul 2017 16:40:15 +1000 Archived-At: Subject: Re: [Jmap] Feedback on draft-ietf-jmap-core X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 06:40:20 -0000 This is a multi-part message in MIME format. --_----------=_149966881527856101 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Wed, 5 Jul 2017, at 18:16, Martin Thomson wrote: > Hi Neil, > > My MTA seems to have lost your nicely decorated quoting, sorry. Who > would have thought that that would still be a problem. > > On 5 July 2017 at 14:57, Neil Jenkins wrote:>> If you have a suggestion of an existing authentication scheme that meets>> these criteria, we should look at that. > > I appreciate that HTTP authentication is (badly) challenged, but it > will depend greatly on what context you are operating in. For > instance, if you are assuming that there can't be a user and web > browser involved in the onboarding process, that makes things pretty > challenging. Some interesting places that might require authentication are standalone applications like Thunderbird, and devices without a graphical interface, like routers or smart fridges that want to be able to send email or read email. Of course a lot of these things now pair with a phone to allow setup, but we still need a way to give them a long lived token. > You really need to motivate that more strongly than you have: account> creation is an exceptional process and covering that makes something > arbitrarily complex. There are many questions that you can avoid by > assuming the presence of a user with a browser: do you need CAPTCHA? > do you need to setup 2FA? if there is a password, what are the > policies on those? It's not account creation (which is not specified in JMAP at all) - but authenticating a new device against an existing account. You're never going to get big providers to go back to allowing users to define their own password and store it in an arbitrary number of devices which get to authenticate using just that password. There has been too much abuse with stolen passwords to go back to that as a way of connecting third party clients. Apple just moved iCloud over to requiring device-specific passwords, Google has required OAUTH for IMAP for a while. > The problem with the current document is that you spend 11ish pages on> defining a new authentication scheme. That's a huge amount of work > that distracts from your main task: making a mail access protocol. Do you know of any other protocol which meets the goals? I'd love to see the spec get shorter, but not at the expense of failing to solve the problems that a client to server protocol needs to solve in 2017 to be acceptable to providers. > Also, from experience with these things, 11 pages is far from enough > information to describe an authentication scheme, particularly one > with this level of complexity. For example, I don't think that the > "totp" scheme is specified in sufficient detail to implement > interoperable implementations. Do you want me to log a specific bug in Github about the specification of TOTP scheme? That's my role in this group! If you could detail how it is insufficient that would be useful. > The IETF chartered a working group that concentrates on this exact > problem. I know that you don't want to create dependencies on other > groups, but that is where this is currently headed. I would encourage> you to talk to the folks in the OAUTH and HTTPAUTH working groups to > see if they have solutions for your problems. There's a lot going on> there. Definitely will do. I'll be attending ace on Monday morning: https://datatracker.ietf.org/group/ace/about/ And oauth on Tuesday afternoon: https://datatracker.ietf.org/group/oauth/about/ If there's anything specific of value from there that you want to suggest as a workable alternative to the current authentication scheme, we'd love to see a counter proposal. "Your current plan sucks" isn't very helpful without a workable alternative, because what's proposed has been implemented and tested and does work. >> I explained the technical decisions behind this in the "Structure of a>> request/response" part of my email "JMAP Conceptual Decisions", a few weeks>> ago. If you missed it, a plain-text copy is available in the IETF archive at>> https://mailarchive.ietf.org/arch/msg/jmap/SfCe3UJPEEUdeomeso_-PAzP5tQ> > Since I only just now joined this list, I will reply here. I think > that you can achieve your goals within the same framework. > > As an aside, I'm accepting for the moment that your performance goals> cannot be met by the simple use of HTTP that you discredit in that > thread. I'm not an expert in this area, other than also having long > ping times to servers that many in this organization assume are close,> and I know very well the value of cutting round trips, but I'm not > convinced that the performance constraints are so severe that they > demand this much contortion. If you watch the video of Apple's IMAP client vs FastMail's client using a protocol based on the same request batching process as JMAP from Australia to a server in New York, you can see the difference for real. http://jmap.io/ > If they are indeed that severe, even then I would prefer if you > explored alternative options that would be less opaque to HTTP. Have> you considered creating explicit dependencies between requests just in> your request bodies? That would allow you to send the requests > concurrently. It's possible that a generic facility like that would > be valuable in HTTP for use with transactional APIs. As a server implementer, that's a really difficult scenario. You wind up having a huge amount of state to track for an unbounded amount of time on the server. And you lose the ability to do backreferences (http://jmap.io/spec-core.html#setFoos). You're asking for a ton of extra complexity in the server. That's a massive increase in scope compared to a bounded batch of requests in a single package. > Or there is the pattern of transactional resources. In this you > create a resource. That can be done ahead of the need to use it so > that you avoid spending the round trips on setup. You then populate > that resource (in this case, with the actions you wish to take), then> you execute the transaction. This model has other virtues in that the> non-idempotent requests cause minimal side-effects and the final > transaction commit can use an idempotent method. I'm not sure how this reduces round trips, it looks like it's even more round trips than raw REST. And again, this is asking the server to hold more state. You won't find any server implementation begging for this. JMAP is deliberately as lightweight on state as possible for the server - all you need to maintain between requests (apart from the data model itself) is the long-lived authentication token. Each batch of requests stands alone. >>> 4. Don't use EventSource. >> The EventSource part can easily be made to support long-polling instead at>> the option of the client (the only difference being it closes the connection>> after every push). Having a direct way for clients that are able to hold>> open connections get push notifications without requiring their own push>> server (see below) is still a good thing to have IMO. > > The people who designed EventSource tell me that it's basically > abandoned. It was replaced by thewebsocketprotocol, which has been > largely superceded by the facilities that HTTP/2 provides (though I > will concede that of those facilities, only long-polling is a viable > option today; push still a work in progress). This is all a really good reason not follow the latest fashions, particularly in the HTTP space where things get created and thrown away all the time. While JMAP is defined in terms of JSON and HTTP for ease of understanding, it's really just a structured object built on maps and lists over a batch transport. You could implement it with ASN1 over UUCP just as easily. This is a good thing, tying it to the shiny new work in progress is not a good way to make a long-lived protocol. > That said, you actually have **two** goals here. One is for an > asynchronous communications channel that you can use while there are > ongoing interactions between client and server. For that, I generally> recommend long-polling, though that can lead to generic event streams,> which can easily become the locus of a huge pile of technical debt. > > The other is the need to send messages when the client is effectively> offline. For that, you negatively want something that you manage > yourself. It's a battery drain. It's hard to ensure that you don't > end up with a dead connection as a result of middlebox shenanigans. > Maintaining an open connection is either prohibited or strongly > discouraged on many operating systems for those reasons. > > The messages that traverse those two paths are likely different. Push> messages are considerably more limited in what they can carry. The FastMail system sends tiny edge triggers with no real content via either channel, telling the client that it needs to do a sync. The protocol provides very efficient methods to resync from a previous known state, so there's no benefit to having two different ways to tell the client that there are updates. It's much simpler to always use the same resync method, regardless of the change. This has served us very well in production for years now, which is why Neil is confident proposing the same technique for JMAP. Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_149966881527856101 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Wed, 5 Jul 2017, at 18:16, Martin Thomson wrote:
Hi Neil,

My MTA seems to have lost your nicely decorated quoting, sorry.  Who
would have thought that that would still be a problem.

On 5 July 2017 at 14:57, Neil Jenkins <neilj@fastmailteam.com> wrote:
If you have a suggestion of an existing authentication scheme that meets
these criteria, we should look at that.

I appreciate that HTTP authentication is (badly) challenged, but it
will depend greatly on what context you are operating in.  For
instance, if you are assuming that there can't be a user and web
browser involved in the onboarding process, that makes things pretty
challenging.

Some interesting places that might require authentication are standalone applications like Thunderbird, and devices without a graphical interface, like routers or smart fridges that want to be able to send email or read email.  Of course a lot of these things now pair with a phone to allow setup, but we still need a way to give them a long lived token.

You really need to motivate that more strongly than you have: account
creation is an exceptional process and covering that makes something
arbitrarily complex.  There are many questions that you can avoid by
assuming the presence of a user with a browser: do you need CAPTCHA?
do you need to setup 2FA?  if there is a password, what are the
policies on those?

It's not account creation (which is not specified in JMAP at all) - but authenticating a new device against an existing account.  You're never going to get big providers to go back to allowing users to define their own password and store it in an arbitrary number of devices which get to authenticate using just that password.  There has been too much abuse with stolen passwords to go back to that as a way of connecting third party clients.  Apple just moved iCloud over to requiring device-specific passwords, Google has required OAUTH for IMAP for a while.

The problem with the current document is that you spend 11ish pages on
defining a new authentication scheme.  That's a huge amount of work
that distracts from your main task: making a mail access protocol.

Do you know of any other protocol which meets the goals?  I'd love to see the spec get shorter, but not at the expense of failing to solve the problems that a client to server protocol needs to solve in 2017 to be acceptable to providers.

Also, from experience with these things, 11 pages is far from enough
information to describe an authentication scheme, particularly one
with this level of complexity.  For example, I don't think that the
"totp" scheme is specified in sufficient detail to implement
interoperable implementations.

Do you want me to log a specific bug in Github about the specification of TOTP scheme?  That's my role in this group!  If you could detail how it is insufficient that would be useful.

The IETF chartered a working group that concentrates on this exact
problem.  I know that you don't want to create dependencies on other
groups, but that is where this is currently headed.  I would encourage
you to talk to the folks in the OAUTH and HTTPAUTH working groups to
see if they have solutions for your problems.  There's a lot going on
there.

Definitely will do.  I'll be attending ace on Monday morning:


And oauth on Tuesday afternoon:


If there's anything specific of value from there that you want to suggest as a workable alternative to the current authentication scheme, we'd love to see a counter proposal.

"Your current plan sucks" isn't very helpful without a workable alternative, because what's proposed has been implemented and tested and does work.

I explained the technical decisions behind this in the "Structure of a
request/response" part of my email "JMAP Conceptual Decisions", a few weeks
ago. If you missed it, a plain-text copy is available in the IETF archive at

Since I only just now joined this list, I will reply here.  I think
that you can achieve your goals within the same framework.

As an aside, I'm accepting for the moment that your performance goals
cannot be met by the simple use of HTTP that you discredit in that
thread. I'm not an expert in this area, other than also having long
ping times to servers that many in this organization assume are close,
and I know very well the value of cutting round trips, but I'm not
convinced that the performance constraints are so severe that they
demand this much contortion.

If you watch the video of Apple's IMAP client vs FastMail's client using a protocol based on the same request batching process as JMAP from Australia to a server in New York, you can see the difference for real.  http://jmap.io/

If they are indeed that severe, even then I would prefer if you
explored alternative options that would be less opaque to HTTP.  Have
you considered creating explicit dependencies between requests just in
your request bodies?  That would allow you to send the requests
concurrently.  It's possible that a generic facility like that would
be valuable in HTTP for use with transactional APIs.

As a server implementer, that's a really difficult scenario.  You wind up having a huge amount of state to track for an unbounded amount of time on the server.  And you lose the ability to do backreferences (http://jmap.io/spec-core.html#setFoos).  You're asking for a ton of extra complexity in the server.  That's a massive increase in scope compared to a bounded batch of requests in a single package.

Or there is the pattern of transactional resources.  In this you
create a resource. That can be done ahead of the need to use it so
that you avoid spending the round trips on setup.  You then populate
that resource (in this case, with the actions you wish to take), then
you execute the transaction.  This model has other virtues in that the
non-idempotent requests cause minimal side-effects and the final
transaction commit can use an idempotent method.

I'm not sure how this reduces round trips, it looks like it's even more round trips than raw REST.  And again, this is asking the server to hold more state.  You won't find any server implementation begging for this. JMAP is deliberately as lightweight on state as possible for the server - all you need to maintain between requests (apart from the data model itself) is the long-lived authentication token.  Each batch of requests stands alone.

4. Don't use EventSource.
The EventSource part can easily be made to support long-polling instead at
the option of the client (the only difference being it closes the connection
after every push). Having a direct way for clients that are able to hold
open connections get push notifications without requiring their own push
server (see below) is still a good thing to have IMO.

The people who designed EventSource tell me that it's basically
abandoned.  It was replaced by thewebsocketprotocol, which has been
largely superceded by the facilities that HTTP/2 provides (though I
will concede that of those facilities, only long-polling is a viable
option today; push still a work in progress).

This is all a really good reason not follow the latest fashions, particularly in the HTTP space where things get created and thrown away all the time.  While JMAP is defined in terms of JSON and HTTP for ease of understanding, it's really just a structured object built on maps and lists over a batch transport.  You could implement it with ASN1 over UUCP just as easily.  This is a good thing, tying it to the shiny new work in progress is not a good way to make a long-lived protocol.

That said, you actually have *two* goals here.  One is for an
asynchronous communications channel that you can use while there are
ongoing interactions between client and server.  For that, I generally
recommend long-polling, though that can lead to generic event streams,
which can easily become the locus of a huge pile of technical debt.

The other is the need to send messages when the client is effectively
offline.  For that, you negatively want something that you manage
yourself.  It's a battery drain.  It's hard to ensure that you don't
end up with a dead connection as a result of middlebox shenanigans.
Maintaining an open connection is either prohibited or strongly
discouraged on many operating systems for those reasons.

The messages that traverse those two paths are likely different.  Push
messages are considerably more limited in what they can carry.

The FastMail system sends tiny edge triggers with no real content via either channel, telling the client that it needs to do a sync.  The protocol provides very efficient methods to resync from a previous known state, so there's no benefit to having two different ways to tell the client that there are updates.  It's much simpler to always use the same resync method, regardless of the change.  This has served us very well in production for years now, which is why Neil is confident proposing the same technique for JMAP.

Cheers,

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_149966881527856101-- From nobody Thu Jul 13 11:17: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 D843F128BA2 for ; Thu, 13 Jul 2017 11:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neiljhaveri-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 jLuhik5x-RQR for ; Thu, 13 Jul 2017 11:17:55 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::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 212E7128990 for ; Thu, 13 Jul 2017 11:17:55 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id m68so724010ith.1 for ; Thu, 13 Jul 2017 11:17:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neiljhaveri-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=MnDDyo/nUo87Cr3bWrqzHtsQ/6ql4KAzaHgDi/qmk38=; b=ffFvX7VeNe3WFGKer42W85OLNYUFylWYzJB+4p/1uJS83w5SRiAC0hSAxjFsPeOgSD AqRxceBwBzUzneTOIahygngw/VTegRzJ9cfkvFZkcu+6kSQDDaFJgcIgsSbK6M8M7Zvc wRqxTaJN4v2K3SHLYrzKgC9OFDSSFJ/jsick4GunQ5EVsZOUAHGp3RsGhOdfMBXjQZrn gqd7sTbYMSvU4q+QIOuTaEiQDiEYb2jHe4LEyoQDiwRTorAZIiB+ZBKFV74fEfLyD28j 2ttUtM0M3oz3qCyZtCrZXIjXVZnUS0xCLecQC+2mKqJT4vkxwImIXQjKnAyyc22n+Ds/ mw+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=MnDDyo/nUo87Cr3bWrqzHtsQ/6ql4KAzaHgDi/qmk38=; b=OhdaonMKNxxVmwgCSS1LIdy8rZSSNQtDgbFOd3eARJ6MJPgryyE5n1LIwEmUbNdfs4 FZUfQpZLquzdooivvXor7HEAbPUxf7Jbs6e4HYacK7dIQCRHYItpDFTZBmFSyFJAYQ/h vaOrXQouGqChIFkNPGgEZ7X1DLg9rdtl2XsB70HLYtVcZjWaTxI0QvAULznrIdMPqnbl 6le2ljtEFr6E3c9Aj85pVVPRcmqUmnB/2JeU7bOKiwlN59jZSaWOdHL5P0xzWtp2hdNU vS/oONxVCpOgjQOve9Q7DtMQ7swRbeRyhlN3VIjzHPgQ5WoNmRZNc94hOPz9dR6N49O0 oL1w== X-Gm-Message-State: AIVw111PSytcNm4Zz57KGeGt3faARDnnEWbgLZu/AnNS9FGQfHNfw5+p ECbY+zeG7xQ3+xkZXAF2Y7CMwX8bWDhL X-Received: by 10.36.189.72 with SMTP id x69mr105694ite.56.1499969874541; Thu, 13 Jul 2017 11:17:54 -0700 (PDT) MIME-Version: 1.0 References: <1491886379.444171.940831720.06C71198@webmail.messagingengine.com> <1492579277.2998458.948887296.01406185@webmail.messagingengine.com> <1594590924.2859.1492580398931@appsuite-dev.open-xchange.com> In-Reply-To: <1594590924.2859.1492580398931@appsuite-dev.open-xchange.com> From: Neil Jhaveri Date: Thu, 13 Jul 2017 18:17:43 +0000 Message-ID: To: Aki Tuomi , Neil Jenkins , jmap@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1966aa8bd354055436f312" Archived-At: Subject: Re: [Jmap] Push mechanism X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 18:17:57 -0000 --94eb2c1966aa8bd354055436f312 Content-Type: text/plain; charset="UTF-8" A little late here... but since this is on the meeting agenda, I'll confirm that this seems like the right direction to me too. Before I left Apple, I had a chat with a few of the devs working on APNS and they also thought this was a reasonable direction, and could see implementing the App Server --> Push Server portion of RFC 8030, while leaving the Push Server <--> User Agent portion custom. Right now, the App Server --> Push Server portion does require a special certificate, and doesn't meet RFC 8030. I vaguely recall Martin mentioning during the first meeting that RFC 8030 mostly made sense in the context of the browser. @Martin, now that you're on this list, I wonder if you could provide your thoughts on this. On Tue, Apr 18, 2017 at 10:40 PM Aki Tuomi wrote: > On April 19, 2017 at 8:21 AM Neil Jenkins wrote: > > > On Tue, 11 Apr 2017, at 02:52 PM, Neil Jenkins wrote: > > We talked a bit in Chicago about RFC 8030[1] and what mechanisms we > > > should support for push. Having looked at RFC8030 in a bit more > detail, the JMAP server is just the "Application Server" in this model > (the other two participants are the "UA" and the "Push Server"). We > should specify the behaviour such that it is compatible in this role, > > but not constrain it further. The Web Hook[2] part of the current > > > draft of the JMAP spec basically already does this. I think we just > need to add a few headers to the calls to the push server to make it > compliant: TTL, Topic and Urgency. > > Can I take the lack of argument about this as consensus that this is the > right way forward? :) > Neil. > > Fwiw, using existing standard is a good idea. Had a quick look and it > looked ok. > > Aki > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap > --94eb2c1966aa8bd354055436f312 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A little late here... but since this is on the meeti= ng agenda, I'll confirm that this seems like the right direction to me = too. Before I left Apple, I had a chat with a few of the devs working on AP= NS and they also thought this was a reasonable direction, and could see imp= lementing the App Server --> Push Server portion of RFC 8030, while leav= ing the Push Server <--> User Agent portion custom. Right now, the Ap= p Server --> Push Server portion does require a special certificate, and= doesn't meet RFC 8030.

I vaguely recall Martin mentioning during the first meeting that RFC 80= 30 mostly made sense in the context of the browser. @Martin, now that you&#= 39;re on this list, I wonder if you could provide your thoughts on this.
On Tue, Apr 18, 2017 at 10:40 PM Aki= Tuomi <aki.tuomi@dovecot.fi= > wrote:
On April 19, 2017 at 8:21 AM Neil Jenkins wrote:


On Tu= e, 11 Apr 2017, at 02:52 PM, Neil Jenkins wrote:
We talked a bit in Chicago= about RFC 8030[1] and what mechanisms we

should support f= or push. Having looked at RFC8030 in a bit more
detail, the JMAP server = is just the "Application Server" in this model
(the other two = participants are the "UA" and the "Push Server"). Weshould specify the behaviour such that it is compatible in this role,
<= /blockquote>
but not constrain it further. The Web Hook[2] part of the curr= ent

draft of the JMAP spec basically already does this. I = think we just
need to add a few headers to the calls to the push server = to make it
compliant: TTL, Topic and Urgency.
<= /div>
Can I take the lack of argument about t= his as consensus that this is the
right way forward? :)
Neil.

Fwiw, using exist= ing standard is a good idea. Had a quick look and it looked ok.

Aki

=20 _______________________________________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/mailman/listinfo/jmap
--94eb2c1966aa8bd354055436f312-- From nobody Thu Jul 13 21:36:26 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 BB9EC131AA1 for ; Thu, 13 Jul 2017 21:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, 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 (2048-bit key) header.d=fastmailteam.com header.b=bt+zjzTO; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SxXpte6k 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 EP-VU9r9J_mK for ; Thu, 13 Jul 2017 21:36:24 -0700 (PDT) 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 21584129B66 for ; Thu, 13 Jul 2017 21:36:23 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 6C77E20AA7 for ; Fri, 14 Jul 2017 00:36:22 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Fri, 14 Jul 2017 00:36:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.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=fm1; bh=N1IqwgTvfut9GEjh7 fClltivK5pWJkULUsolkXm9DIE=; b=bt+zjzTOxLMg8T4l1IHjNivbituyZQ3VK SDcOKB4tOR0yVePFyZfvX9oA+rRy3hd3ImiPvAsZFJZuYBMXRSzrbssFLJ3odbQV I/1P7M0/xV9qQlgkXftmjXj9+6+90NHVGCBtTErdsA0UMI5JOXs8c3aKnxKUdRHH HMvOKbqXC7VerwrhO0WZhqn+fsC1Fl9BDMm16ie0/ELRMrkqLInN9PPY5qGfoUoF pRfWDq+/ipv9LZYjJt2SxLP6aiO6CtGR4biCZn4kJbJe4pIYfr2cHwPpi5gGyHJj OXX/hT7yiqLmqhhh6VU9lyxnraEKS2F6r4rpND+prq5rikumzKRhA== DKIM-Signature: v=1; a=rsa-sha256; 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=fm1; bh=N1Iqwg Tvfut9GEjh7fClltivK5pWJkULUsolkXm9DIE=; b=SxXpte6ktFDdHN7M7DwXKv kVJlXKMGIY/UOg4Ikb1zy/32Kv/U67XmtJ0GwkA38I8Wg9K3jRlH8pEJ8UZEIjZC 6iIBwZzmADfb7HAhxXUMrKabYp6w1YNSm6QuykMquT3bLcSRNZTcgvO5DF8hFIoJ 8qqAdnxRDcmXNjtwqJDXfevvl1bxT7OPY+fyH/A/y0BNn/mq2k8TWIzaN4RmmmV5 KnV6mTeg1kAQUoxGvmH9IPiwAG4nX3d/oK6GGNQ+NAYeELi3m8P8PwtDL1MPRis0 MDpdSUsoafJvkdaTHUo8bREbbucqQHjJrwtBPobODnP1hixeyRQ1j/NVdelxPEWw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 1E7B6E21CF; Fri, 14 Jul 2017 00:36:22 -0400 (EDT) Message-Id: <1500006982.3128200.1040505360.7E937418@webmail.messagingengine.com> From: Neil Jenkins To: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150000698231282000" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e68a8ca3 References: <1491886379.444171.940831720.06C71198@webmail.messagingengine.com> <1492579277.2998458.948887296.01406185@webmail.messagingengine.com> <1594590924.2859.1492580398931@appsuite-dev.open-xchange.com> In-Reply-To: Date: Fri, 14 Jul 2017 14:36:22 +1000 Archived-At: Subject: Re: [Jmap] Push mechanism X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 04:36:26 -0000 This is a multi-part message in MIME format. --_----------=_150000698231282000 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" OK, I have now made a pull request with my proposed spec changes to make the Push mechanism compliant with the application server role in RFC8030: https://github.com/jmapio/jmap/pull/100 Feedback welcome either as direct comments on the changes in the GitHub issue or on the mailing list. Cheers, Neil. --_----------=_150000698231282000 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
OK, I have now made a pull request with my proposed spec changes to mak= e the Push mechanism compliant with the application server role in RFC8030:=  https://github.com/jmapio/jmap/pull/100
Fe= edback welcome either as direct comments on the changes in the GitHub issue= or on the mailing list.
Ch= eers,
Ne= il.
--_----------=_150000698231282000-- From nobody Thu Jul 13 22:48: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 701351316E2 for ; Thu, 13 Jul 2017 22:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 I_vQNQMwyjZm for ; Thu, 13 Jul 2017 22:48:02 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 436C4131A94 for ; Thu, 13 Jul 2017 22:48:02 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id v202so12518377itb.0 for ; Thu, 13 Jul 2017 22:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M0cnmqDCmCW3UK9zSrRoJNi86pOe9Ep0l2vxZvZZhRE=; b=EZ80xPOUF1zMwsM4yTRLhQL1DLKz1cAkSXkWXFp26lTt5OZXwE9qYkgN2LVMy5zbFP Uk3QzMS0Y9d1JlOV50SOdvXYtstzkCLFW7yjsgPk3kyy21Rc9ZUmbLOUjvlWlSizWRzn xQbgtuy1xbjlLfFsKgwiBVpsVuvFQwlGtmJpIWxP/3Upkd0/zfGIt07dyzYrv8G3GXP6 tAFttVQr8jMtVyK41l4eATW1P2U36g/I8V5MZpHVrxeuoMcT0TV9pUSEVhel12tZaaFF UPqRR0W1xk9+W/l0VDcvJGbZDv90Wd0rK0jcqSDGD78sBQV3SRL/rXtkC+F8ukFLaetT cGKQ== 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; bh=M0cnmqDCmCW3UK9zSrRoJNi86pOe9Ep0l2vxZvZZhRE=; b=hPn7rVW2Sx27PgTERzRTQ8ROUn3jnH+bDCp3xmDBcxBbNNAmdy7xIGZiS6x355XtD/ mqf4h9wT9C5TI/Jsbh3XVPTtdVaZDI11K9SZb8S6rOq9SS7BYLCvpJCbeWAq2v8FZCXs LM3foJlZQy/rwxVDBEq/2NeXztrjpYNMt5u7DJtK/MqKduY6OqJ6k7V5HUh9hwXOeldr m3Db1HikqQ5xABMMJdsBEoa51C7UnKnSh+SkjxC8baQsJjLkmxTAN5d24R5ikw+7i47c ZG1ucYtVmxGnG5Dc1hqQ/JVRDboZqowHqqAqDMHP9wE1btLO9nxYzDxFWyazbgchuBr3 ip8A== X-Gm-Message-State: AIVw111YmFUdZ/PR5Nkwf6L1NfIyHXHkbuZFok1z6YKm9LbXFO+dVPaN I9fFSHG6zWFoIVkEqCDpJ81/jNN/iN6k X-Received: by 10.107.39.205 with SMTP id n196mr6603538ion.37.1500011281601; Thu, 13 Jul 2017 22:48:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.26 with HTTP; Thu, 13 Jul 2017 22:48:00 -0700 (PDT) In-Reply-To: References: <1491886379.444171.940831720.06C71198@webmail.messagingengine.com> <1492579277.2998458.948887296.01406185@webmail.messagingengine.com> <1594590924.2859.1492580398931@appsuite-dev.open-xchange.com> From: Martin Thomson Date: Fri, 14 Jul 2017 15:48:00 +1000 Message-ID: To: Neil Jhaveri Cc: Aki Tuomi , Neil Jenkins , jmap@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Jmap] Push mechanism X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 05:48:04 -0000 What Apple does with Apple's products is Apple's business. However, if you want to use the web Push API, then you will need to use the protocol. On 14 July 2017 at 04:17, Neil Jhaveri wrote: > A little late here... but since this is on the meeting agenda, I'll confirm > that this seems like the right direction to me too. Before I left Apple, I > had a chat with a few of the devs working on APNS and they also thought this > was a reasonable direction, and could see implementing the App Server --> > Push Server portion of RFC 8030, while leaving the Push Server <--> User > Agent portion custom. Right now, the App Server --> Push Server portion does > require a special certificate, and doesn't meet RFC 8030. > > I vaguely recall Martin mentioning during the first meeting that RFC 8030 > mostly made sense in the context of the browser. @Martin, now that you're on > this list, I wonder if you could provide your thoughts on this. > > On Tue, Apr 18, 2017 at 10:40 PM Aki Tuomi wrote: >> >> On April 19, 2017 at 8:21 AM Neil Jenkins wrote: >> >> >> On Tue, 11 Apr 2017, at 02:52 PM, Neil Jenkins wrote: >> >> We talked a bit in Chicago about RFC 8030[1] and what mechanisms we >> >> >> should support for push. Having looked at RFC8030 in a bit more >> detail, the JMAP server is just the "Application Server" in this model >> (the other two participants are the "UA" and the "Push Server"). We >> should specify the behaviour such that it is compatible in this role, >> >> but not constrain it further. The Web Hook[2] part of the current >> >> >> draft of the JMAP spec basically already does this. I think we just >> need to add a few headers to the calls to the push server to make it >> compliant: TTL, Topic and Urgency. >> >> Can I take the lack of argument about this as consensus that this is the >> right way forward? :) >> Neil. >> >> Fwiw, using existing standard is a good idea. Had a quick look and it >> looked ok. >> >> Aki >> >> _______________________________________________ >> Jmap mailing list >> Jmap@ietf.org >> https://www.ietf.org/mailman/listinfo/jmap > > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap > From nobody Fri Jul 14 05:51:24 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 4BF59131A5C for ; Fri, 14 Jul 2017 05:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 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 z2ad7OX-a71X for ; Fri, 14 Jul 2017 05:51:12 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 95B00131A68 for ; Fri, 14 Jul 2017 05:51:11 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v6ECp8MN027160 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 14 Jul 2017 12:51:08 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v6ECp7HJ009181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Jul 2017 12:51:08 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id v6ECp5u4006691; Fri, 14 Jul 2017 12:51:06 GMT Received: from [10.62.152.255] (/46.189.28.46) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 14 Jul 2017 05:51:05 -0700 From: "Chris Newman" To: "Neil Jenkins" Cc: jmap@ietf.org Date: Fri, 14 Jul 2017 14:50:56 +0200 Message-ID: <1D965B45-B630-4BE4-BE42-606E03DE1C1F@oracle.com> In-Reply-To: <1499146797.2319096.1029695160.34130D2D@webmail.messagingengine.com> References: <1499146797.2319096.1029695160.34130D2D@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: Re: [Jmap] New message sending API proposal X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 12:51:22 -0000 I think this is moving in a good direction... On 4 Jul 2017, at 7:39, Neil Jenkins wrote: > Hi all, > > Hopefully we can get this area resolved by the end of the Prague > meeting, so I'm sending through a first draft for initial discussion. > I think the proposal addresses the concerns that were raised by > various people on the list, while remaining consistent with the rest > of JMAP. > *Sending a message* > > The core idea is the introduction of a new MessageDelivery object > type. To send a message, you create a new MessageDelivery, which has > the following properties: How about calling it a MessageSubmission object? Semantically, this object becomes a record of a message submission (whether or not the message is delivered). > * *id*: String The id of the message delivery. This is server-set and > immutable. > * *messageId*: String The id of the message to send. This is > immutable. > The message being sent does not have to be a draft, for example > when > “redirecting” an existing message to a different email address. > * *threadId*: String The thread id of the message to send. This is > immutable and set by the server to the *threadId* property of the > message referenced by the *messageId*. > * *envelope*: Envelope|null > > > Information for use when sending via SMTP. This is immutable. An > *Envelope* object has the following properties: > > * *mailFrom*: String The email address to use as the return address > in the SMTP delivery. This may be the empty string. We also need the envelope mail from parameters. Perhaps: * *mailFromParams*: Object. Mail from parameters are converted to a JSON object with the parameter name as a string key and the parameter value as a string value (with any xtext or unitext encodings removed, (RFC 3461, 6533) and JSON string encoding applied to the value). > * *rcptTo*: String[] An array of email addresses to send the > message > to. If the *envelope* property is null or omitted on creation, > the > server MUST generate this from the referenced message as follows: And we also need the Rcpt To parameters. > * *mailFrom*: The email in the *From* header, if present. > * *rcptTo*: The deduplicated list of emails from the *To*, *Cc* and > *Bcc* headers, if present. > * *sendAt*: Date|Duration|null This is not needed. If you have mail from parameters, you just use "holdfor" or "holduntil" mail from parameters as defined in RFC 4865. > * *maybeCanUnsend*: Boolean If true, attempting to unsend the message > by destroying the MessageDelivery object, *might* succeed. This is > server set. On systems that do not support unsending, this will > always be false. On systems that do this, it will start as true, > and > MAY transition to false when the server knows it definitely cannot > recall the message, but MAY just remain true. These semantics work for me. Good balance between simplicity for client and flexibility for server. > Simple SMTP proxies would not store these objects, but more advanced > servers would allow you to retrieve them later, for example a client > might fetch a list of all the MessageDelivery objects with > maybeCanUnsend == true, to present to the user messages they can still > possibly cancel. I like that flexibility. These objects look like a client view of a submission log. That's useful in and of itself; definitely worth the effort to persist these objects. > The MessageDelivery object also seems an ideal place to be able to put > delivery status for servers that support this, so clients can query > for each email address the message was sent to, what happened > (delivered? If not, what was the error? Has it been read?). Any > thoughts on whether this is a good idea and what pieces of information > should be represented? Good idea. The starting point I'd suggest is a JSON representation of: * RFC 3464 message/delivery-status * RFC 3798 message/disposition-notification * RFC 3886 message/tracking-status All the semantics are standardized already. So changing the syntax isn't a big deal. > *Unsending a message* > > To unsend a message, you destroy the MessageDelivery object, using > standard JMAP commands. If this succeeds, the delivery was > successfully cancelled. Otherwise you get an error. If the object is semantically a record of a past submission, I think unsend is more of a modification of the record then a deletion of the record. Perhaps add a mutable "unsendAttempted" (client set boolean) property? > *Updating the message if the send/unsend is successful* > > We really want the ability to include in the same API command an > update to perform on the message if the send/unsend succeeds (i.e. the > MessageDelivery object is successfully created/destroyed). For > example, remove the $Draft flag and move the message to the sent > folder. > Without this, you would need two round trips (the client would need to > wait to see if the send was successful before updating the message), > which increases the likelihood of the send succeeding but the client > losing the connection for whatever reason and so never updating the > message. > At the moment, this is enabled by extra onCreateUpdateMessage and > onDestroyUpdateMessage arguments to the setMessageDeliveries method. > They work like this:For each successful create/destroy, the server > should see if there is an entry with the same id in the > onCreateUpdateMessage/onDestroyUpdateMessage properties respectively. > If so, add an entry to an (initially empty) *update* object, with the > key being the *messageId* on the MessageDelivery object that was > created/destroyed, and the value being the value from the > onCreateUpdateMessage/onDestroyUpdateMessage object.After the > *messagesDeliveriesSet* response is emitted, if the *update* object is > not empty, an implicit call is made to *setMessages*, with the > following arguments: > > > * *accountId*: Same as for the call to *setMessageDeliveries*. > * *update*: The *update* object as calculated above. > This is a little awkward, but I haven't managed to come up with a > better way of representing this ability. Any thoughts? Ideas for > improvements? This is acceptable. Right now an API request always attempts all methods. The other way to do this would be to have an API request variant that executes a sequence of methods but halts the sequence on failure. I also think the suggestion to default the mail from based on an identity reference is a good one. > Yeh, this doesn't currently allow that. I agree this is going to be a > thing clients want to do, so how to represent > it? Bron suggested an update of the "id" property to `null` for > delete, but I'm not a huge fan of the idea. If we do unsend by updating an "unsendAttempted" property, then you can remove the record of the submission by deleting the object which seems clean to me. - Chris From nobody Fri Jul 14 06:10: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 A9AC413170E for ; Fri, 14 Jul 2017 06:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.002 X-Spam-Level: X-Spam-Status: No, score=-7.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, 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 Mvv9D4uzSsUa for ; Fri, 14 Jul 2017 06:10:27 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 4F43C12F17A for ; Fri, 14 Jul 2017 06:10:21 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v6EDAKID031825 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 14 Jul 2017 13:10:20 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v6EDAJ91002710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 14 Jul 2017 13:10:19 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v6EDAJvX001428 for ; Fri, 14 Jul 2017 13:10:19 GMT Received: from [10.62.152.255] (/46.189.28.46) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 14 Jul 2017 06:10:19 -0700 From: "Chris Newman" To: jmap@ietf.org Date: Fri, 14 Jul 2017 15:10:12 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: [Jmap] Review of draft-ietf-jmap-core-00.txt and draft-ietf-jmap-mail-00.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 13:10:29 -0000 draft-ietf-jmap-core-00 Overall: This is a high quality -00 document. 2.2 Getting an access token You refer to "POST request" before defining what that means. I think you need a clear statement that JMAP as described in this specification runs on top of HTTPS, but the design does not preclude running JMAP on top of an application protocol with semantics similar to HTTP in the future. 2.2.1 more authorization required SASL/GSSAPI? * Kerberos, SCRAM, etc Recommend dropping yubikeyotp & u2f from base spec, but create a registry for AuthMethod that is expert review so they can be added later if need be. Need to specify a minimal security mechanism that must be implemented for interoperability of implementations. Likely https with current TLS policy + password. It's OK to turn off the minimal mechanism as a site policy matter if better mechanisms are available, but this is helpful guidance for implementers. If implementer A does passwords only, implementer B does oauth only, and implementer C does totp, these implementations won't interoperate. 2.2.2 authentication complete This should clarify if the server is allowed to return a different 'username' from the POST request. > maxObjectsInGet: Number The maximum number of obje ts that the client > may request in a single getFoos type method call. Typo: obje ts => objects Why base64url rather than base64? communicate expected lifetime of accessToken & signingKey? Recommend including a password expiration warning (either timestamp or X days/hours). accounts / isReadOnly: if the entire account is read-only => if the entire account is read-only based on this access token. Q: does this cover flags? *URL => need to define minimum supported set of URI types. 2.2.3-2.2.9 Need error codes for: * Account Disabled / Contact Admin * Password Expired 2.2.9: maybe should be 'service temporarily unavailable'. Should server suggest a backoff in the payload? There should probably be some definition of "exponential backoff". 2.5.1: needs hash agility; at present time, HMAC SHA-256 MUST be implemented, but algorithms may be added or deprecated by future best practice documents. 3.2. API structure This model only allows extensibility by adding methods or altering method parameters. There's no way to attach properties to the entire API request. There are a number of potentially interesting request-level properties such as "fail on error" (stop on first error) or "transaction"/"atomic" (either perform all methods successfully or none of them). If you made the top-level an object and the array of methods a property of the top-level object, you'd get request-level extensibility. 3.3. Errors "transport level" => This seems wrong because TCP is typically the transport level for HTTP-based protocols, but returning a TCP-level error is not desirable here. Why not just simplify this to one sentence saying the error is returned at the HTTP level. 3.6 Concurrency For potentially long-running operations like search and copy/move-messages, the creates an inappropriate and unnecessary implementation burden on the server. In general, the goal is that the server should present a consistent view of data to the client, even if it's slightly out-of-date by the time the method completes. It's fine to state this and even say the ability of a server to present a consistent view to clients is a quality-of-implementation issue for the server. But don't force the presence of a hard locking mechanism into the server implementation unless it's absolutely necessary as that harms server scalability. Normative restrictions on concurrency should be specified for those methods that need them and be minimally restrictive. For example, a multi-message move operation should either move all messages or none of them, and the messages should retain their relative ordering in the destination folder. But additional restrictions are not needed to present a good client experience. 3.8 Date datatype Are you sure you want to pin the timezone of timestamps to UTC? This potentially loses information. 3.10.1 getFoos state: need to specify scope and duration of this string. I'd guess it is scoped to the specific getFoos request, so there's no requirement for portability of this state token to other users or types. But it'd be better if it's quite persistent (e.g., lasts a month or until the client issues an update). 3.10.2 getFooUpdates fetchRecords & fetchRecordProperties Instead of two separate parallel properties, how about defining fetchRecords as having the same structure as a getFoos object, but with appropriate defaults for accountId and ids. This way, extensions to the getFoos object naturally apply to the fetchRecords value object. If the cannotCalculateChanges error occurs too frequently, the server becomes problematic for client performance. A quality server should strive to persist state tokens for several clients per user for at least a month. 3.10.3. setFoos > Each create, update or destroy is considered an atomic unit. I suggest: Each create, update or destroy list item is considered an atomic unit. > record, so it can substitute in the correct value if necessary in > later method calls. The type dangling end of paragraph. > a separate creation id -> id map MUST be kept for each type. I assume these must only be kept for the duration of a single API request? It would be helpful to say that explicitly. 3.11.1. getFooList position: it's very useful to specify position relative to the end of the list. For mail, the following search is common: "the 50 most recent not-deleted messages". I suggest making -50, the 50th position from the end of the list (the way Python list slicing works). Failure to add support like this makes RFC 5267 partial results far less useful than it could have been. For the response, always using non-negative positioning makes sense. 5. Uploading binary data Can you make the header "JMAP-AccountId" instead of "X-JMAP-AccountId" per RFC 6648? 5.1 file upload The 'type' field is not well defined. Is this the Content-Type header field with CFWS collapsed to SP and RFC 2231/2047 encoding removed? Or should the content-type parameters be split out into a separate property with an object as a value? size: For IMAP compatibility, this needs to allow sizes up to 2^32-1, 6.2 Web hook > The JMAP server MUST follow any redirects. Maybe I'm a bit paranoid, but I suggest: The JMAP server implementation MUST be capable of following at least one redirect, but MAY choose not to do so for configured policy reasons. 6.2.1. setPushCallback I think this needs another error code: policyDenied: The server is not willing to connect to the specified URL for policy reasons. ==== draft-ietf-jmap-mail-00 2. Mailboxes Need to distinguish JMAP message id from RFC 5322 Message-ID header. Duplicate 5322 message ids occur, so it's helpful to have a JMAP message ID that's unique within an account. role: I support proposal to either remove 'outbox' (or make it optional) and replace with MessageDelivery/MessageSubmission object. I'd also like to see this more closely aligned with RFC 6154 (at least use the same names). We should discuss issue of multiple folders with same role; I like the simplicity of not having that, but RFC 6154 was written as it is for a reason; we should make sure that reason doesn't apply to JMAP before changing that design. sortOrder: don't hand-wave the locale-specific character order problem as that breaks interoperability. I suggest abstracting the problem by associating a collation (RFC 4790) with each account. If there's a collation associated with the account, that produces a deterministic order. Otherwise, permission has been given to be non-deterministic. Server operators can derive the collation algorithm name from the user's language when they register their account; then it will work even on a client with the wrong locale configured. mustBeOnlyMailbox: I don't understand the distinction. Is it important? "may*": Can we just replace this with a "myrights" per RFC 4314? If you want to drop the rights grouping model of RFC 4314 to be simpler, that's fine with me, but I'd prefer to keep the set of rights the same. 2.3.3. updating mailboxes myrights (may*) isn't immutable; it's server-generated (possibly based on an IMAP ACL from RFC 4314) so the client can't directly update it. I think it's fine to leave ACLs as an extension to base JMAP but having the equivalent of myrights in the base spec is a good decision. 3.1.1 filtering This really needs to be semantically closer to IMAP. In particular, support for extensible flags is needed. Does this need an extensibility mechanism? A way to filter the search that's ignored if not understood by the server (like non-critical LDAP search controls)? 3.1.2. Sorting We have a collation model (RFC 4790) that covers sorting. I think servers need to implement either RFC 5051 or the Unicode Collation Algorithm as a minimum/default. Allowing a collation to be specified would be good for interoperabiltiy/predictability. 5. Messages Overall, I find this to be almost as problematic as the sending model of the specification. I understand the goal of trying to make a minimal JMAP client work without having to implement 5322/MIME/2047/2231. But the problem with creating a data format gateway is you've got the union of the problems and the intersection of the functionality. And while having a way to fetch the raw blob is nice, that's not great for clients that want some of the 5322/MIME/2047/2231 functionality that's missing from JMAP but don't want to be forced to fetch the full message and do a full parse of it. I suggest a different approach. First, define a set of properties that are largely un-adulterated (similar to IMAP header fetch, IMAP body part references, etc). Then define properties that try to convert/simplify/flatten that data (losing information in the process). Then clients can choose the level of precision they want. You'll need to describe the algorithms used to convert/simplify/flatten the data in detail. And if you're going to simplify some address fields, you need the ability to simplify all of them, including ones like Message-Disposition-To. > or RFC 2047 encoding of non-ASCII characters, MUST be fully decoded > into standard UTF-8. If you say this, you need to identify the charsets that MUST be supported; otherwise the requirement is impossible. You'll also want to mention RFC 2231. > hasAttachment: Boolean Does the message have any attachments? You need to define what you mean by an attachment. Do you mean a MIME part with a Content-Disposition of "attachment", or do you mean something else? Be precise. textBody & htmlBody: I assume these are converted to UTF-8? This model is not good. I generally want to be presented the plain text body if present and the HTML body if the text body is not present. Are you unfolding RFC 3676 for this? What if it's S/MIME signed? date: the timezone of the sender is relevant information, so if you're parsing out the date, you should parse out that field as well. For submission you need a way to provide the timezone. 8. Vacation Response Can this be moved to an extension? The question of how this interacts with Sieve, ManageSieve, etc, is tricky. ==== Missing stuff: * email address internationalization => the protocol could be defined in such a way that this will mostly "just work" (to the degree that's possible). Needs changes to Emailer object, Message object, etc. I don't have time to do it now, but I'll run through the list of IMAP extensions to come up with more 'missing stuff'. - Chris From nobody Fri Jul 14 11:50:13 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 4AD88129BA4 for ; Fri, 14 Jul 2017 11:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.534 X-Spam-Level: X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] 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 r5W9DBv5Fm6s for ; Fri, 14 Jul 2017 11:50:08 -0700 (PDT) Received: from mout02.posteo.de (mout02.posteo.de [185.67.36.142]) (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 5265D12741D for ; Fri, 14 Jul 2017 11:50:08 -0700 (PDT) Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 3x8MF81pqrz10HY for ; Fri, 14 Jul 2017 20:50:03 +0200 (CEST) From: Lukas Eipert Content-Type: multipart/alternative; boundary="Apple-Mail=_DB5E2AF6-4B12-4AC4-8A2D-95964AC27158" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Fri, 14 Jul 2017 20:50:03 +0200 To: jmap@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Jmap] JSON Schema X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 18:50:12 -0000 --Apple-Mail=_DB5E2AF6-4B12-4AC4-8A2D-95964AC27158 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, I had a quick glance over the jmap specification [1] in the github repo. = In my opinion it would be useful to convert the markdown descriptions to = json schema [2]. This should make it easier 1. to validate the spec itself 2. to validate servers/clients against the spec 3. generate documentation [3] I could spend some of my time helping you with a migration to json = schema and setup of a json-schema->documentation pipeline starting end = of July iff you are interested. Otherwise the project looks great and I wish the best of luck that xkcd = 927 [4] may not be the future for this project ;) [1]: https://github.com/jmapio/jmap/tree/master/spec/mail = [2]: http://json-schema.org/ [3]: https://github.com/cloudflare/doca = [4]: https://xkcd.com/927/ --Apple-Mail=_DB5E2AF6-4B12-4AC4-8A2D-95964AC27158 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi all,
I had a quick glance = over the jmap specification [1] in the github repo. In my opinion it = would be useful to convert the markdown descriptions to json schema [2]. = This should make it easier

1. to validate = the spec itself
2. to validate servers/clients against the = spec
3. generate documentation [3]

I could spend some of my time helping you with a migration to = json schema and setup of a json-schema->documentation pipeline = starting end of July iff you are interested.

Otherwise the project looks great and I wish the best of luck = that xkcd 927 [4] may not be the future for this project ;)


[1]: https://github.com/jmapio/jmap/tree/master/spec/mail
[2]: http://json-schema.org/
[3]: https://github.com/cloudflare/doca
[4]: https://xkcd.com/927/

= --Apple-Mail=_DB5E2AF6-4B12-4AC4-8A2D-95964AC27158-- From nobody Sun Jul 16 10:31: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 0E860129A9F for ; Sun, 16 Jul 2017 10:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, 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 (2048-bit key) header.d=fastmailteam.com header.b=bd5RC9t6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=V5xB7mkp 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 lSmPSRNmtK-R for ; Sun, 16 Jul 2017 10:31:17 -0700 (PDT) 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 CE160124D68 for ; Sun, 16 Jul 2017 10:31:16 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 44FEB20719 for ; Sun, 16 Jul 2017 13:31:16 -0400 (EDT) Received: from web1 ([10.202.2.211]) by compute6.internal (MEProxy); Sun, 16 Jul 2017 13:31:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=sWrLLIcZZXA6eFtCXt0DJP5fs9j0j3N9leA7IRvoS Z0=; b=bd5RC9t6fmCHPvuz2TPcIKgJlmkg01ZWcJ1cgXcx3wUcdwmrl+hssAPOX MolgqwcMngbdeaGdioFiuBWZQiLjG7Vl6wkPoI4Pmnylowo4QhndEGzEya8yg7pr bs7Zk8QY3Jw4Cqnva+9wLaySOpYSPq1qvaCmMLzKZGWaz+OFgt3KDc4anU2EQSjf kNVHcLmMcANiLJ5RXjKk89thLF9clyGJg/lkgXw97Oc13NPo7u+F2o2Sq3uZcMdn 2aYbwb0xp4cbraO6utTI3WRiWYjf62pLdrCOjLe2Ip7/XHmigzc/0p2JQuwXol+l 7aen51jBJbf2V/Czq8Htsv9y+B0MQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=sWrLLIcZZXA6eFtCXt0DJP5fs9j0j 3N9leA7IRvoSZ0=; b=V5xB7mkpNzpBtN2LHoqMVJewYKdTOgTCBFMtKwjgk4+k5 niFkWqmmAU1xdLAbJBqV/EvGTGhJ8ITx5ahjB/mmPVbKWesDzXllXzL6DCTyJdyp gYRvYqIbXtwTiVNl5oOrLeTNmsDHbfMVf9O7Y/MU3/IL3I3V0x6RmmFBYTdjPC6+ /kYBzJhiSufewXxZDpidKfV7Z7SoNIyX5E7aB8j9Ty8+mPHGsQ7XLsL54S7nx2yN WL1u1r9yYbueKv57ZWuwPpgSDnpzDMgg7+skN19TQgaf7AWQTB6KipJHg3pJIMvy bzrbpB7hz8MeHpkDcE9S08fFk+k0WaqVX9UmIWbCQ== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 0AC189467E; Sun, 16 Jul 2017 13:31:16 -0400 (EDT) Message-Id: <1500226275.808580.1042572648.64F5140E@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15002262768085800" X-Mailer: MessagingEngine.com Webmail Interface - ajax-b8c51eee Date: Mon, 17 Jul 2017 03:31:15 +1000 Archived-At: Subject: [Jmap] Agenda updated X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 17:31:20 -0000 This is a multi-part message in MIME format. --_----------=_15002262768085800 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" I've uploaded a new agenda: https://datatracker.ietf.org/doc/agenda-99-jmap/01 Changes are: - we have more time, so I've expanded the estimates out a bit to use that time.- put 5 minutes at the start to refresh our memory of the problems that JMAP is trying to solve and what our charter covers- moved JMAP-Mail first as it has fewer controversial items - reordered items within each category to put items likely to blow out time towards the end I've been working on slides, but they're not quite finished yet. Will upload slides later tonight or tomorrow morning. Bron -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_15002262768085800 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
I've uploaded a new agenda:


Changes are:
- we have more time, so I've expanded the estimates out a bit to use that time.
- put 5 minutes at the start to refresh our memory of the problems that JMAP is trying to solve and what our charter covers
- moved JMAP-Mail first as it has fewer controversial items
- reordered items within each category to put items likely to blow out time towards the end

I've been working on slides, but they're not quite finished yet.  Will upload slides later tonight or tomorrow morning.

Bron

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_15002262768085800-- From nobody Sun Jul 16 23:23:24 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 0B47F130154 for ; Sun, 16 Jul 2017 23:23:23 -0700 (PDT) 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, 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 (2048-bit key) header.d=fastmailteam.com header.b=Nk3CeHFE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JHT8OfGZ 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 LJHmWLHF1ojS for ; Sun, 16 Jul 2017 23:23:21 -0700 (PDT) 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 98E31120726 for ; Sun, 16 Jul 2017 23:23:21 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 018CF206A2 for ; Mon, 17 Jul 2017 02:23:20 -0400 (EDT) Received: from web1 ([10.202.2.211]) by compute6.internal (MEProxy); Mon, 17 Jul 2017 02:23:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=3BcG6RZkMeFqXLYe/6Mw+RF/DKDzSaHzNl7G0q6Bi ho=; b=Nk3CeHFEKf9rbUIdFJ2zcB4bV1bqJ5eqvB5Q0GKDcvst9azzVb3H6hfEY 7K+idxFvWX5B77+ZlBBE14TwVyyi+qTMkr+KRoVR1U8L++vPlJ8MncFRmDjNl7Bm y2+HJDsykxa0fuogyg81M7gJ5Ih8hZj5XJbbO4A99tqVd3Bu07+pCMuRarRk+VNx L4YztiW1vJweICZV0XZ4CszNh2S/xbJUFNknFyIDHDRRUr4mJ63HlJnzDZ4WkTjE mRyg3I7yvBjVLUxVt6cQgKvDvpYLRJ5lnBI82J7a+jXPc5UkDfNK4K7B0abP+8uG aK61e9BTXUVHfcD7DqgVrYFQIgQLQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=3BcG6RZkMeFqXLYe/6Mw+RF/DKDzS aHzNl7G0q6Biho=; b=JHT8OfGZP9eN9c+edd5FMTXpEopy8B5//E/FQzw3snW2X 3D1a2y9zngBXhqZn+hXZaXJEBLAPZuG/tI7LHrbwGyxCLnyLWTZHOkclZMhIRtR3 xkb0xyhc8e38rB+7Y0/xrKZbE8BeeUDwsEAW9Uud3640cwuWD93q4gbuzr19Tja9 CQZVWAC0BF0SdxHvr6AEuz/B9RXDNkmhTZrrpOOk95QFALZcruH8e8D9Jap8Ca51 gtxZXJztHvYIptHzcTXc4ZfXOrQBMDFKsxB457RqXgdhTGHjJNmeEwHZszF+Bssx 8isFcdW3wIRrAf36EoSev7X/nwpu8nWZ7FRU5iVgQ== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id BC6E394787; Mon, 17 Jul 2017 02:23:20 -0400 (EDT) Message-Id: <1500272600.1853648.1042995048.18DA59B2@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150027260018536480" X-Mailer: MessagingEngine.com Webmail Interface - ajax-b8c51eee Date: Mon, 17 Jul 2017 16:23:20 +1000 Archived-At: Subject: [Jmap] Drafts updated X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 06:23:23 -0000 This is a multi-part message in MIME format. --_----------=_150027260018536480 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Neil has just uploaded -01 of each of the drafts. These are the changes that have been made on github over the past few months, including the Keywords changes. Sorry about not uploading these earlier - next IETF we'll make sure drafts are uploaded in time for people to review on IETF datatracker rather than just reviewing the github change history. See you later today. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150027260018536480 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Neil has just uploaded -01 of each of the drafts.  These are the changes that have been made on github over the past few months, including the Keywords changes.  Sorry about not uploading these earlier - next IETF we'll make sure drafts are uploaded in time for people to review on IETF datatracker rather than just reviewing the github change history.

See you later today.

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_150027260018536480-- From nobody Mon Jul 17 00:27:22 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 D02D212EC0D; Sun, 16 Jul 2017 23:17:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.56.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150027226680.32737.12623316106203052386@ietfa.amsl.com> Date: Sun, 16 Jul 2017 23:17:46 -0700 Archived-At: X-Mailman-Approved-At: Mon, 17 Jul 2017 00:27:20 -0700 Subject: [Jmap] I-D Action: draft-ietf-jmap-mail-01.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 06:17:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol of the IETF. Title : JMAP for Mail Author : Neil Jenkins Filename : draft-ietf-jmap-mail-01.txt Pages : 61 Date : 2017-07-16 Abstract: This document specifies a data model for synchronising email data with a server using JMAP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-mail/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-mail-01 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-mail-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-mail-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 17 00:27:27 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 DE1E3131553; Sun, 16 Jul 2017 23:19:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.56.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150027234788.32552.816961202132220038@ietfa.amsl.com> Date: Sun, 16 Jul 2017 23:19:07 -0700 Archived-At: X-Mailman-Approved-At: Mon, 17 Jul 2017 00:27:20 -0700 Subject: [Jmap] I-D Action: draft-ietf-jmap-core-01.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 06:19:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol of the IETF. Title : JSON Meta Application Protocol Author : Neil Jenkins Filename : draft-ietf-jmap-core-01.txt Pages : 41 Date : 2017-07-16 Abstract: This document specifies a protocol for synchronising JSON-based data objects efficiently, with support for push and out-of-band binary data upload/download. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-core/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-core-01 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-core-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-core-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 17 07:13:48 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 442DD131BBA for ; Mon, 17 Jul 2017 07:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 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 PfXDLrTHTYKM for ; Mon, 17 Jul 2017 07:13:45 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 C079C131BF6 for ; Mon, 17 Jul 2017 07:13:39 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v6HEDc0j027561 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 17 Jul 2017 14:13:39 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v6HEDc3U020588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 17 Jul 2017 14:13:38 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v6HEDcgh004720 for ; Mon, 17 Jul 2017 14:13:38 GMT Received: from [31.133.136.212] (/31.133.136.212) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 17 Jul 2017 07:13:37 -0700 From: "Chris Newman" To: jmap@ietf.org Date: Mon, 17 Jul 2017 16:13:34 +0200 Message-ID: <70DDF0EC-CCBE-48C8-BA73-7EAE6012C517@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: [Jmap] Draft meeting notes X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 14:13:46 -0000 Topic: "why JMAP" Issue: JMAP Mail: keywords seems concluded action item: register four $XXX keywords for system flags (Chris volunteered to help with IANA considerations) discussion, but no objections from attendees Issue: JMAP Mail: Submission changed to use a more JMAP-ish MessageSubmission object ongoing discussion seems close to consensus action item: Chris Newman will propose syntax to align better with concern expressed about name "messageid" no other objections from attendees about general direction Issue: JMAP Mail: Message object & partial body fetch no proposal yet suggestion to expose IMAP MIME part numbers in attachment list discussion that HTTP range is probably not be sufficient needs more discussion Issue: JMAP Core: extension mechanisms needs some work but no significant controversy expressed in room Issue: JMAP Core: authentication action item: need to split to separate document action item: Torsten & Neil will discuss possibility of profiling OAuth point: possible interaction with token binding WG Issue: JMAP Core: push mechanism discussion of Martin's objections to EventSource discussion of encryption of push data Issue: JMAP Core: "transport" HTTP as a tunnel vs. HTTP resources for every object long discussion Github Tickets * changed vs. created in getFooUpdates (issues/78) * disallow destroying mailboxes with messages (issues/69) some preference expressed to allow delete of mailbox with messages * mailboxids property - Chris From nobody Mon Jul 17 07:30: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 7773E131C09 for ; Mon, 17 Jul 2017 07:30:48 -0700 (PDT) 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, 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 (2048-bit key) header.d=fastmailteam.com header.b=N1KZ0CX5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=g/qFfN+/ 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 8w_CXQMqD-sI for ; Mon, 17 Jul 2017 07:30:46 -0700 (PDT) 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 0B1B0131C10 for ; Mon, 17 Jul 2017 07:30:36 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 714BD20998 for ; Mon, 17 Jul 2017 10:30:35 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Mon, 17 Jul 2017 10:30:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=l/QejwDqcuzIWUQdkEeR05+edRt0BNwKYrdq3EMNC Cw=; b=N1KZ0CX5s3zvKd/iQR7pSKgcf46CaTvNFKVJUjVZyK5tb4ebFMPfs2GE/ zuS/VUnDPadeFytztg9baViSOT5y3OxIFx9nxK+hJRmGyuFMM0el8cyPulqXe3K8 Kg2MU3CQ7EYMxJtvMb7jxtwKSTOxz31blf+qFPkKtngm8RtSq1IpagtnX7hsiu+/ w4Q1D8M8QyqXQEwX2awPV2ByiK3uk2avEVSyjHo1aEO1+7Sa1WDNWcxCVKRT0m8O shI9z0p/U22ZVcnVzceuDdyN7qKsNWGlZhNdc0z0bwv4vY53cvD5XKNW1zBQsoRO 82i/jfAL5JnxmeKpfXRAZjBu1foGg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=l/QejwDqcuzIWUQdkEeR05+edRt0B NwKYrdq3EMNCCw=; b=g/qFfN+/No/vbNud3xbQgIPubVg56zubh3RU34UDnCOmw Q4b3fCH6VOFFkPI9FIaaHOKvCCqnWlohqmAjBziDZLJsLmRuSxo6QMBX5I0fRPhA I8cl58hO2CCCq+TiAhQvpp+AiTs4juUBtjBKt95cpoRswi7rCYTlPLZIliCEZWXG xXr61z9cy8q2veVPm3Nyvk/NAZSbuEKnwVLPJ25NvSF4a8J90V1cYidPIs5tzATq pHOGW7Krd2Ebsk9cTnfXW/ziX2EI83ijEUWWl4rAwBg8QecrQD41Q7iQC/8skrOf fVwHngv3u7J3Lib2/bFUF//IDM/R7RS/EspumnI0g== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 517EDBAB51; Mon, 17 Jul 2017 10:30:35 -0400 (EDT) Message-Id: <1500301835.1498112.1043444880.3FB433EB@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150030183514981120" X-Mailer: MessagingEngine.com Webmail Interface - ajax-b8c51eee Date: Tue, 18 Jul 2017 00:30:35 +1000 Archived-At: Subject: [Jmap] Dinner tonight 7pm X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 14:30:48 -0000 This is a multi-part message in MIME format. --_----------=_150030183514981120 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" http://www.currytandoor.cz/en/ Based on the show of hands I have reserved for 12 people. We will meet there at 7pm. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150030183514981120 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"

Based on the show of hands I have reserved for 12 people.

We will meet there at 7pm.

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_150030183514981120-- From nobody Mon Jul 17 08:08:27 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 2B3B4127077 for ; Mon, 17 Jul 2017 08:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 (2048-bit key) header.d=mailforce.net header.b=HE6EtwHb; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IEEKJ06P 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 cMhr90aWKmTY for ; Mon, 17 Jul 2017 08:08:24 -0700 (PDT) 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 71CDA1200FC for ; Mon, 17 Jul 2017 08:08:24 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id C5F08209AA for ; Mon, 17 Jul 2017 11:08:23 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Mon, 17 Jul 2017 11:08:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; 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:x-sasl-enc; s=fm1; bh=M9XnFv9Xk7gvbHktzN M2ll2UAvpoi/0Dsnr+k/3civI=; b=HE6EtwHb8aABiFdhKENV4D829Om5SQ2a+F nc+7C+/lOnPSzLn/1VQROkiKjxM6BU/mB9GXmk/c/3OEglhfNP8AUlPm5nlbKVp5 WgwcDRciaNwz+aIb/t49m3ZhL8vIRcPKwbRD9E/ltL7OyDtPzEKsjYiDi4ltlOqV LH8tP206cT7tAtKR2rIImpFAHvH0W2pjzKVVxNmHZyG9wXcooeE3NadzcB5W27Gl KhB+0XrSRfgTEdcelBZo7cq/1OLUsPpKWWRaLyagCf7lcDuilmb9PbmNusSkccR3 EY2XaxKnwuTgW035P3AmgJ5O3QrsDErDqLFvwgvXMfbCvusubgug== DKIM-Signature: v=1; a=rsa-sha256; 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:x-sasl-enc; s= fm1; bh=M9XnFv9Xk7gvbHktzNM2ll2UAvpoi/0Dsnr+k/3civI=; b=IEEKJ06P f5jtEVtm3Id4ak61UGDBSFcAoyRbfcI4aMOADzatkV3eYY+/RDUAlP5kZElAQF2D rUMY0sZcTkBtWXTRc9V2im8zdgcQ3f/iK/WFetUbHcinmhMEU9G647CkdyPssEO0 Jqcko62JA4OkcPi838+g3hEk+bw8TsiQ6S7IehvZM0qYJNj5BwbjZAcw0qD7X0hS 3UVwkss3c7zZRRlFCq4LsgErUOTden2YSUvuVLpldhkQG1RYpjy96rDm7mF7rDPd 3Ecjeao17zS2+GzjJSTNUp+IMKytv7KhH9K2DO3l1v3jUBuehizXwQKoiq7avx/8 xVkQfVww3MkXkg== X-ME-Sender: X-Sasl-enc: wo0ZApIcBPt3dgjkqgZsBtlAcIU5DH5bQki7VUSp1lWw 1500304103 Received: from [10.255.125.181] (45.sub-97-45-66.myvzw.com [97.45.66.45]) by mail.messagingengine.com (Postfix) with ESMTPA id 39C5E7E65E for ; Mon, 17 Jul 2017 11:08:23 -0400 (EDT) References: <150027226680.32737.12623316106203052386@ietfa.amsl.com> From: Stan Kalisch Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (13B143) In-Reply-To: <150027226680.32737.12623316106203052386@ietfa.amsl.com> Message-Id: <8B35955B-C77A-44FE-9CDB-872FBF6C3B10@glyphein.mailforce.net> Date: Mon, 17 Jul 2017 11:08:20 -0400 To: jmap@ietf.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Archived-At: Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-mail-01.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 15:08:26 -0000 Minor point: should not the terms "header field" and "header section" be us= ed as in RFC 5322? Stan > On Jul 17, 2017, at 2:17 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. > This draft is a work item of the JSON Mail Access Protocol of the IETF. >=20 > Title : JMAP for Mail > Author : Neil Jenkins > Filename : draft-ietf-jmap-mail-01.txt > Pages : 61 > Date : 2017-07-16 >=20 > Abstract: > This document specifies a data model for synchronising email data > with a server using JMAP. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-jmap-mail/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-jmap-mail-01 > https://datatracker.ietf.org/doc/html/draft-ietf-jmap-mail-01 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jmap-mail-01 >=20 >=20 > Please note that it may take a couple of minutes from the time of submissi= on > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap From nobody Mon Jul 17 09:16:21 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 68D83131C8F for ; Mon, 17 Jul 2017 09:16:19 -0700 (PDT) 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, 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 (2048-bit key) header.d=fastmailteam.com header.b=lh3Is2Cc; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=J6jvarq1 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 F_yRBMzc9zus for ; Mon, 17 Jul 2017 09:16:17 -0700 (PDT) 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 89C8612711E for ; Mon, 17 Jul 2017 09:16:17 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id E3A5420910 for ; Mon, 17 Jul 2017 12:16:16 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Mon, 17 Jul 2017 12:16:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.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=fm1; bh=Axwa6/byi0qRehpvy 2YoYvFSc5NH5ZHE+qmIOkQp7+E=; b=lh3Is2CcDCg0KjhIdS1CwnaB7TGyZM4Cd IrUxHcsa9wdXcgJjUTex7OckbOr7aodRz6Ynv27i6VfUswfJA2VEZZjwcXH2ddH4 oMZWg04/zPQM1bvloyhaVvGAGYTRy6HyjSW0j+D52I2G061hxclINhBKWprUharx fHbNzNVjXqHBpnB4/POn94v7ON1jWUZyBkr1FTbdzc1qYA8CfG95simgwYoB1r+x y6qXgqGpuGMDDEfWnmQL0vLnfqcgbH2rTYrBIxw5/0c5ATk1dmf/S9p7PkC7x2f0 H3bOeOQR3i4yv/o9axqQ+QPQHHPR9MA9DW/bEuBchjNnJLXT7BLMg== DKIM-Signature: v=1; a=rsa-sha256; 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=fm1; bh=Axwa6/ byi0qRehpvy2YoYvFSc5NH5ZHE+qmIOkQp7+E=; b=J6jvarq1AhMHcDTO791ZAs hC5wCA/WMVV6hnDfLKgV31v3Cac3WOtWMibTslB2FRDsCs4BEOBEChSvXQ6QUfWY TnxrvOyAGgckQbHP6o4WDf4Cmnf51Z5s27JULTIA0BGd9MNraqkXDdPaGVRKyuky ewzMJ7U7usRi5RK/m34563hEMtlwlbX9SQL6nN57IvB6G75Dqwvc1wFfltUTOTvy ZePm7EO9v3o35I5WqTWQ8mVDeX39zvTKl5qjajnmyEzZZqRPvwqHscisWAXq9yBL cgHIVaTdKt+e6vhInDMxGyG11buw46CmaqkPZvFLdkTlTTLa0FIVbNKN+pPcK1Fg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id C06FEBAB51; Mon, 17 Jul 2017 12:16:16 -0400 (EDT) Message-Id: <1500308176.1523484.1043579424.0E157144@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150030817615234840" X-Mailer: MessagingEngine.com Webmail Interface - ajax-b8c51eee References: <150027226680.32737.12623316106203052386@ietfa.amsl.com> <8B35955B-C77A-44FE-9CDB-872FBF6C3B10@glyphein.mailforce.net> Date: Tue, 18 Jul 2017 02:16:16 +1000 In-Reply-To: <8B35955B-C77A-44FE-9CDB-872FBF6C3B10@glyphein.mailforce.net> Archived-At: Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-mail-01.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 16:16:19 -0000 This is a multi-part message in MIME format. --_----------=_150030817615234840 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Tracking at https://github.com/jmapio/jmap/issues/101 On Tue, 18 Jul 2017, at 01:08, Stan Kalisch wrote: > Minor point: should not the terms "header field" and "header section" be> used as in RFC 5322? > > > Stan > >> On Jul 17, 2017, at 2:17 AM, internet-drafts@ietf.org wrote: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories.>> This draft is a work item of the JSON Mail Access Protocol of the IETF.>> >> Title : JMAP for Mail >> Author : Neil Jenkins >> Filename : draft-ietf-jmap-mail-01.txt >> Pages : 61 >> Date : 2017-07-16 >> >> Abstract: >> This document specifies a data model for synchronising email data >> with a server using JMAP. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-jmap-mail/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-jmap-mail-01 >> https://datatracker.ietf.org/doc/html/draft-ietf-jmap-mail-01 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-mail-01 >> >> >> Please note that it may take a couple of minutes from the time of submission>> until the htmlized version and diff are available at tools.ietf.org.>> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _________________________________________________ >> Jmap mailing list >> Jmap@ietf.org >> https://www.ietf.org/mailman/listinfo/jmap > > _________________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150030817615234840 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"


On Tue, 18 Jul 2017, at 01:08, Stan Kalisch wrote:
Minor point:  should not the terms "header field" and "header section" be
used as in RFC 5322?


Stan

On Jul 17, 2017, at 2:17 AM, internet-drafts@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the JSON Mail Access Protocol of the IETF.

      Title           : JMAP for Mail
      Author          : Neil Jenkins
  Filename        : draft-ietf-jmap-mail-01.txt
  Pages           : 61
  Date            : 2017-07-16

Abstract:
This document specifies a data model for synchronising email data
with a server using JMAP.


The IETF datatracker status page for this draft is:

There are also htmlized versions available at:

A diff from the previous version is available at:


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:

_______________________________________________
Jmap mailing list

_______________________________________________
Jmap mailing list

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_150030817615234840-- From nobody Mon Jul 17 09:48: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 35D38131B48 for ; Mon, 17 Jul 2017 09:48:39 -0700 (PDT) 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, 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 (2048-bit key) header.d=fastmailteam.com header.b=TKWGe7VP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Omq1Mxby 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 Td-Oxf_U--fE for ; Mon, 17 Jul 2017 09:48:37 -0700 (PDT) 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 52DD4131B61 for ; Mon, 17 Jul 2017 09:48:37 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id BC444209BE for ; Mon, 17 Jul 2017 12:48:36 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Mon, 17 Jul 2017 12:48:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.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=fm1; bh=MpTrxYYmdhwyGFLzN nhhy3xuW73Y074Vs/2quLd9+iQ=; b=TKWGe7VPtn+spVjgJ18b0pPuXUg3eJKFq Nt9E2Em1qm4PHL9O5a85Bh3U+39f2LzYvY9wko+vr3Jx9JuMqFlBLwQ5+yOnT7+1 e3wwhB/5m6Fyf0deS+mCwicRL0291XWv+SF+i2fSum5lTfwc7yUHs72AQmRlusPq sIu0CKG8B1YQU7XQU9mj0kjBQJ0SHi9t5NXR/KuiRDA205Hw0/Y5fXtIZ+J6QjSK rpBqmiV1vjke7sQJo13lE0cFNNWMA0hx089zKv92kPdzTnj/uYjECinCFo0Wm9cj s7/EoQ0ldjLFIVx1duw4cvGFaSl7HVYZSpJsA/KJaoJ8beYI/VV1g== DKIM-Signature: v=1; a=rsa-sha256; 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=fm1; bh=MpTrxY YmdhwyGFLzNnhhy3xuW73Y074Vs/2quLd9+iQ=; b=Omq1MxbyVzf9RqY/CpNfVs Mm391GPO0ma/vyhcltDBJNM3EdQj5ddmn5swu19BDHNXSEC+phnJANoKFMU/ron8 y5BVycoVp8sv+ltlx7B8MKi6kJER2HJ+EDbaQkU3VEIpvCSZYCBEPz3T8+UPeE4E ybjrKE7ztCzx+cBElBQkBhg5Wz/r8cDzf+9zf3WPvcORLJukPTfXlxlqQNOFICoX ek/ItIB7WAUQmzEupn8jReqHOJ+YVnzXWL8jko/fVKt6NZRzwzwvH+EdWDtOa+YS jxJDCbNUApwVCmprr48TL3SZV4VHpW5yNFWKNGsdzYFw7QHzyApBFhl1czrDMRiA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 94359BAB57; Mon, 17 Jul 2017 12:48:36 -0400 (EDT) Message-Id: <1500310116.1530592.1043581184.7A2BBD34@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150031011615305921" X-Mailer: MessagingEngine.com Webmail Interface - ajax-b8c51eee In-Reply-To: <70DDF0EC-CCBE-48C8-BA73-7EAE6012C517@oracle.com> References: <70DDF0EC-CCBE-48C8-BA73-7EAE6012C517@oracle.com> Date: Tue, 18 Jul 2017 02:48:36 +1000 Archived-At: Subject: Re: [Jmap] Draft meeting notes X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 16:48:39 -0000 This is a multi-part message in MIME format. --_----------=_150031011615305921 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Tue, 18 Jul 2017, at 00:13, Chris Newman wrote: > Topic: "why JMAP" > > action item: register four $XXX keywords for system flags (Chris > volunteered to help with IANA considerations) https://github.com/jmapio/jmap/issues/73 > discussion, but no objections from attendees > > Issue: JMAP Mail: Submission > concern expressed about name "messageid" https://github.com/jmapio/jmap/issues/102 > Issue: JMAP Mail: Message object & partial body fetch > no proposal yet > suggestion to expose IMAP MIME part numbers in attachment list > discussion that HTTP range is probably not be sufficient > needs more discussion https://github.com/jmapio/jmap/issues/103 and more generally: https://github.com/jmapio/jmap/issues/104 > Issue: JMAP Core: authentication > action item: need to split to separate document https://github.com/jmapio/jmap/issues/105 > action item: Torsten & Neil will discuss possibility of profiling > OAuth https://github.com/jmapio/jmap/issues/106 > point: possible interaction with token binding WG https://github.com/jmapio/jmap/issues/107 > Issue: JMAP Core: push mechanism > discussion of Martin's objections to EventSource > discussion of encryption of push data https://github.com/jmapio/jmap/issues/109 came up from a jabber question https://github.com/jmapio/jmap/issues/110 for the encryption question > Issue: JMAP Core: "transport" > HTTP as a tunnel vs. HTTP resources for every object > long discussion https://github.com/jmapio/jmap/issues/111 about working with HTTP folks on what we need that HTTP doesn't provide (yet), even if we don't change to meet it https://github.com/jmapio/jmap/issues/112 for the URL mapping of objects. > Github Tickets > * changed vs. created in getFooUpdates (issues/78) > * disallow destroying mailboxes with messages (issues/69) > some preference expressed to allow delete of mailbox with > messages > * mailboxids property https://github.com/jmapio/jmap/issues/113 for mailboxIds > > - Chris > > _________________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150031011615305921 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Tue, 18 Jul 2017, at 00:13, Chris Newman wrote:
Topic: "why JMAP"

  action item: register four $XXX keywords for system flags (Chris
volunteered to help with IANA considerations)


discussion, but no objections from attendees

Issue: JMAP Mail: Submission
  concern expressed about name "messageid"


Issue: JMAP Mail: Message object & partial body fetch
  no proposal yet
  suggestion to expose IMAP MIME part numbers in attachment list
  discussion that HTTP range is probably not be sufficient
needs more discussion


and more generally:


Issue: JMAP Core: authentication
  action item: need to split to separate document


  action item: Torsten & Neil will discuss possibility of profiling
OAuth


  point: possible interaction with token binding WG


Issue: JMAP Core: push mechanism
  discussion of Martin's objections to EventSource
  discussion of encryption of push data

https://github.com/jmapio/jmap/issues/109 came up from a jabber question

https://github.com/jmapio/jmap/issues/110 for the encryption question

Issue: JMAP Core: "transport"
  HTTP as a tunnel vs. HTTP resources for every object
  long discussion

https://github.com/jmapio/jmap/issues/111 about working with HTTP folks on what we need that HTTP doesn't provide (yet), even if we don't change to meet it

https://github.com/jmapio/jmap/issues/112 for the URL mapping of objects.

Github Tickets
* changed vs. created in getFooUpdates (issues/78)
* disallow destroying mailboxes with messages (issues/69)
  some preference expressed to allow delete of mailbox with     
  messages
* mailboxids property



- Chris

_______________________________________________
Jmap mailing list

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_150031011615305921-- From nobody Mon Jul 17 10:03:31 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 BC3AB131C54 for ; Mon, 17 Jul 2017 10:03:28 -0700 (PDT) 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, 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 (2048-bit key) header.d=fastmailteam.com header.b=M5SRB62a; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=et0v9pNH 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 uj9LxrlEcDe8 for ; Mon, 17 Jul 2017 10:03:27 -0700 (PDT) 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 DA381131BD9 for ; Mon, 17 Jul 2017 10:03:26 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 4ADDE20B6D for ; Mon, 17 Jul 2017 13:03:26 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Mon, 17 Jul 2017 13:03:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.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=fm1; bh=8AfjJWzBe7GTAYSBZ OTrZcRnjbWN5IEGZxORZH97ppk=; b=M5SRB62aUScZuGCvF3rErwrmQXwjWrqZL rfmA73PeXLPMJFEs2Ner3L63j/wN1apysFgorm3WtBpkbPtRgtAF1MqevAJkuynS wzLQuZZvhTU33dgje1vu0kvh/+mkpDjsRbT0iQut/EvZwTBRVPJsYQvH5jKtkPRH 5VJEqT6GncnoffQph6tN/vJL9OFUMO+8pC85tNuSR+oGFESrlmTMrURdGp4pr685 gNfQ+6l7lRBJn/3zu5Q387YeJW1sQKsX0PhkP10rdlEAeUnPomtwyelphNioTjSL spoLpSN3X3mmNzkfXySZj8wOjKgBBNz/hwig76Aw3iO3EgPrr4E0A== DKIM-Signature: v=1; a=rsa-sha256; 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=fm1; bh=8AfjJW zBe7GTAYSBZOTrZcRnjbWN5IEGZxORZH97ppk=; b=et0v9pNHsEIK4IliYE1Q62 0nUvDVX8oZZ8oZlHJCSWTPGcdebS5LuOivDqpCXmG3W/knIdonextjmNvlcNPKVk 0vbNGUStjRZLVgtw8NFC5Od5zPpC9zGZ2wbgngeTDj6MgfIlMEGOMRBVbhFFRQUh dFZNxqG+j9gh9UaWXRg065Vow8RS3qd8ivfQyaCWkkuqrbtiFivA+f0QC9dWUrUD URfaga0vKJFrO11WzbIpZaUvc9xmYRfOt2H6Nrv9RmgnUFBEYLVKx19sPlsrUdLd deDYwfQG+CVVowUbfxcYDvVKWmDGqKoXNd03S9apUmxl+WIX5CQM8sHo+17sN/2Q == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 1C1959E278; Mon, 17 Jul 2017 13:03:26 -0400 (EDT) Message-Id: <1500311006.3175691.1043634576.5C4D50CF@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150031100631756910" X-Mailer: MessagingEngine.com Webmail Interface - ajax-b8c51eee Date: Tue, 18 Jul 2017 03:03:26 +1000 In-Reply-To: <1500301835.1498112.1043444880.3FB433EB@webmail.messagingengine.com> References: <1500301835.1498112.1043444880.3FB433EB@webmail.messagingengine.com> Archived-At: Subject: Re: [Jmap] Dinner tonight 7pm X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 17:03:29 -0000 This is a multi-part message in MIME format. --_----------=_150031100631756910 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" We are settled in. It's about 6 minutes walk from the hotel. See some of you soon. Bron On Tue, 18 Jul 2017, at 00:30, Bron Gondwana wrote: > http://www.currytandoor.cz/en/ > > Based on the show of hands I have reserved for 12 people. > > We will meet there at 7pm. > > Bron. > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > > > _________________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150031100631756910 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
We are settled in. It's about 6 minutes walk from the hotel. See some of you soon.

Bron 


On Tue, 18 Jul 2017, at 00:30, Bron Gondwana wrote:

Based on the show of hands I have reserved for 12 people.

We will meet there at 7pm.

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


_______________________________________________
Jmap mailing list

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com

--_----------=_150031100631756910-- From nobody Tue Jul 18 06:02: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 8D00213172B for ; Tue, 18 Jul 2017 06:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.002 X-Spam-Level: X-Spam-Status: No, score=-7.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, 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 tnsY4qxC0zxY for ; Tue, 18 Jul 2017 06:02:48 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 1335B12EC3F for ; Tue, 18 Jul 2017 06:02:48 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v6ID2kxi018991 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 18 Jul 2017 13:02:47 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v6ID2k3s015176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 18 Jul 2017 13:02:46 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v6ID2kKf027057 for ; Tue, 18 Jul 2017 13:02:46 GMT Received: from [31.133.136.212] (/31.133.136.212) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 18 Jul 2017 06:02:45 -0700 From: "Chris Newman" To: jmap@ietf.org Date: Tue, 18 Jul 2017 15:02:38 +0200 Message-ID: <71E3B9BE-C58C-40DF-AA63-EB4B94334DD5@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Subject: [Jmap] DSN and MDN in JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 13:02:49 -0000 Adding Delivery Status RFC 3464 and Message Disposition Notification RFC 3798 to MessageSubmission object: Most interesting fields for a client UI: A client wishing to show whether message has been seen by a recipient will look at the "Disposition-Type" per-recipient field (semantics in RFC 3798 section 3.2.6.2). A client wishing to show delivery status will look at the "Action" per-recipient field (semantics in RFC 3464 section 2.3.3). Thoughts on how to map data from these standards to JMAP: 1. RFC 3464 uses type;value for most items. 99% of the time only one type is used/needed on the Internet. I suggest we strip the "type;" when mapping to JSON. That makes the mapping spec slightly more complex, but the values easier for a client to use. Alternatively we could pass the values through unchanged (simpler spec, more complex client). 2. I suggest we just allow UTF-8 in all fields, including addresses. This gets us nearly free support for RFC 6533. If we're removing "type;", we also need to remove 3464/6533 quoting from addresses. 3. Probably want to convert date syntax from 5322 format to RFC 3339 format, but numeric time zone offsets are required by RFC 3464, so we shouldn't break that. 4. DSNs have per-DSN fields (that apply when a report covering multiple recipients is sent) and per-recipient fields. I suggest storing a copy of the per-DSN fields with each recipient to keep the data model as simple as possible. An alternative would be to have an array of JSON objects for each DSN received and store a pointer to that record. 5. For MDN, the 'Disposition' field is a meta-field; I split it into three fields, it's possible to split it into 4 but I think that's not necessary 6. JMAP servers MAY hide DSN & MDN notification messages so they don't appear in the JMAP view of the mail store. If we do this and want to guarantee no loss of information, we might want to add a list of BLOB IDs to the MessageSubmission object that can be used to fetch raw DSN & MDN messages. * 7. An implementation of JMAP is permitted to set DSN & MDN fields for local deliveries without actually generating one or more DSN/MDN messages to transport the information, as long as the semantics of the fields are the same as if such a notification message was generated according to the DSN & MDN standards.* 8. One interesting idea... DSNs correlate using the ENVID (envelope ID, RFC 3461). We could require JMAP servers to set the ENVID to the ID of the JMAP MessageSubmission object on submission (presuming the submission server advertises RFC 3461). If we do this, the MessageSubmission ID must be restricted to ASCII and it would be best to avoid characters requiring xtext escaping (RFC 3461 section 4).* 9. It's possible to move most of this mapping to a separate spec, but I think four items belong in the JMAP Mail base spec (identified by *). See base spec RFC 3464 & 3798 for defined semantics of the fields. All fields are per-recipient (per #5): { "Original-Envelope-Id": string, # optional "Reporting-MTA": string, # required, drop "dns;" "DSN-Gateway": string # optional, drop "dns;" "Received-From-MTA": string # optional, drop "dns;" "Arrival-Date": string # optional, numeric time zone "Original-Recipient": string, # optional, drop address-type, allow 5321 & 6531 "Final-Recipient": string # required, drop address-type, allow 5321 & 6531 "Action": string # required: failed, delayed, delivered, relayed, expanded* "Status": string # required: SMTP enhanced status code. "Remote-MTA": string # optional, drop "dns;" "Diagnostic-Code": string # optional, drop "smtp;" "Last-Attempt-Date": string # optional, numeric time zone required "Final-Log-ID": string # optional "Will-Retry-Until": string # optional, numeric time zone required i18n DSN (RFC 6533) "Localized-Diagnostic": { "lang-tag" : string, ... } MDN fields (per-recipient, RFC 3798) ------------------------------------ "Reporting-UA": string # optional "MDN-Gateway": string # optional, drop "smtp;" "MDN-Original-Recipient": string # optional "MDN-Final-Recipient": string # required "Original-Message-ID": string # optional "Disposition-Mode": string # required {manual,automatic}-action/MDN-sent-{manually,automatically} "Disposition-Type": string # required {displayed,deleted}* "Disposition-Modifiers": string # optional "Failure": string # optional "Error": string # optional "Warning": string # optional } JMAP Clients wishing to generate MDNs (RFC 3798) will look at the following three headers: Disposition-Notification-To Disposition-Notification-Options Original-Recipient and the $MDNSent keyword (RFC 3503) JMAP servers MAY generate MDNs as a result of setting $Seen if they follow the rules in RFC 3503 and set $MDNSent keyword appropriately. Comments? - Chris From nobody Tue Jul 18 10:14: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 6BE42131B8A for ; Tue, 18 Jul 2017 10:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, 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 (2048-bit key) header.d=fastmailteam.com header.b=JXBDzpJW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=A55MBIDS 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 3Ftoyjm89Qec for ; Tue, 18 Jul 2017 10:14:45 -0700 (PDT) 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 6B25F127342 for ; Tue, 18 Jul 2017 10:14:45 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id D7C0720B08 for ; Tue, 18 Jul 2017 13:14:44 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Tue, 18 Jul 2017 13:14:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.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=fm1; bh=UVsUEJwAcZ9864fOT FCgPGpZ0OoDPv+b9UuPPaveN2o=; b=JXBDzpJWUOxAzgZETWwaUtyDXNECSOHFS 6VfVc6RHqLbV96NEPTbllmOgrKbknKis+UaoXzYJHE/u4lkhva2MuEAEnI1ooQvP IxnOdnd9pYUaqStlVYCPdF0/J0xNUzPyKvM/D1WKM0ReduBc9GcZY/bgju+0T9k2 dGGiogo1DprW2dzdGYq7DVIND3h0mf4eVegEqpIPlyb5zDBAnuQ3QguxqWqVrv+f oV3dJ1tjqI2gls8rIKcPjG2oWQZaw6Wntf8gigruDLgp6QVFOlILJ82JyEXGLxFs 9jDLsciKYXqZeV6zuKmdH9s2CcdcZEXewyXgisr+LQ21+jDxqOIrg== DKIM-Signature: v=1; a=rsa-sha256; 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=fm1; bh=UVsUEJ wAcZ9864fOTFCgPGpZ0OoDPv+b9UuPPaveN2o=; b=A55MBIDSXmeqF2+utK2Vwl 3Ga0tcnBHdEQaXrqVP4Ydg5cg0Gt7MYwsHQ52wmPugeHn2PNS1oaUGLI12ntPafF CU5iHaCscBwYL5jTsbwr0nPUkxQDT/GKOcCax3DhOewgTPuldCz6IvpRUSwmi5Zk 7h8v4FuUGuJtJsNciy2eRH+P+bzxG8Rqy+jdWp27Xqm82BellzkeLpLslhf520sc mHwDkUboZ10/mNVfPtjMPZYHJdzN1N+6LUZ2ntXntZOgCzsdGq8OKDqcIpfgw94C 9l7kuZBqZEZW/lFBWm57C4yzBKdax+122EOdWjmHOhi3JpDuNFUcYYQ/70yzADYA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 96FE5E2451; Tue, 18 Jul 2017 13:14:44 -0400 (EDT) Message-Id: <1500398084.797896.1044865312.4893BFE7@webmail.messagingengine.com> From: Neil Jenkins To: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15003980847978962" X-Mailer: MessagingEngine.com Webmail Interface - ajax-ed444df6 References: <71E3B9BE-C58C-40DF-AA63-EB4B94334DD5@oracle.com> Date: Wed, 19 Jul 2017 03:14:44 +1000 In-Reply-To: <71E3B9BE-C58C-40DF-AA63-EB4B94334DD5@oracle.com> Archived-At: Subject: Re: [Jmap] DSN and MDN in JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 17:14:48 -0000 This is a multi-part message in MIME format. --_----------=_15003980847978962 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" After discussing this with Chris, we agreed that most of this is probably not useful, and we would be better off simplifying the key information into two properties, and providing access to the raw DSN/MDN as blobs should a client wish to do more. So I propose we add the following to the DeliveryStatus object for each recipient: * *delivered*: `String` This MUST be one of the following values: `unknown`: The delivery status is unknown. This is the initial value. `yes`: A DSN has been received for this recipient with Action (as per RFC3464 section 2.3.3) equal to "delivered". `no`: A DSN has been received for this recipient with Action equal to "failed". * *seen*: `String` This MUST be one of the following values: `unknown`: The seen status is unknown. This is the initial value. `yes`: An MDN has been received for this recipient with Disposition-Type (as per RFC 3798 section 3.2.6.2[1]) equal to "displayed". * *dsnBlobIds*: `String[]` A list of blob ids for DSNs received for this recipient, in order of receipt, oldest first. * *mdnBlobIds*: `String[]` A list of blob ids for MDNs received for this recipient, in order of receipt, oldest first.The other nice thing about this is that JMAP servers may be able to update the delivered/seen properties based on other mechanisms (for example when there are local recipients); the client doesn't have to care how the server knows if the message has been delivered/seen. Neil. Links: 1. https://tools.ietf.org/html/rfc3798#section-3.2.6.2 --_----------=_15003980847978962 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
After discussing this with Chris, we agreed that most of this is probably not useful, and we would be better off simplifying the key information into two properties, and providing access to the raw DSN/MDN as blobs should a client wish to do more.

So I propose we add the following to the DeliveryStatus object for each recipient:

  • delivered: `String`
    This MUST be one of the following values:
    `unknown`: The delivery status is unknown. This is the initial value.
    `yes`: A DSN has been received for this recipient with Action (as per RFC3464 section 2.3.3) equal to "delivered".
    `no`: A DSN has been received for this recipient with Action equal to "failed".
  • seen: `String`
    This MUST be one of the following values:
    `unknown`: The seen status is unknown. This is the initial value.
    `yes`: An MDN has been received for this recipient with Disposition-Type (as per RFC 3798 section 3.2.6.2) equal to "displayed".
  • dsnBlobIds: `String[]`
    A list of blob ids for DSNs received for this recipient, in order of receipt, oldest first.
  • mdnBlobIds: `String[]`
    A list of blob ids for MDNs received for this recipient, in order of receipt, oldest first.
The other nice thing about this is that JMAP servers may be able to update the delivered/seen properties based on other mechanisms (for example when there are local recipients); the client doesn't have to care how the server knows if the message has been delivered/seen.

Neil.
--_----------=_15003980847978962-- From nobody Tue Jul 18 23:49: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 E2FE7131A7C for ; Tue, 18 Jul 2017 23:49:07 -0700 (PDT) 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, 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 (2048-bit key) header.d=fastmailteam.com header.b=ijfbfp+X; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PoRzSv5y 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 5T27mKgMWPtV for ; Tue, 18 Jul 2017 23:49:03 -0700 (PDT) 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 75414131935 for ; Tue, 18 Jul 2017 23:49:03 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id D4DEF20ADF for ; Wed, 19 Jul 2017 02:49:02 -0400 (EDT) Received: from web6 ([10.202.2.216]) by compute6.internal (MEProxy); Wed, 19 Jul 2017 02:49:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.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=fm1; bh=UzZdc0prF6JWS0jbw 7pYY92k++ReqRpUvl6DKqECSbU=; b=ijfbfp+X/F18ekhzbcP6ciRsKSUY2JGny bEEV+FIyvDORQ6pB7hIYiBFZ/gleUfR6w5Xn0WmraI7hFmjtmwJB2s0ZWneEoSxk IlRYEvwmiT3XJLR8tjYjr7Bi4g0om/eB4sjNYRYKupO4vuO46OggrTB3DOpLiLH8 ttLleqLYZC8rDrmxnKhUjZAebeKhhrLnScXuNQIh6Lt8iMaHk5VJzBSraYY6ukoj 0CZy04lrzwA+t/HG7m6Ga2IN/rKf4zP00VSRhkK+eoHBwjzx1RYsE2V9i8rViNn/ XhsywIKsQdmB9XNSjNXoF5WqY1zBl2mzxNGsooF5eUGfhtB+ztHmQ== DKIM-Signature: v=1; a=rsa-sha256; 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=fm1; bh=UzZdc0 prF6JWS0jbw7pYY92k++ReqRpUvl6DKqECSbU=; b=PoRzSv5yGWxHu6bTmwl598 giPGpsX6PE1lJDTmh16Nxc0mIy5oDjur/M6oGeyYdJqhH8xcJvdwU/3coON9GXrR 7lkmrygz4f6heFDwvc6Ra2C0+fpNo35JcNxcaXyWF4wfaj5bctf8auYNqqORbLFz uHZK2tmG2K2a5J19nzDoScLx5cbQLrMieug3YWYkgEEuoSU0Wu5PZku3t/sWA8nM T9RMs3fviN4yMdVi7/0Fj9poE8Dg95/HfVkQ0BFX00zTfGO8+AoqclVjCj3Ou33E lyYD7Cihap7LNvJOloaTeO4EtXsONoXutrvB8YNUv7ygNPlPwUOp7R+bnkdzMiCg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id A384048006; Wed, 19 Jul 2017 02:49:02 -0400 (EDT) Message-Id: <1500446942.4021701.1045523016.632D0EF4@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150044694240217012" X-Mailer: MessagingEngine.com Webmail Interface - ajax-095ee039 Date: Wed, 19 Jul 2017 16:49:02 +1000 References: <71E3B9BE-C58C-40DF-AA63-EB4B94334DD5@oracle.com> <1500398084.797896.1044865312.4893BFE7@webmail.messagingengine.com> In-Reply-To: <1500398084.797896.1044865312.4893BFE7@webmail.messagingengine.com> Archived-At: Subject: Re: [Jmap] DSN and MDN in JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 06:49:08 -0000 This is a multi-part message in MIME format. --_----------=_150044694240217012 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Regarding "delivered" there is a 4th state which you haven't captured here which is "definitely not yet" while the message is still in an outbound queue. That's not quite the same as unknown. Obviously a future-send email would also have that state. On Wed, 19 Jul 2017, at 03:14, Neil Jenkins wrote: > *delivered*: `String` > * This MUST be one of the following values: > `unknown`: The delivery status is unknown. This is the initial value. > `yes`: A DSN has been received for this recipient with Action (as per RFC3464 section 2.3.3) equal to "delivered". > `no`: A DSN has been received for this recipient with Action equal to "failed". > * *seen*: `String` > This MUST be one of the following values: > `unknown`: The seen status is unknown. This is the initial value. > `yes`: An MDN has been received for this recipient with Disposition-Type (as per RFC 3798 section 3.2.6.2[1]) equal to "displayed". > * *dsnBlobIds*: `String[]` > A list of blob ids for DSNs received for this recipient, in order of receipt, oldest first. > * *mdnBlobIds*: `String[]` > A list of blob ids for MDNs received for this recipient, in order of receipt, oldest first.> The other nice thing about this is that JMAP servers may be able to update the delivered/seen properties based on other mechanisms (for example when there are local recipients); the client doesn't have to care how the server knows if the message has been delivered/seen.> > Neil. > _________________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com Links: 1. https://tools.ietf.org/html/rfc3798#section-3.2.6.2 --_----------=_150044694240217012 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Regarding "delivered" there is a 4th state which you haven't captured here which is "definitely not yet" while the message is still in an outbound queue.  That's not quite the same as unknown.  Obviously a future-send email would also have that state.

On Wed, 19 Jul 2017, at 03:14, Neil Jenkins wrote:
delivered: `String`
  • This MUST be one of the following values:
    `unknown`: The delivery status is unknown. This is the initial value.
    `yes`: A DSN has been received for this recipient with Action (as per RFC3464 section 2.3.3) equal to "delivered".
    `no`: A DSN has been received for this recipient with Action equal to "failed".
  • seen: `String`
    This MUST be one of the following values:
    `unknown`: The seen status is unknown. This is the initial value.
    `yes`: An MDN has been received for this recipient with Disposition-Type (as per RFC 3798 section 3.2.6.2) equal to "displayed".
  • dsnBlobIds: `String[]`
    A list of blob ids for DSNs received for this recipient, in order of receipt, oldest first.
  • mdnBlobIds: `String[]`
    A list of blob ids for MDNs received for this recipient, in order of receipt, oldest first.
The other nice thing about this is that JMAP servers may be able to update the delivered/seen properties based on other mechanisms (for example when there are local recipients); the client doesn't have to care how the server knows if the message has been delivered/seen.

Neil.
_______________________________________________
Jmap mailing list

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_150044694240217012-- From nobody Wed Jul 19 00:36: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 0B49212ECC3 for ; Wed, 19 Jul 2017 00:35:58 -0700 (PDT) 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, 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 (2048-bit key) header.d=fastmailteam.com header.b=cj7N8Lq/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hftOsEBw 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 jJT2WAqZYLJT for ; Wed, 19 Jul 2017 00:35:55 -0700 (PDT) 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 8F33A127337 for ; Wed, 19 Jul 2017 00:35:55 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id F26E2207AD for ; Wed, 19 Jul 2017 03:35:54 -0400 (EDT) Received: from web6 ([10.202.2.216]) by compute6.internal (MEProxy); Wed, 19 Jul 2017 03:35:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.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=fm1; bh=lo6zU+7SSos5FY6FJ dr3aydbOTTSZ7Ig9Ly+nhNCCz0=; b=cj7N8Lq/L9peKQndhi3p6TlQ+coVQ1Ytx jxkL/DHdESzvj9zVkUpp+tvpSIzCKwrtBP+UYrsFS4OLLK+R7eyZFWoYE2KPmg0A DB1MNabVKeC2yOLXMO2yZOKCAJE1n/tpp2cVCFNucjvHSxTYNOWuXwyIu4gID7MS JET2PRJcthYi1nDeTwi5R3YKRuOOiGdI9s7qxEe/F25ZtjWhQUJKfcfhOnEwOEq1 wILvldNLwe4+j4uBdZzWLP3bPuJYASV4o6oPXRlbv5GGzg6jE8JzbNB8/4ZSRUZe KyXROyhGqBfgmjE80fP9OT8RYt4gWCmxKKIXhZ46yS1TyK1Nhek1w== DKIM-Signature: v=1; a=rsa-sha256; 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=fm1; bh=lo6zU+ 7SSos5FY6FJdr3aydbOTTSZ7Ig9Ly+nhNCCz0=; b=hftOsEBwWyl6aktjN+k3Tk xzfu4zhkq2XgyPNVKg0S3wfGU7GgqjmDbbfHbPJjwCDCmVxqk5dyUqChwbaop0Uy srervYu1eRjq8eWpEhMW0fA26y5afSr5pW21ZUAehujTul+haGTAv5kk3Lfg+iyf mOC7UdBR15i0Pm88SINP4a8qsNeGOE/+Ix+uGWd2SXFb1gSQGoxuvMZQk6tO5JQA v+i4zHv0PgGmgdO8gBWFH3TtjtsRyX9uv9jqC9NKzyJkiQN5tmHixNRpS43WDqOZ xtHByzTS04dy1DQ0N9diuf3JcUGeTJtvdFs+TeChV/UTsYzI3S8xurmGeXozYsXQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id C0B2448004; Wed, 19 Jul 2017 03:35:54 -0400 (EDT) Message-Id: <1500449754.4031183.1045541368.68075C86@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150044975440311830" X-Mailer: MessagingEngine.com Webmail Interface - ajax-095ee039 Date: Wed, 19 Jul 2017 17:35:54 +1000 In-Reply-To: References: Archived-At: Subject: Re: [Jmap] Review of draft-ietf-jmap-core-00.txt and draft-ietf-jmap-mail-00.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 07:35:58 -0000 This is a multi-part message in MIME format. --_----------=_150044975440311830 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Fri, 14 Jul 2017, at 23:10, Chris Newman wrote: > 2.x [ ... ] I haven't created any tickets for this as the discussion is mostly superseded by "split authentication out". If we do go ahead with our own authentication document within JMAP, I'll come back to this for notes. > 3.2. API structure > > This model only allows extensibility by adding methods or altering > method parameters. There's no way to attach properties to the entire > API request. There are a number of potentially interesting > request-level properties such as "fail on error" (stop on first error)> or "transaction"/"atomic" (either perform all methods successfully or> none of them). If you made the top-level an object and the array of > methods a property of the top-level object, you'd get request-level > extensibility. https://github.com/jmapio/jmap/issues/115 > 3.3. Errors > > "transport level" => This seems wrong because TCP is typically the > transport level for HTTP-based protocols, but returning a TCP-level > error is not desirable here. Why not just simplify this to one > sentence saying the error is returned at the HTTP level. https://github.com/jmapio/jmap/issues/116 > 3.6 Concurrency > > For potentially long-running operations like search and > copy/move-messages, the creates an inappropriate and unnecessary > implementation burden on the server. In general, the goal is that the> server should present a consistent view of data to the client, even > if it's slightly out-of-date by the time the method completes. It's > fine to state this and even say the ability of a server to present a > consistent view to clients is a quality-of-implementation issue for > the server. But don't force the presence of a hard locking mechanism > into the server implementation unless it's absolutely necessary as > that harms server scalability. > > Normative restrictions on concurrency should be specified for those > methods that need them and be minimally restrictive. For example, a > multi-message move operation should either move all messages or none > of them, and the messages should retain their relative ordering in the> destination folder. But additional restrictions are not needed to > present a good client experience. https://github.com/jmapio/jmap/issues/117 I would probably implement a lot of these things as an MVCC-style snapshot view for read operations. Write is trickier depending how you do your state management, do you do either need to lock against changes entirely so you can give back a new state string at the end, or you wind up in cases where creating a state string is tricky. > 3.8 Date datatype > > Are you sure you want to pin the timezone of timestamps to UTC? This > potentially loses information. https://github.com/jmapio/jmap/issues/118 > 3.10.1 getFoos > > state: need to specify scope and duration of this string. I'd guess it> is scoped to the specific getFoos request, so there's no requirement > for portability of this state token to other users or types. But > it'd be better if it's quite persistent (e.g., lasts a month or until> the client issues an update). > > 3.10.2 getFooUpdates > > fetchRecords & fetchRecordProperties > > Instead of two separate parallel properties, how about defining > fetchRecords as having the same structure as a getFoos object, but > with appropriate defaults for accountId and ids. This way, > extensions to the getFoos object naturally apply to the fetchRecords > value object. > > If the cannotCalculateChanges error occurs too frequently, the server> becomes problematic for client performance. A quality server should > strive to persist state tokens for several clients per user for at > least a month. > > 3.10.3. setFoos > >> Each create, update or destroy is considered an atomic unit. > I suggest: > Each create, update or destroy list item is considered an atomic unit.> >> record, so it can substitute in the correct value if necessary in >> later method calls. The type > dangling end of paragraph. > >> a separate creation id -> id map MUST be kept for each type. > > I assume these must only be kept for the duration of a single API > request? It would be helpful to say that explicitly. https://github.com/jmapio/jmap/issues/119 (state string SHOULD persist e.g. 1 month)https://github.com/jmapio/jmap/issues/120 (setFoos and idmap duration) https://github.com/jmapio/jmap/issues/121 (fetchRecords as getFoos with defaults) > 3.11.1. getFooList > > position: it's very useful to specify position relative to the end of> the list. For mail, the following search is common: "the 50 most > recent not-deleted messages". I suggest making -50, the 50th position> from the end of the list (the way Python list slicing works). Failure> to add support like this makes RFC 5267 partial results far less > useful than it could have been. For the response, always using > non-negative positioning makes sense. This already got created as: https://github.com/jmapio/jmap/issues/114 > 5. Uploading binary data > > Can you make the header "JMAP-AccountId" instead of "X-JMAP-AccountId"> per RFC 6648? This is already covered by: https://github.com/jmapio/jmap/issues/92 > 5.1 file upload > > The 'type' field is not well defined. Is this the Content-Type header> field with CFWS collapsed to SP and RFC 2231/2047 encoding removed? Or> should the content-type parameters be split out into a separate > property with an object as a value? > > size: For IMAP compatibility, this needs to allow sizes up to 2^32-1, Size is an interesting area of discussion, what with LITERAL- and various server restrictions. I'm feeling lazy so I just made one ticket for both of these: https://github.com/jmapio/jmap/issues/122 > 6.2 Web hook > >> The JMAP server MUST follow any redirects. > > Maybe I'm a bit paranoid, but I suggest: The JMAP server > implementation MUST be capable of following at least one redirect, but> MAY choose not to do so for configured policy reasons. > > 6.2.1. setPushCallback > > I think this needs another error code: > > policyDenied: The server is not willing to connect to the specified > URL for policy reasons. https://github.com/jmapio/jmap/issues/123 > ==== > > draft-ietf-jmap-mail-00 > > 2. Mailboxes > > Need to distinguish JMAP message id from RFC 5322 Message-ID > header. Duplicate 5322 message ids occur, so it's helpful to have a > JMAP message ID that's unique within an account. This got made into a ticket during the meeting notes regarding naming: https://github.com/jmapio/jmap/issues/102 > role: I support proposal to either remove 'outbox' (or make it > optional) and replace with MessageDelivery/MessageSubmission object. > I'd also like to see this more closely aligned with RFC 6154 (at least> use the same names). We should discuss issue of multiple folders with> same role; I like the simplicity of not having that, but RFC 6154 was> written as it is for a reason; we should make sure that reason doesn't> apply to JMAP before changing that design. Wow, for all that we've talked about this, we don't actually have a ticket for it! https://github.com/jmapio/jmap/issues/124 > sortOrder: don't hand-wave the locale-specific character order problem> as that breaks interoperability. I suggest abstracting the problem by> associating a collation (RFC 4790) with each account. If there's a > collation associated with the account, that produces a deterministic > order. Otherwise, permission has been given to be > non-deterministic. Server operators can derive the collation algorithm> name from the user's language when they register their account; then > it will work even on a client with the wrong locale configured. https://github.com/jmapio/jmap/issues/125 > mustBeOnlyMailbox: I don't understand the distinction. Is it > important? I haven't created anything for this, maybe Neil can just reply directly. This is for servers which don't support having the same message in multiple mailboxes. > "may*": Can we just replace this with a "myrights" per RFC 4314? If > you want to drop the rights grouping model of RFC 4314 to be simpler,> that's fine with me, but I'd prefer to keep the set of rights the same.> > 2.3.3. updating mailboxes > > myrights (may*) isn't immutable; it's server-generated (possibly based> on an IMAP ACL from RFC 4314) so the client can't directly update > it. I think it's fine to leave ACLs as an extension to base JMAP but > having the equivalent of myrights in the base spec is a good decision. https://github.com/jmapio/jmap/issues/126 > 3.1.1 filtering > > This really needs to be semantically closer to IMAP. In particular, > support for extensible flags is needed. > > Does this need an extensibility mechanism? A way to filter the search> that's ignored if not understood by the server (like non-critical LDAP> search controls)? Extending filtering would be done with a "using jmapesearch" or something, and that spec would define exactly how it extended filtering, so clients would opt in to search methods that the server claimed to support. > 3.1.2. Sorting > > We have a collation model (RFC 4790) that covers sorting. I think > servers need to implement either RFC 5051 or the Unicode Collation > Algorithm as a minimum/default. Allowing a collation to be specified > would be good for interoperabiltiy/predictability. updated and renamed #125 :) > 5. Messages > > Overall, I find this to be almost as problematic as the sending model of> the specification. I understand the goal of trying to make a minimal > JMAP client work without having to implement 5322/MIME/2047/2231. But> the problem with creating a data format gateway is you've got the union> of the problems and the intersection of the functionality. And while > having a way to fetch the raw blob is nice, that's not great for clients> that want some of the 5322/MIME/2047/2231 functionality that's missing> from JMAP but don't want to be forced to fetch the full message and do a> full parse of it. > > I suggest a different approach. First, define a set of properties that> are largely un-adulterated (similar to IMAP header fetch, IMAP body part> references, etc). Then define properties that try to > convert/simplify/flatten that data (losing information in the process).> Then clients can choose the level of precision they want. You'll need to> describe the algorithms used to convert/simplify/flatten the data in > detail. And if you're going to simplify some address fields, you need> the ability to simplify all of them, including ones like > Message-Disposition-To. > >> or RFC 2047 encoding of non-ASCII characters, MUST be fully decoded >> into standard UTF-8. > > If you say this, you need to identify the charsets that MUST be > supported; otherwise the requirement is impossible. You'll also want to> mention RFC 2231. This is all covered by https://github.com/jmapio/jmap/issues/104 but I've copied this text into a comment. >> hasAttachment: Boolean Does the message have any attachments? > > You need to define what you mean by an attachment. Do you mean a MIME> part with a Content-Disposition of "attachment", or do you mean > something else? Be precise. https://github.com/jmapio/jmap/issues/127 > textBody & htmlBody: I assume these are converted to UTF-8? This model> is not good. I generally want to be presented the plain text body if > present and the HTML body if the text body is not present. Are you > unfolding RFC 3676 for this? What if it's S/MIME signed? Threw this into 104. > date: the timezone of the sender is relevant information, so if you're> parsing out the date, you should parse out that field as well. For > submission you need a way to provide the timezone. and this :) > 8. Vacation Response > > Can this be moved to an extension? The question of how this interacts> with Sieve, ManageSieve, etc, is tricky. We talked this one out at dinner on Monday night. Let me know if you still want a ticket created for it. > ==== > > Missing stuff: > > * email address internationalization > => the protocol could be defined in such a way that this will mostly > "just work" (to the degree that's possible). Needs changes to Emailer> object, Message object, etc. > > I don't have time to do it now, but I'll run through the list of IMAP> extensions to come up with more 'missing stuff'. And likewise with this bit. Do you have a github user? Might be easier to add you to the org so you can create/edit tickets yourself! Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150044975440311830 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Fri, 14 Jul 2017, at 23:10, Chris Newman wrote:
2.x [ ... ]

I haven't created any tickets for this as the discussion is mostly superseded by "split authentication out".  If we do go ahead with our own authentication document within JMAP, I'll come back to this for notes.

3.2. API structure

This model only allows extensibility by adding methods or altering
method parameters. There's no way to attach properties to the entire
API request. There are a number of potentially interesting
request-level properties such as "fail on error" (stop on first error)
or "transaction"/"atomic" (either perform all methods successfully or
none of them). If you made the top-level an object and the array of
methods a property of the top-level object, you'd get request-level
extensibility.


3.3. Errors

"transport level" => This seems wrong because TCP is typically the
transport level for HTTP-based protocols, but returning a TCP-level
error is not desirable here. Why not just simplify this to one
sentence saying the error is returned at the HTTP level.


3.6 Concurrency

For potentially long-running operations like search and
copy/move-messages, the creates an inappropriate and unnecessary
implementation burden on the server. In general, the goal is that the
server should present a consistent view of data to the client, even
if it's slightly out-of-date by the time the method completes. It's
fine to state this and even say the ability of a server to present a
consistent view to clients is a quality-of-implementation issue for
the server. But don't force the presence of a hard locking mechanism
into the server implementation unless it's absolutely necessary as
that harms server scalability.

Normative restrictions on concurrency should be specified for those
methods that need them and be minimally restrictive. For example, a
multi-message move operation should either move all messages or none
of them, and the messages should retain their relative ordering in the
destination folder. But additional restrictions are not needed to
present a good client experience.


I would probably implement a lot of these things as an MVCC-style snapshot view for read operations.  Write is trickier depending how you do your state management, do you do either need to lock against changes entirely so you can give back a new state string at the end, or you wind up in cases where creating a state string is tricky.

3.8 Date datatype

Are you sure you want to pin the timezone of timestamps to UTC? This
potentially loses information.


3.10.1 getFoos

state: need to specify scope and duration of this string. I'd guess it
is scoped to the specific getFoos request, so there's no requirement
for portability of this state token to other users or types. But
it'd be better if it's quite persistent (e.g., lasts a month or until
the client issues an update).

3.10.2 getFooUpdates

fetchRecords & fetchRecordProperties

Instead of two separate parallel properties, how about defining
fetchRecords as having the same structure as a getFoos object, but
with appropriate defaults for accountId and ids. This way,
extensions to the getFoos object naturally apply to the fetchRecords
value object.

If the cannotCalculateChanges error occurs too frequently, the server
becomes problematic for client performance. A quality server should
strive to persist state tokens for several clients per user for at
least a month.

3.10.3. setFoos

Each create, update or destroy is considered an atomic unit.
I suggest:
Each create, update or destroy list item is considered an atomic unit.

record, so it can substitute in the correct value if necessary in
later method calls. The type
dangling end of paragraph.

a separate creation id -> id map MUST be kept for each type.

I assume these must only be kept for the duration of a single API
request? It would be helpful to say that explicitly.

https://github.com/jmapio/jmap/issues/119 (state string SHOULD persist e.g. 1 month)
https://github.com/jmapio/jmap/issues/120 (setFoos and idmap duration)
https://github.com/jmapio/jmap/issues/121 (fetchRecords as getFoos with defaults)

3.11.1. getFooList

position: it's very useful to specify position relative to the end of
the list. For mail, the following search is common: "the 50 most
recent not-deleted messages". I suggest making -50, the 50th position
from the end of the list (the way Python list slicing works). Failure
to add support like this makes RFC 5267 partial results far less
useful than it could have been. For the response, always using
non-negative positioning makes sense.

This already got created as:


5. Uploading binary data

Can you make the header "JMAP-AccountId" instead of "X-JMAP-AccountId"
per RFC 6648?

This is already covered by:


5.1 file upload

The 'type' field is not well defined. Is this the Content-Type header
field with CFWS collapsed to SP and RFC 2231/2047 encoding removed? Or
should the content-type parameters be split out into a separate
property with an object as a value?

size: For IMAP compatibility, this needs to allow sizes up to 2^32-1,

Size is an interesting area of discussion, what with LITERAL- and various server restrictions.  I'm feeling lazy so I just made one ticket for both of these:


6.2 Web hook

The JMAP server MUST follow any redirects.

Maybe I'm a bit paranoid, but I suggest: The JMAP server
implementation MUST be capable of following at least one redirect, but
MAY choose not to do so for configured policy reasons.

6.2.1. setPushCallback

I think this needs another error code:

policyDenied: The server is not willing to connect to the specified
URL for policy reasons.


====

draft-ietf-jmap-mail-00

2. Mailboxes

Need to distinguish JMAP message id from RFC 5322 Message-ID
header. Duplicate 5322 message ids occur, so it's helpful to have a
JMAP message ID that's unique within an account.

This got made into a ticket during the meeting notes regarding naming:


role: I support proposal to either remove 'outbox' (or make it
optional) and replace with MessageDelivery/MessageSubmission object.
I'd also like to see this more closely aligned with RFC 6154 (at least
use the same names). We should discuss issue of multiple folders with
same role; I like the simplicity of not having that, but RFC 6154 was
written as it is for a reason; we should make sure that reason doesn't
apply to JMAP before changing that design.

Wow, for all that we've talked about this, we don't actually have a ticket for it!


sortOrder: don't hand-wave the locale-specific character order problem
as that breaks interoperability. I suggest abstracting the problem by
associating a collation (RFC 4790) with each account. If there's a
collation associated with the account, that produces a deterministic
order. Otherwise, permission has been given to be
non-deterministic. Server operators can derive the collation algorithm
name from the user's language when they register their account; then
it will work even on a client with the wrong locale configured.


mustBeOnlyMailbox: I don't understand the distinction. Is it
important?

I haven't created anything for this, maybe Neil can just reply directly.  This is for servers which don't support having the same message in multiple mailboxes.

"may*": Can we just replace this with a "myrights" per RFC 4314? If
you want to drop the rights grouping model of RFC 4314 to be simpler,
that's fine with me, but I'd prefer to keep the set of rights the same.

2.3.3. updating mailboxes

myrights (may*) isn't immutable; it's server-generated (possibly based
on an IMAP ACL from RFC 4314) so the client can't directly update
it. I think it's fine to leave ACLs as an extension to base JMAP but
having the equivalent of myrights in the base spec is a good decision.


3.1.1 filtering

This really needs to be semantically closer to IMAP. In particular,
support for extensible flags is needed.

Does this need an extensibility mechanism? A way to filter the search
that's ignored if not understood by the server (like non-critical LDAP
search controls)?

Extending filtering would be done with a "using jmapesearch" or something, and that spec would define exactly how it extended filtering, so clients would opt in to search methods that the server claimed to support.

3.1.2. Sorting

We have a collation model (RFC 4790) that covers sorting. I think
servers need to implement either RFC 5051 or the Unicode Collation
Algorithm as a minimum/default. Allowing a collation to be specified
would be good for interoperabiltiy/predictability.

updated and renamed #125 :)

5. Messages

Overall, I find this to be almost as problematic as the sending model of
the specification. I understand the goal of trying to make a minimal
JMAP client work without having to implement 5322/MIME/2047/2231. But
the problem with creating a data format gateway is you've got the union
of the problems and the intersection of the functionality. And while
having a way to fetch the raw blob is nice, that's not great for clients
that want some of the 5322/MIME/2047/2231 functionality that's missing
from JMAP but don't want to be forced to fetch the full message and do a
full parse of it.

I suggest a different approach. First, define a set of properties that
are largely un-adulterated (similar to IMAP header fetch, IMAP body part
references, etc). Then define properties that try to
convert/simplify/flatten that data (losing information in the process).
Then clients can choose the level of precision they want. You'll need to
describe the algorithms used to convert/simplify/flatten the data in
detail. And if you're going to simplify some address fields, you need
the ability to simplify all of them, including ones like
Message-Disposition-To.

or RFC 2047 encoding of non-ASCII characters, MUST be fully decoded
into standard UTF-8.

If you say this, you need to identify the charsets that MUST be
supported; otherwise the requirement is impossible. You'll also want to
mention RFC 2231.

This is all covered by https://github.com/jmapio/jmap/issues/104 but I've copied this text into a comment.

hasAttachment: Boolean Does the message have any attachments?

You need to define what you mean by an attachment. Do you mean a MIME
part with a Content-Disposition of "attachment", or do you mean
something else? Be precise.


textBody & htmlBody: I assume these are converted to UTF-8? This model
is not good. I generally want to be presented the plain text body if
present and the HTML body if the text body is not present. Are you
unfolding RFC 3676 for this? What if it's S/MIME signed?

Threw this into 104.

date: the timezone of the sender is relevant information, so if you're
parsing out the date, you should parse out that field as well. For
submission you need a way to provide the timezone.

and this :)

8. Vacation Response

Can this be moved to an extension? The question of how this interacts
with Sieve, ManageSieve, etc, is tricky.

We talked this one out at dinner on Monday night.  Let me know if you still want a ticket created for it.

====

Missing stuff:

* email address internationalization
=> the protocol could be defined in such a way that this will mostly
"just work" (to the degree that's possible). Needs changes to Emailer
object, Message object, etc.

I don't have time to do it now, but I'll run through the list of IMAP
extensions to come up with more 'missing stuff'.

And likewise with this bit.

Do you have a github user?  Might be easier to add you to the org so you can create/edit tickets yourself!

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_150044975440311830-- From nobody Wed Jul 19 00:39: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 69A0D12ECC3 for ; Wed, 19 Jul 2017 00:39:42 -0700 (PDT) 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, 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 (2048-bit key) header.d=fastmailteam.com header.b=s0SSTyGd; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lS9h1QjZ 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 PbsLvgyMpZi9 for ; Wed, 19 Jul 2017 00:39:40 -0700 (PDT) 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 A7002127337 for ; Wed, 19 Jul 2017 00:39:40 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 10DA420818 for ; Wed, 19 Jul 2017 03:39:40 -0400 (EDT) Received: from web6 ([10.202.2.216]) by compute6.internal (MEProxy); Wed, 19 Jul 2017 03:39:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.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=fm1; bh=VfAbf9ZAdwXWa2gEW uN7WysGvF7pZZlgqVDWjRB0WsA=; b=s0SSTyGd99jpuNygPDK4uyXxDETLQ+g6i bAdO8NuzdIPcf9U53PWZfq8U0UOJI3ON9g3eExrTmb0dy6tuOBVrzrUMkek/sr8Y w+VconTddmD1sxIc5gMBk/ezKsUZ/dh5hWpiRzZbOm8cviyd+POg7fomsr5qMWzb ESTsq5PBFb1YJGk8sNY6m1r/8GJDJ8MDvPquAOcDtHzeozyT0z+PYniWVTK63OCa G9eS5sKVcpJFrU/G4XeOHV116i7CyKFwYFKY7Mx6q68kjc64HCrfDchusppjc1f+ X0SJ1alcDZN1ZnzeAzU7xMwb6YVcmN9yE+E0K8kWhSzBnLkHVdrRg== DKIM-Signature: v=1; a=rsa-sha256; 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=fm1; bh=VfAbf9 ZAdwXWa2gEWuN7WysGvF7pZZlgqVDWjRB0WsA=; b=lS9h1QjZaUElGDVCoCmRcR W/Ed4CvcLA6c3ffaG8693fJqP5THnYFSbo7A3UbX1erI5bnD0Lt/Pzszh+q0lnrF lN5ABRtCS8O2XbH5Y8FCYAfR13GCSW6B4HMlHzcwf/52Z1Cg4R/oKcXsdeq6/RMa bkP9BjtJuFn7WmYFLX9p1bDQFpFhLwpW5vZwLBjqa3ceqv2SC5pR5D6+bXvfpxx6 YRzCtdlIg+RIbZSDBq/aDpHWvNNKF1p5IxDdTmD35cr94WoRoTJIKI1s4EcFtnYg aJQAjo99YAHLrzAUO/HXuSu/XM8AdnrKe1fOOfetEw5Ejx3lL4GG0pQy10GgVWEA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id E2B1E48004; Wed, 19 Jul 2017 03:39:39 -0400 (EDT) Message-Id: <1500449979.4032013.1045557336.0F7A54E1@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150044997940320132" X-Mailer: MessagingEngine.com Webmail Interface - ajax-095ee039 Date: Wed, 19 Jul 2017 17:39:39 +1000 In-Reply-To: <70DDF0EC-CCBE-48C8-BA73-7EAE6012C517@oracle.com> References: <70DDF0EC-CCBE-48C8-BA73-7EAE6012C517@oracle.com> Archived-At: Subject: Re: [Jmap] Draft meeting notes X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 07:39:42 -0000 This is a multi-part message in MIME format. --_----------=_150044997940320132 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" These are now uploaded to datatracker - sorry I forgot to do that on Monday. Bron. On Tue, 18 Jul 2017, at 00:13, Chris Newman wrote: > Topic: "why JMAP" > > Issue: JMAP Mail: keywords > seems concluded > action item: register four $XXX keywords for system flags (Chris > volunteered to help with IANA considerations) > discussion, but no objections from attendees > > Issue: JMAP Mail: Submission > changed to use a more JMAP-ish MessageSubmission object > ongoing discussion seems close to consensus > action item: Chris Newman will propose syntax to align better with > concern expressed about name "messageid" > no other objections from attendees about general direction > > Issue: JMAP Mail: Message object & partial body fetch > no proposal yet > suggestion to expose IMAP MIME part numbers in attachment list > discussion that HTTP range is probably not be sufficient > needs more discussion > > Issue: JMAP Core: extension mechanisms > needs some work but no significant controversy expressed in room > > Issue: JMAP Core: authentication > action item: need to split to separate document > action item: Torsten & Neil will discuss possibility of profiling > OAuth > point: possible interaction with token binding WG > > Issue: JMAP Core: push mechanism > discussion of Martin's objections to EventSource > discussion of encryption of push data > > Issue: JMAP Core: "transport" > HTTP as a tunnel vs. HTTP resources for every object > long discussion > > Github Tickets > * changed vs. created in getFooUpdates (issues/78) > * disallow destroying mailboxes with messages (issues/69) > some preference expressed to allow delete of mailbox with > messages > * mailboxids property > > - Chris > > _________________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150044997940320132 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
These are now uploaded to datatracker - sorry I forgot to do that on Monday.

Bron.


On Tue, 18 Jul 2017, at 00:13, Chris Newman wrote:
Topic: "why JMAP"

Issue: JMAP Mail: keywords
  seems concluded
  action item: register four $XXX keywords for system flags (Chris
volunteered to help with IANA considerations)
discussion, but no objections from attendees

Issue: JMAP Mail: Submission
  changed to use a more JMAP-ish MessageSubmission object
  ongoing discussion seems close to consensus
  action item: Chris Newman will propose syntax to align better with
  concern expressed about name "messageid"
no other objections from attendees about general direction

Issue: JMAP Mail: Message object & partial body fetch
  no proposal yet
  suggestion to expose IMAP MIME part numbers in attachment list
  discussion that HTTP range is probably not be sufficient
needs more discussion

Issue: JMAP Core: extension mechanisms
needs some work but no significant controversy expressed in room

Issue: JMAP Core: authentication
  action item: need to split to separate document
  action item: Torsten & Neil will discuss possibility of profiling
OAuth
  point: possible interaction with token binding WG

Issue: JMAP Core: push mechanism
  discussion of Martin's objections to EventSource
  discussion of encryption of push data

Issue: JMAP Core: "transport"
  HTTP as a tunnel vs. HTTP resources for every object
  long discussion

Github Tickets
* changed vs. created in getFooUpdates (issues/78)
* disallow destroying mailboxes with messages (issues/69)
  some preference expressed to allow delete of mailbox with     
  messages
* mailboxids property

- Chris

_______________________________________________
Jmap mailing list

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_150044997940320132-- From nobody Wed Jul 19 01:07: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 0E37A131C10 for ; Wed, 19 Jul 2017 01:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 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 w4pjM7WyYaYE for ; Wed, 19 Jul 2017 01:07:30 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 C5D3A131600 for ; Wed, 19 Jul 2017 01:07:30 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v6J87RXN007881 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 19 Jul 2017 08:07:27 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v6J87QXZ030650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 19 Jul 2017 08:07:27 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v6J87Q2E017376; Wed, 19 Jul 2017 08:07:26 GMT Received: from [31.133.136.2] (/31.133.136.2) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 19 Jul 2017 01:07:25 -0700 From: "Chris Newman" To: "Neil Jenkins" Cc: "IETF JMAP Mailing List" Date: Wed, 19 Jul 2017 10:07:20 +0200 Message-ID: <4186F083-C4AA-49FA-8056-530E2A53FBE0@oracle.com> In-Reply-To: <1500398084.797896.1044865312.4893BFE7@webmail.messagingengine.com> References: <71E3B9BE-C58C-40DF-AA63-EB4B94334DD5@oracle.com> <1500398084.797896.1044865312.4893BFE7@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: Re: [Jmap] DSN and MDN in JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 08:07:32 -0000 On 18 Jul 2017, at 19:14, Neil Jenkins wrote: > After discussing this with Chris, we agreed that most of this is > probably not useful, and we would be better off simplifying the key > information into two properties, and providing access to the raw > DSN/MDN as blobs should a client wish to do more. > So I propose we add the following to the DeliveryStatus object for > each recipient: > * *delivered*: `String` This MUST be one of the following values: > `unknown`: The delivery status is unknown. This is the initial > value. > `yes`: A DSN has been received for this recipient with Action (as > per > RFC3464 section 2.3.3) equal to "delivered". `no`: A DSN has been > received for this recipient with Action equal to "failed". > * *seen*: `String` This MUST be one of the following values: > `unknown`: > The seen status is unknown. This is the initial value. `yes`: An > MDN > has been received for this recipient with Disposition-Type (as per > RFC 3798 section 3.2.6.2[1]) equal to "displayed". > * *dsnBlobIds*: `String[]` A list of blob ids for DSNs received for > this recipient, in order of receipt, oldest first. > * *mdnBlobIds*: `String[]` A list of blob ids for MDNs received for > this recipient, in order of receipt, oldest first.The other nice > thing about this is that JMAP servers may be able to update the > delivered/seen properties based on other mechanisms (for example when > there are local recipients); the client doesn't have to care how the > server knows if the message has been delivered/seen. I think that should be explicit in the spec, perhaps say: JMAP servers MAY set the delivered/seen strings based on information other than standard DSN and MDN messages. We could move dsnBlobIds & mdnblobIds to the MessageSubmission object. For the power users (or support staff) who want the details in those messages, JMAP-level per-recipient correlation isn't that important and it may be easier for a UI to put a "show technical details" feature on a messageSubmission object. A couple other details I think are helpful to articulate: JMAP servers MAY (SHOULD?) hide standard DSN and MDN messages that correlate to a MessageSubmission object from the normal mailbox view and expose them only in the dsnBlobIds and mdnblobIds fields. When a JMAP server performs a message submission, it MAY use the same ID string for the RFC 3461 ENVID parameter and the JMAP MessageSubmission object ID. JMAP servers that do this MAY replace a client-provided value for ENVID with a server-provided value. - Chris From nobody Wed Jul 19 01:46:42 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 3E1D7131C32 for ; Wed, 19 Jul 2017 01:46:41 -0700 (PDT) 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, 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 (1024-bit key) header.d=sonnection.nl 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 BZKCffFyfaJ1 for ; Wed, 19 Jul 2017 01:46:39 -0700 (PDT) Received: from mx10.mailtransaction.com (mx10.mailtransaction.com [88.198.59.241]) by ietfa.amsl.com (Postfix) with ESMTP id 07066131C2F for ; Wed, 19 Jul 2017 01:46:39 -0700 (PDT) Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx10.mailtransaction.com (Postfix) with ESMTP id 3xC9cY6wghz5MgwC; Wed, 19 Jul 2017 10:46:37 +0200 (CEST) Received: from tiger.sonnection.nl (D57E1706.static.ziggozakelijk.nl [213.126.23.6]) by mx24.mailtransaction.com (Postfix) with ESMTP id 3xC9cY4zyBz1L8nH; Wed, 19 Jul 2017 10:46:37 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by tiger.sonnection.nl (Postfix) with ESMTP id 77029422288; Wed, 19 Jul 2017 10:46:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at tiger.sonnection.nl Received: from tiger.sonnection.nl ([127.0.0.1]) by localhost (tiger.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id HtI5VN_9tXTz; Wed, 19 Jul 2017 10:46:37 +0200 (CEST) Received: from lion.sonnection.nl (lion.sonnection.nl [192.168.30.2]) by tiger.sonnection.nl (Postfix) with ESMTP id 5B553422287; Wed, 19 Jul 2017 10:46:37 +0200 (CEST) Date: Wed, 19 Jul 2017 10:46:37 +0200 (CEST) From: "Rolf E. Sonneveld" To: Neil Jenkins Cc: IETF JMAP Mailing List Message-ID: <1570577976.59819.1500453997153.JavaMail.zimbra@sonnection.nl> In-Reply-To: <1500398084.797896.1044865312.4893BFE7@webmail.messagingengine.com> References: <71E3B9BE-C58C-40DF-AA63-EB4B94334DD5@oracle.com> <1500398084.797896.1044865312.4893BFE7@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_59818_1997467895.1500453997153" X-Originating-IP: [192.168.20.2] X-Mailer: Zimbra 8.6.0_GA_1182 (ZimbraWebClient - FF44 (Linux)/8.6.0_GA_1182) Thread-Topic: DSN and MDN in JMAP Thread-Index: 9JsPwOpHlrWfa6Ig+TBULBekWqdryQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1500453998; bh=ILeVxgx1xgPrIbXh5kAF6MFF/Khc9RmZQqrECBTU1Pg=; h=Date:From:To:Message-ID:Subject:From; b=IXodQTrziSxL2hDl7F00TXnzcMGRewJoRYkc2x5m09W5PHnS3iLY3lKF9wxYgGK5u TNYuFUj1b5RPbvY9Q9chP5GkWFzFuAcZx7oHP6iZRwIBSExG8NzOnDCnCVkzmbG2Vb r37eodbYP7GEjXj2to9qBjDawYxNCQJs7xpxVXOc= DKIM-Filter: OpenDKIM Filter v2.8.2 mx10.mailtransaction.com 3xC9cY6wghz5MgwC Archived-At: Subject: Re: [Jmap] DSN and MDN in JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 08:46:41 -0000 ------=_Part_59818_1997467895.1500453997153 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit > After discussing this with Chris, we agreed that most of this is probably not > useful, and we would be better off simplifying the key information into two > properties, and providing access to the raw DSN/MDN as blobs should a client > wish to do more. > So I propose we add the following to the DeliveryStatus object for each > recipient: > * > delivered : `String` > This MUST be one of the following values: > `unknown`: The delivery status is unknown. This is the initial value. > `yes`: A DSN has been received for this recipient with Action (as per RFC3464 > section 2.3.3) equal to "delivered". `no`: A DSN has been received for this > recipient with Action equal to "failed". > * > seen : `String` > This MUST be one of the following values: > `unknown`: The seen status is unknown. This is the initial value. > `yes`: An MDN has been received for this recipient with Disposition-Type (as per > RFC 3798 section 3.2.6.2 ) equal to " displayed". I would suggest to use 'disposed' (or another name that can be associated with message-disposition-notification) as IMHO the word 'seen' refers too much to the act of reading a message by a human being. /rolf ------=_Part_59818_1997467895.1500453997153 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

After d= iscussing this with Chris, we agreed that most of this is probably not usef= ul, and we would be better off simplifying the key information into two pro= perties, and providing access to the raw DSN/MDN as blobs should a client w= ish to do more.

So I propose we add the following to the = DeliveryStatus object for each recipient:

  • delivered: `String`
    This MUST be one of the following va= lues:
    `unknown`: The delivery status is unknown. This is the = initial value.
    `yes`: A DSN has been received for this recipi= ent with Action (as per RFC3464 section 2.3.3) equal to "deli= vered".
    `no`: A DSN has been received for this recipient wit= h Action equal to "failed".
  • seen: = `String`
    This MUST be one of the following values:
    `unknown`: The seen status is unknown. This is the initial value.<= br>
    `yes`: An MDN has been received for this recipient with Di= sposition-Type (as per RFC 3798 section 3.2= .6.2) equal to "displayed".

I would suggest to use 'disposed' (or another na= me that can be associated with message-disposition-notification) as IMHO th= e word 'seen' refers too much to the act of reading a message by a human be= ing.

/rolf

------=_Part_59818_1997467895.1500453997153-- From nobody Wed Jul 19 02:24: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 70A2C131C45 for ; Wed, 19 Jul 2017 02:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 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_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=mrochek.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 eO89MzYrS_zR for ; Wed, 19 Jul 2017 02:24:49 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 3B2B1131C3F for ; Wed, 19 Jul 2017 02:24:49 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QGVJGULGLC007NFH@mauve.mrochek.com> for jmap@ietf.org; Wed, 19 Jul 2017 02:19:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1500455985; bh=FJ4rSXDNWkJF+ojaMGLYaeItozw9/pRgbFkTMES/iRA=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=e+vF30Zx+TujmAujS+Vu214+E4C3/Q4yPePnPTqVzaMH4QGgcob1TkuLZOL0kaejo rsVP3r4zE0pph2xgatW9UxE7B5axiegPaKpICE0CN48LZE/7koWrH/EEXrz063GUeE JTZ11Si24hejHQYmAsUppoyBDWVLeWHDxv2uKedE= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QGGZN1ZVAO0000D4@mauve.mrochek.com>; Wed, 19 Jul 2017 02:19:44 -0700 (PDT) Cc: jmap@ietf.org Message-id: <01QGVJGTAE800000D4@mauve.mrochek.com> Date: Wed, 19 Jul 2017 02:14:59 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 19 Jul 2017 16:49:02 +1000" <1500446942.4021701.1045523016.632D0EF4@webmail.messagingengine.com> References: <71E3B9BE-C58C-40DF-AA63-EB4B94334DD5@oracle.com> <1500398084.797896.1044865312.4893BFE7@webmail.messagingengine.com> <1500446942.4021701.1045523016.632D0EF4@webmail.messagingengine.com> To: Bron Gondwana Archived-At: Subject: Re: [Jmap] DSN and MDN in JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 09:24:50 -0000 > Regarding "delivered" there is a 4th state which you haven't captured here > which is "definitely not yet" while the message is still in an outbound queue. > That's not quite the same as unknown. Obviously a future-send email would also > have that state. Why are we repeating prior work here? In regards to submission-transmission-delivery, the model for all of this was worked out as part of the message tracking work published in RFCs 3885-3888. In this particular case, you're talking about the action field defined in RFC 3886 section 3.3.3. The specific state you're desribing is the "delayed" state. Ned From nobody Wed Jul 19 08:29:47 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 6106E131898 for ; Wed, 19 Jul 2017 08:29:45 -0700 (PDT) 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, 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 (2048-bit key) header.d=fastmailteam.com header.b=tgGUyp+l; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ozSLuSvV 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 tTNL_OqleJGs for ; Wed, 19 Jul 2017 08:29:41 -0700 (PDT) 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 922C7131714 for ; Wed, 19 Jul 2017 08:29:41 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id EA01B20ABC for ; Wed, 19 Jul 2017 11:29:40 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Wed, 19 Jul 2017 11:29:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=mKxQLQBpduXNP7v/dVtsl8Ozi58tA9Q8b0xcry6HN p8=; b=tgGUyp+lfsRux23iC53XfkA1wFU08UKbbvBrCAQBFp5bUHT5t9UBKi2SS ZmSy6h2wQJvYm9JLCZcq3oPUS0a+HERo7fvfsveSH2E66uFwiZJMMkRafGXrwHkQ WSFxEFfpNWDab53EY18Zu6JxekrfvFrDelLhWl3t3FaQnUsG3BZQvo+/iqHJ4D2l hS8b4hF7fLQ5MxwoybLcCKO2+NNvV/iVT6WqcTBL7A5uI8OtLYE/AcP7SKyayvLr xCyDEo0q0gBEYxvEmU1hjJt4iTI1FITH9PDBM3j+Ax2JSMAAh1J6o59xSWjPDBh4 yvEYFDbJKtZqYvKgnM5EvNTCBuyWA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=mKxQLQBpduXNP7v/dVtsl8Ozi58tA 9Q8b0xcry6HNp8=; b=ozSLuSvVuO4v5gNiubxbHulqEVH8BazOy9gQhaBZ10ZLM wJXsLHTPy3Fn3bFWMA4b66DZh0ZdNxJnMuN1ql3WpTzAyd5ms7HiolVv2YPCE90c w9GGufhl0xesTJbSNJR+aHEc9Uqss7nGtN8e58RcCRjgvnsOBq1EQo8L+EbwB2Of DsmZeE73zNRkiNhiyWCo5RIgKmMpnLcnrG1QZiVKDJNu6LTmD7iCyAQFDOgdSY+e ju2b8fLSnUd+JvBu5hmetlYQM7a1W+EIkXAVKJn2TC0uIChaPCpUCzvRowbcf8x7 2JiVy76+HdEjJWhJl8Nz9Sk0tRgqVWXZntFWLzEdQ== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 91F16E22F9; Wed, 19 Jul 2017 11:29:40 -0400 (EDT) Message-Id: <1500478180.2145846.1046007808.31167238@webmail.messagingengine.com> From: Neil Jenkins To: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150047818021458462" X-Mailer: MessagingEngine.com Webmail Interface - ajax-97a62731 Date: Thu, 20 Jul 2017 01:29:40 +1000 Archived-At: Subject: [Jmap] Revised MessageSubmission object X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 15:29:45 -0000 This is a multi-part message in MIME format. --_----------=_150047818021458462 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" OK, I've taken on all the feedback from the mailing list and as discussed a= t the IETF Prague meeting, and have updated the pull request[1]. The intere= sting bit is the MessageSubmission object definition, which I also include = below for convenience. I think (hope) this is pretty close to finished, so = please do a final review before I merge. Cheers, Neil. -------- The MessageSubmission object represents the submission of a message for del= ivery to one or more recipients. A *MessageSubmission* object has the follo= wing properties: * *id*: String The id of the message submission. This is server-set and immutable. * *identityId*: String The id of the identity to associate with this submission. This is immutable. * *messageId*: String The id of the message to send. This is immutable. The message being sent does not have to be a draft, for example when =E2=80=9Credirecting=E2=80=9D an existing message to a different email a= ddress. * *threadId*: String The thread id of the message to send. This is immutable and set by the server to the *threadId* property of the message referenced by the *messageId*. * *envelope*: Envelope|null Information for use when sending via SMTP. This is immutable. An *Envelope* object has the following properties: * *mailFrom*: String The email address to use as the return address in the SMTP submission. The JMAP server MAY allow this to be the empty string. * *mailFromParams*: String[String]|null SMTP parameters to pass with the MAIL FROM address. Each key is a parameter name, and the value the parameter value. In both cases, any xtext or unitext encodings are removed ([@!RFC3461], [@!RFC6533]) and JSON string encoding applied. When a JMAP server performs a message submission, it MAY use the same id string for the [@!RFC3461] ENVID parameter and the MessageSubmission object id. Servers that do this MAY replace a client-provided value for ENVID with a server-provided value. * *rcptTo*: String[String[String]|null] The keys of this object are the email addresses to send the message to. The value is either null, or another object representing SMTP RCPT TO parameters to pass with this recipient. Each key is a parameter name, and the value the parameter value. In both cases, any xtext or unitext encodings are removed ([@!RFC3461], [@!RFC6533]) and JSON string encoding applied. If the *envelope* property is null or omitted on creation, the server MUST generate this from the referenced message as follows: * *mailFrom*: The email in the *Sender* header, if present, otherwise the *From* header, if present. If multiple addresses are present in one of these headers, or there is more than one *Sender*/*From* header, the server SHOULD reject the message as invalid but otherwise MUST take the first email address in the last *Sender*/*From* header in the [@!RFC5322] version of the message. If the address found from this is not allowed by the identity associated with this submission, the *email* property from the identity MUST be used instead. * *mailFromParams*: null * *rcptTo*: An object with the keys being the deduplicated set of email addresses from the *To*, *Cc* and *Bcc* headers, if present, and the value for each being null. * *sendAt*: Date The date the message was/will be released for delivery. This is server-set and immutable. If the client successfully used [@!RFC4865] FUTURERELEASE with the message, this MUST be the time when the server will release the message; otherwise it MUST be the time the MessageSubmission was created. * *undoStatus*: String This represents whether the submission may be canceled. This is server set and MUST be one of the following values: * "pending": It MAY be possible to cancel this submission. * "final": The message has been relayed to at least one recipient in a manner that cannot be recalled. It is no longer possible to cancel this submission. * "canceled": The message submission was canceled and will not be delivered to any recipient. On systems that do not support unsending, the value of this property will always be final. On systems that do support canceling submission, it will start as pending, and MAY transition to final when the server knows it definitely cannot recall the message, but MAY just remain pending. If in pending state, a client can attempt to cancel the submission by setting this property to canceled; if the update succeeds, the submission was successfully canceled. * *deliveryStatus*: String[DeliveryStatus]|null This represents the delivery status for each of the message recipients, if known. This property is server-set and MAY not be supported by all servers, in which case it will remain null. Servers that support it SHOULD update the MessageSubmission object each time the status of any of the recipients changes. This is a map from the email address of each recipient of the message, to the most recent SMTP reply code/text known. This property is server set and MAY not be supported by all servers, in which case it will remain null. Servers that support it SHOULD update the MessageSubmission object each time the status of one of the recipients changes, even if some recipients are still being retried. The *isFinal* property allows clients to know if the status may still change further. A *DeliveryStatus* object has the following properties: * *isQueued*: Boolean This is true if the server is still trying to send the message to this recipient (and so the *smtpReply* could still change), otherwise false. * *smtpReply*: String The SMTP reply string returned for this recipient when the server last tried to relay the message. This SHOULD be the response to the RCPT TO stage, unless this was accepted and the message as a whole rejected at the end of the DATA stage, in which case the DATA stage reply SHOULD be used instead. For messages relayed via an alternative to SMTP, the server MAY generate a synthetic string representing the status instead. If it does this, the string MUST be of the following form: * A 3-digit SMTP reply code, as defined in [@!RFC5321], section 4.2.3. * Then a single space character. * Then an SMTP Enhanced Mail System Status Code as defined in [@!RFC3463], with a registry defined in [@!RFC5248]. * Then a single space character. * Then an implementation-specific information string with a human readable explanation of the response. * *delivered*: String Represents whether the message has been succesfully delivered to the recipient. This MUST be one of the following values: * "unknown": The final delivery status is unknown, either because the delivery is still queued and being retried, or it was relayed to an external machine and no further information is available. This is the initial value. * "yes": The message was successfully delivered to the mailbox of the recipient. * "no": Message delivery to the recipient permanently failed. Note, succesful relaying to an external SMTP server SHOULD NOT be taken as an indication that the message has successfully reached the final mailbox. In this case though, the server MAY receive a DSN response, if requested. If a DSN is received for the recipient with Action equal to =E2=80=9Cdelive= red=E2=80=9D, as per [@!RFC3464] section 2.3.3, then the *delivered* property SHOULD be set to yes; if the Action equals =E2=80=9Cfailed=E2=80=9D, the property = SHOULD be set to no. Receipt of any other DSN SHOULD NOT affect this property. The server MAY also set this property based on other feedback channels. * *displayed*: String Represents whether the message has been displayed to the recipient. This MUST be one of the following values: * "unknown": The display status is unknown. This is the initial value. * "yes": The message content has been displayed to the recipient. Note, there is no guarantee that the recipient has noticed, read, or understood the content. If an MDN is received for this recipient with Disposition-Type (as per [@!RFC3798] section 3.2.6.2) equal to =E2=80=9Cdisplayed=E2=80=9D, t= his property SHOULD be set to yes. The server MAY also set this property based on other feedback channels. * *dsnBlobIds*: String[] A list of blob ids for DSNs received for this submission, in order of receipt, oldest first. This is server-set. * *mdnBlobIds*: String[] A list of blob ids for MDNs received for this submission, in order of receipt, oldest first. This is server-set.JMAP s= ervers SHOULD NOT expose DSN and MDN messages that correlate to a MessageSu= bmission object in responses to *getMessageList*. It SHOULD only expose the= m in the *dsnBlobIds* and *mdnblobIds* fields of this object.For efficiency= , a server MAY destroy MessageSubmission objects a certain amount of time a= fter the message is successfully sent or it has finished retrying sending t= he message. For very basic SMTP proxies, this MAY be immediately after crea= tion, as it has no way to assign a real id and return the information again= if fetched later. Links: 1. https://github.com/jmapio/jmap/pull/99 --_----------=_150047818021458462 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
OK, I've taken on all the feedback from the mailing list and as = discussed at the IETF Prague meeting, and have updated the pull request. The interesting bit is= the MessageSubmission object definition, which I also include below for co= nvenience. I think (hope) this is pretty close to finished, so please do a = final review before I merge.

Cheers,
Neil.

--------

The MessageSubmission object represents the submission of a message for = delivery to one or more recipients. A MessageSubmission object has t= he following properties:

  • id: String=
    The id of the message submission. This is server-set and immutable.
  • identityId: String
    The id of the identity to associate with this submission. This is imm= utable.
  • messageId: String
    The id of the message to send. This is immutable. The message being s= ent does not have to be a draft, for example when =E2=80=9Credirecting=E2= =80=9D an existing message to a different email address.
  • threadId: String
    The thread id of the message to send. This is immutable and set by th= e server to the threadId property of the message referenced by the <= i>messageId.

  • envelope: Envelope|null
    Information for use when sending via SMTP. This is immutable.

    An Envelope object has the following properties:

      <= li>
      mailFrom: String
      The email address to use as the return address in the SMTP submission= . The JMAP server MAY allow this to be the empty string.

    • mailFromParams: String[String]|null
      SMTP parameters to pass with the MAIL FROM address. Each key is a par= ameter name, and the value the parameter value. In both cases, any xtext or= unitext encodings are removed ([@!RFC3461], [@!RFC6533]) and JSON string e= ncoding applied.

      When a JMAP server performs a message submission, it MAY use th= e same id string for the [@!RFC3461] ENVID parameter and the MessageSubmiss= ion
      object id. Servers that do this MAY replace a client-provided value = for ENVID with a server-provided value.

    • rcptTo: String[String[String]|null]
      The keys of this object are the email addresses to send the message t= o. The value is either null, or another object representing SM= TP RCPT TO parameters to pass with this recipient. Each key is a parameter = name, and the value the parameter value. In both cases, any xtext or unitex= t encodings are removed ([@!RFC3461], [@!RFC6533]) and JSON string encoding= applied.

    If the envelope property is null or om= itted on creation, the server MUST generate this from the referenced messag= e as follows:

    • mailFrom: The email in the S= ender header, if present, otherwise
      the From header, if present.

      If multiple addresses are present in one of these headers, or there = is more than one Sender/From header, the server SHOULD reject= the message as invalid but otherwise MUST take the first email address in = the last Sender/From header in the [@!RFC5322] version of the= message.

      If the address found from this is not allowed by the id= entity associated with this submission, the email property from the = identity MUST be used instead.

    • mailFromParams: null

    • rcptTo: An object with the keys= being the deduplicated set of email
      addresses from the To, Cc and Bcc headers, if pr= esent, and the value for each being null.

  • sendAt: Date
    The date the message was/will be released for delivery. This is serve= r-set and immutable.

    If the client successfully used [@!RFC4865] FUTURERELEASE with the m= essage, this MUST be the time when the server will release the message; oth= erwise it MUST be the time the MessageSubmission was created.

    • <= li>

    undoStatus: String
    This represents whether the submission may be canceled. This is serve= r set and MUST be one of the following values:

    • "pending": It MAY be possible to cancel this submi= ssion.
    • "final": The message has been relayed = to at least one recipient in a
      manner that cannot be recalled. It is no longer possible to cancel th= is
      submission.
    • "canceled": The message submission was canceled = and will not be delivered
      to any recipient.

    On systems that do not support unsending, the value of this pr= operty will always be final. On systems that do support cancel= ing submission, it will start as pending, and MAY transition t= o final when the server knows it definitely cannot recall the = message, but MAY just remain pending. If in pending state, a c= lient can attempt to cancel the submission by setting this property to canceled; if the update succeeds, the submission was successfully = canceled.

  • deliveryStatus: String[Deliv= eryStatus]|null
    This represents the delivery status for each of the message recipient= s, if known. This property is server-set and MAY not be supported by all se= rvers, in which case it will remain null. Servers that support= it SHOULD update the MessageSubmission object each time the status of any = of the recipients changes.

    This is a map from the email address of each recipient of the messag= e, to the most recent SMTP reply code/text known.

    This property i= s server set and MAY not be supported by all servers, in which case it will= remain null. Servers that support it SHOULD update the Messag= eSubmission object each time the status of one of the recipients changes, e= ven if some recipients are still being retried. The isFinal property= allows clients to know if the status may still change further.

    A= DeliveryStatus object has the following properties:

    • =
      isQueued: Boolean
      This is true if the server is still trying to send the m= essage to this
      recipient (and so the smtpReply could still change), otherwise= false.

    • smtpReply: String
      The SMTP reply string returned for this recipient when the server las= t tried to relay the message. This SHOULD be the response to the RCPT TO st= age, unless this was accepted and the message as a whole rejected at the en= d of the DATA stage, in which case the DATA stage reply SHOULD be used inst= ead.

      For messages relayed via an alternative to SMTP, the server MAY gene= rate a synthetic string representing the status instead. If it does this, t= he string MUST be of the following form:

      • A 3-digit SMTP repl= y code, as defined in [@!RFC5321], section 4.2.3.
      • Then a single= space character.
      • Then an SMTP Enhanced Mail System Status= Code as defined in
        [@!RFC3463], with a registry defined in [@!RFC5248].
      • Then a single space character.
      • Then an implementa= tion-specific information string with a human
        readable explanation of the response.

    • delivered: String
      Represents whether the message has been succesfully delivered to the = recipient. This MUST be one of the following values:

      • "unknown": The final delivery status is unkno= wn, either because the
        delivery is still queued and being retried, or it was relayed to an e= xternal machine and no further information is available. This is the initia= l value.
      • "yes": The message was successfully delivered to= the mailbox of the
        recipient.
      • "no": Message delivery to the recipient permanently f= ailed.

      Note, succesful relaying to an external SMTP server = SHOULD NOT be taken as an indication that the message has successfully reac= hed the final mailbox. In this case though, the server MAY receive a DSN re= sponse, if requested.

      If a DSN is received for the recipient with= Action equal to =E2=80=9Cdelivered=E2=80=9D, as per [@!RFC3464] section 2.= 3.3, then the delivered property SHOULD be set to yes; = if the Action equals =E2=80=9Cfailed=E2=80=9D, the property SHOULD be set t= o no. Receipt of any other DSN SHOULD NOT affect this property= .

      The server MAY also set this property based on other feedback c= hannels.

    • displayed: String
      <= /div>
      Represents whether the message has been displayed to the recipient. T= his MUST be one of the following values:

      • "unknown": The display status is unknown. This is = the initial value.
      • "yes": The message content= has been displayed to the recipient. Note,
        there is no guarantee that the recipient has noticed, read, or unders= tood the content.

      If an MDN is received for this recipient with Disposition-Type= (as per [@!RFC3798] section 3.2.6.2) equal to =E2=80=9Cdisplayed=E2=80=9D,= this property SHOULD be set to yes.

      The server MAY = also set this property based on other feedback channels.

    <= /li>

  • dsnBlobIds: String[]
    A list of blob ids for DSNs received for this submission, in order of= receipt, oldest first. This is server-set.

  • mdnBlobIds: String[]
    A list of blob ids for MDNs received for this submission, in order of= receipt, oldest first. This is server-set.

JMAP servers SHOULD NOT expose DSN and MDN messages that corre= late to a MessageSubmission object in responses to getMessageList. I= t SHOULD only expose them in the dsnBlobIds and mdnblobIds fi= elds of this object.

For efficiency, a server MAY destroy Message= Submission objects a certain amount of time after the message is successful= ly sent or it has finished retrying sending the message. For very basic SMT= P proxies, this MAY be immediately after creation, as it has no way to assi= gn a real id and return the information again if fetched later.


--_----------=_150047818021458462-- From nobody Fri Jul 21 01:25: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 F09C312EB2B for ; Fri, 21 Jul 2017 01:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 0qggNJU7JmNw for ; Fri, 21 Jul 2017 01:25:13 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 9D5B712778D for ; Fri, 21 Jul 2017 01:25:13 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v6L8P8sL005971 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 21 Jul 2017 08:25:09 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v6L8P8vr017499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 21 Jul 2017 08:25:08 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v6L8P8ic013424; Fri, 21 Jul 2017 08:25:08 GMT Received: from [10.175.206.68] (/10.175.206.68) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 21 Jul 2017 01:25:07 -0700 From: "Chris Newman" To: "Neil Jenkins" Cc: "IETF JMAP Mailing List" Date: Fri, 21 Jul 2017 10:25:04 +0200 Message-ID: <59546D54-DE6D-435C-B5F8-37A2650DF3FF@oracle.com> In-Reply-To: <1500478180.2145846.1046007808.31167238@webmail.messagingengine.com> References: <1500478180.2145846.1046007808.31167238@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_8D412384-28A5-4EEE-981A-96D360B29323_=" Embedded-HTML: [{"HTML":[1412, 11428], "plain":[79, 9969], "uuid":"6C1FA708-39E9-4602-B159-98F32BB26404"}] X-Mailer: MailMate (1.9.6r5347) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: Re: [Jmap] Revised MessageSubmission object X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 08:25:16 -0000 --=_MailMate_8D412384-28A5-4EEE-981A-96D360B29323_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Looks good to me. - Chris On 19 Jul 2017, at 17:29, Neil Jenkins wrote: > OK, I've taken on all the feedback from the mailing list and as = > discussed at the IETF Prague meeting, and have updated the pull = > request[1]. The interesting bit is the MessageSubmission object = > definition, which I also include below for convenience. I think (hope) = > this is pretty close to finished, so please do a final review before I = > merge. > Cheers, > Neil. > > -------- > The MessageSubmission object represents the submission of a message = > for delivery to one or more recipients. A *MessageSubmission* object = > has the following properties: > > > * *id*: String The id of the message submission. This is server-set = > and > immutable. > * *identityId*: String The id of the identity to associate with this > submission. This is immutable. > * *messageId*: String The id of the message to send. This is = > immutable. > The message being sent does not have to be a draft, for example = > when > =E2=80=9Credirecting=E2=80=9D an existing message to a different ema= il address. > * *threadId*: String The thread id of the message to send. This is > immutable and set by the server to the *threadId* property of the > message referenced by the *messageId*. > * *envelope*: Envelope|null Information for use when sending via = > SMTP. > This is immutable. > > > An *Envelope* object has the following properties: > > > * *mailFrom*: String The email address to use as the return address > in the SMTP submission. The JMAP server MAY allow this to be the > empty string. > * *mailFromParams*: String[String]|null SMTP parameters to pass > with the MAIL FROM address. Each key is a parameter name, and the > value the parameter value. In both cases, any xtext or unitext > encodings are removed ([@!RFC3461], [@!RFC6533]) and JSON string > encoding applied. > > > When a JMAP server performs a message submission, it MAY use the same = > id > string for the [@!RFC3461] ENVID parameter and the MessageSubmission > object id. Servers that do this MAY replace a client-provided value = > for > ENVID with a server-provided value. > > > * *rcptTo*: String[String[String]|null] The keys of this object are > the email addresses to send the message to. The value is either > null, or another object representing SMTP RCPT TO parameters to > pass with this recipient. Each key is a parameter name, and the > value the parameter value. In both cases, any xtext or unitext > encodings are removed ([@!RFC3461], [@!RFC6533]) and JSON string > encoding applied. > > > If the *envelope* property is null or omitted on creation, the server > MUST generate this from the referenced message as follows: > > > * *mailFrom*: The email in the *Sender* header, if present, = > otherwise > the *From* header, if present. > > > If multiple addresses are present in one of these headers, or there > is more than one *Sender*/*From* header, the server SHOULD reject > the message as invalid but otherwise MUST take the first email > address in the last *Sender*/*From* header in the [@!RFC5322] > version of the message. > > > If the address found from this is not allowed by the identity = > associated > with this submission, the *email* property from the identity MUST be > used instead. > > > * *mailFromParams*: null > > > * *rcptTo*: An object with the keys being the deduplicated set of > email addresses from the *To*, *Cc* and *Bcc* headers, if = > present, > and the value for each being null. > * *sendAt*: Date The date the message was/will be released for > delivery. This is server-set and immutable. > > > If the client successfully used [@!RFC4865] FUTURERELEASE with the > message, this MUST be the time when the server will release the = > message; > otherwise it MUST be the time the MessageSubmission was created. > > > * *undoStatus*: String This represents whether the submission may be > canceled. This is server set and MUST be one of the following = > values: > > > * "pending": It MAY be possible to cancel this submission. > * "final": The message has been relayed to at least one recipient = > in > a manner that cannot be recalled. It is no longer possible to > cancel this submission. > * "canceled": The message submission was canceled and will not be > delivered to any recipient. On systems that do not support > unsending, the value of this property will always be final. On > systems that do support canceling submission, it will start as > pending, and MAY transition to final when the server knows it > definitely cannot recall the message, but MAY just remain = > pending. > If in pending state, a client can attempt to cancel the = > submission > by setting this property to canceled; if the update succeeds, the > submission was successfully canceled. > > > * *deliveryStatus*: String[DeliveryStatus]|null This represents the > delivery status for each of the message recipients, if known. This > property is server-set and MAY not be supported by all servers, in > which case it will remain null. Servers that support it SHOULD = > update > the MessageSubmission object each time the status of any of the > recipients changes. > > > This is a map from the email address of each recipient of the message, > to the most recent SMTP reply code/text known. > > > This property is server set and MAY not be supported by all servers, = > in > which case it will remain null. Servers that support it SHOULD update > the MessageSubmission object each time the status of one of the > recipients changes, even if some recipients are still being retried. > The *isFinal* property allows clients to know if the status may still > change further. > > > A *DeliveryStatus* object has the following properties: > > > * *isQueued*: Boolean This is true if the server is still trying to > send the message to this recipient (and so the *smtpReply* could > still change), otherwise false. > * *smtpReply*: String The SMTP reply string returned for this > recipient when the server last tried to relay the message. This > SHOULD be the response to the RCPT TO stage, unless this was > accepted and the message as a whole rejected at the end of the = > DATA > stage, in which case the DATA stage reply SHOULD be used instead. > > > For messages relayed via an alternative to SMTP, the server MAY = > generate > a synthetic string representing the status instead. If it does this, = > the > string MUST be of the following form: > > > * A 3-digit SMTP reply code, as defined in [@!RFC5321], > section 4.2.3. > * Then a single space character. > * Then an SMTP Enhanced Mail System Status Code as defined in > [@!RFC3463], with a registry defined in [@!RFC5248]. > * Then a single space character. > * Then an implementation-specific information string with a human > readable explanation of the response. > * *delivered*: String Represents whether the message has been > succesfully delivered to the recipient. This MUST be one of the > following values: > > > * "unknown": The final delivery status is unknown, either because > the delivery is still queued and being retried, or it was = > relayed > to an external machine and no further information is available. > This is the initial value. > * "yes": The message was successfully delivered to the mailbox of > the recipient. > * "no": Message delivery to the recipient permanently failed. = > Note, > succesful relaying to an external SMTP server SHOULD NOT be = > taken > as an indication that the message has successfully reached the > final mailbox. In this case though, the server MAY receive a = > DSN > response, if requested. > > > If a DSN is received for the recipient with Action equal to = > =E2=80=9Cdelivered=E2=80=9D, > as per [@!RFC3464] section 2.3.3, then the *delivered* property SHOULD > be set to yes; if the Action equals =E2=80=9Cfailed=E2=80=9D, the prope= rty SHOULD = > be set > to no. Receipt of any other DSN SHOULD NOT affect this property. > > > The server MAY also set this property based on other feedback = > channels. > > > * *displayed*: String Represents whether the message has been > displayed to the recipient. This MUST be one of the following > values: > > > * "unknown": The display status is unknown. This is the > initial value. > * "yes": The message content has been displayed to the > recipient. Note, there is no guarantee that the recipient has > noticed, read, or understood the content. If an MDN is > received for this recipient with Disposition-Type (as per > [@!RFC3798] section 3.2.6.2) equal to =E2=80=9Cdisplayed=E2=80=9D= , this > property SHOULD be set to yes. > > > The server MAY also set this property based on other feedback = > channels. > > > * *dsnBlobIds*: String[] A list of blob ids for DSNs received for = > this > submission, in order of receipt, oldest first. This is server-set. > > > * *mdnBlobIds*: String[] A list of blob ids for MDNs received for = > this > submission, in order of receipt, oldest first. This is = > server-set.JMAP servers SHOULD NOT expose DSN and MDN messages that = > correlate to a MessageSubmission object in responses to = > *getMessageList*. It SHOULD only expose them in the *dsnBlobIds* and = > *mdnblobIds* fields of this object.For efficiency, a server MAY = > destroy MessageSubmission objects a certain amount of time after the = > message is successfully sent or it has finished retrying sending the = > message. For very basic SMTP proxies, this MAY be immediately after = > creation, as it has no way to assign a real id and return the = > information again if fetched later. > > Links: > > 1. = > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.com_jmapi= o_jmap_pull_99&d=3DDwIFaQ&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10= &r=3DQBZgPENFbjFadxqU4HJ3ZDpRz3X1JlDY-keqMt52FFo&m=3DgZ8BsJE1nhSVdPcIJutq= -IjfDKx6F21XQIJFaJm98vU&s=3DGRDYqGh3s-ov_V_EQqQeW-7or0XlCPWvxrhfjf405Go&e= =3D > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= lman_listinfo_jmap&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057S= bK10&r=3DQBZgPENFbjFadxqU4HJ3ZDpRz3X1JlDY-keqMt52FFo&m=3DgZ8BsJE1nhSVdPcI= Jutq-IjfDKx6F21XQIJFaJm98vU&s=3DFeIDCfMS_WzhsVdtIezLLrRatQ64x7uFEwrM4VHEj= CU&e=3D --=_MailMate_8D412384-28A5-4EEE-981A-96D360B29323_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Looks good to me.

- Chris

On 19 Jul 2017, at 17:29, Neil Jenkins wrote:

OK, I've taken on all the feedback from the mailing list and as disc= ussed at the IETF Prague meeting, and have updated the pull= request. The interesting bit is the MessageSubmission object definit= ion, which I also include below for convenience. I think (hope) this is p= retty close to finished, so please do a final review before I merge.
<= /div>

Cheers,
Neil.

--------

The MessageSubmission object represents the submission of a message fo= r delivery to one or more recipients. A MessageSubmission object h= as the following properties:

  • id: String<= /code>
    The id of the message submission. This is server-set and immutable.=
  • identityId: String
    The id of the identity to associate with this submission. This is i= mmutable.
  • messageId: String
    The id of the message to send. This is immutable. The message being= sent does not have to be a draft, for example when =E2=80=9Credirecting=E2= =80=9D an existing message to a different email address.
  • threadId: String
    The thread id of the message to send. This is immutable and set by = the server to the threadId property of the message referenced by t= he messageId.

  • envelope: Envelope|null
    Information for use when sending via SMTP. This is immutable.

    An Envelope object has the following properties:

  • mailFrom: String
    The email address to use as the return address in the SMTP submissi= on. The JMAP server MAY allow this to be the empty string.

  • mailFromParams: String[String]|null<= br>
    SMTP parameters to pass with the MAIL FROM address. Each key is a p= arameter name, and the value the parameter value. In both cases, any xtex= t or unitext encodings are removed ([@!RFC3461], [@!RFC6533]) and JSON st= ring encoding applied.

    When a JMAP server performs a message submission, it MAY use = the same id string for the [@!RFC3461] ENVID parameter and the MessageSub= mission
    object id. Servers that do this MAY replace a client-provided value= for ENVID with a server-provided value.

  • rcptTo: String[String[String]|null]
    The keys of this object are the email addresses to send the message= to. The value is either null, or another object representin= g SMTP RCPT TO parameters to pass with this recipient. Each key is a para= meter name, and the value the parameter value. In both cases, any xtext o= r unitext encodings are removed ([@!RFC3461], [@!RFC6533]) and JSON strin= g encoding applied.

If the envelope property is null or = omitted on creation, the server MUST generate this from the referenced me= ssage as follows:

  • mailFrom: The email in th= e Sender header, if present, otherwise
    the From header, if present.

    If multiple addresses are present in one of these headers, or ther= e is more than one Sender/From header, the server SHOULD re= ject the message as invalid but otherwise MUST take the first email addre= ss in the last Sender/From header in the [@!RFC5322] versio= n of the message.

    If the address found from this is not allowed= by the identity associated with this submission, the email proper= ty from the identity MUST be used instead.

  • mailFrom= Params: null

  • rcptTo: An obje= ct with the keys being the deduplicated set of email
    addresses from the To, Cc and Bcc headers, if = present, and the value for each being null.

  • sendAt: Date
    The date the message was/will be released for delivery. This is ser= ver-set and immutable.

    If the client successfully used [@!RFC4865] FUTURERELEASE with the= message, this MUST be the time when the server will release the message;= otherwise it MUST be the time the MessageSubmission was created.

    =

  • undoStatus: String
    This represents whether the submission may be canceled. This is ser= ver set and MUST be one of the following values:

    • "pending": It MAY be possible to cancel this sub= mission.
    • "final": The message has been rela= yed to at least one recipient in a
      manner that cannot be recalled. It is no longer possible to cancel = this
      submission.
    • "canceled": The message submission was cancele= d and will not be delivered
      to any recipient.

    On systems that do not support unsending, the value of this = property will always be final. On systems that do support ca= nceling submission, it will start as pending, and MAY transi= tion to final when the server knows it definitely cannot rec= all the message, but MAY just remain pending. If in pending = state, a client can attempt to cancel the submission by setting this prop= erty to canceled; if the update succeeds, the submission was= successfully canceled.

  • deliveryStatus: String[DeliveryStatus]|null
    This represents the delivery status for each of the message recipie= nts, if known. This property is server-set and MAY not be supported by al= l servers, in which case it will remain null. Servers that s= upport it SHOULD update the MessageSubmission object each time the status= of any of the recipients changes.

    This is a map from the email address of each recipient of the mess= age, to the most recent SMTP reply code/text known.

    This proper= ty is server set and MAY not be supported by all servers, in which case i= t will remain null. Servers that support it SHOULD update th= e MessageSubmission object each time the status of one of the recipients = changes, even if some recipients are still being retried. The isFinal<= /i> property allows clients to know if the status may still change furthe= r.

    A DeliveryStatus object has the following properties:=

    • isQueued: Boolean
      This is true if the server is still trying to send the= message to this
      recipient (and so the smtpReply could still change), otherwi= se false.

    • smtpReply: String
      The SMTP reply string returned for this recipient when the server l= ast tried to relay the message. This SHOULD be the response to the RCPT T= O stage, unless this was accepted and the message as a whole rejected at = the end of the DATA stage, in which case the DATA stage reply SHOULD be u= sed instead.

      For messages relayed via an alternative to SMTP, the server MAY ge= nerate a synthetic string representing the status instead. If it does thi= s, the string MUST be of the following form:

      • A 3-digit SMT= P reply code, as defined in [@!RFC5321], section 4.2.3.
      • Then = a single space character.
      • Then an SMTP Enhanced Mail Sys= tem Status Code as defined in
        [@!RFC3463], with a registry defined in [@!RFC5248].
      • Then a single space character.
      • Then an implemen= tation-specific information string with a human
        readable explanation of the response.

    • delivered: String
      Represents whether the message has been succesfully delivered to th= e recipient. This MUST be one of the following values:

      • "unknown": The final delivery status is unk= nown, either because the
        delivery is still queued and being retried, or it was relayed to an= external machine and no further information is available. This is the in= itial value.
      • "yes": The message was successfully delivered = to the mailbox of the
        recipient.
      • "no": Message delivery to the recipient permanently= failed.

      Note, succesful relaying to an external SMTP ser= ver SHOULD NOT be taken as an indication that the message has successfull= y reached the final mailbox. In this case though, the server MAY receive = a DSN response, if requested.

      If a DSN is received for the reci= pient with Action equal to =E2=80=9Cdelivered=E2=80=9D, as per [@!RFC3464= ] section 2.3.3, then the delivered property SHOULD be set to yes; if the Action equals =E2=80=9Cfailed=E2=80=9D, the property= SHOULD be set to no. Receipt of any other DSN SHOULD NOT af= fect this property.

      The server MAY also set this property based= on other feedback channels.

    • displayed: String
      Represents whether the message has been displayed to the recipient.= This MUST be one of the following values:

      • "unknown": The display status is unknown. This i= s the initial value.
      • "yes": The message con= tent has been displayed to the recipient. Note,
        there is no guarantee that the recipient has noticed, read, or unde= rstood the content.

      If an MDN is received for this recipient with Disposition-Ty= pe (as per [@!RFC3798] section 3.2.6.2) equal to =E2=80=9Cdisplayed=E2=80= =9D, this property SHOULD be set to yes.

      The serve= r MAY also set this property based on other feedback channels.

  • dsnBlobIds: String[]
    A list of blob ids for DSNs received for this submission, in order = of receipt, oldest first. This is server-set.

  • mdnBlobIds: String[]
    A list of blob ids for MDNs received for this submission, in order = of receipt, oldest first. This is server-set.

    • JMAP servers SHOULD NOT expose DSN and MDN messages that cor= relate to a MessageSubmission object in responses to getMessageList. It SHOULD only expose them in the dsnBlobIds and mdnblobIds<= /i> fields of this object.

    For efficiency, a server MAY destroy= MessageSubmission objects a certain amount of time after the message is = successfully sent or it has finished retrying sending the message. For ve= ry basic SMTP proxies, this MAY be immediately after creation, as it has = no way to assign a real id and return the information again if fetched la= ter.


    ____________________________________________= ___
    Jmap mailing list
    Jmap@ietf.org
    https://urldefense.proofpoint.c= om/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_jmap&d=3DDwICAg= &c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DQBZgPENFbjFa= dxqU4HJ3ZDpRz3X1JlDY-keqMt52FFo&m=3DgZ8BsJE1nhSVdPcIJutq-IjfDKx6F21XQ= IJFaJm98vU&s=3DFeIDCfMS_WzhsVdtIezLLrRatQ64x7uFEwrM4VHEjCU&e=3D

    --=_MailMate_8D412384-28A5-4EEE-981A-96D360B29323_=-- From nobody Fri Jul 21 02:25: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 3B1E312EC51 for ; Fri, 21 Jul 2017 02:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, 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 (2048-bit key) header.d=fastmailteam.com header.b=juEp1dLf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HvVRvTt+ 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 zeO4PGOR-8ZN for ; Fri, 21 Jul 2017 02:25:29 -0700 (PDT) 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 9C3FA129AA0 for ; Fri, 21 Jul 2017 02:25:29 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 133A72086D for ; Fri, 21 Jul 2017 05:25:29 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Fri, 21 Jul 2017 05:25:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.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=fm1; bh=n+uk+mJKHeU5zVoQA QEkFa1Ne63iejluY+aiM1FBzzQ=; b=juEp1dLfjH19y5gJMPKftQPV6B3/umjG0 MxQQTQkZNt1pEJC0t2VfI6itzYLqQApLgAO0RF8NqgONMFE6VBO/xMquPVAJAnVs 5LXMO31MViZ1oCo9x20j1nAnUV8M6/yyDkP5aVRswIibxvC40qx+HstGYUu3Bvso ey8mcjsSWiiGEUBpA1WBYgoKLQ66PEmKOHA9oL+iQ5ijKEbnxkLdkg3tf13UCunO ybwoPz9eCjA3Wbh0z4lJGi//jUJsYtxd5YR6U1KBwMLETqr4O2xepC+6e5ohl8jF ScZ0OfB9PIGO98y0RGMM0vu7XvUKryeUqNd3WOTyz367PGK7KDKsg== DKIM-Signature: v=1; a=rsa-sha256; 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=fm1; bh=n+uk+m JKHeU5zVoQAQEkFa1Ne63iejluY+aiM1FBzzQ=; b=HvVRvTt+c6SwVYSIvN6/tT ZWw1jU7Yd12AVZy0ftzq9ZYaxW1DgsYEbiZXDTljqCMkOFJVB0VdInpBXOHFZXNi 9EyAnmrVvgcBCSvVOJUlodmr7jJCckwps5+fqhDya605nL+YPGsIdSmHtDpP2h7j w12SVieS3MMYhqCs3RuJQHmI03N3+a0dzNm2jCx0umJPhX9Wn2vRhsE7baNu7ya5 sRg2pHRuJmgqv00lJHInCflitSX1Qvwm8Ps+0tfg4sXA/MdxqlTB7e5SOGmeAPfU B0gyYDWG7tMli+RPVH3UZ2B69KV4UPC1V/5nrwiec//gLmaG2CGQaPaZyqO3Bl0A == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id BDAE7E22C4; Fri, 21 Jul 2017 05:25:28 -0400 (EDT) Message-Id: <1500629128.566223.1048026864.43131E47@webmail.messagingengine.com> From: Neil Jenkins To: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15006291285662231" X-Mailer: MessagingEngine.com Webmail Interface - ajax-bc7e1bfe Date: Fri, 21 Jul 2017 19:25:28 +1000 References: <1500478180.2145846.1046007808.31167238@webmail.messagingengine.com> <59546D54-DE6D-435C-B5F8-37A2650DF3FF@oracle.com> In-Reply-To: <59546D54-DE6D-435C-B5F8-37A2650DF3FF@oracle.com> Archived-At: Subject: Re: [Jmap] Revised MessageSubmission object X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 09:25:31 -0000 This is a multi-part message in MIME format. --_----------=_15006291285662231 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" One small syntax change based on feedback received off list: I've changed the structure of the Envelope object to be more consistent between rcptTo and mailFrom. New version below for reference. Neil. ---- *envelope*: Envelope|null Information for use when sending via SMTP. This is immutable. An *Envelope* object has the following properties: * *mailFrom*: Address The email address to use as the return address in the SMTP submission, plus any parameters to pass with the MAIL FROM address. The JMAP server MAY allow the email to be the empty string. When a JMAP server performs a message submission, it MAY use the same id string for the [@!RFC3461] ENVID parameter and the MessageSubmission object id. Servers that do this MAY replace a client-provided value for ENVID with a server-provided value. * *rcptTo*: Address[] The email addresses to send the message to, and any RCPT TO parameters to pass with the recipient.An *Address* object has the following properties: * *email*: String The email address being represented by the object. * *parameters*: Object|null Any parameters to send with the email. If supplied, each key in the object is a parameter name, and the value the parameter value. In both cases, any xtext or unitext encodings are removed ([@!RFC3461], [@!RFC6533]) and JSON string encoding applied.If the *envelope* property is null or omitted on creation, the server MUST generate this from the referenced message as follows: * *mailFrom*: The email in the *Sender* header, if present, otherwise the *From* header, if present, and no parameters. If multiple addresses are present in one of these headers, or there is more than one *Sender*/*From* header, the server SHOULD reject the message as invalid but otherwise MUST take the first email address in the last *Sender*/*From* header in the [@!RFC5322] version of the message. If the address found from this is not allowed by the identity associated with this submission, the *email* property from the identity MUST be used instead. * *rcptTo*: The deduplicated set of email addresses from the *To*, *Cc* and *Bcc* headers, if present, with no parameters for any of them. --_----------=_15006291285662231 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
    One small syntax change based on feedback received off list: I've changed the structure of the Envelope object to be more consistent between rcptTo and mailFrom. New version below for reference.

    Neil.

    ----

    envelope: Envelope|null
    Information for use when sending via SMTP. This is immutable.

    An Envelope object has the following properties:

    • mailFrom: Address
      The email address to use as the return address in the SMTP submission, plus any parameters to pass with the MAIL FROM address. The JMAP server MAY allow the email to be the empty string.

      When a JMAP server performs a message submission, it MAY use the same id string for the [@!RFC3461] ENVID parameter and the MessageSubmission
      object id. Servers that do this MAY replace a client-provided value for ENVID with a server-provided value.

    • rcptTo: Address[]
      The email addresses to send the message to, and any RCPT TO parameters to pass with the recipient.

    An Address object has the following properties:

    • email: String
      The email address being represented by the object.
    • parameters: Object|null
      Any parameters to send with the email. If supplied, each key in the object is a parameter name, and the value the parameter value. In both cases, any xtext or unitext encodings are removed ([@!RFC3461], [@!RFC6533]) and JSON string encoding applied.

    If the envelope property is null or omitted on creation, the server MUST generate this from the referenced message as follows:

    • mailFrom: The email in the Sender header, if present, otherwise
      the From header, if present, and no parameters.

      If multiple addresses are present in one of these headers, or there is more than one Sender/From header, the server SHOULD reject the message as invalid but otherwise MUST take the first email address in the last Sender/From header in the [@!RFC5322] version of the message.

      If the address found from this is not allowed by the identity associated with this submission, the email property from the identity MUST be used instead.

    • rcptTo: The deduplicated set of email addresses from the To, Cc
      and Bcc headers, if present, with no parameters for any of them.


    --_----------=_15006291285662231-- From nobody Tue Jul 25 19:01:18 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 5EC3D1321AA for ; Tue, 25 Jul 2017 19:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, 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 (2048-bit key) header.d=fastmailteam.com header.b=O+fsFlSC; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hy7NSnRe 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 h3tu6JEam60Y for ; Tue, 25 Jul 2017 19:01:14 -0700 (PDT) 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 1F0161321A8 for ; Tue, 25 Jul 2017 19:01:14 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 79BFF20AE0 for ; Tue, 25 Jul 2017 22:01:13 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Tue, 25 Jul 2017 22:01:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.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=fm1; bh=TErMLQDDAucVcMFAD FYwhaIyXnf8HntLoPW56zsUtqY=; b=O+fsFlSCAru9LHdfEUOOetetIflGhzJsS AB9FnLwO0oWQMBQTR1BCUrZj/KDdFOuDLrquoX3PpvbYXkzSGcSiig1JUFX2ZM7v tc3CM3a4H9+YwU9qx6uVwudmenkisWCOtjS1P2qCBg0ucr4F7htYTheWbb0EeSVU LtCnF2/jyxb/HvHzQLfyExfwDEIIcc+ss1v1rmokoU+LjUEQHu6U+bDtkMWEdcoV F79DvIeMAOUV8jOJYDEr24x71ZEbynsN6pFthLfikVpWI5WPZV2H2Ns4qNdDwZgi fYihidijxr/76zuR9hQshRpA2DmsiYf/mL/oB1W/irnoWEmIoyFXQ== DKIM-Signature: v=1; a=rsa-sha256; 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=fm1; bh=TErMLQ DDAucVcMFADFYwhaIyXnf8HntLoPW56zsUtqY=; b=hy7NSnReJS1bU6ii7h3Xoj JPLuOhOIkw7AYYBe8aiLF59wt/H5eB8wYxTBOdB47psq9i9DC7LwCr4J2gP5NAfa UpccOLhhO8WHFJqCVyyeuP0jwh9yEokRolvTk1pt6FoAkmXbpwjUe431wbtZD1WM nX8F2QmMAC1b6Qtt1HrZoOaCAc5XU9y8yKh3WTUIyqDfrweLd/3V7W1giWTskDOT COpfOscbFIvuxZoe6h0KH8KzL2L36ti20J5MO1ZBp/8t0br/7f797yMUCfl/XLnm YLMgmgru5CWxz9tXLQ13cvltXqwnAEWR+BLSKxTTBY9Vgf2OIk/JHcOqOku6SGMA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 4DF206264C; Tue, 25 Jul 2017 22:01:13 -0400 (EDT) Message-Id: <1501034473.2494715.1052680736.6C3768C7@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150103447324947152" X-Mailer: MessagingEngine.com Webmail Interface - ajax-c8af44bc References: <1499230650.3642220.1030669400.4800D481@webmail.messagingengine.com> In-Reply-To: Date: Wed, 26 Jul 2017 12:01:13 +1000 Archived-At: Subject: Re: [Jmap] Feedback on draft-ietf-jmap-core X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 02:01:17 -0000 This is a multi-part message in MIME format. --_----------=_150103447324947152 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Hi Martin, Reading back through this email, I think we've resolved Authentication by agreeing to split it into either a separate spec or just handwave a bit "the user will be authenticated somehow" and provide an endpoint at which the list of Accounts accessible to the currently authenticated user can be fetched. Does that resolve your concerns there? https://github.com/jmapio/jmap/issues/105 (also a task specific to seeing if OAUTH with automatic registration could work with JMAP)https://github.com/jmapio/jmap/issues/106 Regarding push, I think we also agreed to make the wording more clear, and add encryption support: github #108-#110. So the main area left that isn't resolved is the use of HTTP as a transport: https://github.com/jmapio/jmap/issues/111 and optionally having two methods for accessing every object: 1) the JMAP-method style (which would also work over websockets or similar, and is batch friendly); and2) per-Object URLs and GET / PUT / PATCH / DELETE semantics (more round trips, but maybe easier for basic integrations that don't need updates, push, etc) https://github.com/jmapio/jmap/issues/112 Have I missed anything that you think needs a separate issue to track it? Thanks, Bron. On Wed, 5 Jul 2017, at 18:16, Martin Thomson wrote: > Hi Neil, > > My MTA seems to have lost your nicely decorated quoting, sorry. Who > would have thought that that would still be a problem. > > On 5 July 2017 at 14:57, Neil Jenkins wrote:>> If you have a suggestion of an existing authentication scheme that meets>> these criteria, we should look at that. > > I appreciate that HTTP authentication is (badly) challenged, but it > will depend greatly on what context you are operating in. For > instance, if you are assuming that there can't be a user and web > browser involved in the onboarding process, that makes things pretty > challenging. > > You really need to motivate that more strongly than you have: account> creation is an exceptional process and covering that makes something > arbitrarily complex. There are many questions that you can avoid by > assuming the presence of a user with a browser: do you need CAPTCHA? > do you need to setup 2FA? if there is a password, what are the > policies on those? > > The problem with the current document is that you spend 11ish pages on> defining a new authentication scheme. That's a huge amount of work > that distracts from your main task: making a mail access protocol. > > Also, from experience with these things, 11 pages is far from enough > information to describe an authentication scheme, particularly one > with this level of complexity. For example, I don't think that the > "totp" scheme is specified in sufficient detail to implement > interoperable implementations. > > The IETF chartered a working group that concentrates on this exact > problem. I know that you don't want to create dependencies on other > groups, but that is where this is currently headed. I would encourage> you to talk to the folks in the OAUTH and HTTPAUTH working groups to > see if they have solutions for your problems. There's a lot going on> there. > >> I explained the technical decisions behind this in the "Structure of a>> request/response" part of my email "JMAP Conceptual Decisions", a few weeks>> ago. If you missed it, a plain-text copy is available in the IETF archive at>> https://mailarchive.ietf.org/arch/msg/jmap/SfCe3UJPEEUdeomeso_-PAzP5tQ> > Since I only just now joined this list, I will reply here. I think > that you can achieve your goals within the same framework. > > As an aside, I'm accepting for the moment that your performance goals> cannot be met by the simple use of HTTP that you discredit in that > thread. I'm not an expert in this area, other than also having long > ping times to servers that many in this organization assume are close,> and I know very well the value of cutting round trips, but I'm not > convinced that the performance constraints are so severe that they > demand this much contortion. > > If they are indeed that severe, even then I would prefer if you > explored alternative options that would be less opaque to HTTP. Have> you considered creating explicit dependencies between requests just in> your request bodies? That would allow you to send the requests > concurrently. It's possible that a generic facility like that would > be valuable in HTTP for use with transactional APIs. > > Or there is the pattern of transactional resources. In this you > create a resource. That can be done ahead of the need to use it so > that you avoid spending the round trips on setup. You then populate > that resource (in this case, with the actions you wish to take), then> you execute the transaction. This model has other virtues in that the> non-idempotent requests cause minimal side-effects and the final > transaction commit can use an idempotent method. > > You might have already considered these approaches and found them > wanting, or maybe you need more information before you can decide. > I'd like to hear why some time. > >>> 4. Don't use EventSource. >> The EventSource part can easily be made to support long-polling instead at>> the option of the client (the only difference being it closes the connection>> after every push). Having a direct way for clients that are able to hold>> open connections get push notifications without requiring their own push>> server (see below) is still a good thing to have IMO. > > The people who designed EventSource tell me that it's basically > abandoned. It was replaced by thewebsocketprotocol, which has been > largely superceded by the facilities that HTTP/2 provides (though I > will concede that of those facilities, only long-polling is a viable > option today; push still a work in progress). > > That said, you actually have **two** goals here. One is for an > asynchronous communications channel that you can use while there are > ongoing interactions between client and server. For that, I generally> recommend long-polling, though that can lead to generic event streams,> which can easily become the locus of a huge pile of technical debt. > > The other is the need to send messages when the client is effectively> offline. For that, you negatively want something that you manage > yourself. It's a battery drain. It's hard to ensure that you don't > end up with a dead connection as a result of middlebox shenanigans. > Maintaining an open connection is either prohibited or strongly > discouraged on many operating systems for those reasons. > > The messages that traverse those two paths are likely different. Push> messages are considerably more limited in what they can carry. > >> I presume this is referring to the Web Hook part of the push section of the>> spec, as this is the only place this word is mentioned. I'm not sure exactly>> what you mean by "client reachability isn't consistent", but the intention>> here (with a few header changes still required) is that the JMAP server is>> an RFC8030 compliant "Application Server". > > I had no idea that that was your intention from reading the draft. If> your intent was to act as an application server and actually use the > Push API, then it needs to be explicit. > > _________________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150103447324947152 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
    Hi Martin,

    Reading back through this email, I think we've resolved Authentication by agreeing to split it into either a separate spec or just handwave a bit "the user will be authenticated somehow" and provide an endpoint at which the list of Accounts accessible to the currently authenticated user can be fetched.  Does that resolve your concerns there?

    (also a task specific to seeing if OAUTH with automatic registration could work with JMAP)

    Regarding push, I think we also agreed to make the wording more clear, and add encryption support:

    github #108-#110.

    So the main area left that isn't resolved is the use of HTTP as a transport:


    and optionally having two methods for accessing every object:
    1) the JMAP-method style (which would also work over websockets or similar, and is batch friendly); and
    2) per-Object URLs and GET / PUT / PATCH / DELETE semantics (more round trips, but maybe easier for basic integrations that don't need updates, push, etc)


    Have I missed anything that you think needs a separate issue to track it?

    Thanks,

    Bron.

    On Wed, 5 Jul 2017, at 18:16, Martin Thomson wrote:
    Hi Neil,

    My MTA seems to have lost your nicely decorated quoting, sorry.  Who
    would have thought that that would still be a problem.

    On 5 July 2017 at 14:57, Neil Jenkins <neilj@fastmailteam.com> wrote:
    If you have a suggestion of an existing authentication scheme that meets
    these criteria, we should look at that.

    I appreciate that HTTP authentication is (badly) challenged, but it
    will depend greatly on what context you are operating in.  For
    instance, if you are assuming that there can't be a user and web
    browser involved in the onboarding process, that makes things pretty
    challenging.

    You really need to motivate that more strongly than you have: account
    creation is an exceptional process and covering that makes something
    arbitrarily complex.  There are many questions that you can avoid by
    assuming the presence of a user with a browser: do you need CAPTCHA?
    do you need to setup 2FA?  if there is a password, what are the
    policies on those?

    The problem with the current document is that you spend 11ish pages on
    defining a new authentication scheme.  That's a huge amount of work
    that distracts from your main task: making a mail access protocol.

    Also, from experience with these things, 11 pages is far from enough
    information to describe an authentication scheme, particularly one
    with this level of complexity.  For example, I don't think that the
    "totp" scheme is specified in sufficient detail to implement
    interoperable implementations.

    The IETF chartered a working group that concentrates on this exact
    problem.  I know that you don't want to create dependencies on other
    groups, but that is where this is currently headed.  I would encourage
    you to talk to the folks in the OAUTH and HTTPAUTH working groups to
    see if they have solutions for your problems.  There's a lot going on
    there.

    I explained the technical decisions behind this in the "Structure of a
    request/response" part of my email "JMAP Conceptual Decisions", a few weeks
    ago. If you missed it, a plain-text copy is available in the IETF archive at

    Since I only just now joined this list, I will reply here.  I think
    that you can achieve your goals within the same framework.

    As an aside, I'm accepting for the moment that your performance goals
    cannot be met by the simple use of HTTP that you discredit in that
    thread. I'm not an expert in this area, other than also having long
    ping times to servers that many in this organization assume are close,
    and I know very well the value of cutting round trips, but I'm not
    convinced that the performance constraints are so severe that they
    demand this much contortion.

    If they are indeed that severe, even then I would prefer if you
    explored alternative options that would be less opaque to HTTP.  Have
    you considered creating explicit dependencies between requests just in
    your request bodies?  That would allow you to send the requests
    concurrently.  It's possible that a generic facility like that would
    be valuable in HTTP for use with transactional APIs.

    Or there is the pattern of transactional resources.  In this you
    create a resource. That can be done ahead of the need to use it so
    that you avoid spending the round trips on setup.  You then populate
    that resource (in this case, with the actions you wish to take), then
    you execute the transaction.  This model has other virtues in that the
    non-idempotent requests cause minimal side-effects and the final
    transaction commit can use an idempotent method.

    You might have already considered these approaches and found them
    wanting, or maybe you need more information before you can decide.
    I'd like to hear why some time.

    4. Don't use EventSource.
    The EventSource part can easily be made to support long-polling instead at
    the option of the client (the only difference being it closes the connection
    after every push). Having a direct way for clients that are able to hold
    open connections get push notifications without requiring their own push
    server (see below) is still a good thing to have IMO.

    The people who designed EventSource tell me that it's basically
    abandoned.  It was replaced by thewebsocketprotocol, which has been
    largely superceded by the facilities that HTTP/2 provides (though I
    will concede that of those facilities, only long-polling is a viable
    option today; push still a work in progress).

    That said, you actually have *two* goals here.  One is for an
    asynchronous communications channel that you can use while there are
    ongoing interactions between client and server.  For that, I generally
    recommend long-polling, though that can lead to generic event streams,
    which can easily become the locus of a huge pile of technical debt.

    The other is the need to send messages when the client is effectively
    offline.  For that, you negatively want something that you manage
    yourself.  It's a battery drain.  It's hard to ensure that you don't
    end up with a dead connection as a result of middlebox shenanigans.
    Maintaining an open connection is either prohibited or strongly
    discouraged on many operating systems for those reasons.

    The messages that traverse those two paths are likely different.  Push
    messages are considerably more limited in what they can carry.

    I presume this is referring to the Web Hook part of the push section of the
    spec, as this is the only place this word is mentioned. I'm not sure exactly
    what you mean by "client reachability isn't consistent", but the intention
    here (with a few header changes still required) is that the JMAP server is
    an RFC8030 compliant "Application Server".

    I had no idea that that was your intention from reading the draft.  If
    your intent was to act as an application server and actually use the
    Push API, then it needs to be explicit.

    _______________________________________________
    Jmap mailing list

    --
      Bron Gondwana, CEO, FastMail Pty Ltd
      brong@fastmailteam.com


    --_----------=_150103447324947152-- From nobody Tue Jul 25 21:50: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 A7E1A129B6A for ; Tue, 25 Jul 2017 21:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 00F4ys_ZLEa7 for ; Tue, 25 Jul 2017 21:50:04 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::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 B3B58129B5B for ; Tue, 25 Jul 2017 21:50:04 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id l7so63878237iof.1 for ; Tue, 25 Jul 2017 21:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JsZhr4J530lTwqUImnnyPd1o7WcKckeuQN0ibbPQR6U=; b=pZDU1gsoIc44KdQ2fDAH7L4yuUa6eY5tFxclnL+zj2OrTCz49q/F+epwjTq0kk3piO 3mmNt9dYMZMik7L2klEhm3uaiY1VxcV54yPVLT/r411kqEitF6HujNv43E+EVKPy66AV mKbK3A3VUo7y7x3idLeVXqGSoH002udAJvF4xJtWub/GXSLKBHjQtJUlqdapGalFw3Iz v/NFTrmXLl/lyHRGjdxTee4ooUHMV5NHyC57goxItNo2weCgaYH/ROuUObJEHTZUOcee 3H/FQiWC0mpo3fZ/ZI5vY8r1ks/E/9F7NfwRecyOrig95woeODkKwYUIVK4ocJlwN/OD dyEw== 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; bh=JsZhr4J530lTwqUImnnyPd1o7WcKckeuQN0ibbPQR6U=; b=D/H0pgLjoy4W5TdmOHe9aItb0b9ZmJR1H9XM8Q9a0zZOxpowqH22BBziOdrendkQlU 8ZUbOKcjuMl4ZqELjRr9Jr/24bvvaDh6NSvpsDPkPkmAUE9G4AfzrOAMYQ8N04XQY3zC xK6xOqAEiowYd98py6mIR9EU8bHn0SEgyqDupOVRtZNyT7dOmMMSPOtDmu22qTgmDAkH OrgUSov0eNEZ4hcoBUCOqO1WziFlZQEIrTtpAnEaQ+UhlKM/E+u7OKB65SIqUwJLG0Cm RaHyJYV5nv60i0Rfl0l94ZXBlWsMnncDVb9a6r8d0uLtYbYPO3twXTNKNqZgg03Pk4fV AIbQ== X-Gm-Message-State: AIVw113OYHvncNY2Ss0fGBK0Yx3DQzrMyvg16qI4miTBqdIpenKwIit7 fnnJvdBPANB333s6X0kOnqNK+fih79Hi X-Received: by 10.107.16.196 with SMTP id 65mr24565009ioq.297.1501044603742; Tue, 25 Jul 2017 21:50:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Tue, 25 Jul 2017 21:50:02 -0700 (PDT) In-Reply-To: <1501034473.2494715.1052680736.6C3768C7@webmail.messagingengine.com> References: <1499230650.3642220.1030669400.4800D481@webmail.messagingengine.com> <1501034473.2494715.1052680736.6C3768C7@webmail.messagingengine.com> From: Martin Thomson Date: Wed, 26 Jul 2017 14:50:02 +1000 Message-ID: To: Bron Gondwana Cc: jmap@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Jmap] Feedback on draft-ietf-jmap-core X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 04:50:08 -0000 I think that covers it. On 26 July 2017 at 12:01, Bron Gondwana wrote: > Hi Martin, > > Reading back through this email, I think we've resolved Authentication by > agreeing to split it into either a separate spec or just handwave a bit "the > user will be authenticated somehow" and provide an endpoint at which the > list of Accounts accessible to the currently authenticated user can be > fetched. Does that resolve your concerns there? > > https://github.com/jmapio/jmap/issues/105 > > (also a task specific to seeing if OAUTH with automatic registration could > work with JMAP) > https://github.com/jmapio/jmap/issues/106 > > Regarding push, I think we also agreed to make the wording more clear, and > add encryption support: > > github #108-#110. > > So the main area left that isn't resolved is the use of HTTP as a transport: > > https://github.com/jmapio/jmap/issues/111 > > and optionally having two methods for accessing every object: > 1) the JMAP-method style (which would also work over websockets or similar, > and is batch friendly); and > 2) per-Object URLs and GET / PUT / PATCH / DELETE semantics (more round > trips, but maybe easier for basic integrations that don't need updates, > push, etc) > > https://github.com/jmapio/jmap/issues/112 > > Have I missed anything that you think needs a separate issue to track it? > > Thanks, > > Bron. > > On Wed, 5 Jul 2017, at 18:16, Martin Thomson wrote: > > Hi Neil, > > My MTA seems to have lost your nicely decorated quoting, sorry. Who > would have thought that that would still be a problem. > > On 5 July 2017 at 14:57, Neil Jenkins wrote: > > If you have a suggestion of an existing authentication scheme that meets > these criteria, we should look at that. > > > I appreciate that HTTP authentication is (badly) challenged, but it > will depend greatly on what context you are operating in. For > instance, if you are assuming that there can't be a user and web > browser involved in the onboarding process, that makes things pretty > challenging. > > You really need to motivate that more strongly than you have: account > creation is an exceptional process and covering that makes something > arbitrarily complex. There are many questions that you can avoid by > assuming the presence of a user with a browser: do you need CAPTCHA? > do you need to setup 2FA? if there is a password, what are the > policies on those? > > The problem with the current document is that you spend 11ish pages on > defining a new authentication scheme. That's a huge amount of work > that distracts from your main task: making a mail access protocol. > > Also, from experience with these things, 11 pages is far from enough > information to describe an authentication scheme, particularly one > with this level of complexity. For example, I don't think that the > "totp" scheme is specified in sufficient detail to implement > interoperable implementations. > > The IETF chartered a working group that concentrates on this exact > problem. I know that you don't want to create dependencies on other > groups, but that is where this is currently headed. I would encourage > you to talk to the folks in the OAUTH and HTTPAUTH working groups to > see if they have solutions for your problems. There's a lot going on > there. > > I explained the technical decisions behind this in the "Structure of a > request/response" part of my email "JMAP Conceptual Decisions", a few weeks > ago. If you missed it, a plain-text copy is available in the IETF archive at > https://mailarchive.ietf.org/arch/msg/jmap/SfCe3UJPEEUdeomeso_-PAzP5tQ > > > Since I only just now joined this list, I will reply here. I think > that you can achieve your goals within the same framework. > > As an aside, I'm accepting for the moment that your performance goals > cannot be met by the simple use of HTTP that you discredit in that > thread. I'm not an expert in this area, other than also having long > ping times to servers that many in this organization assume are close, > and I know very well the value of cutting round trips, but I'm not > convinced that the performance constraints are so severe that they > demand this much contortion. > > If they are indeed that severe, even then I would prefer if you > explored alternative options that would be less opaque to HTTP. Have > you considered creating explicit dependencies between requests just in > your request bodies? That would allow you to send the requests > concurrently. It's possible that a generic facility like that would > be valuable in HTTP for use with transactional APIs. > > Or there is the pattern of transactional resources. In this you > create a resource. That can be done ahead of the need to use it so > that you avoid spending the round trips on setup. You then populate > that resource (in this case, with the actions you wish to take), then > you execute the transaction. This model has other virtues in that the > non-idempotent requests cause minimal side-effects and the final > transaction commit can use an idempotent method. > > You might have already considered these approaches and found them > wanting, or maybe you need more information before you can decide. > I'd like to hear why some time. > > 4. Don't use EventSource. > > The EventSource part can easily be made to support long-polling instead at > the option of the client (the only difference being it closes the connection > after every push). Having a direct way for clients that are able to hold > open connections get push notifications without requiring their own push > server (see below) is still a good thing to have IMO. > > > The people who designed EventSource tell me that it's basically > abandoned. It was replaced by thewebsocketprotocol, which has been > largely superceded by the facilities that HTTP/2 provides (though I > will concede that of those facilities, only long-polling is a viable > option today; push still a work in progress). > > That said, you actually have *two* goals here. One is for an > asynchronous communications channel that you can use while there are > ongoing interactions between client and server. For that, I generally > recommend long-polling, though that can lead to generic event streams, > which can easily become the locus of a huge pile of technical debt. > > The other is the need to send messages when the client is effectively > offline. For that, you negatively want something that you manage > yourself. It's a battery drain. It's hard to ensure that you don't > end up with a dead connection as a result of middlebox shenanigans. > Maintaining an open connection is either prohibited or strongly > discouraged on many operating systems for those reasons. > > The messages that traverse those two paths are likely different. Push > messages are considerably more limited in what they can carry. > > I presume this is referring to the Web Hook part of the push section of the > spec, as this is the only place this word is mentioned. I'm not sure exactly > what you mean by "client reachability isn't consistent", but the intention > here (with a few header changes still required) is that the JMAP server is > an RFC8030 compliant "Application Server". > > > I had no idea that that was your intention from reading the draft. If > your intent was to act as an application server and actually use the > Push API, then it needs to be explicit. > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap > > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > > > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap > From nobody Wed Jul 26 01:58:46 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 97D77131FD0 for ; Wed, 26 Jul 2017 01:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.934 X-Spam-Level: * X-Spam-Status: No, score=1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 zbsR9PWDVZlB for ; Wed, 26 Jul 2017 01:58:42 -0700 (PDT) Received: from smtp-out10-fallback.linagora.com (smtp-out10-fallback.linagora.com [109.197.179.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0DD131FCE for ; Wed, 26 Jul 2017 01:58:42 -0700 (PDT) Received: from smtp.linagora.com (smtp.linagora.dc1 [172.16.18.53]) by smtp-out10-fallback.linagora.com (Postfix) with ESMTP id E4B071005DC1 for ; Wed, 26 Jul 2017 10:58:40 +0200 (CEST) Received: from [192.168.11.172] (unknown [118.70.135.8]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.linagora.com (Postfix) with ESMTPSA id B819965A for ; Wed, 26 Jul 2017 10:58:39 +0200 (CEST) To: jmap@ietf.org References: <1499230650.3642220.1030669400.4800D481@webmail.messagingengine.com> <1501034473.2494715.1052680736.6C3768C7@webmail.messagingengine.com> From: Benoit Tellier Message-ID: <4063d433-d279-fd06-74af-3949a3f56478@linagora.com> Date: Wed, 26 Jul 2017 15:58:36 +0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0382E0BB3812122B1EBF5D9E" Content-Language: en-US Archived-At: Subject: [Jmap] Handle GetMessageList filter for text in attachment X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 08:58:45 -0000 This is a multi-part message in MIME format. --------------0382E0BB3812122B1EBF5D9E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, I just opened https://github.com/jmapio/jmap/pull/129 By the following proposal, I would like to submit a small addition to the specification to allow text search in attachments. Attachments are the only non-searchable field, and I can hardly see why the specification should be restrictive on this. You will notice the *may* about text extraction. It allows a default implementation that just index attachments with *text/** making a minimal implementation server side working in a question of minutes, while still allowing more clever behavior. Cheers, Benoit --------------0382E0BB3812122B1EBF5D9E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi,

    I just opened https://github.com/jmapio/jmap/pull/129

    By the following proposal, I would like to submit a small addition to the specification to allow text search in attachments.

    Attachments are the only non-searchable field, and I can hardly see why the specification should be restrictive on this.

    You will notice the may about text extraction. It allows a default implementation that just index attachments with text/* making a minimal implementation server side working in a question of minutes, while still allowing more clever behavior.

    Cheers,

    Benoit

    --------------0382E0BB3812122B1EBF5D9E-- From nobody Wed Jul 26 07:10: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 78E6A131B79 for ; Wed, 26 Jul 2017 07:10:35 -0700 (PDT) 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 hJx4msaNM1po for ; Wed, 26 Jul 2017 07:10:33 -0700 (PDT) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 63E5F12EC4B for ; Wed, 26 Jul 2017 07:10:33 -0700 (PDT) Received: from meili (officewifi.dovecot.fi [193.209.119.110]) by mail.dovecot.fi (Postfix) with ESMTPSA id 0E9152B3CD0 for ; Wed, 26 Jul 2017 17:11:06 +0300 (EEST) Date: Wed, 26 Jul 2017 17:10:22 +0300 From: Josef 'Jeff' Sipek To: jmap@ietf.org Message-ID: <20170726141022.GA1352@meili> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.8.3 (2017-05-23) Archived-At: Subject: [Jmap] blob API in draft-ietf-jmap-{core,mail}-01 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 14:10:35 -0000 I finally got a bit of time to go over the blob interface in the draft. In general, I like the idea of a separate endpoint to get/put raw emails. The other uses of this blob interface are what I think needs more work / details. The blob upload scheme for attachments is a bit scary - not only are we dealing with email (which is complex enough), but the draft pulls in generic-ish object storage and deduplication along with the associated issues and complexities. Downloads --------- jmap section 4 says: After completing authentication, the client will receive a _downloadUrl_ as part of the response. This is in [RFC6570] URI Template (level 1) format. The URL MUST contain variables called "accountId" and "blobId". The URL SHOULD contain a variable called "name". Why is accountId required in the URL? I don't see a reason why a server couldn't use blobIds that either have internal structure to correctly determine the accountId, or to not care about accountId at all. Concerns about malicious users accessing known hashes can be addressed by salting the hash when generating the blobIds on the server. This is of course an implementation detail, but I think it demonstrates that the accountId seems superfluous. I'd expect the spec to say that the URL MAY contain accountId, just to make sure that clients expect it. Uploads ------- jmap section 5.1 (201: File uploaded successfully) says: o *expires*: "Date" The date the file will be deleted from temporary storage if not referenced by another object, e.g. used in a draft. Should the spec provide some guidance how far into the future the expiration date should be? Should it explicitly point out that the timestamp is purely advisory, and the blob may disappear at any time for a variety of other reasons? jmap section 5.1 (201: File uploaded successfully) also says: If identical binary content is uploaded, the same _blobId_ SHOULD be returned. If the same blobId is returned, should the expiration date be bumped as if it were the first upload of the blob? jmap section 5.1 (201: File uploaded successfully) also says: Once the file has been used, for example attached to a draft message, the file will no longer expire, and is instead guaranteed to exist while at least one other object references it. Once no other object references it, the server MAY immediately delete the file at any time. Once a blobId is used by an object (e.g., via setMessages), is it supposed to be still accessible via the same blobId? Or can the server move the data associated with the blobId out of the "pending blob" storage into a more permanent place and in the process generate a new blobId? I'm imagining the "pending blob" storage to be a simple directory with one file per blob, but once a setMessages tries to take a "reference" on the blob, the server instead synthesizes an RFC5322 email and stores it in the requested mailbox and then removes the "pending blobs" copy. It would be nice if jmap worked seamlessly on top of maildir/mbox/etc. without the need for too many extra storage pools or duplication of data between the blob store and the actual mailbox storage. Eviction -------- The expiration-based eviction is ok, however I think there needs to be more clarification about the other causes for blob eviction and how eviction interacts with the rest of jmap. For example: jmap section 5.1 (201: File uploaded successfully) says: If uploading a file would take the user over quota, the server SHOULD delete previously uploaded (but unused) files before their expiry time. jmap mail section 5.3.1 (Saving a draft) says: If any of the files specified in _attachments_ cannot be found, the creation MUST be rejected with an "invalidProperties" error. When these two behaviors are combined, it is easy to run into a ugly scenario where a client wants to save a draft with two large attachments with quota enabled. For example: (1) the user is 1.5MB away from reaching quota, there are no unreferenced blobs (2) the client uploads first attachment that is 1MB in size (a) the user is now 0.5MB away from reaching quota (b) there is one unreferenced blob (the one just uploaded) (3) the client uploads second attachment that is 1MB in size (a) since the user would be over quota, the server evicts the previously uploaded blob to make space for the new blob (jmap 5.1) (b) the client gets no notification that the previous blob was evicted (c) the user is still 0.5MB away from reaching quota (0.5MB + 1MB - 1MB) (d) there is one unreferenced blob (the second one uploaded) (4) the client tries to store the actual draft mail, referencing the two blobIds obtained from the uploads (a) the server fails the setMessages call because one of the blobIds doesn't exist (jmap mail 5.3.1) In this case, the client uploaded 2MB+ and accomplished absolutely nothing. A naive client would then proceed to reupload the missing attachment, using up even more bandwidth but still making no actual progress. I think it would be good for jmap all requests to either succeed or fail in a way that tell the client what can be done to get more forward progress (even if it is sub-optimal) or that there is no way forward. In this particular example, the issue is that the invalidProperties error returned from setMessages covers multiple situations. At least some of them are: (1) client error: the client didn't upload the attachment before trying to reference it (2) blob expired: the server removed the blob because it remained unreferenced for too long (3) blob evicted: the server removed the blob early because of over-quota situation, etc. There is nothing to indicate that repeating the upload will or will not result in any progress. By the way, a number of the HTTP status code descriptions include: "There is no content in the response." Is that saying that the response body SHOULD be ignored? Or that the responses' Content-Length MUST be 0? Anyway, that's it for now. Jeff. From nobody Mon Jul 31 06:44: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 D083B128C9C for ; Mon, 31 Jul 2017 06:44:56 -0700 (PDT) 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 vZfsm_9dgqpR for ; Mon, 31 Jul 2017 06:44:55 -0700 (PDT) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id A5AEB1275FD for ; Mon, 31 Jul 2017 06:44:55 -0700 (PDT) Received: from meili (officewifi.dovecot.fi [193.209.119.110]) by mail.dovecot.fi (Postfix) with ESMTPSA id 7BDC12B3DD1 for ; Mon, 31 Jul 2017 16:45:29 +0300 (EEST) Date: Mon, 31 Jul 2017 16:44:53 +0300 From: Josef 'Jeff' Sipek To: jmap@ietf.org Message-ID: <20170731134452.GB1402@meili> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.8.3 (2017-05-23) Archived-At: Subject: [Jmap] message copying and moving X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 13:44:57 -0000 There appear to be three different ways in jmap mail to "copy" an email from one mailbox to another. That is, duplicating a message but leaving the original in place (like COPY in IMAP). They are: 1. setMessages on an existing message's messageId with destination mailbox's mailboxId added to mailboxIds 2. importMessages with blobId referencing an existing message's blobId 3. copyMessages with fromAccountId == toAccountId Based on my reading of the draft, the semantics of these are: The first method creates a "hardlink" copy - any keyword changes will be shared by all the copies of the message. The second method creates a total duplicate of the message and its metadata. The new copy has a new messageId. Changes to keywords are not propagated to other copies. (The headers and body may be shared by the copies if the server supports some form of transparent deduplication.) The third method appears to work similarly to the second. That is, a new messageId is created and the new duplicate is *not* "linked" to the original. When it comes to moving mails from one mailbox to another (like MOVE or COPY+EXPUNGE in IMAP) the situation is equally complex. The options are: 1. setMessages on an existing message's messageId with destination mailbox's mailboxId replacing the source mailbox's mailboxId in mailboxIds 2. importMessages with blobId referencing an existing message's blobId, followed by a setMessages on the original message but removing the source mailbox's mailboxId from mailboxIds 3. copyMessages with fromAccountId == toAccountId, followed by setMessages on the original message but removing the source mailbox's mailboxId from mailboxIds The first method preserves the "links" between the source message and any other "hardlinks" it may have had. The second method creates a totally independent copy (much like IMAP COPY + EXPUNGE). (The headers and body may be shared with other copies if the server supports some sort of transparent deduplication.) The third method has same semantics as the second. This brings up a number of questions: The description of copyMessages (jmap mail section 5.5) is confusing. Instead of describing what the call does, it talks about one potential use (namely, moving emails between accounts). Am I understanding the copyMessages semantics correctly? Or is it more like IMAP MOVE rather than COPY? Is there a limit to how many mailboxes a message may belong to? I can't seem to find anything that talks about it. If the server implements a limit, what would be the appropriate error to return from setMessages? What should a client do when it encounters this error? Should it try to fall back to copyMessages? Does it make sense to allow copyMessages with fromAccountId equal to toAccountId? My inclination is to say that there should be only one way to copy emails. At the same time, I see a reason for both "hardlink" and "copy" flavors of copying to exist and the server supporting whatever is feasible given the storage format it uses. Sadly, that leads to added complexity in the client. Thanks, Jeff. From nobody Mon Jul 31 07:54: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 92384132420 for ; Mon, 31 Jul 2017 07:54:28 -0700 (PDT) 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=ham 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 mp1HRFtgmFCL for ; Mon, 31 Jul 2017 07:54:27 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 263C5132390 for ; Mon, 31 Jul 2017 07:54:27 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id d136so153377511qkg.3 for ; Mon, 31 Jul 2017 07:54:27 -0700 (PDT) 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=B45g7DI2qLJOoRKX5Rukb6iUnfcaIE6jDmCOYyjvIOw=; b=UV3DN4JF/3EBC+4l4iQnVI6WO3husf5yJy+mGiXI+oHWY5fTyk3C0LIcJQhjfguV7c C/X+JSE7H5426mDq4xmYEKwKDeXDH3cw6aLws0tcCiJYieZizveXRxw9OC+S2D5H2b4c mRYU8q1/TIIKRtHrgcRiAZSMs3vHXQ7VRlRBnJNq9pqQ7rv2+2mMBV1QFhvfPQV+uLCc rNr5HOIO7TfYKe/1jjlq0iRQhi1VHAOnVfc8PyQ31L+/CGFtyEUZghuvvwp7U5fvhZde 2b3ZzEPn091oJGJ3n22TYtPVBDDZCVP4E8zTNrkPM6UBq3JM7cvAmnwkd3neKs1aPI9U khrQ== 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=B45g7DI2qLJOoRKX5Rukb6iUnfcaIE6jDmCOYyjvIOw=; b=BYPIl+Irtb6UnHFmZR9VUCFZ7OAAOnMrQ1iJ92s/fHcJ/29eqmVWddtTwoV1ceXFhk FlGZmfWV0Z4I4o+lwH5vw6StXCH8vsIpSILl0NUdEqC6qdGX0j8hV4IaJ9mH/2zElcPe sHdgyAZtkolZ9MCvsos1XmuS3DJ710UzcMzOGNB7/mQWyiIDwmnaWwZh4H5gaDot+N+u rUAM7NJa44ygnk/T40W4hrzQHLpObubn37B/JarCCOfMp/G21BrVgLWh9Yu0hm1QyI1d Vo4CQPvrrzKHjpGlPdYZoMcMQic8RcadZc4zWODc893fJPaVTm3TZuLlsx0taylewXwT DEaw== X-Gm-Message-State: AIVw112K7oTl0M6WKLeOZh0Ak7KPl1Y+x4gkPGhNpZSdDpM3yNuFf48L GzYmfp4lijD+Duf/h39wQg== X-Received: by 10.55.92.130 with SMTP id q124mr20629119qkb.274.1501512866225; Mon, 31 Jul 2017 07:54:26 -0700 (PDT) Received: from [10.0.30.153] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id a48sm2397357qtb.59.2017.07.31.07.54.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Jul 2017 07:54:23 -0700 (PDT) From: Ted Lemon Message-Id: <27EB9EDE-A81C-4640-9F02-F76850002221@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_2C178741-3CC0-4516-B474-320C9CBAB660" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 31 Jul 2017 10:54:22 -0400 In-Reply-To: <20170731134452.GB1402@meili> Cc: jmap@ietf.org To: Josef 'Jeff' Sipek References: <20170731134452.GB1402@meili> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Jmap] message copying and moving X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 14:54:29 -0000 --Apple-Mail=_2C178741-3CC0-4516-B474-320C9CBAB660 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jul 31, 2017, at 9:44 AM, Josef 'Jeff' Sipek = wrote: > My inclination is to say that there should be only one way to copy = emails. > At the same time, I see a reason for both "hardlink" and "copy" = flavors of > copying to exist and the server supporting whatever is feasible given = the > storage format it uses. Sadly, that leads to added complexity in the > client. I think this is right, and is the right way to document it. Default = behavior on the client should be link=E2=80=94it's unlikely that the = user ever wants a copy when a link is possible. The only use case for = copy is when the mail client is showing two mail stores on separate = servers, or in the rare case where the user _wants_ two copies that are = treated differently. (I'm curious if there is general agreement on = this or if folks think I'm crazy, though!) --Apple-Mail=_2C178741-3CC0-4516-B474-320C9CBAB660 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jul 31, 2017, at 9:44 AM, Josef 'Jeff' Sipek <jeff.sipek@dovecot.fi> wrote:
    My inclination is to say that there = should be only one way to copy emails.
    At the same time, I = see a reason for both "hardlink" and "copy" flavors of
    copying to exist and the server supporting = whatever is feasible given the
    storage format it = uses.  Sadly, that leads to added complexity in the
    client.

    I think this is right, and is the right way = to document it.   Default behavior on the client should be = link=E2=80=94it's unlikely that the user ever wants a copy when a link = is possible.   The only use case for copy is when the mail client = is showing two mail stores on separate servers, or in the rare case = where the user _wants_ two copies that are treated differently.   = (I'm curious if there is general agreement on this or if folks think I'm = crazy, though!)

    = --Apple-Mail=_2C178741-3CC0-4516-B474-320C9CBAB660-- From nobody Mon Jul 31 09:11: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 902FA127B73 for ; Mon, 31 Jul 2017 09:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 cQVz1twzyxnZ for ; Mon, 31 Jul 2017 09:11:39 -0700 (PDT) Received: from a.tbms.in (a.tbms.in [202.157.72.18]) by ietfa.amsl.com (Postfix) with ESMTP id B5F58120721 for ; Mon, 31 Jul 2017 09:11:36 -0700 (PDT) Received: From 202.157.83.50[202.157.83.50] by [202.157.83.51] [mx2.datainfosys.com] [mta] with SMTP id ../InBoxS/20170731/21/45024.1691500888(1501517493705); Mon, 31 Jul 2017 16:11:33 +0000 Received: From power0.dil.in[202.157.83.50] by [202.157.83.50] [power0.dil.in] [mta] with SMTP id 47551.01932515178(1501517490905); Mon, 31 Jul 2017 16:11:30 +0000 Received: From[2d38264d106c21f3674cd7e5be5fc143] [210.212.102.65] with SMTP id 96115.46557514124(1501517453391); Mon, 31 Jul 2017 16:10:53 +0000 User-Agent: BharatSync Communicator for Android X_Xgen_Delivery_Report: yes X_Xgen_Device_Id: 355909070379808 In-Reply-To: <20170731134452.GB1402@meili> References: <20170731134452.GB1402@meili> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----9JKM2JESFZP0LUQSHWPTWU0KC8JY45" Content-Transfer-Encoding: 7bit From: =?UTF-8?B?4KSF4KSc4KSvIOCkoeCkvuCkn+CkviAoQWpheSBEQVRBKQ==?= Date: Mon, 31 Jul 2017 21:35:07 +0530 To: jeff.sipek@dovecot.fi,jmap@ietf.org Message-ID: <1e929200-195f-49d4-9ebd-035b4ac124e9@email.android.com> Archived-At: Subject: Re: [Jmap] message copying and moving X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 16:11:43 -0000 ------9JKM2JESFZP0LUQSHWPTWU0KC8JY45 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In case of MOVE, how about we just change the owner ID of the message , and= not move the email message at all=2E In copy, just hardliNk wirh new UID and do not move the messages at all=2E Thanks=2E=20 On July 31, 2017 7:14:53 PM GMT+05:30, Josef 'Jeff' Sipek wrote: >There appear to be three different ways in jmap mail to "copy" an email >from >one mailbox to another=2E That is, duplicating a message but leaving the >original in place (like COPY in IMAP)=2E They are: > >1=2E setMessages on an existing message's messageId with destination > mailbox's mailboxId added to mailboxIds >2=2E importMessages with blobId referencing an existing message's blobId >3=2E copyMessages with fromAccountId =3D=3D toAccountId > >Based on my reading of the draft, the semantics of these are: > >The first method creates a "hardlink" copy - any keyword changes will >be >shared by all the copies of the message=2E > >The second method creates a total duplicate of the message and its >metadata=2E >The new copy has a new messageId=2E Changes to keywords are not >propagated to >other copies=2E (The headers and body may be shared by the copies if the >server supports some form of transparent deduplication=2E) > >The third method appears to work similarly to the second=2E That is, a >new >messageId is created and the new duplicate is *not* "linked" to the >original=2E > > >When it comes to moving mails from one mailbox to another (like MOVE or >COPY+EXPUNGE in IMAP) the situation is equally complex=2E The options >are: > >1=2E setMessages on an existing message's messageId with destination > mailbox's mailboxId replacing the source mailbox's mailboxId in > mailboxIds >2=2E importMessages with blobId referencing an existing message's blobId, > followed by a setMessages on the original message but removing the > source mailbox's mailboxId from mailboxIds >3=2E copyMessages with fromAccountId =3D=3D toAccountId, followed by >setMessages >on the original message but removing the source mailbox's mailboxId >from > mailboxIds > >The first method preserves the "links" between the source message and >any >other "hardlinks" it may have had=2E > >The second method creates a totally independent copy (much like IMAP >COPY + >EXPUNGE)=2E (The headers and body may be shared with other copies if the >server supports some sort of transparent deduplication=2E) > >The third method has same semantics as the second=2E > > >This brings up a number of questions: > >The description of copyMessages (jmap mail section 5=2E5) is confusing=2E >Instead of describing what the call does, it talks about one potential >use >(namely, moving emails between accounts)=2E Am I understanding the >copyMessages semantics correctly? Or is it more like IMAP MOVE rather >than >COPY? > >Is there a limit to how many mailboxes a message may belong to? I >can't >seem to find anything that talks about it=2E If the server implements a >limit, what would be the appropriate error to return from setMessages?=20 >What >should a client do when it encounters this error? Should it try to >fall >back to copyMessages? > >Does it make sense to allow copyMessages with fromAccountId equal to >toAccountId? > >My inclination is to say that there should be only one way to copy >emails=2E >At the same time, I see a reason for both "hardlink" and "copy" flavors >of >copying to exist and the server supporting whatever is feasible given >the >storage format it uses=2E Sadly, that leads to added complexity in the >client=2E > >Thanks, > >Jeff=2E > >_______________________________________________ >Jmap mailing list >Jmap@ietf=2Eorg >https://www=2Eietf=2Eorg/mailman/listinfo/jmap --=20 Sent from my Android device with BharatSync Communicator=2E ------9JKM2JESFZP0LUQSHWPTWU0KC8JY45 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable In case of MOVE, how about we just change the owne= r ID of the message , and not move the email message at all=2E

    In copy, just hardliNk wirh new UID and do not move the messages at all=2E=

    Thanks=2E

    On July 31, 2017 7:14:53 PM G= MT+05:30, Josef 'Jeff' Sipek <jeff=2Esipek@dovecot=2Efi> wrot= e:
    There appear to be three different ways in jmap mail=
 to "copy" an email from
    one mailbox to another=2E  That is, duplicati=
ng a message but leaving the
    original in place (like COPY in IMAP)=2E =
 They are:

    1=2E setMessages on an existing message's messageId w=
ith destination
       mailbox's mailboxId added to mailboxIds
    2=2E i=
mportMessages with blobId referencing an existing message's blobId
    3=
=2E copyMessages with fromAccountId =3D=3D toAccountId

    Based on =
my reading of the draft, the semantics of these are:

    The first m=
ethod creates a "hardlink" copy - any keyword changes will be
    shared b=
y all the copies of the message=2E

    The second method creates a t=
otal duplicate of the message and its metadata=2E
    The new copy has a n=
ew messageId=2E  Changes to keywords are not propagated to
    other copie=
s=2E  (The headers and body may be shared by the copies if the
    server =
supports some form of transparent deduplication=2E)

    The third me=
thod appears to work similarly to the second=2E  That is, a new
    messag=
eId is created and the new duplicate is *not* "linked" to the original=2E

    When it comes to moving mails from one mailbox to another (=
like MOVE or
    COPY+EXPUNGE in IMAP) the situation is equally complex=2E=
  The options are:

    1=2E setMessages on an existing message's mes=
sageId with destination
       mailbox's mailboxId replacing the source ma=
ilbox's mailboxId in
       mailboxIds
    2=2E importMessages with blobI=
d referencing an existing message's blobId,
       followed by a setMessag=
es on the original message but removing the
       source mailbox's mailbo=
xId from mailboxIds
    3=2E copyMessages with fromAccountId =3D=3D toAcco=
untId, followed by setMessages
       on the original message but removing=
 the source mailbox's mailboxId from
       mailboxIds

    The firs=
t method preserves the "links" between the source message and any
    othe=
r "hardlinks" it may have had=2E

    The second method creates a tot=
ally independent copy (much like IMAP COPY +
    EXPUNGE)=2E  (The headers=
 and body may be shared with other copies if the
    server supports some =
sort of transparent deduplication=2E)

    The third method has same =
semantics as the second=2E


    This brings up a number of ques=
tions:

    The description of copyMessages (jmap mail section 5=2E5)=
 is confusing=2E
    Instead of describing what the call does, it talks ab=
out one potential use
    (namely, moving emails between accounts)=2E  Am =
I understanding the
    copyMessages semantics correctly?  Or is it more l=
ike IMAP MOVE rather than
    COPY?

    Is there a limit to how man=
y mailboxes a message may belong to?  I can't
    seem to find anything th=
at talks about it=2E  If the server implements a
    limit, what would be =
the appropriate error to return from setMessages?  What
    should a clien=
t do when it encounters this error?  Should it try to fall
    back to cop=
yMessages?

    Does it make sense to allow copyMessages with fromAcc=
ountId equal to
    toAccountId?

    My inclination is to say that =
there should be only one way to copy emails=2E
    At the same time, I see=
 a reason for both "hardlink" and "copy" flavors of
    copying to exist a=
nd the server supporting whatever is feasible given the
    storage format=
 it uses=2E  Sadly, that leads to added complexity in the
    client=2E
    Thanks,

    Jeff=2E


    Jmap mailing lis=
t
    Jmap@ietf=2Eorg
    https://www=2Eietf=2Eorg/mailman/listinfo/jmap
    <= /blockquote>

    --
    Sent from my Android device with BharatSync Communicator=2E ------9JKM2JESFZP0LUQSHWPTWU0KC8JY45-- From nobody Mon Jul 31 20:38: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 0CDDF131CF9 for ; Mon, 31 Jul 2017 20:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, 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 (2048-bit key) header.d=fastmailteam.com header.b=Wv5Cqpd8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=a6KYh73r 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 3CVXGLhpPqcm for ; Mon, 31 Jul 2017 20:38:37 -0700 (PDT) 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 2136D1317AD for ; Mon, 31 Jul 2017 20:38:36 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 188B520B69 for ; Mon, 31 Jul 2017 23:38:36 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Mon, 31 Jul 2017 23:38:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.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=fm1; bh=ymfRLgI8UEI3T3H29 Xfv9H/a6hBJi1x79y3bBeuR01o=; b=Wv5Cqpd8dxqrCQBow53jXfoIynMeNtibB RWFnUqFhkLb4KyMEEkJNn1gHFjM3Nh/RMFE12n4KIxtTSBhQjvF8UpYol0qcpTFs F9WgW/+tqr9wxTqkHPHFNElreUks4AuqUgJSraO8M2/k/L2gDRVK4WlEnU/ggAXx O0GBLznW/KgVcC1+4ym1cJBjIwytvH/H1DQRGn2qI70PUMaqjqratFPOED4LDZkN IpSRpf/DW6HbVgW9Fx8ftyzWje6J6HYHBys+MEuhMrkHYsp0xWq3JWwXEC2a+VRn TG0hIDxUCdVWARNzbDElqM50/UGe4h0kLg7vdH5zYeFIv394Hdifw== DKIM-Signature: v=1; a=rsa-sha256; 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=fm1; bh=ymfRLg I8UEI3T3H29Xfv9H/a6hBJi1x79y3bBeuR01o=; b=a6KYh73rRokU4SiRG6dnYY 5UhAa76r3YoFPwL2/SkJGf9Ajchs0LN22aqUSomkFiGTJOQ/HVftWw8c6TveBlnt vmTUVD1SUdbNqbvZ7Du9JMnLgUrX7bhaAG5EJhnvNFEyBDPcPHKpvGROhWA632uY 6TxRxlH5bepsU4XaSh1msFU04TTYU6GBv5EopCoQctpyjKv/++oPhDol0A2lZ2PO s927MdRxysgyHdI/D3Y5FeJHIznXriyAVsvFtPC0o69i509htYhOrKjyMldzO9mk 9u0MP1iRFdbKKPGDBbo8qYpnH08IBN/XRQqvYNjnX1ZMMF2llCWnZ+rXnriO9tXw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id D293DE22C2; Mon, 31 Jul 2017 23:38:35 -0400 (EDT) Message-Id: <1501558715.3114940.1059090760.3D266D17@webmail.messagingengine.com> From: Neil Jenkins To: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150155871531149403" X-Mailer: MessagingEngine.com Webmail Interface - ajax-4aa8b2c4 In-Reply-To: <20170731134452.GB1402@meili> References: <20170731134452.GB1402@meili> Date: Tue, 01 Aug 2017 13:38:35 +1000 Archived-At: Subject: Re: [Jmap] message copying and moving X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 03:38:39 -0000 This is a multi-part message in MIME format. --_----------=_150155871531149403 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Mon, 31 Jul 2017, at 11:44 PM, Josef 'Jeff' Sipek wrote: > There appear to be three different ways in jmap mail to "copy" an email> from one mailbox to another. That is, duplicating a message but leaving the> original in place (like COPY in IMAP). They are: > > 1. setMessages on an existing message's messageId with destination > mailbox's mailboxId added to mailboxIds Not exactly. JMAP is currently designed so it's optional for servers to support the concept of a single message appearing in multiple mailboxes ("labels" rather than "folders"). This is designated by the mustBeOnlyMailbox property on the mailbox objects, but I think we should re-evaluate this. It seems likely to be the same for every mailbox in the account. A simpler (and better IMO) method would be to add a maxMailboxesPerMessage property to the capabilities given for an account, which would be 1 for simple IMAP proxies and >1 for more sophisticated servers. > 2. importMessages with blobId referencing an existing message's blobId> 3. copyMessages with fromAccountId == toAccountId While not intended for this purpose, yes these could be used to copy messages. However, > The first method creates a "hardlink" copy - any keyword changes will be> shared by all the copies of the message. > The second method creates a total duplicate of the message and its > metadata. Looking at the spec, this needs to be clarified. However I believe we definitely need to make it so that (2)/(3) MAY return an existing message id if the content is the same as an existing message (or alternatively an error; either works for me). For example, the Cyrus implementation of JMAP uses a secure hash of the message content to generate the message id, so you cannot have two identical messages within the same user with different message ids. > When it comes to moving mails from one mailbox to another (like MOVE or> COPY+EXPUNGE in IMAP) the situation is equally complex. The options are:> > 1. setMessages on an existing message's messageId with destination > mailbox's mailboxId replacing the source mailbox's mailboxId in > mailboxIds Yes, this is the expected way clients would do it. > 2. importMessages with blobId referencing an existing message's blobId,> followed by a setMessages on the original message but removing the > source mailbox's mailboxId from mailboxIds > 3. copyMessages with fromAccountId == toAccountId, followed by > setMessages on the original message but removing the source mailbox's mailboxId from mailboxIds Again, what this does depends on whether the server supports multiple copies of the same message content with different ids. So I think the following would help: * Remove mustBeOnlyMailbox property from individual mailbox objects and add a capability for maxMailboxesPerMessage instead. Add an appropriate error for setMailboxes if you try to go over this limit. * Allow servers to return an error instead of copy/import if the message already exists, rather than creating a duplicate with separate metadata. (But if it does succeed, then it MUST have separate metadata, be a new message id). A lot of this depends on how much flexibility we want to give servers for making it easier to proxy/build-on IMAP. Every extra option does make it harder for clients. I'd be happy to forbid having two copies of the same message in the same user if people think this is reasonable. So something like: * maxMailboxesPerMessage MUST be at least 10 (or greater) * copyMessages fromAccount MUST be different to toAccount * (import|copy)Messages MUST reject attempts to import/copy a message whose content already exists. Or similar. On Tue, 1 Aug 2017, at 12:54 AM, Ted Lemon wrote: > it's unlikely that the user ever wants a copy when a link is possible. Agreed. The current spec was designed for allowing the possibility that a link is not possible. But maybe we can be more prescriptive about what servers must support. Neil. --_----------=_150155871531149403 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
    On Mon, 31 Jul 2017, at 11:44 PM, Josef 'Jeff' Sipek wrote:
    There appear to be three different ways in jmap mail to "copy" an email
    from one mailbox to another.  That is, duplicating a message but leaving the
    original in place (like COPY in IMAP).  They are:

    1. setMessages on an existing message's messageId with destination
      mailbox's mailboxId added to mailboxIds

    Not exactly. JMAP is currently designed so it's optional for servers to support the concept of a single message appearing in multiple mailboxes ("labels" rather than "folders"). This is designated by the mustBeOnlyMailbox property on the mailbox objects, but I think we should re-evaluate this. It seems likely to be the same for every mailbox in the account. A simpler (and better IMO) method would be to add a maxMailboxesPerMessage property to the capabilities given for an account, which would be 1 for simple IMAP proxies and >1 for more sophisticated servers.

    2. importMessages with blobId referencing an existing message's blobId
    3. copyMessages with fromAccountId == toAccountId

    While not intended for this purpose, yes these could be used to copy messages. However, 

    The first method creates a "hardlink" copy - any keyword changes will be
    shared by all the copies of the message.
    The second method creates a total duplicate of the message and its
    metadata.

    Looking at the spec, this needs to be clarified. However I believe we definitely need to make it so that (2)/(3) MAY return an existing message id if the content is the same as an existing message (or alternatively an error; either works for me). For example, the Cyrus implementation of JMAP uses a secure hash of the message content to generate the message id, so you cannot have two identical messages within the same user with different message ids.

    When it comes to moving mails from one mailbox to another (like MOVE or
    COPY+EXPUNGE in IMAP) the situation is equally complex.  The options are:

    1. setMessages on an existing message's messageId with destination
      mailbox's mailboxId replacing the source mailbox's mailboxId in
      mailboxIds

    Yes, this is the expected way clients would do it.

    2. importMessages with blobId referencing an existing message's blobId,
      followed by a setMessages on the original message but removing the
      source mailbox's mailboxId from mailboxIds
    3. copyMessages with fromAccountId == toAccountId, followed by
    setMessages on the original message but removing the source mailbox's mailboxId from mailboxIds

    Again, what this does depends on whether the server supports multiple copies of the same message content with different ids.

    So I think the following would help:
    • Remove mustBeOnlyMailbox property from individual mailbox objects and add a capability for maxMailboxesPerMessage instead. Add an appropriate error for setMailboxes if you try to go over this limit.
    • Allow servers to return an error instead of copy/import if the message already exists, rather than creating a duplicate with separate metadata. (But if it does succeed, then it MUST have separate metadata, be a new message id). 

    A lot of this depends on how much flexibility we want to give servers for making it easier to proxy/build-on IMAP. Every extra option does make it harder for clients. I'd be happy to forbid having two copies of the same message in the same user if people think this is reasonable. So something like:
    • maxMailboxesPerMessage MUST be at least 10 (or greater)
    • copyMessages fromAccount MUST be different to toAccount
    • (import|copy)Messages MUST reject attempts to import/copy a message whose content already exists.

    Or similar.

    On Tue, 1 Aug 2017, at 12:54 AM, Ted Lemon wrote:
    it's unlikely that the user ever wants a copy when a link is possible.

    Agreed. The current spec was designed for allowing the possibility that a link is not possible. But maybe we can be more prescriptive about what servers must support.

    Neil.
    --_----------=_150155871531149403--