From nobody Wed Jun 14 19:21:33 2017 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C072D12943B for ; Wed, 14 Jun 2017 19:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.718 X-Spam-Level: X-Spam-Status: No, score=-2.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=2C8u29KH; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JSmxQoCD 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 dTDhMe-gOmJG for ; Wed, 14 Jun 2017 19:21:30 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 995F0128D69 for ; Wed, 14 Jun 2017 19:21:30 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 1222720AB6 for ; Wed, 14 Jun 2017 22:21:30 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Wed, 14 Jun 2017 22:21:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=xW6QT/qKDGgUxNGCt7M/wh3PD9b2g D4aEb+zqISxja8=; b=2C8u29KHNveudjJC96Y3HL8mFY8sxQiVxj7W/mknWvj5d iHIPW+VuEdAdmQ80aIc1/T5Lv6dbBFQXIBFBtiAQMzXXV2zPeoN7+WcG0O1Ak3FC 7IrKjiXnSTjqRgPR5onWNgKEbhZmyE9Vlm5tur4iJgTdkp2gtTCOD+SBL1kZrWW1 8zsLcKmW0sUBAsy7EugQReaKqu1JxbR9PnKEfYVe1lsgc8SkmIIe0xXOe2GSOnnA yysRm1NUNBfmpgSuEoed4HvZWgxr2Tkla0k0LA8SRxswCQ9UAlf//mX2Q3HQA+0j pTypA+qU3xMi1wd28UPsaRf3tHNgR70NuJTwII/Ig== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=xW6QT/ qKDGgUxNGCt7M/wh3PD9b2gD4aEb+zqISxja8=; b=JSmxQoCD4ThrUgvRHMrjK/ 3P2uNh7yzS3fJkaR2QcIDVOsSzdmJoubjCZ5QzpHXV18wCYqVluL7Mew2Rh40/qj +Nbwfq05/RfeVNyJ9XcKLE7P8Xl4HQw2QipMUzJ/+KpD253i3C6EfDkFxywgKXEB PmjPibONH+YltJbmwoWJOa8VaNgFLNpLWcaH0dXusHaFDDEzHB7viITX6e1CWm6G +VPWTKs45g7OsRTAxurf9iCIdAtZrrYW4Cqx4QF9bCPUo8J7On2rOne89OjSdgNk fyiSOyrsyxopHHNNTpx9pxyiYE2r8HbqwL4/7QLbbLgqCcZht3fCJ4Ae/32hRY3Q == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id BC708E28E9; Wed, 14 Jun 2017 22:21:29 -0400 (EDT) Message-Id: <1497493289.1841083.1009922936.5BAEB289@webmail.messagingengine.com> From: Neil Jenkins To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_149749328918410830" X-Mailer: MessagingEngine.com Webmail Interface - ajax-72d83a02 References: <148716911729.17277.15371202023742081890.idtracker@ietfa.amsl.com> <9eb1fd3c-8868-9d24-6c30-46d333b69fef@isode.com> <3c1711a2-46dd-db1c-506e-5e1ad89ce56d@linagora.com> <92769755-62c6-7257-ce3d-7d0b5699735d@isode.com> <27c62cc8-68e0-49b5-4900-34c26d7b4c6a@linagora.com> <1492581452.3025596.948906456.71780673@webmail.messagingengine.com> <1A7624AF-2FD9-4FE8-A29D-23BFADEED04B@apple.com> <1493360522.1171603.959013464.217C003E@webmail.messagingengine.com> Date: Thu, 15 Jun 2017 12:21:29 +1000 In-Reply-To: <1493360522.1171603.959013464.217C003E@webmail.messagingengine.com> Archived-At: Subject: Re: [Jmap] Adding the Message::isForwarded property 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, 15 Jun 2017 02:21:33 -0000 This is a multi-part message in MIME format. --_----------=_149749328918410830 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Fri, 28 Apr 2017, at 04:22 PM, Neil Jenkins wrote: > OK, I think we have consensus on this. I've made a pull request on > GitHub with the changes[1] for people to review. This has now been merged. > Firstly, I think we should map the 4 \System flags to $System in JMAP. > Using backslash is a real pain because it is an escape character in > JSON, so examples in the spec are confusing if nothing else! Changing > it to $ would make the system keywords consistent with the IANA > registered keywords, which I believe will be less confusing for > developers coming in without an IMAP background. The only issue would > be what to do if someone has added "$Flagged" etc. user keywords on an > IMAP server. This seems unlikely to be much of a real-world occurrence > to me, on the basis it would have been very confusing, but I think we > can just specify that these keywords are not visible over JMAP. This has been merged too, and the document metadata updated to say this "updates RFC 5788". I've not yet submitted the names to the IANA registry to be reserved from use in IMAP; I'll do this when we're closer to final status with the JMAP draft. > Secondly, matching the setting of the \Answered keyword, I've added a > section that the server SHOULD automatically set the $Forwarded > keyword if appropriate on send (the request that started this whole > thread!). This is looking at the X-Forwarded-Message-Id header though, > which as mentioned earlier in the thread is not a standard (it seems > it was first introduced by Thunderbird). The current draft references `X-Forwarded-Message-Id`, but should a Forwarded-Message- Id header perhaps be standardised? Neil. Links: 1. https://github.com/jmapio/jmap/pull/61/files --_----------=_149749328918410830 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
On Fri, 28 Apr 2017, at 04:22 PM, Neil Jenkins wrote:
OK, I think we have consensus on this. I've = made a pull reques= t on GitHub with the changes for people to review.

