From nobody Tue May 8 22:34:04 2018 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 E589012EB26; Tue, 8 May 2018 22:33:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152584403689.3081.18421957354284844602@ietfa.amsl.com> Date: Tue, 08 May 2018 22:33:56 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-core-05.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: Wed, 09 May 2018 05:33:57 -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 WG of the IETF. Title : JSON Meta Application Protocol Author : Neil Jenkins Filename : draft-ietf-jmap-core-05.txt Pages : 53 Date : 2018-05-08 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-05 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-core-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-core-05 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 Tue May 8 22:34:10 2018 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 9B7621270FC; Tue, 8 May 2018 22:33:58 -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.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152584403858.2892.16360201764017131238@ietfa.amsl.com> Date: Tue, 08 May 2018 22:33:58 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-mail-05.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: Wed, 09 May 2018 05:33:59 -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 WG of the IETF. Title : JMAP for Mail Author : Neil Jenkins Filename : draft-ietf-jmap-mail-05.txt Pages : 60 Date : 2018-05-08 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-05 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-mail-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-mail-05 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 Sat May 26 04:58:03 2018 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 353B6124F57; Sat, 26 May 2018 04:58:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: jmap@ietf.org, brong@fastmailteam.com, jmap-chairs@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.80.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152733588114.25370.7419634822088990296.idtracker@ietfa.amsl.com> Date: Sat, 26 May 2018 04:58:01 -0700 Archived-At: Subject: [Jmap] jmap - New Meeting Session Request for IETF 102 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: Sat, 26 May 2018 11:58:02 -0000 A new meeting session request has just been submitted by Bron Gondwana, a Chair of the jmap working group. --------------------------------------------------------- Working Group Name: JSON Mail Access Protocol Area Name: Applications and Real-Time Area Session Requester: Bron Gondwana Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 20 Conflicts to Avoid: First Priority: extra dispatch uta artarea dmarc mtgvenue saag oauth dcrup doh Second Priority: tls httpbis ace lamps core t2trg People who must be present: Barry Leiba Alexey Melnikov Neil Jenkins Bron Gondwana Resources Requested: Experimental Room Setup (U-Shape and classroom, subject to availability) Flipcharts: please specify number in Special Requests field Special Requests: We will have Neil Jenkins presenting remotely from Australia. 4pm in Montreal is 6am in Australia, so please no earlier than that! Also please not Thursday or Friday. --------------------------------------------------------- From nobody Sat May 26 04:58:33 2018 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 48BF21241FC; Sat, 26 May 2018 04:58:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: jmap@ietf.org, brong@fastmailteam.com, jmap-chairs@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.80.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152733591129.25309.16901806097401377739.idtracker@ietfa.amsl.com> Date: Sat, 26 May 2018 04:58:31 -0700 Archived-At: Subject: [Jmap] jmap - Update to a Meeting Session Request for IETF 102 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: Sat, 26 May 2018 11:58:31 -0000 An update to a meeting session request has just been submitted by Bron Gondwana, a Chair of the jmap working group. --------------------------------------------------------- Working Group Name: JSON Mail Access Protocol Area Name: Applications and Real-Time Area Session Requester: Bron Gondwana Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 20 Conflicts to Avoid: First Priority: extra dispatch uta artarea dmarc mtgvenue saag oauth dcrup doh Second Priority: tls httpbis ace lamps core t2trg People who must be present: Barry Leiba Alexey Melnikov Neil Jenkins Bron Gondwana Resources Requested: Special Requests: We will have Neil Jenkins presenting remotely from Australia. 4pm in Montreal is 6am in Australia, so please no earlier than that! Also please not Thursday or Friday. --------------------------------------------------------- From nobody Sat May 26 05:00:46 2018 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 370EA1241FC for ; Sat, 26 May 2018 05:00:44 -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=pcBWMdkr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FNpUxKkD 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 TB_jWyxf9MW7 for ; Sat, 26 May 2018 05:00:43 -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 CAE12124F57 for ; Sat, 26 May 2018 05:00:42 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 36B8A20E7B for ; Sat, 26 May 2018 08:00:42 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Sat, 26 May 2018 08:00:42 -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=fm2; bh=YoldDJVfJrSWB/MEw8VqXtbrtimG+LyAVbV6SMKkF iA=; b=pcBWMdkrfW+d6J8D3YdBN5jM0VwOs1AklpMvW4gbOJ540/mQW0TtsZA5D htCdBYk8irxP46n8/ZLKbY2UR+QEmhHtD8v7o8oSEoLNK+RfXH63B4+tRldktIIi BNX8OxKCKcNXtkuetQkAYL2EgFGdra2wh/xDy2Ypk6pPQZV4t+mcISkQoLKSSR1O nAZ2TEXchiYbJl4pPqXkkCxpGbde0mlpFhc9EL50nRt1yoQd/0t9cvzo9/rRjpuc mCewi0/YrvDNYYsjhOI849K4QeixkBuIKjSoLeyw79XmyLyUvaPqrc33w0p+D22f 2GpHiSVHODk8vst39n1sCnQZzTaSg== 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=fm2; bh=YoldDJVfJrSWB/MEw8VqXtbrtimG+ LyAVbV6SMKkFiA=; b=FNpUxKkDie+AUkDq/OyLHmznIcVPRI+qmkPSB3c0gCFEM wtuTHa8UKvFpiKfBEEBp6kXlf0laJtmUDNdgFJfuDfNR0EoVnDba2pfDMqKBXNVY qYMRqHJRsTVObGC8IAw2L3y0cOkgDisNVfP9x8ehNVVogUYxz4TiAQZNNNT3VGU2 tmXZubP10L/iMF9g7qQ2hPVCVFHldlBniGEi9E3+Y241zagr6Qee5e7oMxzvOh7q iJrG3l7okvrCa5yUAjAd/rcjDaFTS61Ja2H686v81Jcct6qDiTgv4Bn7HcsrJsYI ZV8WodUqc7n+uuvF1H5W+qLrx0Fa1Ja8VSyIq5NfQ== X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id D3CBF621DC; Sat, 26 May 2018 08:00:41 -0400 (EDT) Message-Id: <1527336041.790041.1386430328.7B007AD1@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15273360417900410" X-Mailer: MessagingEngine.com Webmail Interface - ajax-29e6b281 Date: Sat, 26 May 2018 22:00:41 +1000 Archived-At: Subject: [Jmap] Planning Montreal session 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: Sat, 26 May 2018 12:00:44 -0000 This is a multi-part message in MIME format. --_----------=_15273360417900410 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Hi All, Sorry I've been slack getting this done. We need to schedule our session for Montreal. Sadly, Neil won't be able to attend. I'm going to ask for the last session of a day so that Neil can remote in from Australia without waking too early. I've only requested 1 hour at the moment, since Neil believes most of the work will be finished by then, so it will be a "present the spec and ask if it's ready for WGLC" session mostly, with some time also for looking at the next steps (Calendaring and Contacts). Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_15273360417900410 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Hi All,

Sorry I've been slack getting this done.  We need to schedule our session for Montreal.  Sadly, Neil won't be able to attend.  I'm going to ask for the last session of a day so that Neil can remote in from Australia without waking too early.

I've only requested 1 hour at the moment, since Neil believes most of the work will be finished by then, so it will be a "present the spec and ask if it's ready for WGLC" session mostly, with some time also for looking at the next steps (Calendaring and Contacts).

Cheers,

Bron.



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


--_----------=_15273360417900410-- From nobody Tue May 29 13:07:25 2018 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 F417D12FAB6 for ; Tue, 29 May 2018 13:07:14 -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=vXA3+0E7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PItQmw/j 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 qFQG9x_lhYJh for ; Tue, 29 May 2018 13:07:11 -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 D925612AAB6 for ; Tue, 29 May 2018 13:07:09 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 54C4121B32 for ; Tue, 29 May 2018 16:07:09 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 29 May 2018 16:07:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=1tfn5EwNIMPZ8HmxUfLLm2XrNvitt t/U/b7HstkxhMM=; b=vXA3+0E78ZVdt4vIfJ0oX6pSHvZF9SsJisDsuaUNixN41 Zf9zvTVy872JHZTXZwseA++6m6z9OjrHBuTbKsAeso7Cx1CR+gmo5og73m1BxS8M f7rQrXYVxNjgopsww3JRMdeE6kfpHLx9d0/2/ipe2VeNKpu50McD8chIkvRvR4v5 EQIrYr0PpUlfijy4IB4qMZBQ1wYoCETe7RQZt1pwoXpdJHFMmmR0Vqt0jjXyNweh ORsS3irVfsL0gjfyrGI02azmvyrapI1q5EAOTVXGJ8HMXBxcjKWcO4xy0BOvs6rk kU06E2R9TR57IAk/ue1KPPoLWKKTmYpHyuAykkLbA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=1tfn5EwNIMPZ8HmxUfLLm2XrNvitt t/U/b7HstkxhMM=; b=PItQmw/j4NEeQMtyomM+bQGor7jJF7KZyrkYETGWnsZ3w J9iE67y//zlb3XvBMTq4zay/jqoHi3TYo2TR+Cu1D7HIID3KowT6HO/hQ+CrbIZf J12aFHrK9uM8oRN0U1AkGFwlybDx9vNhqhwxNyyOsWaeVTsxnMszIqoDWtxjsX4D u+RVDa1eP0mRpBnVD7EGWZIDBn9umn/BPdcZKi/LH4+70JionAsomJ3X2CUT4OJb mdRRxlhJTdSyN0Fh9iWz8J/jtpy/arIqKFFfe4zko5SArPzB3zhUmG3q1A/asZeD bHY5KqQyBOU2nvHb9I8NZ2twYXL4p82eYl2w7kUHA== X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: from localhost.localdomain (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id BB71A10261 for ; Tue, 29 May 2018 16:07:08 -0400 (EDT) References: <152762434119.30187.891281157139219165.idtracker@ietfa.amsl.com> To: IETF JMAP Mailing List From: Ken Murchison Organization: FastMail US LLC X-Forwarded-Message-Id: <152762434119.30187.891281157139219165.idtracker@ietfa.amsl.com> Message-ID: <42d9cdbc-338b-125b-4164-76dda81c81fa@fastmailteam.com> Date: Tue, 29 May 2018 16:07:08 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <152762434119.30187.891281157139219165.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------1A79EA60524A6122399A4256" Content-Language: en-US Archived-At: Subject: [Jmap] Fwd: New Version Notification for draft-murchison-jmap-websocket-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: Tue, 29 May 2018 20:07:24 -0000 This is a multi-part message in MIME format. --------------1A79EA60524A6122399A4256 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Having implemented JMAP over WebSocket in the Cyrus IMAP server, I figured that I would go ahead and start documenting it. -------- Forwarded Message -------- Subject: New Version Notification for draft-murchison-jmap-websocket-00.txt Date: Tue, 29 May 2018 13:05:41 -0700 From: internet-drafts@ietf.org To: Ken Murchison , Kenneth Murchison A new version of I-D, draft-murchison-jmap-websocket-00.txt has been successfully submitted by Kenneth Murchison and posted to the IETF repository. Name: draft-murchison-jmap-websocket Revision: 00 Title: A JSON Meta Application Protocol (JMAP) Subprotocol for WebSocket Document date: 2018-05-29 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/internet-drafts/draft-murchison-jmap-websocket-00.txt Status: https://datatracker.ietf.org/doc/draft-murchison-jmap-websocket/ Htmlized: https://tools.ietf.org/html/draft-murchison-jmap-websocket-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-murchison-jmap-websocket Abstract: This document defines a binding for the JSON Meta Application Protocol (JMAP) over a WebSocket transport layer. A WebSocket binding for JMAP provides higher performance than the current HTTP binding for JMAP. Open Issues o Discovering support for JMAP over WebSocket. o Should we allow push notifications over the WS connection? 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. The IETF Secretariat --------------1A79EA60524A6122399A4256 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Having implemented JMAP over WebSocket in the Cyrus IMAP server, I figured that I would go ahead and start documenting it.