This has now been merged.

Firstly, I think we should map the 4 = \Sy= stem flags to $System in JMAP. Using backsl= ash is a real pain because it is an escape character in JSON, so examples i= n the spec are confusing if nothing else! Changing it to $ would make the s= ystem keywords consistent with the IANA registered keywords, which I believ= e will be less confusing for developers coming in without an IMAP backgroun= d. The only issue would be what to do if someone has added "$Flagged" etc. = user keywords on an IMAP server. This seems unlikely to be much of a real-w= orld occurrence to me, on the basis it would have been very confusing, but = I think we can just specify that these keywords are not visible over JMAP.<= br>

This has been merged too, and the document metadata updated to say thi= s "updates RFC 5788". I've not yet submitted the names to the IANA registry= to be reserved from use in IMAP; I'll do this when we're closer to final s= tatus with the JMAP draft.

Secondly, matching the setting of the \A= nswered keyword, I've added a section that the server SHOULD = automatically set the $Forwarded keyword if appropriate o= n send (the request that started this whole thread!). This is looking at th= e X-Forwarded-Message-Id header though, which as men= tioned earlier in the thread is not a standard (it seems it was first intro= duced by Thunderbird).

The current draft references `X-Forwarded-Message-Id`, but should a Fo= rwarded-Message-Id header perhaps be standardised?

Neil.
--_----------=_149749328918410830-- From nobody Thu Jun 15 03:36:15 2017 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C6E126C25 for ; Thu, 15 Jun 2017 03:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pnn5GM5M8kuT for ; Thu, 15 Jun 2017 03:36:13 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 09672120046 for ; Thu, 15 Jun 2017 03:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1497522972; d=isode.com; s=june2016; i=@isode.com; bh=L76XZnt16B7672ynHrcfJ2NEwtvPrfNs7aob4syWO7Q=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=RQ1EhHvzp9mMGSWb5lvq/ewGsfqtmkTRf9vHSYquFQEji6Kg850mkHfegCoV2k9q3AlPnq B0IJda3RbIoUaJuDo4m859AuzYHJ3yF5AwAAQi45F+BrQt45ajSEkdoXH2/LFMlv0DVUSr e/G0aFFwhMChlocgVSh9Hb4rkBYOmvk=; Received: from [10.215.149.46] ((unknown) [85.255.237.187]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 15 Jun 2017 11:36:12 +0100 X-SMTP-Protocol-Errors: NORDNS PIPELINING From: Alexey Melnikov X-Mailer: iPhone Mail (13G35) In-Reply-To: <1497493289.1841083.1009922936.5BAEB289@webmail.messagingengine.com> Date: Thu, 15 Jun 2017 11:54:51 +0100 Cc: jmap@ietf.org Message-Id: References: <148716911729.17277.15371202023742081890.idtracker@ietfa.amsl.com> <9eb1fd3c-8868-9d24-6c30-46d333b69fef@isode.com> <3c1711a2-46dd-db1c-506e-5e1ad89ce56d@linagora.com> <92769755-62c6-7257-ce3d-7d0b5699735d@isode.com> <27c62cc8-68e0-49b5-4900-34c26d7b4c6a@linagora.com> <1492581452.3025596.948906456.71780673@webmail.messagingengine.com> <1A7624AF-2FD9-4FE8-A29D-23BFADEED04B@apple.com> <1493360522.1171603.959013464.217C003E@webmail.messagingengine.com> <1497493289.1841083.1009922936.5BAEB289@webmail.messagingengine.com> To: Neil Jenkins MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Apple-Mail-7A2225A7-906C-405C-A5E9-2DF0BFB43C2B Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Jmap] Adding the Message::isForwarded property 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, 15 Jun 2017 10:36:14 -0000 --Apple-Mail-7A2225A7-906C-405C-A5E9-2DF0BFB43C2B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On 15 Jun 2017, at 03:21, Neil Jenkins wrote: >> Secondly, matching the setting of the \Answered keyword, I've added a sec= tion that the server SHOULD automatically set the $Forwarded keyword if appr= opriate on send (the request that started this whole thread!). This is looki= ng at the X-Forwarded-Message-Id header though, which as mentioned earlier i= n the thread is not a standard (it seems it was first introduced by Thunderb= ird). >=20 > The current draft references `X-Forwarded-Message-Id`, but should a Forwar= ded-Message-Id header perhaps be standardised? Yes. --Apple-Mail-7A2225A7-906C-405C-A5E9-2DF0BFB43C2B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On 15 Jun 2017, at 03:21, Neil Jenkins= <neilj@fastmail.com> wrote:=

Secondly, matching the setting of the \Answered keyword, I= 've added a section that the server SHOULD automatically set the $Forwarde= d keyword if appropriate on send (the request that started thi= s whole thread!). This is looking at the X-Forwarded-Message-Id header though, which as mentioned earlier in the thread is not a st= andard (it seems it was first introduced by Thunderbird).


The current draft references `X-Forwarded-Message-Id`, but should a For= warded-Message-Id header perhaps be standardised?

Yes.

= --Apple-Mail-7A2225A7-906C-405C-A5E9-2DF0BFB43C2B-- From nobody Tue Jun 20 20:53:03 2017 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA6BF131560 for ; Tue, 20 Jun 2017 20:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=sOTKE1FE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZEUl2QbM 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 aGcHotREBPcw for ; Tue, 20 Jun 2017 20:52:59 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87341126DFF for ; Tue, 20 Jun 2017 20:52:59 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id E153D20899 for ; Tue, 20 Jun 2017 23:52:58 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Tue, 20 Jun 2017 23:52:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=ItYzvYQn4JcVFtrJao5tVS927LjPmvBMWMjJ+whcFBc=; b=sOTKE1FE y/e2kCP9K1DGzwt0ism2z/5F2VsXY6OQDbUo/tCFQDrSPUeY5iMkAN40sifNWP7l bHKw6WjoqFQx81rTwQfOqxiz0/GDe876oqWYdQXfGgyLSQo8JtaJjIVgOW1T5Y6q TKdHQw9q1AdvXSxSnDr6vimmn5j373evXt5WbWS0kRKtGv7MqzSAqYxDwlHhD22M aiuLCEDb729n3zD1QAvaqg75dpH0cCrq5rDfCG9DdlwzgoIN4DciOb93nY0iZx7P 2zn6jEBik8AVT60bBq9EvceM7rWU/+vPyhb7WBgGuVd0zpIf0JmeMMW2se4og3gF j26G+jTR3zA9YA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=ItYzvYQn4JcVFtrJao5tVS927LjPm vBMWMjJ+whcFBc=; b=ZEUl2QbMsb0zxGQ3J52CcTBsYjSWTbcI/xUIKmiZLQ916 FQYhVvp7PgixcA73zCqg8K1+8XiTx2N/qRQqK669pIeleLTbQdiLQ5M3216XT+V4 PzBu7Os32lRT6wruXJosNzgBQWykgNuqs81vEOf1nGGLZuMpLBCDge8zbGxbbmrm EuPM8mMhmIv+wWZtQLMZZt9Twkil08n/rUs/CAsDPFQKHqyOsyybcVc3CXJceBU2 3+yJzeVlUcbVthDsLu9kOXXokawVDpW8BHh+UP4YIgElWzo4D5Z0im/lDhdKEGAj lzSSNtSdjIjB4795gjqiqY/L31/f57uA8FSoQZUYA== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 8C6A8E2503; Tue, 20 Jun 2017 23:52:58 -0400 (EDT) Message-Id: <1498017178.1304756.1016181400.0FCF0683@webmail.messagingengine.com> From: Neil Jenkins To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_149801717813047560" X-Mailer: MessagingEngine.com Webmail Interface - ajax-3794775e X-Priority: 1 (High) Importance: high Date: Wed, 21 Jun 2017 13:52:58 +1000 Archived-At: Subject: [Jmap] JMAP Conceptual Decisions X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 03:53:03 -0000 This is a multi-part message in MIME format. --_----------=_149801717813047560 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The core JMAP protocol has a number of conceptual decisions. Here are the choices we made in the initial design and the reasons behind them, so it's all documented on this mailing list. The core conceptual decisions, I think, are: * Use of HTTP + JSON * Separate end points for binary data upload/download * Concurrency model * Structure of request/response as array of [ method-name, data, tag ] tuples Why use HTTPS/JSON? The short answer is it's good enough, widely understood and it's by far the easiest thing for developers to adopt. There's support in basically all OSes and programming languages. It's easy to read and debug.HTTP doesn'= t tend to run into firewall issues, and is so commonly used it has integrations which can help with optimisation (for example, iOS has built-in support for optimising radio usage by batching HTTP calls from different apps where possible, which Apple's mail team have said they would like to be able to use). This isn't an innate advantage of HTTP, but rather an advantage of its ubiquity.With GZIP, JSON data is reaso= nably compact and fast enough to serialise/parse. However, the encoding/transport part of JMAP is not core to its operation, so future specifications could easily add alternatives (e.g. WebSocket[1] instead of HTTPS, CBOR[2] instead of JSON). For the initial version though, HTTPS+JSON makes the most sense.Hand= ling of binary data Binary data is not transported in the JSON as it can't be without base64 encoding or similar, which is inefficient. Instead, binary blobs are always referenced by a blobId, and uploaded/downloaded separately via HTTPS. As it's out-of-band with the API calls, uploading/downloading files can easily be parallelised and doesn't block other API operations, so a client can remain responsive and make new API requests while uploading, for example, a large attachment concurrently.Clients can also re= ference the blobId elsewhere to, for example, attach the same file to a new message without having to download and reupload it again, a big win on slower internet connections. This also means that regularly saving drafts (a common client behaviour) does not mean sending the same full multi-megabyte attachments over the network every 60s or so, as happens with IMAP.Concurrency model Straight forward but worth mentioning. To ensure the client always sees a consistent view of the data, the state accessed by a method call MUST NOT change during the execution of the method, except due to actions by the method call itself.Concurrent requests are allowed (subject to a server= -defined limit), but the server must ensure that the above constraint is not violated. This is basically the minimum required for sane behaviour, while still giving the server wide flexibility in implementation.Structure of request/response JMAP does not use HTTP verbs for the API requests (everything goes over a POST request to a single end point). This decision was made primarily for efficiency, which is best illustrated by example:Suppose you are lookin= g at your inbox, and decide you want to move a message into a new mailbox which you will call "Invoices 2017". The client also needs to get the changes this results in to our query listing the ids of threads in the Inbox. I don't believe this is contrived; this functionality exists in many clients today.With the JMAP mo= del this is one HTTP request: POST /jmap-api/ [ [ "setMailboxes", { "create": { "clientId": { "name": "Invoices 2017" ... other properties elided ... } } }, "tag-0" ], [ "setMessages", { "update": { "msg123": { "mailboxes": [ "#clientId" ] } } }, "tag-1"], [ "getMessageListUpdates", { "filter": { "inMailbox": "inboxId" }, "sort": [ "date desc" ], "collapseThreads": true, "sinceState": "deadbeef", "maxChanges": 50 }, "tag-2"] ]which would return = something like: 200 OK [ [ "mailboxesSet", { "accountId": "foo", "oldState": "x1234", "newState" "x1237", "created": { "clientId": { "id": "mbox98" ... other server-set properties elided ... } } }, "tag-0" ], [ "messagesSet", { "accountId": "foo", "oldState": "mx987", "newState" "mx7141", "updated": { "msg123": null } }, "tag-1"], [ "messageListUpdates", { "accountId": "foo", "filter": { "inMailbox": "inboxId" }, "sort": [ "date desc" ], "collapseThreads": true, "oldState": "deadbeef", "newState": "12345678", "total": 587120, "removed": [ { "messageId": "msg123", "threadId": "thd17" } ], "added": [] }, "tag-2"] ]This example illustrates a few things: * Arbitrary bundling of methods into a single HTTP request lets you minimise round trips, while being flexible and easy to implement. * Methods are processed in order, so you have a guarantee that the message will be modified before the message list updates are calculated. * Use of back references (the message is set to move to mailbox with id #clientId =E2=80=93 this is not the real, server-assigned id, but the id= the client gave the server to keep track of it for the duration of this request. It is trivial for the server to keep a map of clientId -> real id for each record it creates for the duration of HTTP request (it can then throw this away; it does not need to persist it). Forward references not allowed! * The third item in the tuple for each method request is an arbitrary "tag" given by the client, which is just echoed back in the response. Although none do in this example, a method may return multiple responses, so this allows them to be correlated with requests if necessary. (Note a lot of the time you may not even need this: our client mainly just handles the responses based on the "name" of the response; it doesn't care who called or why).Now, let's look at what thi= s same exchange might look like with a more traditional REST style: POST /mailboxes/ { "name": "Invoices 2017" ... other properties elided ... }which might return: 201 Created { "id": "mbox98" } and then you can do: PATCH /messages/msg123 { "mailboxes": [ "mbox98" ] }wait for the response, = and finally do GET /messagelist/updates?filter=3D{"inMailbox":"inboxId"}&sort=3Ddatedesc&c- ollapsethreads=3Dtrue&sinceState=3Ddeadbeef&maxChanges=3D50(Yeh, not sure a= bout that one; I don't think many REST APIs have a concept of delta updates to query results.)We needed three round trips to d= o the same thing. When round trip times are 300ms or more (such as Australia talking to East Coast US, or just many cellular connections), this is a really noticeable performance hit.Wit= h HTTP/2 you could maybe use dependent streams to parallelise the latter two requests, but this is more complicated for both client and server authors, and has far less support out there (as far as I know you couldn't do this from a browser for example). You still have to wait for the first request to complete even with dependent streams, because you can't do the backreferences (if you did, how long does the server have to hold on to them? Forever? There's no neat method bundle like with the JMAP API request format).This example didn't even do batching of changes to= multiple records. Suppose you wanted to move 10 messages to that new folder, it's still 3 method calls and 1 HTTP request in JMAP. With HTTP you now have an extra 9 requests. Even with HTTP/2 to reduce the transport overhead, you would still have to work much harder to make the server efficient (you will need to take out locks on some data before you can make the changes: for efficiency you want to do this once and modify all 9 items then release the locks).I hope I have illustrated the reasoning behind the format we cho= se when designing the current JMAP draft. Compared to HTTP REST, I believe it is: * More efficient * More consistent (can do batching, or non standard CRUD such as importMessages/copyMessages methods, all in the same style) * Just as easy to use, if a little unfamiliar at first * Not tied to HTTP (as mentioned above, WebSockets or other future transport may be desired in the future). Neil. Links: 1. https://tools.ietf.org/html/rfc6455 2. http://tools.ietf.org/html/rfc7049 --_----------=_149801717813047560 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
The core JMAP protocol has a number of conceptual decisions. Her= e are the choices we made in the initial design and the reasons behind them= , so it's all documented on this mailing list.