-------- Forwarded Message --------
Subject: New Version Notification for draft-murchison-jmap-websocket-00.txt
Date: Tue, 29 May 2018 13:05:41 -0700
From: internet-drafts@ietf.org
To: Ken Murchison <murch@fastmailteam.com>, Kenneth Murchison <murch@fastmailteam.com> 


A new version of I-D, draft-murchison-jmap-websocket-00.txt
has been successfully submitted by Kenneth Murchison and posted to the
IETF repository.

Name:		draft-murchison-jmap-websocket
Revision:	00
Title:		A JSON Meta Application Protocol (JMAP) Subprotocol for WebSocket
Document date:	2018-05-29
Group:		Individual Submission
Pages:		8
URL:            https://www.ietf.org/internet-drafts/draft-murchison-jmap-websocket-00.txt
Status:         https://datatracker.ietf.org/doc/draft-murchison-jmap-websocket/
Htmlized:       https://tools.ietf.org/html/draft-murchison-jmap-websocket-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-murchison-jmap-websocket


Abstract:
   This document defines a binding for the JSON Meta Application
   Protocol (JMAP) over a WebSocket transport layer.  A WebSocket
   binding for JMAP provides higher performance than the current HTTP
   binding for JMAP.

Open Issues

   o  Discovering support for JMAP over WebSocket.

   o  Should we allow push notifications over the WS connection?

                                                                                  


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.

The IETF Secretariat
--------------1A79EA60524A6122399A4256-- From nobody Tue May 29 19:53:14 2018 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 6AA95126BF6 for ; Tue, 29 May 2018 19:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 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, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=beXBrTWo; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XlLHvjpS 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 fxWCBfFuAe9Y for ; Tue, 29 May 2018 19:53:11 -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 DE772124D37 for ; Tue, 29 May 2018 19:53:10 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 3F37421CB1 for ; Tue, 29 May 2018 22:53:10 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Tue, 29 May 2018 22:53:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=QxIM/xzff3pAya07dgTeHbdRbTRr8rXqEyQoAO7Eo NQ=; b=beXBrTWo5NeEoVYGt3CLWmcNT6dX+GAXtc+UJS+x9YryLo+KACPYY0JuU +rznySE/fufOSMlnU5MupBbaYqhdYi4EUqMoiALfA9Lfo9f1yH0YqEpzW4M6hPlc 03Nns9mqKhs/Kt7tLjoCgQhlz8COrf8QQR1kNz0rawzdpiTl5bDr2wxK4uj11g8H Ysn98p4J9BiZxQPi29g7BDMbPFq0qo9dr93JUKV2ny5p23mwS3mhAGeP80KEwX3C ip1Oc7foWt4etvqyLVS1NmSSNlLrFRdNg3rWGuWrsX390kzl7FH833fCkhndKi5n /r12CJflqmbOFkimSIL9sNcyylRYw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=QxIM/xzff3pAya07dgTeHbdRbTRr8rXqEyQoAO7Eo NQ=; b=XlLHvjpSNgNStQneeciVhp9+Z3Y4x7Y/UbQj2Q+pdUZ6WZt3yBUWyPnLH zPN7rRrfz4JMwms2xHMXWmx8r3JZ/d0gT7vwAw4iG96Gh/6ordPXU8PkhDU/zxXf hASV4YvYi7ExZqVljhyFPRydbAJMW7SKtpMM2F8pGL0FoUYwy2ZCqSAeP6Hby0e4 wsGeoQTR8T9jndZQBebpVed0Q0n3P2dv5BsiGw5Go5dh2/hTONiV1wezSkkPSWGg 1rL7wteZ2Q6kF8nNkHbruFS0slPlmvhLY105d0v17ymoNdO3OSZ6u4rHdBilHM6V lg255IgJNASSEffAg3dv5m4EoyOTw== X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B77DBCA2B7; Tue, 29 May 2018 22:53:09 -0400 (EDT) Message-Id: <113acf52-6b03-4914-a0f2-7fdf08b1cf98@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.3-636-g719d684-next x-jmap-identity-id: 64588216 In-Reply-To: <42d9cdbc-338b-125b-4164-76dda81c81fa@fastmailteam.com> References: <42d9cdbc-338b-125b-4164-76dda81c81fa@fastmailteam.com> <152762434119.30187.891281157139219165.idtracker@ietfa.amsl.com> Date: Tue, 29 May 2018 22:53:09 -0400 From: Neil Jenkins To: IETF JMAP Mailing List Content-Type: multipart/alternative; boundary=d8ae2b03b7c44c2ea34a618cc008c554 Archived-At: Subject: Re: [Jmap] =?utf-8?q?Fwd=3A_New_Version_Notification_for_draft-murch?= =?utf-8?q?ison-jmap-websocket-00=2Etxt?= 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, 30 May 2018 02:53:13 -0000 --d8ae2b03b7c44c2ea34a618cc008c554 Content-Type: multipart/related; boundary=ca35caf4a3a14ba09f6d9d7127c103b9 --ca35caf4a3a14ba09f6d9d7127c103b9 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Looks good= . A few thoughts:
  • This should definitely be advertised = in the capabilities object, as per any JMAP extensions.
  • Shou= ld the server be allowed to advertise a different URL for a websockets A= PI connection as opposed to an HTTP one?
  • Are responses guara= nteed to be in the same order as requests? (Probably not; if you want me= thods to execute sequentially you should bundle them in a single request= object, but then how do you correlate the response objects to the reque= st objects? Probably need to add an id property to the request/response = object.)
  • I think being able to receive push events over the = single websocket connection makes sense, but that means you'd have to be= able to distinguish the different message types you might receive (API = response or push).
  • What changes are required to rate limitin= g options for the server? These probably need to be advertised in the ca= pabilities object for this extension.

N= eil.
--ca35caf4a3a14ba09f6d9d7127c103b9-- --d8ae2b03b7c44c2ea34a618cc008c554 Content-Type: text/plain Looks good. A few thoughts: * This should definitely be advertised in the capabilities object, as per any JMAP extensions. * Should the server be allowed to advertise a different URL for a websockets API connection as opposed to an HTTP one? * Are responses guaranteed to be in the same order as requests? (Probably not; if you want methods to execute sequentially you should bundle them in a single request object, but then how do you correlate the response objects to the request objects? Probably need to add an id property to the request/response object.) * I think being able to receive push events over the single websocket connection makes sense, but that means you'd have to be able to distinguish the different message types you might receive (API response or push). * What changes are required to rate limiting options for the server? These probably need to be advertised in the capabilities object for this extension. Neil. --d8ae2b03b7c44c2ea34a618cc008c554-- From nobody Wed May 30 06:31:33 2018 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 6F0D412E8A1 for ; Wed, 30 May 2018 06:31:31 -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, 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=fastmail.com header.b=m0oCHOei; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MkwZorco 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 aNo8NIRsMBLc for ; Wed, 30 May 2018 06:31: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 1B09712E898 for ; Wed, 30 May 2018 06:31:12 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 535EC215AC for ; Wed, 30 May 2018 09:31:11 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Wed, 30 May 2018 09:31:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=FNdOVKChzSCUIvaw3Ex9mvkSSEizBjBOyJCxpXaXpHg=; b=m0oCHOei ZNNLT//yu4aLM3p48Mb2RM/DDd+djps8ie+6Q4tczQBhhUL9LgtYAF5jA5zXMxYL XdPhZqGlnOZgBE+3Y2mUCPSFCilsAbKCaBvod+LyQ8ztePqYpYQ0cN8/mLf4bU7a ICCmze8TmUFyjQ//7+sGO2po7lw3Qp30Bqre5AswWn2x2zhx+w3kRHFaq87N37/d z2f5XJsQuO2wdcxIMNdMMVQ/+m24gWaZOuUKVdSuo9DazXrO+Pfwo4SLK4LNNMTV Y4tyfoAairYJkPjXogsfzcd5Hv3BZMHX7QkyMDRTKUgNAGmPaDBVt29mjKWXNUG9 7LRP6MzW6KRDgQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=FNdOVKChzSCUIvaw3Ex9mvkSSEizB jBOyJCxpXaXpHg=; b=MkwZorco4E0l8SxHNiX5kvn/a6t4vMohmWhUiw90TMaQo bgt1PHQmE3v4qtPz26TpC4+xHvSltnBuSYb2GAqP+kUIsX1dIynIljQcQQbZRUAc 4U2NvmqcrhJ0sCKCNyWo3/1lzQfb+M8bajLxRbDt3w37rB/Ja3MHjAKj3re2z1uK JYadGUyEGCP4z4DdfOlZpm65NAUzPSigXHV2vAUU48nge1uZXpmOx6r+GbvB0dcf gbVP/0WOXnmxpGzFD1XpEwnCKfjnNpxM+aAj4wOdLYU7g99rbksTqk6e62B3gCPz yLCNrhPuAmvFSTHyZjBw3s/kkoOYHIbZlXYWUM+0Q== X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: from localhost.localdomain (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id D6C931028C for ; Wed, 30 May 2018 09:31:10 -0400 (EDT) To: jmap@ietf.org References: <42d9cdbc-338b-125b-4164-76dda81c81fa@fastmailteam.com> <152762434119.30187.891281157139219165.idtracker@ietfa.amsl.com> <113acf52-6b03-4914-a0f2-7fdf08b1cf98@sloti22d1t06> From: Ken Murchison Organization: FastMail US LLC Message-ID: <305ecac4-d5cb-2935-a1ef-e3dcc6823e0f@fastmail.com> Date: Wed, 30 May 2018 09:31:10 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <113acf52-6b03-4914-a0f2-7fdf08b1cf98@sloti22d1t06> Content-Type: multipart/mixed; boundary="------------87FFDB43C94D7BB5A384DFF3" Content-Language: en-US Archived-At: Subject: Re: [Jmap] Fwd: New Version Notification for draft-murchison-jmap-websocket-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, 30 May 2018 13:31:32 -0000 This is a multi-part message in MIME format. --------------87FFDB43C94D7BB5A384DFF3 Content-Type: multipart/alternative; boundary="------------F7CEB16822242CA4CE1F2E68" --------------F7CEB16822242CA4CE1F2E68 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 05/29/2018 10:53 PM, Neil Jenkins wrote: > Looks good.. A few thoughts: > > * This should definitely be advertised in the capabilities object, > as per any JMAP extensions. > OK.  For now, I'll put the extension in the cyrusimap.org namespace. > * Should the server be allowed to advertise a different URL for a > websockets API connection as opposed to an HTTP one? > Sure.  I'll add a 'wsUrl' String to the capabilities. > * Are responses guaranteed to be in the same order as requests? > (Probably not; if you want methods to execute sequentially you > should bundle them in a single request object, but then how do you > correlate the response objects to the request objects? Probably > need to add an id property to the request/response object.) > I had intended that they would be in the same order, but I suppose out of order could be allowed if deemed necessary. > * I think being able to receive push events over the single > websocket connection makes sense, but that means you'd have to be > able to distinguish the different message types you might receive > (API response or push). > Can't the client distinguish between a Response object and a StateChange object?  If we need a better way, do you have a recommendation? > * What changes are required to rate limiting options for the server? > These probably need to be advertised in the capabilities object > for this extension. > Are you thinking that we need separate maxSizeRequest, maxConcurrentRequests, maxCallsInRequest, maxObjectsInGet, and maxObjectsInSet for the WebSocket connection? -- Ken Murchison Cyrus Development Team FastMail US LLC --------------F7CEB16822242CA4CE1F2E68 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 05/29/2018 10:53 PM, Neil Jenkins wrote:
Looks good.. A few thoughts:
  • This should definitely be advertised in the capabilities object, as per any JMAP extensions.