The core conceptual decisions, I think, a= re:
  • Use of HTTP + JSON
  • Separate end points for binary data = upload/download
  • Concurrency model
  • Structure of requ= est/response as array of [ method-name, data, tag ] tuples

Why use HTTPS/JSON?
=

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

<= p>HTTP doesn't tend to run into firewall issues, and is so commonly used it= has integrations which can help with optimisation (for example, iOS has bu= ilt-in support for optimising radio usage by batching HTTP calls from diffe= rent apps where possible, which Apple's mail team have said they would like= to be able to use). This isn't an innate advantage of HTTP, but rather an = advantage of its ubiquity.

With GZIP, JSON data is reasonably com= pact and fast enough to serialise/parse. However, the encoding/transport pa= rt of JMAP is not core to its operation, so future specifications could eas= ily add alternatives (e.g. = WebSocket instead of HTTPS, CBOR instead of JSON). For the initial version though, HTTPS+JSON m= akes the most sense.

= Handling of binary data

Binary data is not transporte= d in the JSON as it can't be without base64 encoding or similar, which is i= nefficient. Instead, binary blobs are always referenced by a blobId, and up= loaded/downloaded separately via HTTPS. As it's out-of-band with the API ca= lls, uploading/downloading files can easily be parallelised and doesn't blo= ck other API operations, so a client can remain responsive and make new API= requests while uploading, for example, a large attachment concurrently.