OK.  For now, I'll put the extension in the cyrusimap.org namespace.


  • Should the server be allowed to advertise a different URL for a websockets API connection as opposed to an HTTP one?

Sure.  I'll add a 'wsUrl' String to the capabilities.


  • Are responses guaranteed to be in the same order as requests? (Probably not; if you want methods to execute sequentially you should bundle them in a single request object, but then how do you correlate the response objects to the request objects? Probably need to add an id property to the request/response object.)

I had intended that they would be in the same order, but I suppose out of order could be allowed if deemed necessary.


  • I think being able to receive push events over the single websocket connection makes sense, but that means you'd have to be able to distinguish the different message types you might receive (API response or push).

Can't the client distinguish between a Response object and a StateChange object?  If we need a better way, do you have a recommendation?


  • What changes are required to rate limiting options for the server? These probably need to be advertised in the capabilities object for this extension.

Are you thinking that we need separate maxSizeRequest, maxConcurrentRequests, maxCallsInRequest, maxObjectsInGet, and maxObjectsInSet for the WebSocket connection?

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC
--------------F7CEB16822242CA4CE1F2E68-- --------------87FFDB43C94D7BB5A384DFF3 Content-Type: text/x-vcard; name="murch.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="murch.vcf" bnVsbA== --------------87FFDB43C94D7BB5A384DFF3-- From nobody Wed May 30 15:44:42 2018 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 A38D212D87E for ; Wed, 30 May 2018 15:44:41 -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=qNEEgyTl; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jg/v1Rb1 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 6uKm5S9pTSwT for ; Wed, 30 May 2018 15:44: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 0DE2C12D86A for ; Wed, 30 May 2018 15:44:40 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 773CC21A79 for ; Wed, 30 May 2018 18:44:39 -0400 (EDT) Received: from web1 ([10.202.2.211]) by compute6.internal (MEProxy); Wed, 30 May 2018 18:44:39 -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=fm2; bh=MALivufJIL/e9RV7Qbksu3oBaU7ByqByk11po6MzE S0=; b=qNEEgyTlBSZo0odWAtIBqiN1Xxw/JjL7oYTopImKRgnJmip6GTUKia/Uy mCD5+VPNEw8B0eL3tZiJw4DZBvF2AGI5c48TOBKMEDDzip7BPqTw5OI+/y0a4Ofl u7/WD0or1X3JUAQi/lNY5Vzey9k+zonPMxEJpyz6bgvYDNxZqZknhGHpboLZkM0D B6T6Tg2zFW5oD5cu3TtgDiKzHUcj5Y6/p5punuRu9OP01JpsSy3gk0lYICt2SRhi rHKwGtxKYkyNX8SmyDN7fX8uH20m7AoXIN+F6jROUJXbSimG3c7nWAoOGeVZMyGG uBVgRyy2Uo68ku34fKp6+j5ofV9Cw== 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=fm2; bh=MALivufJIL/e9RV7Qbksu3oBaU7By qByk11po6MzES0=; b=jg/v1Rb15HUBM2O29LIc4lg8BYJKp2TYnah8mxbRUiwyh LVB8bi0MFC+yytFJW6zhACpLBX9SrPSnBrvgKmDhdaheyv4CaEWbiGNE6kb4VFPC oQuEYEPTH+vjy4cR1lmSfP2zmocU9DksbcIMdsKxuGCJHmmjbyoL5ieMz9r9/AzT RtYn/OupXjEATnWQVMkOB5V+eqjrsJP5at/bEvb1rvl6gUiLLT2U1QL8F2GSFM6k bphYYJpVkKmNrBU849/dTQ9XeDiP8KrJiZ+UJe37NcTFx2tVXgdSmBQD/uiBR3md MwkpyfzJFvyitX7rox1DHtn25kBxuEbi3ET4XGxWg== X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 4EFDA9412B; Wed, 30 May 2018 18:44:39 -0400 (EDT) Message-Id: <1527720279.3714177.1391085296.7AC3A4C2@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_152772027937141770" X-Mailer: MessagingEngine.com Webmail Interface - ajax-397f98d6 Date: Thu, 31 May 2018 08:44:39 +1000 Archived-At: Subject: [Jmap] Hackathon in Montreal 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, 30 May 2018 22:44:42 -0000 This is a multi-part message in MIME format. --_----------=_152772027937141770 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Hi All, I've put JMAP down for a table at the hackathon in Montreal. I know a few of us from FastMail will be there hacking on our code, and we'd love to do some interop. It will be particularly valuable this time because we'll have the developer of our JMAP test suite present, so we can make sure it works with other servers. Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_152772027937141770 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Hi All,

I've put JMAP down for a table at the hackathon in Montreal.  I know a few of us from FastMail will be there hacking on our code, and we'd love to do some interop.  It will be particularly valuable this time because we'll have the developer of our JMAP test suite present, so we can make sure it works with other servers.

Cheers,

Bron.

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