Clients can also reference the blobId elsewhere to, for example, at= tach the same file to a new message without having to download and reupload= it again, a big win on slower internet connections. This also means that r= egularly saving drafts (a common client behaviour) does not mean sending th= e same full multi-megabyte attachments over the network every 60s or so, as= happens with IMAP.

= Concurrency model

Straight forward but worth mentioning. To = ensure the client always sees a consistent view of the data, the state acce= ssed by a method call MUST NOT change during the execution of the method, e= xcept due to actions by the method call itself.

Concurrent reques= ts are allowed (subject to a server-defined limit), but the server must ens= ure that the above constraint is not violated. This is basically the minimu= m required for sane behaviour, while still giving the server wide flexibili= ty in implementation.

= Structure of request/response

JMAP does not use= HTTP verbs for the API requests (everything goes over a POST = request to a single end point). This decision was made primarily for effici= ency, which is best illustrated by example:

Suppose you are looki= ng at your inbox, and decide you want to move a message into a new mailbox = which you will call "Invoices 2017". The client also needs to get the chang= es this results in to our query listing the ids of threads in the Inbox. I = don't believe this is contrived; this functionality exists in many clients = today.

With the JMAP model this is one HTTP request:

=
POST /jmap-api/
[
    [ "setMailboxes", {
        "create": {
            "clientId": {
                "name": "Invoices 2017"
                ... other properties elided ...
            }
        }
    }, "tag-0" ],
    [ "setMessages", {
        "update": {
            "msg123": {
                "mailboxes": [ "#clientId" ]
            }
        }
    }, "tag-1"],
    [ "getMessageListUpdates", {
        "filter": {
            "inMailbox": "inboxId"
        },
        "sort": [ "date desc" ],
        "collapseThreads": true,
        "sinceState": "deadbeef",
        "maxChanges": 50
    }, "tag-2"]
]