--_----------=_152772027937141770-- From nobody Wed May 30 20:46:26 2018 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 8C23B12FAA2 for ; Wed, 30 May 2018 20:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, T_DKIMWL_WL_MED=-0.01] 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 KIDkI3F29TDn for ; Wed, 30 May 2018 20:46:21 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F39F412FA7A for ; Wed, 30 May 2018 20:46:20 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id m5-v6so4701260pgd.3 for ; Wed, 30 May 2018 20:46:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neiljhaveri-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:to; bh=iuIUtB46ut5nAAdG0ntytdaLAfxGBZQxGvw7HZF8Bao=; b=tB1u3qbAp911mh9B/ogfp6PGwG4uVt7rlxgjaqOrYd/JRc0HE3EkUVbzwKgSpDipTP NhlqVATOhNfTjiHXGMRRZWGPIT5sZg+2RT5eoJaVKAuN7KIt2gP+mFJOVDnjMtEM4LQY +HBNGKJ7qog8+d5s+ld4y2fTjOXGWAkXgx88iBTb/mBlBGdcN/PxFGubn5DnDkeWFjQn L3SAkSLVdpij3hiYL9vG4jgx8Te89/dI3FYfKe3b+cyDRqP+d4H1FH2RenTIY6Tidz60 HW6sRVkmk5aBSAa9C+Vhi35KBCP1iqq1gxbeadcqW/37FBx0qRT8TIGdj3V+O68UiEPW ddFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=iuIUtB46ut5nAAdG0ntytdaLAfxGBZQxGvw7HZF8Bao=; b=pHZuiYgbX5llbFEEVykTuVEncc+Iap++b3kLcD9U6Ec2JvYhfL4bIkriMPUs1cDdcw A9C8oWIrTy2oRBInY+I2guICjTcU7HDTyKVYk0tz3UdD0I6t3rzz/6NS6sAqDBTpfMF2 3WBkSNQTxNuzhYl7PQaqpzBhAF1cpmoS0XQC11cyNIyL7sug+AfB+5xRG5KStCqCUTjy /MASMt5wT4dXplH2MHtQUFXLnHvx1FOqXfCUITApB1xOB699qdO8fsa8F4EXfHu1cTLC cGmKGZnOLE9KsYSjGtSsdgsuBJcQhsC/1tTAmy3/HiFEAwFvY5o4zNDXOtreNPJaPNnB xJ5g== X-Gm-Message-State: ALKqPwfGwwi41J5pjk3mPVyayRHyxIwJReTec4q0F/iXcKbFz0um5Sbp fHCt/UgCbiv2TlgxG3FA4ESYD/J/58M= X-Google-Smtp-Source: ADUXVKISF3lfxEN4TRgMZOMlnrlq3ohKtCRWi3vdyyu88OwCIMhpa38q3PLjqt++nIODMZ/iubxLqQ== X-Received: by 2002:a63:6bc7:: with SMTP id g190-v6mr4179727pgc.230.1527738380006; Wed, 30 May 2018 20:46:20 -0700 (PDT) Received: from [192.168.1.14] (ip70-190-168-77.ph.ph.cox.net. [70.190.168.77]) by smtp.gmail.com with ESMTPSA id 76-v6sm86500273pfm.178.2018.05.30.20.46.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 May 2018 20:46:18 -0700 (PDT) From: Neil Jhaveri Content-Type: multipart/alternative; boundary="Apple-Mail=_087F6C94-5816-4223-8F54-728FCDFFA631" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Message-Id: Date: Wed, 30 May 2018 20:46:17 -0700 To: IETF JMAP Mailing List X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: [Jmap] Review of draft-ietf-jmap-core-05 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, 31 May 2018 03:46:25 -0000 --Apple-Mail=_087F6C94-5816-4223-8F54-728FCDFFA631 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, Here are some comments from my latest reading of = draft-ietf-jmap-core-05. Apologies if I=E2=80=99m revisiting anything = already discussed!=20 Questions / Needs Discussion > 3.2.1. Example request > { > "using": [ "urn:ietf:params:jmap:core", "urn:ietf:params:jmap:mail" = ], Can the JMAP Core capability just be assumed? Any good reasons to = actually have this listed out? > 4.2. /changes > =E2=80=A6 > o *changed*: "String[]" An array of ids for records which have = been > created or modified but not destroyed since the oldState. Could =E2=80=9Ccreations=E2=80=9D and =E2=80=9Cmodifications=E2=80=9D be = separated into separate array properties? A common resynchronization = case is a small number of creations, without any modifications, and it = may be more efficient for some clients to process creations than = modifications.=20 For instance, an iOS app using Core Data could then create new objects = and immediately save them off, rather than having to first do an initial = fetch to see if it already has an existing record with that ID.=20 By comparison to IMAP + CONDSTORE, I think you can infer if something is = created vs. modified if a fetch response's UID is greater than your = last-cached UIDNEXT. Since IDs in JMAP seem to be opaque, it might be = nice to do this separation to afford this possibility again. > 4.2. /changes > ... > o *newState*: "String" This is the state the client will be in = after applying the set of changes to the old state. If an offline client is resynchronizing after being disconnected and = there are a lot of changes, the way that /changes is set up seems to = imply that if the changes don=E2=80=99t all fit in 1 response, the = sequence of responses will be ordered oldest-to-newest. Is that true?=20 If so, and assuming most clients are fairly naive and just immediately = dispatch /get=E2=80=99s on IDs that they retrieve (perhaps by = back-reference), that isn=E2=80=99t ideal for a UI that shows objects in = newest-to-oldest order, potentially resulting in a user experience of = =E2=80=9Chere are new objects from 5 days ago=E2=80=9D, followed by = =E2=80=9Chere are new objects from 4 days ago=E2=80=9D, and so on. When = really, the user ideally would prefer to see =E2=80=9Chere are objects = from right now=E2=80=9D as the first screen update =E2=80=94 at least = for e-mail, I think this is the case. Have we had any discussion around handling pages of changes in a = different way? For instance, the Gmail API = = has a Users.history : list resource, which takes a =E2=80=9CstartHistoryId= =E2=80=9D as well as a =E2=80=9CpageToken=E2=80=9D. The response = includes a =E2=80=9CnextPageToken=E2=80=9D, or null if there are no = additional pages. Clients only update their local =E2=80=9ChistoryId=E2=80= =9D after fetching all pages. (This admittedly comes at the trade-off of a client not being able to = checkpoint any changed-ID ingestion until it is fully caught up with all = changed IDs). A client could do a /query to get the absolute most recent page of = items, merge that into it=E2=80=99s cache, and then handle /changes = normally in order, but this seems a little less efficient. > 4.3. /set > A *SetError* object has the following properties: > ... > o *description*: "String|null" A description of the error to display = to the user. Presumably, this error is not localized. The recommendation to display = it to the user is not consistent with the document's earlier = recommendation in 3.6.2. Method-level errors: "A =E2=80=98description' = property MAY be present to help debug with an explanation of what the = problem was. This is a non-localised string, and is not intended to be = shown directly to end users." Should the same suggestion be made here? > 4.4. /query > ... > *anchorOffset*: "Number|null" The index of the anchor object relative = to the index of the first result to return. This MAY be negative. For = example, "-1" means the first Foo after the anchor Foo should be the = first result in the results returned (see below for more details). FWIW, when reading this, I also made the same scribble note that Matthew = H. did almost 3 months ago =E2=80=94 that the anchorOffset seemed = flipped from what my brain was expecting, and I was confused for a bit = about why it was negative instead of positive. Re-reading it and the = previous thread, I get it, and either way is fine since it is just = stylistic, but I will cast my vote in favor of flipping anchorOffset. > 4.5. /queryChanges > ... > The response has the following arguments: > ... > o *removed*: > o *added* Is there a reason why there is no modified property? For instance, how = would a primarily-online mail client realize that certain threads became = flagged, unread, etc., aside from re-get'ing everything in the query = window after handling the adds/deletes?=20 > 5. Binary data > ... > A blob that is not referenced by a JMAP object (e.g. as a message = attachment), MAY be deleted by the server to free up resources. > =E2=80=A6 > o Except where quota restrictions force early deletion, an = unreferenced blob SHOULD NOT be deleted for at least 24h from the time = of upload; if reuploaded, the same blobId MAY be returned, but this = SHOULD reset the expiry time. The way I=E2=80=99m understanding this garbage-collection policy, it = could be alarming to a user if they try to delete some blob data they = accidentally put on the server, but it=E2=80=99s still possible to = access it even after deletion because it=E2=80=99s just unreferenced. = There is a trade-off between being able to save users when they = accidentally delete important data, and a user being able to actually = delete data they=E2=80=99re trying to delete, but I think those sort of = data-recovery policies should not be totally opaque to JMAP. What would you all think about being a little more explicit here? = Perhaps defining a =E2=80=9CMUST=E2=80=9D-conformance expiration time in = the spec (N minutes)? (The current policy saying SHOULD NOT delete for = 24h seems excessively generous for API clients to me?) > 6.2.1. PushSubscription/set > Each session may only have a single push subscription registered. Can somebody clarify what is meant by session here? Is this meant to be = a single =E2=80=9Caccount=E2=80=9D? Grammatical Nit-picks > 1.1 Notational Conventions > =E2=80=A6 > Types signatures are given for all JSON objects in this document. Should this be =E2=80=9CType=E2=80=9D, rather than =E2=80=9CTypes=E2=80=9D= ? > 2. The JMAP Session resource > To communicate with a JMAP server you need two things to start: Is a comma needed between =E2=80=9Cserver=E2=80=9D and =E2=80=9Cyou=E2=80=9D= ? > 5. Binary data > ... > A blob that is not referenced by a JMAP object (e.g. as a message = attachment), MAY be deleted by the server to free up resources. I think the comma before =E2=80=9CMAY=E2=80=9D is not needed. > 6.1. The StateChange object > o *trigger*: "String" What caused this change. The following = causes are defined: > * "delivery": The arrival of a new message caused the change. Since JMAP is intended to be the foundation of data types beyond Mail, = perhaps this should say something besides =E2=80=9Cnew message=E2=80=9D = =E2=80=94 maybe =E2=80=9CThe cause of the change is delivery from an = external system or user=E2=80=9D. Formatting nit-picks PDF version - page 19 is very small (list of IDs doesn=E2=80=99t wrap). - Neil --Apple-Mail=_087F6C94-5816-4223-8F54-728FCDFFA631 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = all,

Here are some comments from my latest reading of = draft-ietf-jmap-core-05. Apologies if I=E2=80=99m revisiting = anything already discussed! 

Questions / Needs = Discussion

3.2.1.  Example = request
{
  "using": [ "urn:ietf:params:jmap:core", "urn:ietf:params:jmap:mail" = ],
Can the JMAP Core capability = just be assumed? Any good reasons to actually have this listed = out?

4.2.= /changes
=E2=80=A6
   o  *changed*: "String[]" An array of ids = for records which have been
      created or modified but not destroyed since the = oldState.
Could =E2=80=9Ccreations=E2=80=9D and =E2=80=9Cmodifications=E2= =80=9D be separated into separate array properties?  A common = resynchronization case is a small number of creations, without any = modifications, and it may be more efficient for some clients to process = creations than modifications. 

For instance, an iOS app using Core = Data could then create new objects and immediately save them off, rather = than having to first do an initial fetch to see if it already has an = existing record with that ID. 

By comparison to IMAP + CONDSTORE, I = think you can infer if something is created vs. modified if a fetch = response's UID is greater than your last-cached UIDNEXT. Since IDs in = JMAP seem to be opaque, it might be nice to do this separation to afford = this possibility again.

4.2.= /changes
...
   o =  *newState*: "String" This is the state the client will be in after = applying the set of changes to the old = state.
If an offline client is = resynchronizing after being disconnected and there are a lot of changes, = the way that /changes is set up seems to imply that if the changes = don=E2=80=99t all fit in 1 response, the sequence of responses will be = ordered oldest-to-newest. Is that true? 

If so, and assuming most clients are = fairly naive and just immediately dispatch /get=E2=80=99s on IDs that = they retrieve (perhaps by back-reference), that isn=E2=80=99t ideal for = a UI that shows objects in newest-to-oldest order, potentially resulting = in a user experience of =E2=80=9Chere are new objects from 5 days = ago=E2=80=9D, followed by =E2=80=9Chere are new objects from 4 days = ago=E2=80=9D, and so on. When really, the user ideally would prefer to = see =E2=80=9Chere are objects from right now=E2=80=9D as the first = screen update =E2=80=94 at least for e-mail, I think this is the = case.

Have we = had any discussion around handling pages of changes in a different way? = For instance, the Gmail API has a Users.history : list = resource, which takes a =E2=80=9CstartHistoryId=E2=80=9D as well as a = =E2=80=9CpageToken=E2=80=9D. The response includes a = =E2=80=9CnextPageToken=E2=80=9D, or null if there are no additional = pages. Clients only update their local =E2=80=9ChistoryId=E2=80=9D after = fetching all pages.

(This admittedly comes at the trade-off of a client not being = able to checkpoint any changed-ID ingestion until it is fully caught up = with all changed IDs).

A client could do a /query to get the absolute most recent = page of items, merge that into it=E2=80=99s cache, and then handle = /changes normally in order, but this seems a little less = efficient.

4.3.= /set
A *SetError* object has the following = properties:
...
o =  *description*: "String|null" A description of the error to display to the = user.
Presumably, this error is = not localized. The recommendation to display it to the user is not = consistent with the document's earlier recommendation in 3.6.2. = Method-level errors: "A =E2=80=98description' property MAY be present to = help debug with an explanation of what the problem was.  This is a = non-localised string, and is not intended to be shown directly to end = users."

Should = the same suggestion be made here?

4.4. /query
...
*anchorOffset*: = "Number|null" The index of the anchor object relative to the index of = the first result to return.  This MAY be negative.  For = example, "-1" means the first Foo after the anchor Foo should be the = first result in the results returned (see below for more = details).
FWIW, when reading = this, I also made the same scribble note that Matthew H. did almost 3 = months ago =E2=80=94 that the anchorOffset seemed flipped from what my = brain was expecting, and I was confused for a bit about why it was = negative instead of positive. Re-reading it and the previous thread, I = get it, and either way is fine since it is just stylistic, but I will = cast my vote in favor of flipping anchorOffset.

4.5. /queryChanges
...
The response has the following = arguments:
...
   o =  *removed*:
   o =  *added*
Is there a reason why = there is no modified property? For instance, how would a = primarily-online mail client realize that certain threads became = flagged, unread, etc., aside from re-get'ing everything in the query = window after handling the adds/deletes? 

5. Binary data
...
A blob that is = not referenced by a JMAP object (e.g. as a message attachment), MAY be = deleted by the server to free up = resources.
=E2=80=A6
   o =  Except where quota restrictions force early deletion, = an unreferenced blob SHOULD NOT be deleted for at least 24h from = the time of upload; if reuploaded, the same blobId MAY be = returned, but this SHOULD reset the expiry = time.
The way I=E2=80=99= m understanding this garbage-collection policy, it could be alarming to = a user if they try to delete some blob data they accidentally put on the = server, but it=E2=80=99s still possible to access it even after deletion = because it=E2=80=99s just unreferenced. There is a trade-off between = being able to save users when they accidentally delete important data, = and a user being able to actually delete data they=E2=80=99re trying to = delete, but I think those sort of data-recovery policies should not be = totally opaque to JMAP.

What would you all think about being a little more explicit = here? Perhaps defining a =E2=80=9CMUST=E2=80=9D-conformance expiration = time in the spec (N minutes)? (The current policy saying SHOULD NOT = delete for 24h seems excessively generous for API clients to = me?)


6.2.1. = PushSubscription/set
Each session = may only have a single push subscription = registered.
Can somebody clarify what = is meant by session here? Is this meant to be a single = =E2=80=9Caccount=E2=80=9D?


Grammatical Nit-picks

1.1 Notational = Conventions
=E2=80=A6
Types signatures are given for all JSON objects in this = document.
Should this be =E2=80=9CType=E2= =80=9D, rather than =E2=80=9CTypes=E2=80=9D?

2. The JMAP Session resource
To communicate with a JMAP server you need = two things to start:
Is a comma needed between = =E2=80=9Cserver=E2=80=9D and =E2=80=9Cyou=E2=80=9D?

5. = Binary data
...
A blob that is not referenced by a JMAP = object (e.g. as a message attachment), MAY be = deleted by the server to free up resources.
I think = the comma before =E2=80=9CMAY=E2=80=9D is not needed.

6.1. The = StateChange object
   o =  *trigger*: "String" What caused this change.  The following = causes are defined:
      * =  "delivery": The arrival of a new message caused the = change.
Since JMAP is intended to be the foundation of data types = beyond Mail, perhaps this should say something besides =E2=80=9Cnew = message=E2=80=9D =E2=80=94 maybe =E2=80=9CThe cause of the change is = delivery from an external system or user=E2=80=9D.


Formatting = nit-picks
PDF version - page 19 is very small = (list of IDs doesn=E2=80=99t wrap).

- Neil


= --Apple-Mail=_087F6C94-5816-4223-8F54-728FCDFFA631-- From nobody Wed May 30 22:26:42 2018 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 0BAC912EC6F for ; Wed, 30 May 2018 22:26: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 (2048-bit key) header.d=fastmailteam.com header.b=ml/b1pPE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=gB4AhBwX 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 n4h7qQJq6YYa for ; Wed, 30 May 2018 22:26: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 A6B2312EC19 for ; Wed, 30 May 2018 22:26:37 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id D9BC521924 for ; Thu, 31 May 2018 01:26:36 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute6.internal (MEProxy); Thu, 31 May 2018 01:26: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=fm2; bh=HJtgxhOgH2pgqNRiA 5oKKfWbn/eEDD8iONwGGeGZtEM=; b=ml/b1pPENjuFSYT5wJNW8vhz6VQeTSJx5 /6Dkn30y+m0ypg9VTcRSiUwRfV3DbekS+ZtE6bZBJs4vBu5EAN/hop2M3++0b6iy RVn4+pUvxb7qfLh/M/eIcZ3UDjaCx8Ce30oOhZm0bh4FGjYfbj1MwTjIFJUSBW+k mN/kiQdhQDp7pxLAxx57kYpDKTDxmakN4a/p03WVAwPUlXwIaHqF5ES7WbqL8Qna LUo7i1sCpM2MS2Ey7GgzlO16L2E1JuLcNy5lXG6igfXcb5r0YcsHdwI0mvPoVaBm n5+uAMrRx4eeHPSLhEzn6fQ3WGHKXCK+X9FeNZb+BUcnAyIafkY1w== 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=fm2; bh=HJtgxh OgH2pgqNRiA5oKKfWbn/eEDD8iONwGGeGZtEM=; b=gB4AhBwXF1hNlC5WuG9Rsl 78QM8Vlp8Y29qCkgbVCO4ERDnCpUqo5Wf455ZE3VievL0sffBaE5EXKoQEkNoUzX ZRK+waDXzZQdoWBHB6R+RclGqWBZAbGvkk1qaBG/2I76WsHJdK8kPQQPAAwAFEai Qz+EN38kwI/KNHwYznAk3dehqewqseIaNJN2uJY5uBVk9KSUu6gnEs9YOLh3azoh 4PvpIyz304nkxK7hLQ/crv1BMHg4+NDpE+5MJX6IWWrKuvQoeoGTOc87dEn5eOEV tTJ21j8ymTTTa+Al2xvVAgwUd0LVXN6Q2hxg2i4aIfRJIy0BWzYu5vOCNnvIsK/w == X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 7FC579E3A4; Thu, 31 May 2018 01:26:36 -0400 (EDT) Message-Id: <1527744396.19460.1391345832.3A4034F6@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_1527744396194600" X-Mailer: MessagingEngine.com Webmail Interface - ajax-397f98d6 Date: Thu, 31 May 2018 15:26:36 +1000 In-Reply-To: References: Archived-At: Subject: Re: [Jmap] Review of draft-ietf-jmap-core-05 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, 31 May 2018 05:26:41 -0000 This is a multi-part message in MIME format. --_----------=_1527744396194600 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Thu, May 31, 2018, at 13:46, Neil Jhaveri wrote: > Hi all, >=20 > Here are some comments from my latest reading of draft-ietf-jmap-core- > 05. Apologies if I=E2=80=99m revisiting anything already discussed! (FYI Neil is on leave for a bit) > *Questions / Needs Discussion* > ** >=20 >> 3.2.1. Example request >> { >> "using": [ "*urn:ietf:params:jmap:core*", >> "urn:ietf:params:jmap:mail" ],> Can the JMAP Core capability just be a= ssumed? Any good reasons to > actually have this listed out? This seems reasonable to me - you can't do JMAP without core. >=20 >> 4.2. /changes >> =E2=80=A6 >> o *changed*: "String[]" An array of ids for records which have >> been>> *created or modified* but not destroyed since the oldSta= te. >=20 > Could =E2=80=9Ccreations=E2=80=9D and =E2=80=9Cmodifications=E2=80=9D be = separated into separate array > properties? A common resynchronization case is a small number of > creations, without any modifications, and it may be more efficient for > some clients to process creations than modifications. I'm OK with this so long as if the server can't tell, it's allowed to put things into modified even if they're new. > For instance, an iOS app using Core Data could then create new > objects and immediately save them off, rather than having to first do > an initial fetch to see if it already has an existing record with > that ID.>=20 > By comparison to IMAP + CONDSTORE, I think you can infer if something > is created vs. modified if a fetch response's UID is greater than your > last-cached UIDNEXT. Since IDs in JMAP seem to be opaque, it might be > nice to do this separation to afford this possibility again.>=20 >=20 >> 4.2. /changes >> ... >>=20 >> o *newState*: "String" This is the state the client will be in >> after applying the set of changes to the old state.> If an offline cl= ient is resynchronizing after being disconnected and > there are a lot of changes, the way that /changes is set up seems to > imply that if the changes don=E2=80=99t all fit in 1 response, the sequen= ce of > responses will be ordered oldest-to-newest. Is that true? This isn't enforced. Good point. > If so, and assuming most clients are fairly naive and just immediately > dispatch /get=E2=80=99s on IDs that they retrieve (perhaps by back-refere= nce), > that isn=E2=80=99t ideal for a UI that shows objects in newest-to-oldest > order, potentially resulting in a user experience of =E2=80=9Chere are new > objects from 5 days ago=E2=80=9D, followed by =E2=80=9Chere are new objec= ts from 4 > days ago=E2=80=9D, and so on. When really, the user ideally would prefer = to > see =E2=80=9Chere are objects from right now=E2=80=9D as the first screen= update =E2=80=94 at > least for e-mail, I think this is the case.>=20 > Have we had any discussion around handling pages of changes in a > different way? For instance, the Gmail API[1] has a Users.history : > list resource, which takes a =E2=80=9CstartHistoryId=E2=80=9D as well as a > =E2=80=9CpageToken=E2=80=9D. The response includes a =E2=80=9CnextPageTok= en=E2=80=9D, or null if there > are no additional pages. Clients only update their local =E2=80=9Chistory= Id=E2=80=9D > after fetching all pages.>=20 > (This admittedly comes at the trade-off of a client not being able to > checkpoint any changed-ID ingestion until it is fully caught up with > all changed IDs).>=20 > A client could do a /query to get the absolute most recent page of > items, merge that into it=E2=80=99s cache, and then handle /changes norma= lly > in order, but this seems a little less efficient. Yeah, it's a bit tricky. Do you have a proposal that would be sane? >=20 >> 4.3. /set >=20 >> A *SetError* object has the following properties: >> ... >> o *description*: "String|null" A description of the error *to >> display **to the user*.> Presumably, this error is not localized. The re= commendation to display > it to the user is not consistent with the document's earlier > recommendation in 3.6.2. Method-level errors: "A =E2=80=98description' > property MAY be present to help debug with an explanation of what the > problem was. This is a non-localised string, and is not intended to > be shown directly to end users.">=20 > Should the same suggestion be made here? >=20 >=20 >> 4.4. /query >> ... >> *anchorOffset*: "Number|null" The index of the anchor object relative >> to the index of the first result to return. This MAY be negative. >> For example, "-1" means the first Foo after the anchor Foo should be >> the first result in the results returned (see below for more >> details).> FWIW, when reading this, I also made the same scribble note t= hat > Matthew H. did almost 3 months ago =E2=80=94 that the anchorOffset seemed > flipped from what my brain was expecting, and I was confused for a bit > about why it was negative instead of positive. Re-reading it and the > previous thread, I get it, and either way is fine since it is just > stylistic, but I will cast my vote in favor of flipping anchorOffset. Suits me fine. I think we have a majority for flipping. >=20 >>=20 >>=20 >> 4.5. /queryChanges >> ... >> The response has the following arguments: >> ... >> o *removed*: >> o *added* > Is there a reason why there is no modified property? For instance, how > would a primarily-online mail client realize that certain threads > became flagged, unread, etc., aside from re-get'ing everything in the > query window after handling the adds/deletes? Modified is a property of the item, not the list. So you use /changes to find items which have changed and /queryChanges to see what's added to or removed to the list. If you have all data locally and are sorting locally, you don't need to use query or queryChanges at all. >=20 >> 5. Binary data >> ... >> A blob that is not referenced by a JMAP object (e.g. as a message >> attachment), MAY be deleted by the server to free up resources.>> =E2=80= =A6 >> o Except where quota restrictions force early deletion, an >> unreferenced blob SHOULD NOT be deleted for at least 24h from the >> time of upload; if reuploaded, the same blobId MAY be returned, >> but this SHOULD reset the expiry time.> The way I=E2=80=99m understan= ding this garbage-collection policy, it could be > alarming to a user if they try to delete some blob data they > accidentally put on the server, but it=E2=80=99s still possible to access= it > even after deletion because it=E2=80=99s just unreferenced. There is a tr= ade- > off between being able to save users when they accidentally delete > important data, and a user being able to actually delete data they=E2=80= =99re > trying to delete, but I think those sort of data-recovery policies > should not be totally opaque to JMAP.>=20 > What would you all think about being a little more explicit here? > Perhaps defining a =E2=80=9CMUST=E2=80=9D-conformance expiration time in = the spec (N > minutes)? (The current policy saying SHOULD NOT delete for 24h seems > excessively generous for API clients to me?) It sounds like maybe what you want is a deleteBlob operation to clean up unreferenced blobs? >=20 >=20 >> 6.2.1. PushSubscription/set >> Each *session* may only have a single push subscription registered. > Can somebody clarify what is meant by session here? Is this meant to > be a single =E2=80=9Caccount=E2=80=9D?>=20 >=20 > *Grammatical Nit-picks* > ** >=20 >> 1.1 Notational Conventions >> =E2=80=A6 >> *Types* signatures are given for all JSON objects in this document. > Should this be =E2=80=9CType=E2=80=9D, rather than =E2=80=9CTypes=E2=80= =9D? >=20 >=20 >> 2. The JMAP Session resource >> To communicate with a JMAP *server you* need two things to start: > Is a comma needed between =E2=80=9Cserver=E2=80=9D and =E2=80=9Cyou=E2=80= =9D? >=20 >> 5. Binary data >> ... >> A blob that is not referenced by a JMAP object (e.g. as a message >> *attachment), MAY* be deleted by the server to free up resources.> I thi= nk the comma before =E2=80=9CMAY=E2=80=9D is not needed. >=20 >> 6.1. The StateChange object >> o *trigger*: "String" What caused this change. The following >> causes are defined:>> * "delivery": The arrival of a new messa= ge caused the change.>=20 > Since JMAP is intended to be the foundation of data types beyond Mail, > perhaps this should say something besides =E2=80=9Cnew message=E2=80=9D = =E2=80=94 maybe =E2=80=9CThe > cause of the change is delivery from an external system or user=E2=80=9D.= >=20 >=20 > *Formatting nit-picks* > PDF version - page 19 is very small (list of IDs doesn=E2=80=99t wrap). >=20 > - Neil >=20 >=20 > _________________________________________________ > 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://developers.google.com/gmail/api/v1/reference/users/history/list --_----------=_1527744396194600 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
On Thu, May 31, 2018, at 13:46, Nei= l Jhaveri wrote:
Hi all,

Here are some comments from my = latest reading of draft-ietf-jmap-core-05. Apologies if I=E2=80=99m re= visiting anything already discussed! 

(FYI Neil is on leave for a bit)

Quest= ions / Needs Discussion


3.2.1. &nb= sp;Example request
{
  "using": [ "urn:ietf:params:jmap:core", "urn:ietf:params= :jmap:mail" ],
Can the JMAP Core capability just be assumed? Any good re= asons to actually have this listed out?

This seems reasonable to me - you can't d= o JMAP without core.


4.2. /changes
=E2=80=A6
   o  *changed*: "String[]" An array of ids for re= cords which have been
      created or modified but not destroyed sinc= e the oldState.

Could =E2=80=9Ccreations=E2=80=9D and =E2=80=9Cmodifications=E2=80=9D = be separated into separate array properties?  A common resynchronizati= on case is a small number of creations, without any modifications, and it m= ay be more efficient for some clients to process creations than modificatio= ns. 

I'm OK with this so long as if the server= can't tell, it's allowed to put things into modified even if they're new.<= br>

For instance, an iOS app using Cor= e Data could then create new objects and immediately save them off, rather = than having to first do an initial fetch to see if it already has an existi= ng record with that ID. 

By comparison to IMAP + CONDSTORE, I think you can infer if something = is created vs. modified if a fetch response's UID is greater than your last= -cached UIDNEXT. Since IDs in JMAP seem to be opaque, it might be nice to d= o this separation to afford this possibility again.


4.2. /changes
...

   o  *newS= tate*: "String" This is the state the client will be in after applying the = set of changes to the old state.
If an offline client is resynchronizing after being disconnected and t= here are a lot of changes, the way that /changes is set up seems to imply t= hat if the changes don=E2=80=99t all fit in 1 response, the sequence of res= ponses will be ordered oldest-to-newest. Is that true? 

This isn't enforced.  Good point.

If so, and assuming most clients a= re fairly naive and just immediately dispatch /get=E2=80=99s on IDs that th= ey retrieve (perhaps by back-reference), that isn=E2=80=99t ideal for a UI = that shows objects in newest-to-oldest order, potentially resulting in a us= er experience of =E2=80=9Chere are new objects from 5 days ago=E2=80=9D, fo= llowed by =E2=80=9Chere are new objects from 4 days ago=E2=80=9D, and so on= . When really, the user ideally would prefer to see =E2=80=9Chere are objec= ts from right now=E2=80=9D as the first screen update =E2=80=94 at least fo= r e-mail, I think this is the case.

Have we had any discussion around handling pages of changes in a diffe= rent way? For instance, the Gmail API has a Users.hi= story : list resource, which takes a =E2=80=9CstartHistoryId=E2=80=9D as we= ll as a =E2=80=9CpageToken=E2=80=9D. The response includes a =E2=80=9CnextP= ageToken=E2=80=9D, or null if there are no additional pages. Clients only u= pdate their local =E2=80=9ChistoryId=E2=80=9D after fetching all pages.
=

(This admittedly comes at the trade-off of a client not being able to = checkpoint any changed-ID ingestion until it is fully caught up with all ch= anged IDs).

A client could do a /query to get the absolute most recent page of ite= ms, merge that into it=E2=80=99s cache, and then handle /changes normally i= n order, but this seems a little less efficient.

Yeah, it's a bit tricky.  Do you hav= e a proposal that would be sane?


4.3. /set

A *SetError* object has the following proper= ties:
...
o  *description*: "String|null" A description of the error to = display to the user.
Presumably, this error is not localized. The recommendati= on to display it to the user is not consistent with the document's earlier = recommendation in 3.6.2. Method-level errors: "A =E2=80=98description' prop= erty MAY be present to help debug with an explanation of what the problem w= as.  This is a non-localised string, and is not intended to be shown d= irectly to end users."

Should the same suggestion be made here?


4.4. /query
...
*anchorOffset*: "Number|null" The index of the anchor o= bject relative to the index of the first result to return.  This MAY b= e negative.  For example, "-1" means the first Foo after the anchor Fo= o should be the first result in the results returned (see below for more de= tails).
FWIW, when reading this, I also made the same scribble no= te that Matthew H. did almost 3 months ago =E2=80=94 that the anchorOffset = seemed flipped from what my brain was expecting, and I was confused for a b= it about why it was negative instead of positive. Re-reading it and the pre= vious thread, I get it, and either way is fine since it is just stylistic, = but I will cast my vote in favor of flipping anchorOffset.

Suits me fine.  I think we have a ma= jority for flipping.



<= br>
4.5. /queryChanges
...
The response has the following arguments:
...
   o  *removed*:
   o  *added*
Is there a reason why there is no modified property? For = instance, how would a primarily-online mail client realize that certain thr= eads became flagged, unread, etc., aside from re-get'ing everything in the = query window after handling the adds/deletes? 

Modified is a property of the item, not t= he list.  So you use /changes to find items which have changed and /qu= eryChanges to see what's added to or removed to the list.

If you have all data locally and are sort= ing locally, you don't need to use query or queryChanges at all.


5. Binary data
...
A blob that is not referenced by a JMAP object (e.g. as= a message attachment), MAY be deleted by the server to free up resources.<= br>
=E2=80=A6
   o  Except where quota restrictions force early delet= ion, an unreferenced blob SHOULD NOT be deleted for at least 24h from = the time of upload; if reuploaded, the same blobId MAY be returned,&nb= sp;but this SHOULD reset the expiry time.
The way I=E2=80=99m understanding this garbage-colle= ction policy, it could be alarming to a user if they try to delete some blo= b data they accidentally put on the server, but it=E2=80=99s still possible= to access it even after deletion because it=E2=80=99s just unreferenced. T= here is a trade-off between being able to save users when they accidentally= delete important data, and a user being able to actually delete data they= =E2=80=99re trying to delete, but I think those sort of data-recovery polic= ies should not be totally opaque to JMAP.

What would you all think about being a little more explicit here? Perh= aps defining a =E2=80=9CMUST=E2=80=9D-conformance expiration time in the sp= ec (N minutes)? (The current policy saying SHOULD NOT delete for 24h seems = excessively generous for API clients to me?)

It sounds like maybe what you want is a d= eleteBlob operation to clean up unreferenced blobs?



6.2.1. PushSubscription/set
Each session may only have a single push subscription registere= d.
Can somebody clarify what is meant by session here? Is th= is meant to be a single =E2=80=9Caccount=E2=80=9D?


Grammatical Nit-picks


1.1 Notational Conventions
=E2=80=A6
Types signatures are given for all JSON objects in this documen= t.
Should this be =E2=80=9CType=E2=80=9D, rather than =E2=80= =9CTypes=E2=80=9D?


2. The JMAP Session resource
To communicate with a JMAP server you need two things to start:=
Is a comma needed between = =E2=80=9Cserver=E2=80=9D and =E2=80=9Cyou=E2=80=9D?

5. Binary data
...
A blob that is not referenced by a JMAP= object (e.g. as a message attachment), MAY be deleted by the s= erver to free up resources.
I think the comma before =E2= =80=9CMAY=E2=80=9D is not needed.

6.1. The StateChange object
   o  *trigger*: "String" What caused this change.=  The following causes are defined:
      *  "delivery": The arrival of a new message = caused the change.

Since JMAP is intended to be the foundation of data types beyond Mail,= perhaps this should say something besides =E2=80=9Cnew message=E2=80=9D = =E2=80=94 maybe =E2=80=9CThe cause of the change is delivery from an extern= al system or user=E2=80=9D.


Formatting nit-picks
PDF version - page 19 is very small = (list of IDs doesn=E2=80=99t wrap).

- Neil


_______________________________________________
Jmap mailing list

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


--_----------=_1527744396194600-- From nobody Wed May 30 23:25:13 2018 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 99E5112EC81 for ; Wed, 30 May 2018 23:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, T_DKIMWL_WL_MED=-0.01] 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 k7B0-ybVel1h for ; Wed, 30 May 2018 23:25:09 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2751B12EC66 for ; Wed, 30 May 2018 23:25:09 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id b74-v6so6799895pfl.5 for ; Wed, 30 May 2018 23:25:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neiljhaveri-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:to; bh=xmKm1ZWc6kOEqG6G/pE0Qc0KZrGeQujPzMcYNOYfkFE=; b=REzDpLZ6TLOd5TnCmxpuOXiAQB7CSxtGUHhsxoy38pdMfQBOrhxtT/Gd6+2NhmxRdg snBZtYiPnsUHdR14C0LgOTXWjWZyI2C72OLpoVpcgeWXj9h4RdNMxHrz3oz7PI1yEdSN jBYIE2KIW3RM2FNz+0cd3BeAe7F1zYh1dj7xt12nl7funr2nbbQT+efJI9dkz3reMFNj bEq84IwI7+vCiR/V2lYP+GPEJDXzx5IihRvo5gsA+gZt8sAKl5pC0Lni0B2RqP1S0+gc 78x3xin7VsTxR+qTUeRDE0g0tub9Cuo/rS6CIqce+WiWt1QjUPkx97dNuxkj+B7bECs3 BZ5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=xmKm1ZWc6kOEqG6G/pE0Qc0KZrGeQujPzMcYNOYfkFE=; b=ex3I8TATpID3Nd1wlGzRGBcKSc7QZjlFy2SskVT1FpNA5Z6nmK7ybeHMLj1CjqNSS4 prwzvSjkcg3NJGHL/9Wb/rxMQuxq/PdmQON2z7HjDjgAPNgDzQ8Y6C5PODh9b9bcCWx7 BmkIDdi0AxI9yMRkd5ZXLOmShteIGoLlK3KDhlW2D/ogekuNqZ43HV/vCFYPkS/5pA3S jIoyVmc0DePn7dUlRxBvvcOnIuRnBxs3iG9G7ln3JLxGfFn+uTXQ91b+nQ/kIMQSoq3M whpJlWX2r52IXCZMta9L1lWQqn/ME0TKfig2Aum6yHeCYKxmy+SORzDU8Bxz/VUFnfQT FR4w== X-Gm-Message-State: ALKqPwdfyvCjciMpLqPP/ji4ydYrDaF/KpuTFQ36vJFG8y66vvH1ajYS S18hxcC5FTV42Mu36voPrIjFb4fFoNY= X-Google-Smtp-Source: ADUXVKKSRyyCz+OHzXeStkz/Rw//SupKjX9BATko/k0A61i2Teluc5NClGql8PQ4cAY5GgYFNrWc5A== X-Received: by 2002:a62:8a5b:: with SMTP id y88-v6mr5601333pfd.103.1527747908320; Wed, 30 May 2018 23:25:08 -0700 (PDT) Received: from [192.168.1.14] (ip70-190-168-77.ph.ph.cox.net. [70.190.168.77]) by smtp.gmail.com with ESMTPSA id g4-v6sm19161933pfg.38.2018.05.30.23.25.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 May 2018 23:25:07 -0700 (PDT) From: Neil Jhaveri Content-Type: multipart/alternative; boundary="Apple-Mail=_01720DE2-A59F-4307-892A-FBC85CE79369" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Message-Id: <77C4AF98-B3B6-4C18-AFAE-A63EDAB00DF6@neiljhaveri.com> Date: Wed, 30 May 2018 23:25:05 -0700 To: IETF JMAP Mailing List X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: [Jmap] Review of draft-ietf-jmap-mail-05 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, 31 May 2018 06:25:12 -0000 --Apple-Mail=_01720DE2-A59F-4307-892A-FBC85CE79369 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all,=20 Here are my comments from reading draft-ietf-jmap-mail-05, which looks = great so far! Apologies again if I=E2=80=99m re-hashing anything already = extensively discussed. > 1.1. Notational conventions > ... > Types signatures are given for all JSON objects in this document=E2=80=A6= Since this document is presumably dependent upon JMAP Core, can we = reference it and avoid repeating the same 4 conventions? Something like = "Type signatures are given for all JSON objects in this document. The = conventions follow those in Section 1 of [RFC XXXX]=E2=80=9D. > 2. Mailboxes > =E2=80=A6 > Servers SHOULD forbid sibling Mailboxes with the same name. Should this be be a MUST? I thought this is expressly forbidden in IMAP = - RFC 3501 6.3.3. says "It is an error to attempt to create INBOX or a = mailbox with a name that refers to an extant mailbox=E2=80=9D. > 2. Mailboxes > .. > o *sortOrder*: =E2=80=A6 SHOULD take into account locale-specific = character order > convention.. There should only be one period after convention, not two. > 4.1.2. Header fields > ... > o *Addresses* ("EmailAddress[]") The header is parsed as an = "address-list" value, as specified in [RFC5322] section 3.4, into the = "EmailAddress[]" type. The *EmailAddress* object has the following = properties: > * *name*: "String|null" The _display-name_ of the [RFC5322] = _mailbox_ or _group_, or "null" if none. [...] > * *email*: "String|null" The _addr-spec_ of the [RFC5322] = _mailbox_, or "null" if a _group_. It looks like Bron & N. Jenkins traded comments about this on the list = in February, but the outcome didn=E2=80=99t seem conclusive to me, so = I=E2=80=99ll bring this up again. Is the current definition of EmailAddress object doesn=E2=80=99t seem = sufficient to cover an RFC 5322 Group Address? e.g.: To: A Group:Ed Jones ,joe@where.test,John ; I don=E2=80=99t see how this group address can get mapped into = EmailAddress[] as defined currently?=20 I think perhaps a *groupMembers*: =E2=80=9CEmailAddress[]|null=E2=80=9D = property needs to be added to EmailAddress. > 4.1.2. Header fields > =E2=80=A6 > Any syntactically correct [RFC2047] encoded sections with a known = encoding MUST be decoded, following the same rules as for the _Text_ = form... It looks to me like the indentation of this entire section is 1 level = too low? The same issue applies to the comment right after the = *MessageIds* property definition. Ditto for *URLs*. > 4.1.2. Header fields =20 > ... > In addition, the client may request/send properties representing = individual header fields of the form: >=20 > header:{header-field-name} >=20 > Where "{header-field-name}" means any series of one or more printable = ASCII characters (i.e. characters that have values between 33 and 126, = inclusive), except colon.=20 I am not really sure what the conventions are... would this be better = expressed with ABNF, or is this textual explanation sufficient? > 4.1.3. Body parts > =E2=80=A6 > The following *Email* properties are specified for access to the = body > data of the message: >=20 > o *bodyStructure*: "EmailBodyPart" (immutable) This is the full = MIME > structure of the message body, including sub parts but not > recursing into "message/rfc822" or "message/global" parts. When I first read this, I was a little confused by the text =E2=80=9Cinclu= ding sub parts=E2=80=9D, and thought maybe it meant that the tree of = parts was flattened into a single array. If others also found this = confusing, maybe it could be clarified into something like this: This is the full MIME structure of the message body, represented as an = array of the message=E2=80=99s top-level MIME parts, without recursing = into =E2=80=9Cmessage/rfc822=E2=80=9D or =E2=80=9Cmessage/global=E2=80=9D = parts. Note that EmailBodyParts may have subParts if they are type = =E2=80=9Cmultipart/*=E2=80=9D. > o *bodyValues*: "String[BodyValue]" (immutable) This is a map = of... Should this be EmailBodyValue instead of BodyValue? > 4.1.3. Body parts > ... > MIME structures are arbitrary nested trees of documents, but the = majority of email clients present a model of an email body... This entire section is a solid in-depth explanation, but it comes after = the property definitions, so it read a little bit confusing to me, and = felt like the properties were being re-defined. I think it might be = worthwhile considering an edit where the high-level explanation of = MIME-tree-flattening comes before the list of Email properties, and then = in each property, add more detail as to what each one is, so that it = reads a bit more linearly and each property definition is a bit more = self-contained. Thoughts? > 4.1.3. Body parts > ... > o _attachedEmails_/_attachedFiles_: These provide a list of parts > that should be presented as "attachments" to the message. = Emails > are presented in a separate list so their contents may be easily > fetched via a back-reference with the "Email/parse" method in = the > same request, if the client wishes to.=20 Offering attachedEmails separately from attachedFiles comes at the = slight trade-off of possibly degrading the user fiction of attachments = being an ordered list (as we know it is in many MUAs). For instance, a = user could have composed a 4-part multipart/mixed message list this: 1: text/plain: =E2=80=9C=E2=80=A6. See my 2nd attachment=E2=80=9D 2: message/rfc822 3: application/octet-stream 4: application/octet-stream If we separate them out into two different properties, it=E2=80=99s = equally likely a MUA wishing to treated attachedEmails as file-like = attachments will present attachments as [3, 4, 2] or [2, 3, 4], and in = the first case, the meaning is distorted. Is it common in any MUA to have a UI where attached e-mails are = immediately displayed inline? Every one I have used displays it as a = separate file requiring user interaction to open =E2=80=94 so I = personally think it may be worthwhile considering consolidating back = down to a single attachedFiles property rather than having to have two = properties and merge them. Thoughts? > Pages 27 & 28 - PDF Version - extremely tiny=E2=80=A6 The array of all properties does not wrap. > 4.2. Email/get > =E2=80=A6 > The following properties are expected to be fast to fetch in a = quality implementation: Resent-XX are commonly shown by=20 > 4.4.1. Filtering > =E2=80=A6 > o *text*: "String" Looks for the text in emails. The server = SHOULD look up text in the _from_, _to_, _cc_, _bcc_, _subject_ header = fields of the message, and inside any "text/*" or other body parts that = may converted to text by the server. The server MAY extend the search = to any additional textual property. I think a =E2=80=9Cbe=E2=80=9D is missing between =E2=80=9Cmay=E2=80=9D = and =E2=80=9Cconverted=E2=80=9D > 4.4.1. Filtering > =E2=80=A6 > o *attachments*: "String" Looks for the text in the attachments of = the email. Server MAY handle text extraction when possible for the = different kinds of media. Server should probably be plural? > 4.7. Email/import > ... > The server MAY forbid two email objects with the same exact [RFC5322] = content, or even just with the same [RFC5322] Message-ID, to coexist = within an account. In this case, it MUST reject attempts to import an = email considered a duplicate with an "alreadyExists" SetError. =20 Allowing a rejection purely based on a Message-ID match seems a little = bit restrictive to me =E2=80=94 it=E2=80=99s author-generated, so I have = seen the global-uniqueness requirement violated by naively written = scripts.=20 Why not just force the rejection to be based on a full RFC5322 content = match? Would it be that much more work for a server? Presumably = Message-ID and Size are easily accessible metadata, so those can be = checked fast, and then if there is a hit, an exact byte comparison can = happen (the real added penalty?). If we do tighten this up, then 4.8 Email/copy has a similar =E2=80=9Ceven = just with the same [RFC5322] Message-ID=E2=80=9D clause. > 5. Email Submission > =E2=80=A6 > o *identityId*: "String" (immutable) The id of the identity to = associate with this submission. It=E2=80=99s a little bit confusing that Identity is used here before = it=E2=80=99s defined in section 6. Maybe a slight note?=20 > 5. Email Submission > * *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 email as invalid = but otherwise MUST take the first 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. Instead of silently swapping the user=E2=80=99s requested _From_ to the = identity address, I'd prefer returning a "forbiddenFrom=E2=80=9D error = and give the user a chance to correct their mistake. Thoughts? > 5. Email Submission > =E2=80=A6=20 > For emails 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: >=20 > + A 3-digit SMTP reply code, as defined in [ > RFC5321], section > + 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. Not very familiar with the conventions here, but would ABNF be more = appropriate to specify this?=20 > 5.5 EmailSubmission/set > Standard _/set_ method, with the following two extra arguments: > o *onSuccessUpdateEmail*:... I think a lot of clients will want to move the message from Draft to = Sent using this block. It might be worth explicitly calling that out, or = even giving a full example. Thoughts? > 7. Search Snippets > =E2=80=A6 > o *attachments*: "String|null" If text from the filter matches the = text extracted from an attachment, this is the relevant section of the = attachment (converted to plain text), with matching words/phrases = wrapped in "" tags. It MUST NOT be bigger than 255 octets = in size. If it does not match, this is "null". I could imagine a MUA wanting to present to the user exactly which = attachment the search string was found in, so it might be worth = including an attachment ID property. Thoughts?=20 > 8. Vacation Response > The *VacationResponse* object represents the state of = vacation-response related settings for an account. It has the following = properties: I=E2=80=99m not too knowledgeable about prior work here, but: 1. Exchange Server offers the ability to configure a separate = =E2=80=9CInternal" and =E2=80=9CExternal" vacation response =E2=80=94 = which is useful if you work in a large organization and want to have = your internal reply include things like =E2=80=9Cyou can contact my = manager at XXX=E2=80=9D, but you want your external client-facing = response to expose less information. 2. I also think that there may need to be some mention of loop = prevention =E2=80=94 so that two accounts with vacation responses = don=E2=80=99t continuously reply to each other.=20 I am starting to think this should be deferred to a JMAP extension, so = that prior work in this area can be more carefully considered (such as = RFC 5230). Thoughts? - Neil= --Apple-Mail=_01720DE2-A59F-4307-892A-FBC85CE79369 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = all, 

Here are = my comments from reading draft-ietf-jmap-mail-05, which looks great so = far! Apologies again if I=E2=80=99m re-hashing anything already = extensively discussed.

1.1.= Notational conventions
...
Types signatures are given for all JSON = objects in this document=E2=80=A6
Since = this document is presumably dependent upon JMAP Core, can we reference = it and avoid repeating the same 4 conventions?  Something like = "Type signatures are given for all JSON objects in this document. The = conventions follow those in Section 1 of [RFC XXXX]=E2=80=9D.

2. Mailboxes
=E2=80=A6
Servers SHOULD forbid sibling Mailboxes with the same = name.
Should this be be a MUST? I thought this = is expressly forbidden in IMAP - RFC 3501 6.3.3. says "It is an error to = attempt to create INBOX or a mailbox with a name that refers to an = extant mailbox=E2=80=9D.

2. = Mailboxes
..
   o  *sortOrder*: =E2=80=A6 SHOULD take into = account locale-specific character order
  =     convention..
There= should only be one period after convention, not two.


4.1.2. Header fields
...
   o  *Addresses* = ("EmailAddress[]") The header is parsed as an "address-list" value, as = specified in [RFC5322] section 3.4, into the "EmailAddress[]" type. =  The *EmailAddress* object has the following = properties:
      *  *name*: "String|null" The = _display-name_ of the [RFC5322] _mailbox_ or _group_, or "null" if none. =  [...]
      *  *email*: = "String|null" The _addr-spec_ of the [RFC5322] _mailbox_, or "null" if a = _group_.

It looks = like Bron & N. Jenkins traded comments about this on the list in = February, but the outcome didn=E2=80=99t seem conclusive to me, so = I=E2=80=99ll bring this up again.

Is the current definition of = EmailAddress object doesn=E2=80=99t seem sufficient to cover an RFC 5322 = Group Address? e.g.:
To: A Group:Ed = Jones <c@a.test>,joe@where.test,John <jdoe@one.test>;

I don=E2=80=99t see how this group = address can get mapped into EmailAddress[] as defined = currently? 

I think perhaps a *groupMembers*: =E2=80=9CEmailAddress[]|null=E2= =80=9D property needs to be added to EmailAddress.


4.1.2. = Header fields
=E2=80=A6
   Any syntactically correct = [RFC2047] encoded sections with a known encoding MUST be decoded, = following the same rules as for the _Text_ = form...
It looks to me like the = indentation of this entire section is 1 level too low?  The same = issue applies to the comment right after the *MessageIds* property = definition. Ditto for *URLs*.

4.1.2. Header fields =   
...
In addition, = the client may request/send properties representing individual header = fields of the form:

                =         header:{header-field-name}

Where = "{header-field-name}" means any series of one or more printable ASCII = characters (i.e. characters that have values between 33 and 126, = inclusive), except colon. 
I = am not really sure what the conventions are... would this be better = expressed with ABNF, or is this textual explanation = sufficient?


4.1.3. Body parts
=E2=80=A6
  =  The following *Email* properties are specified for access to the = body
   data of the message:

   o =  *bodyStructure*: "EmailBodyPart" (immutable) This is the full = MIME
      structure of the message = body, including sub parts but not
      recursing into "message/rfc822" or = "message/global" parts.
When I = first read this, I was a little confused by the text =E2=80=9Cincluding = sub parts=E2=80=9D, and thought maybe it meant that the tree of parts = was flattened into a single array. If others also found this confusing, = maybe it could be clarified into something like this:
This is the full MIME structure of the message body, = represented as an array of the message=E2=80=99s top-level MIME parts, = without recursing into =E2=80=9Cmessage/rfc822=E2=80=9D or = =E2=80=9Cmessage/global=E2=80=9D parts. Note that EmailBodyParts may = have subParts if they are type =E2=80=9Cmultipart/*=E2=80=9D.

   o  *bodyValues*: "String[BodyValue]" (immutable) This is a map = of...
Should this be EmailBodyValue instead of = BodyValue?


4.1.3. Body parts
...
MIME structures are arbitrary nested = trees of documents, but the majority of email clients present a model of = an email body...
This entire section is a solid in-depth explanation, but it = comes after the property definitions, so it read a little bit confusing = to me, and felt like the properties were being re-defined. I think it = might be worthwhile considering an edit where the high-level explanation = of MIME-tree-flattening comes before the list of Email properties, and = then in each property, add more detail as to what each one is, so that = it reads a bit more linearly and each property definition is a bit more = self-contained. Thoughts?

4.1.3. Body parts
...
   o =  _attachedEmails_/_attachedFiles_: These provide a list of = parts
      that should be presented = as "attachments" to the message.  Emails
  =     are presented in a separate list so their contents may be = easily
      fetched via a = back-reference with the "Email/parse" method in the
      same request, if the client wishes = to. 
Offering attachedEmails separately from attachedFiles comes = at the slight trade-off of possibly degrading the user fiction of = attachments being an ordered list (as we know it is in many MUAs). For = instance, a user could have composed a 4-part multipart/mixed message = list this:
1: text/plain: =E2=80=9C=E2=80= =A6. See my 2nd attachment=E2=80=9D
= 2: message/rfc822
= 3: application/octet-stream
= 4: application/octet-stream

If we separate them out into two = different properties, it=E2=80=99s equally likely a MUA wishing to = treated attachedEmails as file-like attachments will present attachments = as [3, 4, 2] or [2, 3, 4], and in the first case, the meaning is = distorted.

Is = it common in any MUA to have a UI where attached e-mails are immediately = displayed inline? Every one I have used displays it as a separate file = requiring user interaction to open =E2=80=94 so I personally think it = may be worthwhile considering consolidating back down to a single = attachedFiles property rather than having to have two properties and = merge them. Thoughts?

Pages 27 & 28 - PDF = Version - extremely tiny=E2=80=A6
The array of all = properties does not wrap.


4.2. Email/get
=E2=80=A6
  =  The following properties are expected to be fast to fetch in a = quality implementation:
Resent-XX are commonly = shown by 


4.4.1. Filtering
=E2=80=A6
   o  *text*: "String" Looks = for the text in emails.  The server SHOULD look up text in the = _from_, _to_, _cc_, _bcc_, _subject_ header fields of the message, and = inside any "text/*" or other body parts that may = converted to text by the server.  The server MAY extend the = search to any additional textual property.
I = think a =E2=80=9Cbe=E2=80=9D is missing between =E2=80=9Cmay=E2=80=9D = and =E2=80=9Cconverted=E2=80=9D

4.4.1. Filtering
=E2=80=A6
   o  *attachments*: "String" = Looks for the text in the attachments of the email.  Server MAY handle text extraction when possible for the = different kinds of media.
Server = should probably be plural?

4.7.= Email/import
...
The server = MAY forbid two email objects with the same exact [RFC5322] content, or = even just with the same [RFC5322] Message-ID, to coexist within an = account.  In this case, it MUST reject attempts to import an email = considered a duplicate with an "alreadyExists" SetError.  
Allowing a rejection = purely based on a Message-ID match seems a little bit restrictive to me = =E2=80=94 it=E2=80=99s author-generated, so I have seen the = global-uniqueness requirement violated by naively written = scripts. 

Why not just force the rejection to be based on a full = RFC5322 content match? Would it be that much more work for a server? = Presumably Message-ID and Size are easily accessible metadata, so those = can be checked fast, and then if there is a hit, an exact byte = comparison can happen (the real added penalty?).

If we do tighten this up, then 4.8 = Email/copy has a similar =E2=80=9Ceven just with the same [RFC5322] = Message-ID=E2=80=9D clause.

5. = Email Submission
=E2=80=A6
   o  *identityId*: "String" (immutable) The = id of the identity to associate with this = submission.
It=E2=80=99s a little bit confusing = that Identity is used here before it=E2=80=99s defined in section 6. = Maybe a slight note? 

5. = Email Submission
  * =  *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 email as = invalid but otherwise MUST take the first 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.
Instead = of silently swapping the user=E2=80=99s requested _From_ to the identity = address, I'd prefer returning a "forbiddenFrom=E2=80=9D error and give = the user a chance to correct their mistake. Thoughts?

5. Email Submission
=E2=80=A6 
  =        For emails 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
        =  +  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.
Not very = familiar with the conventions here, but would ABNF be more appropriate = to specify this? 

5.5 = EmailSubmission/set
  =  Standard _/set_ method, with the following two extra = arguments:
   o =  *onSuccessUpdateEmail*:...
I= think a lot of clients will want to move the message from Draft to Sent = using this block. It might be worth explicitly calling that out, or even = giving a full example.  Thoughts?

7. Search Snippets
=E2=80=A6
   o =  *attachments*: "String|null" If text from the filter matches the = text extracted from an attachment, this is the relevant section of the = attachment (converted to plain text), with matching words/phrases = wrapped in "<mark></mark>" tags.  It MUST NOT be bigger = than 255 octets in size.  If it does not match, this is = "null".
I could imagine a MUA = wanting to present to the user exactly which attachment the search = string was found in, so it might be worth including an attachment ID = property. Thoughts? 

8. = Vacation Response
The = *VacationResponse* object represents the state of vacation-response = related settings for an account.  It has the following = properties:
I=E2=80=99m not too knowledgeable = about prior work here, but:
1. Exchange Server offers the = ability to configure a separate =E2=80=9CInternal" and =E2=80=9CExternal" = vacation response =E2=80=94 which is useful if you work in a large = organization and want to have your internal reply include things like = =E2=80=9Cyou can contact my manager at XXX=E2=80=9D, but you want your = external client-facing response to expose less information.
2. I also think that there may need to be some mention of = loop prevention =E2=80=94 so that two accounts with vacation responses = don=E2=80=99t continuously reply to each other. 

I am starting to think = this should be deferred to a JMAP extension, so that prior work in this = area can be more carefully considered (such as RFC 5230). = Thoughts?

- Neil
= --Apple-Mail=_01720DE2-A59F-4307-892A-FBC85CE79369--