which would return something like:

2=
00 OK
[
    [ "mailboxesSet", {
        "accountId": "foo",
        "oldState": "x1234",
        "newState" "x1237",
        "created": {
            "clientId": {
                "id": "mbox98"
                ... other server-set properties elided ...
            }
        }
    }, "tag-0" ],
    [ "messagesSet", {
        "accountId": "foo",
        "oldState": "mx987",
        "newState" "mx7141",
        "updated": {
            "msg123": null
        }
    }, "tag-1"],
    [ "messageListUpdates", {
        "accountId": "foo",
        "filter": {
            "inMailbox": "inboxId"
        },
        "sort": [ "date desc" ],
        "collapseThreads": true,
        "oldState": "deadbeef",
        "newState": "12345678",
        "total": 587120,
        "removed": [
            { "messageId": "msg123", "threadId": "thd17" }
        ],
        "added": []
    }, "tag-2"]
]

This example illustrates a few things:

  • A= rbitrary bundling of methods into a single HTTP request lets you minimise r= ound trips, while being flexible and easy to implement.
  • Methods= are processed in order, so you have a guarantee that the message will be m= odified before the message list updates are calculated.
  • Use of = back references (the message is set to move to mailbox with id #clien= tId =E2=80=93 this is not the real, server-assigned id, but the= id the client gave the server to keep track of it for the duration of this= request. It is trivial for the server to keep a map of clientId -> real= id for each record it creates for the duration of HTTP request (it can the= n throw this away; it does not need to persist it). Forward references not = allowed!
  • The third item in the tuple for each method request is= an arbitrary "tag" given by the client, which is just echoed back in the r= esponse. Although none do in this example, a method may return multiple res= ponses, so this allows them to be correlated with requests if necessary. (N= ote a lot of the time you may not even need this: our client mainly just ha= ndles the responses based on the "name" of the response; it doesn't care wh= o called or why).

Now, let's look at what this same exchang= e might look like with a more traditional REST style:

POS=
T /mailboxes/
{
    "name": "Invoices 2017"
    ... other properties elided ...
}

which might return:

201 Created
{
    "id": "mbox98"
}

and then you can do:

PATCH /messages=
/msg123
{
    "mailboxes": [ "mbox98" ]
}

wait for the response, and finally do

GET /messagelist/updates?filter=3D{"inMailbox":"inboxId"}&sort=3Ddate=
desc&collapsethreads=3Dtrue&sinceState=3Ddeadbeef&maxChanges=3D=
50

(Yeh, not sure about that one; I don't think many RES= T APIs have a concept of delta updates to query results.)

We need= ed three round trips to do the same thing. When round trip times are 300ms = or more (such as Australia talking to East Coast US, or just many cellular = connections), this is a really noticeable performance hit.

With H= TTP/2 you could maybe use dependent streams to parallelise the latter two r= equests, but this is more complicated for both client and server authors, a= nd has far less support out there (as far as I know you couldn't do this fr= om a browser for example). You still have to wait for the first request to = complete even with dependent streams, because you can't do the backreferenc= es (if you did, how long does the server have to hold on to them? Forever? = There's no neat method bundle like with the JMAP API request format).

This example didn't even do batching of changes to multiple records. S= uppose you wanted to move 10 messages to that new folder, it's still 3 meth= od calls and 1 HTTP request in JMAP. With HTTP you now have an extra 9 requ= ests. Even with HTTP/2 to reduce the transport overhead, you would still ha= ve to work much harder to make the server efficient (you will need to take = out locks on some data before you can make the changes: for efficiency you = want to do this once and modify all 9 items then release the locks).

I hope I have illustrated the reasoning behind the format we chose wh= en designing the current JMAP draft. Compared to HTTP REST, I believe it is= :
  • More efficient
  • More consistent (can do batching, or non= standard CRUD such as importMessages/copyMessages methods, all in the same= style)
  • Just as easy to use, if a little unfamiliar at first
  • Not tied to HTTP (as mentioned above, WebSockets or other future = transport may be desired in the future).

Neil.
--_----------=_149801717813047560-- From nobody Fri Jun 23 17:10:13 2017 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B610129B4D; Fri, 23 Jun 2017 17:07:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: jmap@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149826282317.7840.3592288981539912899.idtracker@ietfa.amsl.com> Date: Fri, 23 Jun 2017 17:07:03 -0700 Archived-At: Subject: [Jmap] jmap - Requested session has been scheduled for IETF 99 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, 24 Jun 2017 00:07:03 -0000 Dear Bron Gondwana, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. jmap Session 1 (1:00:00) Monday, Afternoon Session I 1330-1530 Room Name: Athens/Barcelona size: 100 --------------------------------------------- Special Note: 13:30-15:00 Request Information: --------------------------------------------------------- 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: 60 Conflicts to Avoid: First Priority: calext dmarc dcrup uta dispatch People who must be present: Barry Leiba Alexey Melnikov Neil Jenkins Bron Gondwana Resources Requested: Flipcharts: please specify number in Special Requests field Special Requests: 1 flipchart would be useful for drafting ideas --------------------------------------------------------- From nobody Sun Jun 25 18:57:56 2017 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F1212714F for ; Sun, 25 Jun 2017 17:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=S31+ayVl; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jdVuXygV 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 WdvigGTEyh8K for ; Sun, 25 Jun 2017 17:43:33 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B19631201F8 for ; Sun, 25 Jun 2017 17:43:33 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 0C1502088E for ; Sun, 25 Jun 2017 20:43:33 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Sun, 25 Jun 2017 20:43:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=HIJBGBCxIl6WhPQ0VCsd7aNn5O9y1qszmXkdyV3Gm x8=; b=S31+ayVlJwLY3/3LCoadszQqObr+RbKA0GZ2m5jJiN9QFuQrh01Th+S2/ ZnKiMQFk56uiqnrsiF+FTV7YbN3+wwep0xDqgWDTYp1MzlqrvdTFmXTX/XXHeVV4 iNd/gnPU7QLw+o6PmTWuFdTSs628Z+vzcmC8CFrq+kN2JO+KhOBLbwXdHJgi8hsC Vi+M9TODsn01LlmYaVlSmzUbmdsegQURqcW1Q+/BUWe1IHtuYKCrflNN2JAwPEyS KCuBRMxJRn8H+wBT2APDmKjaJ/SrASqBddCyyUozujCmasNz3pNpW+R4FSaa7ihX gpaXMfUUTOGGktQ3niI4jlqgyu+DQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=HIJBGBCxIl6WhPQ0VCsd7aNn5O9y1 qszmXkdyV3Gmx8=; b=jdVuXygVRXFXJDH77rIjNfepnXGRug3RCR6zdzQfbA/HG 6WGtuIU1Cmj4daN7xKK//pIhJFderZq7irLTYWs1UJQYhC4+D5neb1Yj0vkSVj64 J/mXKaeuvHkONXrMhkZdeiMRkoroGLA2vY1owg3OZt+bOqeX5DbuJjuCaXQoJLcx slnav56ux6o+Jw5GWaKOJcsw1Dpi8mRf9CMdpt7g+IS13mwEh0/LSzs0q3Cab+WC UJkUL9NU7D51mDjzui6vvoxsQIXeac5VGDxGj7RLfTfMaq6YzOI2hAvF6splkcQn oQ/1Mas3U8k6UGeJ1FoF+VXi0NlgewKbe1SjEZXLg== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id D2AF162701; Sun, 25 Jun 2017 20:43:32 -0400 (EDT) Message-Id: <1498437812.3554228.1020957248.1DCEFEE5@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-72841c42 Date: Mon, 26 Jun 2017 10:43:32 +1000 Archived-At: X-Mailman-Approved-At: Sun, 25 Jun 2017 18:57:54 -0700 Subject: [Jmap] Agenda uploaded X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 00:43:37 -0000 Hi All, I have just uploaded the following agenda for our session in Prague. We have a 90 minute session, so there's space for adding things if there's anything else you think needs talking about. I'd also like to start discussion on on the list for each important item before we get there, so we can use our time in the meeting for the extra bandwidth required to hash out compromises on competing ideas. In particular the parts that are not well defined yet - for core the extension mechanism is not settled, and authentication may need additional work. For mail, the main area of discussion was submission. I believe we got a conclusion on the list that everybody was happy with, so I'll follow up with Neil to make sure we have draft wording on that to discuss during this meeting, as well as an implementation in Cyrus and an implementation in the proxy. If there's anything missing here, please let me know - happy to modify the agenda to cover what people want to talk about! Bron. JMAP session agenda - IETF99 Prague - 2017-07-17 13:30 === Intro and Note Well: 5 min JMAP Core: 30 min * transport (json over http) 5 min * push mechanism 5 min * authentication 10 min * extension mechanisms 10 min JMAP Mail: 30 min * keywords 5 min * partial body fetch 5 min * submission 20 min Other business / github tickets: 25 min -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com From nobody Wed Jun 28 19:48:05 2017 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7C7126C22 for ; Wed, 28 Jun 2017 19:48:03 -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, 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=V1hGNBcf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=EusbAST3 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 HqdZgLAPPP1p for ; Wed, 28 Jun 2017 19:48:01 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88E3B12420B for ; Wed, 28 Jun 2017 19:48:01 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id EFC0320A11 for ; Wed, 28 Jun 2017 22:48:00 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Wed, 28 Jun 2017 22:48:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=R+1MqWcVeAl2iMDhy8gdFzuoeOx5x88N97vphrxpl SE=; b=V1hGNBcff4aSC7l6lY1h0AzMXrofRDupbolpEpdYGpLRJEkWoIGCECn2R 4p0VvE5PcWTYJJyEwkIcDMRZhUimx7esOB4Rudy5bxBt4w6jxvzdq0MbWfEnRjNK x73VW6TJYuMl8j63S0evWieKSb+z+M4A18p4Y5RKgORtXdCpBx0/edCBFZZZzOWz h28J2loCVVPLsgnkCj4NH4x5lFVKXHwR2GQCdTH8zFXnmx3QcYI4ycSsg2qqxgSO +jD/gV9V4nVHjX8CylzEH+ovFtUnVbm8HbDQz5PRk5K5te3VXR7FIi+s/6xYVD4n 3pyw6AcXohoUYyA4sPQRWJkOcT+gA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=R+1MqWcVeAl2iMDhy8gdFzuoeOx5x 88N97vphrxplSE=; b=EusbAST3Wk7DCSLercLlxhOmRE26KRWqpXNVBhsLQkY14 TXyhajNrc9297D6b9gyrEJu16OIvqvzq8rISzZcIujMSbq/4x6fMfpVFOmdg3ChK uY2tek+VlCngZg9WrtABHBowiiMW+kC0ZwrA9VNEAwdjWu5UaoAw56o6Fh/pOhbv 5NFPhmvY9RBVExnFwBCO9JiKjjq0LrwgBeFJcIoShS283YW94qjCCR0KWYcGHRK9 W5yT44aR4pAQlAGX4kxHpczn2oReKvYW87tEEnA50EK2mMup758TmAn0PEUarxFv hHEpp1leObvm1Hhio8vlEBRTIps8FXXtdbXSYjyjg== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id C14BE627BD; Wed, 28 Jun 2017 22:48:00 -0400 (EDT) Message-Id: <1498704480.172426.1024812712.03CD34C9@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-07d9e719 Date: Thu, 29 Jun 2017 12:48:00 +1000 X-Forwarded-Message-Id: Archived-At: Subject: [Jmap] Fwd: Cutoff date for requesting remote presentations support at IETF99 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, 29 Jun 2017 02:48:03 -0000 Hi JMAPpers, Is there anybody from this list planning to join us remotely? A reminder, our meeting is at 1:30pm Prague time on Monday 17th: https://www.timeanddate.com/worldclock/meetingdetails.html?year=2017&month=7&day=17&hour=11&min=30&sec=0&p1=204&p2=179&p3=152&iv=1800 That's a not-too-insane time of day for either East Coast USA or East Coast Australia :) Cheers, Bron. ----- Original message ----- From: Meetecho IETF support To: wgchairs@ietf.org Subject: Cutoff date for requesting remote presentations support at IETF99 Date: Wed, 28 Jun 2017 17:00:08 +0200 Dear chairs, if you plan to have remote _presentations_ in Prague, you're kindly requested to fill out the following form: https://ietf99.conf.meetecho.com/index.php/Remote_presentations *The cutoff date for remote presentations support requests is July 14.* You can also check scheduled remote presentations here: https://ietf99.conf.meetecho.com/list.php Thanks, the Meetecho team -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com