From nobody Tue Dec 3 06:07:40 2019 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 681B112004F; Tue, 3 Dec 2019 06:07:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Barry Leiba via Datatracker To: "The IESG" Cc: jmap-chairs@ietf.org, jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <157538205135.24843.17780384774128724876.idtracker@ietfa.amsl.com> Date: Tue, 03 Dec 2019 06:07:31 -0800 Archived-At: Subject: [Jmap] Barry Leiba's Yes on charter-ietf-jmap-02-00: (with COMMENT) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 14:07:32 -0000 Barry Leiba has entered the following ballot position for charter-ietf-jmap-02-00: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-jmap/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Actually, "Yes, but..." The concrete deliverables at the bottom include JSCalendar but not JSContact; please add one for the latter. That would make five concrete deliverables, of which only two (websockets and MDNs) have milestones listed. It would be nice to have milestones for the others. And there's a milestone for which there's no listed deliverable (the implementation guidance). I'm ambivalent here: does it make sense to list it as a deliverable? Or maybe it's better just to have it in the milestones, as there is a "catch-all" deliverable that will cover it. From nobody Wed Dec 4 21:44:00 2019 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 23A701200C4; Wed, 4 Dec 2019 21:43:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: jmap-chairs@ietf.org, jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <157552463810.11084.7481608655548872568.idtracker@ietfa.amsl.com> Date: Wed, 04 Dec 2019 21:43:58 -0800 Archived-At: Subject: [Jmap] Benjamin Kaduk's No Objection on charter-ietf-jmap-02-00: (with COMMENT) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 05:43:58 -0000 Benjamin Kaduk has entered the following ballot position for charter-ietf-jmap-02-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-jmap/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Barry basically captured what I was going to say, but I'll note explicitly that some of the removed milestones are not currently marked as "Done" and correspond to items for which "working group will deliver documents for the following"; that mismatch should probably be corrected. From nobody Thu Dec 5 02:03:22 2019 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 7A9A11200A4; Thu, 5 Dec 2019 02:03:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: jmap-chairs@ietf.org, jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <157554019646.16420.4850528172421116176.idtracker@ietfa.amsl.com> Date: Thu, 05 Dec 2019 02:03:16 -0800 Archived-At: Subject: [Jmap] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_charte?= =?utf-8?q?r-ietf-jmap-02-00=3A_=28with_COMMENT=29?= X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 10:03:16 -0000 Mirja Kühlewind has entered the following ballot position for charter-ietf-jmap-02-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-jmap/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Yes, please update milestones! From nobody Thu Dec 5 02:40:53 2019 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 1740B1200FD for ; Thu, 5 Dec 2019 02:40:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157554245208.16429.8486909988290417387.idtracker@ietfa.amsl.com> Date: Thu, 05 Dec 2019 02:40:52 -0800 From: IETF Secretariat Archived-At: Subject: [Jmap] Milestones changed for jmap WG X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 10:40:52 -0000 Changed milestone "Adopt a document for a JSON Contact format (after recharter)", set state to active from review, accepting new milestone. Changed milestone "Submit JSON Contact document to IESG", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/jmap/about/ From nobody Thu Dec 5 02:43:33 2019 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 C90A51209A4 for ; Thu, 5 Dec 2019 02:43:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157554260881.16398.13104185365784374853.idtracker@ietfa.amsl.com> Date: Thu, 05 Dec 2019 02:43:28 -0800 From: IETF Secretariat Archived-At: Subject: [Jmap] Milestones changed for jmap WG X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 10:43:31 -0000 Changed milestone "Submit JMAP over websockets document to the IESG", resolved as "Done". URL: https://datatracker.ietf.org/wg/jmap/about/ From nobody Thu Dec 5 03:34:56 2019 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 BE1AC120103; Thu, 5 Dec 2019 03:34:49 -0800 (PST) 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=uklGvXAw; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YfI4rGGk 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 dxvzRtIKKDli; Thu, 5 Dec 2019 03:34:47 -0800 (PST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC46D12004A; Thu, 5 Dec 2019 03:34:44 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id D399FA69; Thu, 5 Dec 2019 06:34:43 -0500 (EST) Received: from imap99 ([10.202.2.99]) by compute6.internal (MEProxy); Thu, 05 Dec 2019 06:34:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm1; bh=Llk8 wpPOfoYD80McwS9YpJQBHYdfZ62ZZFHeDOXiS74=; b=uklGvXAwh2KUSToUTnhV RKft68TfzLR7QKdtXmdoGJbpMmIlV7YI6GnXOZ2Ia0bRa5PaE2jQPrWxxsS/sshv AbkTWa4tcf5gja00lwVMvV81fvdtd0XVq4ETxVauSaAaq0hMAg1BI2LeK3H9Mb6x GiUnJjhHD6c8pru4Bd/wD1WXYM0lsIu/ImmZ0ET4pKMYanXxgtUevgnoWfZP+68s RGAAs+6aP/cod57rgu+fA2/l5Qonc9+8+876cv7cpTragKCHY4FmPkwVx3YHSq9B hDGaMb9NANSwXO7vD38oCYtOK30cYAk5raoXd1I8Z7oZVAnnbPGKHqVLpND5Dtnp DQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=Llk8wp POfoYD80McwS9YpJQBHYdfZ62ZZFHeDOXiS74=; b=YfI4rGGk+fOi9u/549AgN4 4tvniDzEb6/zqtTmmHWfNdaOCxDnkFiz4TkCgt2tYZl58wLLRFFX4gA3AXpi7n6B FsLJHqZtgsiW3U049Fef8tpDlNpwKPOv7NJ+bi4ZMtaanZE8wjojBprve7i9BHDt VylcLEw7FEkfOueUfEqaA/SU+UNaSXPx8G5O+vADPsRQjvvH4l+8GLqeItuFOhOZ ePSyobpetrXthjR4Hsdrsq7HdLvegaueSWmW6zfKUi9weu1knnGScT16AfnnHci/ LcOsKn3UnUZQID2w4SvLx8rVYpE5xgppJh3lVQX7rig7aia4EAqzQzDPLk9mtaMw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudekuddgfedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesmhdtreerreerjeenucfhrhhomhepfdeurhho nhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh eqnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpihgvthhfrdhorhhgnecurfgrrhgr mhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomhenuc evlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2504F30006F; Thu, 5 Dec 2019 06:34:43 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-612-g13027cc-fmstable-20191203v1 Mime-Version: 1.0 Message-Id: <999f2d6d-0d09-44b6-9b99-ca43774b045f@dogfood.fastmail.com> In-Reply-To: <157538205135.24843.17780384774128724876.idtracker@ietfa.amsl.com> References: <157538205135.24843.17780384774128724876.idtracker@ietfa.amsl.com> Date: Thu, 05 Dec 2019 22:34:48 +1100 From: "Bron Gondwana" To: "Barry Leiba" , "The IESG" Cc: jmap@ietf.org, jmap-chairs@ietf.org Content-Type: multipart/mixed; boundary=69f789ce40584d87855a0d2a06fbbfb8 Archived-At: Subject: Re: [Jmap] =?utf-8?q?Barry_Leiba=27s_Yes_on_charter-ietf-jmap-02-00?= =?utf-8?q?=3A_=28with_COMMENT=29?= X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 11:34:50 -0000 --69f789ce40584d87855a0d2a06fbbfb8 Content-Type: multipart/alternative; boundary=aaf9b4a19fe343a6848bc69f3e2f8bed --aaf9b4a19fe343a6848bc69f3e2f8bed Content-Type: text/plain On Wed, Dec 4, 2019, at 01:07, Barry Leiba via Datatracker wrote: > Barry Leiba has entered the following ballot position for > charter-ietf-jmap-02-00: Yes > > Actually, "Yes, but..." Thanks Barry! I have attached an updated draft charter. It is also available from the master copy where I track changes on Github: https://github.com/jmapio/jmap/blob/master/ietf-docs/charter.txt This explicit change is: https://github.com/jmapio/jmap/commit/23a26b22c5d56c4531f71806b03894180fa1b0c8 > The concrete deliverables at the bottom include JSCalendar but not JSContact; > please add one for the latter. When I wrote this, we hadn't yet chosen the location for JSContact work to occur, which is why it wasn't included. I have updated that now to include both the JSContact format for contacts and groups of contacts, and a JMAP Contacts document to describe how to access addressbooks which contain records in JSContact format. > That would make five concrete deliverables, of which only two (websockets and > MDNs) have milestones listed. It would be nice to have milestones for the > others. I can do that. I already had milestone dates agreed at IETF106 for JSContact, but had not yet had them in datatracker because JSContact isn't in scope until this charter is accepted! I will add milestones for all deliverables once the recharter is finished. > And there's a milestone for which there's no listed deliverable (the > implementation guidance). I'm ambivalent here: does it make sense to list it > as a deliverable? Or maybe it's better just to have it in the milestones, as > there is a "catch-all" deliverable that will cover it. We decided at IETF106 to keep that milestone around for now as we think it's a useful document to produce. I have added additional text to the bottom of the draft charter: Also within scope for this working group are informational documents for converting between JMAP data representation and other formats which can be used to specify the same underlying data. JSCalendar also has a document of this type: https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar-icalendar/ Though it's being tracked in the CALEXT working group because that's where the JSCalendar format was worked on. Cheers, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --aaf9b4a19fe343a6848bc69f3e2f8bed Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Wed, Dec 4, 2019, at 01:07, Barry Leiba via Datatracker= wrote:
Barry Leiba has entered the following ballot position for=
charter-ietf-jmap-02-00: Yes=

Actually, "Yes, but..."

Than= ks Barry!

I have attached an updated draft charter. = It is also available from the master copy where I track changes on Gith= ub:


This explicit change is:


The concrete deliverables at the bottom include JSCalendar = but not JSContact;
please add= one for the latter.

When I wrote this, we h= adn't yet chosen the location for JSContact work to occur, which is why = it wasn't included.  I have updated that now to include both the JS= Contact format for contacts and groups of contacts, and a JMAP Contacts = document to describe how to access addressbooks which contain records in= JSContact format.

=
Th= at would make five concrete deliverables, of which only two (websockets = and
MDNs) have milestones lis= ted.  It would be nice to have milestones for the
others.

I can do t= hat.  I already had milestone dates agreed at IETF106 for JSContact= , but had not yet had them in datatracker because JSContact isn't in sco= pe until this charter is accepted!  I will add milestones for all d= eliverables once the recharter is finished.

And there's a milestone for which there's no listed= deliverable (the
implementat= ion guidance).  I'm ambivalent here: does it make sense to list it<= br>
as a deliverable?  Or ma= ybe it's better just to have it in the milestones, as
there is a "catch-all" deliverable that will co= ver it.

We decided at IETF106 to keep that m= ilestone around for now as we think it's a useful document to produce.

I have added additional text to the bottom of the draft ch= arter:

Also within scope for this working grou= p are informational documents for converting between JMAP data represent= ation and other formats which can be used to specify the same underlying= data.

JSCalendar also has a document of this type= :


Though it's being trac= ked in the CALEXT working group because that's where the JSCalendar form= at was worked on.

<= div style=3D"font-family:Arial;">Cheers,

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com
<= /div> --aaf9b4a19fe343a6848bc69f3e2f8bed-- --69f789ce40584d87855a0d2a06fbbfb8 Content-Disposition: attachment;filename="charter.txt" Content-Type: text/plain; name="charter.txt" Content-Transfer-Encoding: BASE64 VGhlIEpNQVAgcHJvdG9jb2wgZGVmaW5lZCBpbiBkcmFmdC1pZXRmLWptYXAtY29yZSBpcyBk ZXNpZ25lZCB0byBiZQpleHRlbnNpYmxlIHRvIG11bHRpcGxlIGRhdGF0eXBlcyB3aGljaCBh cmUgdXNlZnVsIGZvciBwZXJzb25hbAppbmZvcm1hdGlvbiBtYW5hZ2VtZW50IHJlbGF0ZWQg dG8gZW1haWwgc3RvcmVzLgoKTm93IHRoYXQgZHJhZnQtaWV0Zi1qbWFwLW1haWwgaXMgY29t cGxldGVkLCB0aGUgd29ya2luZyBncm91cCB3aWxsCnByb2R1Y2Ugc3BlY2lmaWNhdGlvbnMg Zm9yIHJlbGF0ZWQgZGF0YSB0eXBlcywgYmVnaW5uaW5nIHdpdGggY2FsZW5kYXJzCmFuZCBj b250YWN0cy4KClRoZSBjYWxlbmRhciB3b3JrIHdpbGwgYmUgYmFzZWQgb24gZHJhZnQtaWV0 Zi1jYWxleHQtanNjYWxhbmRhciBhcyB0aGUKZGF0YSBmb3JtYXQuICBUaGlzIHdvcmtpbmcg Z3JvdXAgd2lsbCBjb25zdWx0IHdpdGggdGhlIGNhbGV4dCB3b3JraW5nCmdyb3VwIHRvIGVu c3VyZSB0aGF0IGNhbGVuZGFyIGFjY2VzcyB2aWEgSk1BUCByZW1haW5zIGNvbXBhdGlibGUg d2l0aApleGlzdGluZyBjYWxlbmRhciBzdGFuZGFyZHMuCgpUaGUgY29udGFjdCB3b3JrIHdp bGwgYmVnaW4gd2l0aCBhIEpTT04gZm9ybWF0IGZvciBjb250YWN0IGRhdGEgYmFzZWQKdXBv biB0aGUgd29yayBiZWd1biBpbiBkcmFmdC1zdGVwYW5lay1qc2NvbnRhY3QsIGFuZCBpbiBj b25zdWx0YXRpb24gd2l0aApvdGhlciB1c2VycyBvZiBjb250YWN0IGRhdGEgd2l0aGluIHRo ZSBJRVRGIGFuZCBvdXRzaWRlIHRvIGJ1aWxkIGFuCmV4dGVuc2libGUgZm9ybWF0LiAgV2hl cmUgcG9zc2libGUsIHRoaXMgZm9ybWF0IHdpbGwgcmV0YWluIHRoZSBhYmlsaXR5CnRvIGNv bnZlcnQgYmFja3dhcmRzIGFuZCBmb3J3YXJkcyB0byBSRkM2MzUwIHZDYXJkIGZvcm1hdC4g IFRoaXMgZm9ybWF0CndpbGwgdGhlbiBiZSB1c2VkIGFzIHRoZSBiYXNpcyBvZiBKTUFQIG9i amVjdCB0eXBlcyBmb3IgY29udGFjdHMuCgpFeHRlbnNpb25zIHRvIHRoZSBleGlzdGluZyBj b3JlIGFuZCBtYWlsIEpNQVAgc3BlY2lmaWNhdGlvbnMgYXJlIGFsc28Kd2l0aGluIHNjb3Bl IGZvciB0aGlzIHdvcmtpbmcgZ3JvdXAsIGZvciBleGFtcGxlIGFueSBhZGRpdGlvbmFsIHBh cnRzCm9mIFNJRVZFLCBJTUFQLCBTTVRQIHN1Ym1pc3Npb24sIGFzIHdlbGwgYXMgdHJhbnNw b3J0IG9mIEpNQVAgb3ZlcgpkaWZmZXJlbnQgcHJvdG9jb2xzIHRoYW4gaHR0cHMuCgpXb3Jr IG9uIEpNQVAgZXh0ZW5zaW9ucyB3aWxsIGJlIGJvdW5kIGJ5IHRoZSBmb2xsb3dpbmcgY29u c3RyYWludHM6CgoxKSBUaGUgd29yayBvZiB0aGlzIGdyb3VwIGlzIGxpbWl0ZWQgdG8gZGV2 ZWxvcGluZyBwcm90b2NvbHMgZm9yIGEKICAgY2xpZW50IHN5bmNocm9uaXNpbmcgZGF0YSB3 aXRoIGEgc2VydmVyLiBBbnkgc2VydmVyLXRvLXNlcnZlciBpc3N1ZXMKICAgYXJlIG91dCBv ZiBzY29wZSBmb3IgdGhpcyB3b3JraW5nIGdyb3VwLgoKMikgT2JqZWN0IG1vZGVscyB3aWxs IHVzZSBleGlzdGluZyBJRVRGIHdvcmsgd2hlcmUgcG9zc2libGUuCgozKSBKTUFQIEV4dGVu c2lvbnMgd2lsbCBiZSBidWlsdCBmb2xsb3dpbmcgdGhlIGNvcmUgcHJpbmNpcGxlczoKCiAg My4xKSBUaGUgc2VydmVyIHdpbGwgbm90IGJlIHJlcXVpcmVkIHRvIHBlcmZvcm0gd29yayBu b3QgZXhwbGljaXRseQogICAgICAgcmVxdWVzdGVkIGJ5IHRoZSBjbGllbnQsIGFuZCB0aGUg ZGVmYXVsdCBzaG91bGQgYWx3YXlzIGJlIHRoZQogICAgICAgbW9kZSB3aGljaCByZXF1aXJl cyB0aGUgbGVhc3Qgc2VydmVyIHdvcmsuCgogIDMuMikgVGhlIGNsaWVudCBjYW4gZGlzY292 ZXIgbGltaXRzIGVuZm9yY2VkIGJ5IHRoZSBzZXJ2ZXIgb24KICAgICAgIHJlc291cmNlcyBv ciByZXF1ZXN0IGNvbXBsZXhpdHkuCgogIDMuMykgV2hlcmUgc2lkZSBlZmZlY3RzIGdlbmVy YXRlZCBieSB0aGUgc2VydmVyIGFyZSBvcHRpb25hbCwgdGhlCiAgICAgICBwcm90b2NvbCB3 aWxsIGRlZmF1bHQgdG8gbm8gc2lkZSBlZmZlY3RzLCBhbmQgdGhlIGNsaWVudCBtdXN0CiAg ICAgICBleHBsaWNpdGx5IHJlcXVlc3QgdGhhdCB0aG9zZSBzaWRlIGVmZmVjdHMgaGFwcGVu IChmb3IgZXhhbXBsZToKICAgICAgIHNlbmRpbmcgYSBjYWxlbmRhciBpbnZpdGF0aW9uIG9y IHJlcGx5IHdoZW4gdXBkYXRpbmcgYW4gZXZlbnQpCgpUaGUgd29ya2luZyBncm91cCB3aWxs IGRlbGl2ZXIgZG9jdW1lbnRzIGZvciB0aGUgZm9sbG93aW5nOgoKIC0gSk1BUCBhY2Nlc3Mg dG8gY2FsZW5kYXJzIHVzaW5nIHRoZSBKU0NhbGVuZGFyIGZvcm1hdAoKIC0gSlNPTiBmb3Jt YXRzIGZvciByZXByZXNlbnRpbmcgY29udGFjdHMgYW5kIGdyb3VwcyBvZiBjb250YWN0cwog ICAoSlNDb250YWN0KQoKIC0gSk1BUCBhY2Nlc3MgdG8gYWRkcmVzc2Jvb2tzIHVzaW5nIHRo ZSBKU0NvbnRhY3QgZm9ybWF0CgogLSBhY2Nlc3NpbmcgSk1BUCBvdmVyIFdlYnNvY2tldHMK CiAtIGhhbmRsaW5nIFMvTUlNRSBlbWFpbHMgb3ZlciBKTUFQCgogLSBtZXNzYWdlIGRlbGl2 ZXJ5IG5vdGlmaWNhdGlvbnMgdmlhIEpNQVAKCiAtIG90aGVyIGV4dGVuc2lvbnMgd2hpY2gg dGhlIHdvcmtpbmcgZ3JvdXAgY29uc2lkZXJzIHJlbGF0ZWQgdG8gZW1haWwKICAgYW5kIGNv bXBhdGlibGUgd2l0aCB0aGUgY29uc3RyYWludHMgbGlzdGVkIGFib3ZlCgpBbHNvIHdpdGhp biBzY29wZSBmb3IgdGhpcyB3b3JraW5nIGdyb3VwIGFyZSBpbmZvcm1hdGlvbmFsIGRvY3Vt ZW50cyBmb3IKY29udmVydGluZyBiZXR3ZWVuIEpNQVAgZGF0YSByZXByZXNlbnRhdGlvbiBh bmQgb3RoZXIgZm9ybWF0cyB3aGljaCBjYW4KYmUgdXNlZCB0byBzcGVjaWZ5IHRoZSBzYW1l IHVuZGVybHlpbmcgZGF0YS4K --69f789ce40584d87855a0d2a06fbbfb8-- From nobody Thu Dec 5 06:09:50 2019 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 8FD261200C4; Thu, 5 Dec 2019 06:09:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: jmap-chairs@ietf.org, jmap@ietf.org, draft-ietf-jmap-websocket@ietf.org, fenton@bluepopcorn.net, alexey.melnikov@isode.com, Jim Fenton Content-Transfer-Encoding: 7bit Reply-To: last-call@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <157555498758.16456.15977798213026205009.idtracker@ietfa.amsl.com> Date: Thu, 05 Dec 2019 06:09:47 -0800 Archived-At: Subject: [Jmap] Last Call: (A JSON Meta Application Protocol (JMAP) Subprotocol for WebSocket) to Proposed Standard X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 14:09:48 -0000 The IESG has received a request from the JSON Mail Access Protocol WG (jmap) to consider the following document: - 'A JSON Meta Application Protocol (JMAP) Subprotocol for WebSocket' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2019-12-19. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a binding for the JSON Meta Application Protocol (JMAP) over a WebSocket transport layer. The WebSocket binding for JMAP provides higher performance than the current HTTP binding for JMAP. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-jmap-websocket/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-jmap-websocket/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Dec 6 09:43:58 2019 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 9659D12007C; Fri, 6 Dec 2019 09:43:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Cc: jmap@ietf.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <157565423158.20984.4039272224350200193.idtracker@ietfa.amsl.com> Date: Fri, 06 Dec 2019 09:43:51 -0800 Archived-At: Subject: [Jmap] WG Review: JSON Mail Access Protocol (jmap) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 17:43:51 -0000 The JSON Mail Access Protocol (jmap) WG in the Applications and Real-Time Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2019-12-16. JSON Mail Access Protocol (jmap) ----------------------------------------------------------------------- Current status: Active WG Chairs: Bron Gondwana Jim Fenton Assigned Area Director: Alexey Melnikov Applications and Real-Time Area Directors: Adam Roach Alexey Melnikov Barry Leiba Mailing list: Address: jmap@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/jmap Archive: https://mailarchive.ietf.org/arch/search/?email_list=jmap Group page: https://datatracker.ietf.org/group/jmap/ Charter: https://datatracker.ietf.org/doc/charter-ietf-jmap/ The JMAP protocol defined in draft-ietf-jmap-core is designed to be extensible to multiple datatypes which are useful for personal information management related to email stores. Now that draft-ietf-jmap-mail is completed, the working group will produce specifications for related data types, beginning with calendars and contacts. The calendar work will be based on draft-ietf-calext-jscalandar as the data format. This working group will consult with the CALEXT working group to ensure that calendar access via JMAP remains compatible with existing calendar standards. The contact work will begin with a JSON format for contact data based upon the work begun in draft-stepanek-jscontact, and in consultation with other users of contact data within the IETF and outside to build an extensible format. Where possible, this format will retain the ability to convert backwards and forwards to RFC6350 vCard format. This format will then be used as the basis of JMAP object types for contacts. Extensions to the existing core and mail JMAP specifications are also within scope for this working group, for example any additional parts of SIEVE, IMAP, SMTP submission, as well as transport of JMAP over WSS (WebSocket over TLS, RFC 6455). Work on JMAP extensions will be bound by the following constraints: 1) The work of this group is limited to developing protocols for a client synchronising data with a server. Any server-to-server issues are out of scope for this working group. 2) Object models will use existing IETF work where possible. 3) JMAP Extensions will be built following the core principles: 3.1) The server will not be required to perform work not explicitly requested by the client, and the default should always be the mode which requires the least server work. 3.2) The client can discover limits enforced by the server on resources or request complexity. 3.3) Where side effects generated by the server are optional, the protocol will default to no side effects, and the client must explicitly request that those side effects happen (for example: sending a calendar invitation or reply when updating an event) The working group will deliver documents for the following: - JMAP access to calendars using the JSCalendar format - JSON formats for representing contacts and groups of contacts (JSContact) - JMAP access to addressbooks using the JSContact format - Accessing JMAP over Websockets - Handling of S/MIME email messages (e.g. signature verification) over JMAP - Message Disposition Notifications (RFC 8098) via JMAP - Other extensions which the working group considers related to email and compatible with the constraints listed above Also within scope for this working group are informational documents for converting between JMAP data representation and other formats already in wide use which can be used to specify the same underlying data. Milestones: Dec 2019 - Submit Message Disposition Notification document to the IESG Jan 2020 - Adopt a document for a JSON Contact format (after recharter) Feb 2020 - Submit JMAP Quotas document to the IESG Feb 2020 - Submit JMAP S/MIME signature validation document to the IESG Feb 2020 - Adopt a document for S/MIME key management and server side signing/encryption Jul 2020 - Adopt a document defining JMAP access to addressbooks Nov 2020 - Submit JMAP Calendars document to the IESG Dec 2020 - Submit document with guidance for implementation of IMAP servers and proxies (Informational) Dec 2020 - Submit JSON Contact document to IESG From nobody Tue Dec 10 14:31:00 2019 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 707B51201EF; Tue, 10 Dec 2019 14:30:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Linda Dunbar via Datatracker To: Cc: last-call@ietf.org, draft-ietf-jmap-websocket.all@ietf.org, jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Linda Dunbar Message-ID: <157601705841.9885.14627802012368211966@ietfa.amsl.com> Date: Tue, 10 Dec 2019 14:30:58 -0800 Archived-At: Subject: [Jmap] Genart last call review of draft-ietf-jmap-websocket-04 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 22:30:58 -0000 Reviewer: Linda Dunbar Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-jmap-websocket-04 Reviewer: Linda Dunbar Review Date: 2019-12-10 IETF LC End Date: 2019-12-19 IESG Telechat date: Not scheduled for a telechat Summary: the document describes binding JSON Meta Application Protocol (JMAP) over a WebSocket Transport Layer (instead the current HTTP layer) The document is written very clear. I think it is ready with a few questions. 1. The current practice of binding JMAP over HTTP requires authentication for every request, vs. over WebSocket Transport only requires authentication at the initial OPEN step. What if there is Man in the Middle attack after the initial OPEN? 2. In the Introduction you stated that compression for HTTP requests has very low deployment. Is it because HTTP request only has very small packet size, therefore with very little benefit of compression? Major issues: Minor issues: Nits/editorial comments: Best Regards, Linda Dunbar From nobody Mon Dec 16 08:51:18 2019 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 7966C1200B2; Mon, 16 Dec 2019 08:51:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <157651507007.21533.1146199149413890106@ietfa.amsl.com> Date: Mon, 16 Dec 2019 08:51:10 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-mdn-04.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2019 16:51:11 -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 : Handling Message Disposition Notification with JMAP Author : Raphaël Ouazana Filename : draft-ietf-jmap-mdn-04.txt Pages : 9 Date : 2019-12-16 Abstract: This document specifies a data model for handling [RFC8098] MDN messages with a server using JMAP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-mdn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-mdn-04 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-mdn-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-mdn-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 16 08:59:07 2019 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 7802B12085C for ; Mon, 16 Dec 2019 08:59:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.522 X-Spam-Level: X-Spam-Status: No, score=-1.522 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, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=linagora.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 76-Tii2ACY1K for ; Mon, 16 Dec 2019 08:59:02 -0800 (PST) Received: from outgoing.linagora.com (outgoing.linagora.com [51.75.198.246]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAE5F12003E for ; Mon, 16 Dec 2019 08:59:01 -0800 (PST) Received: from linagora.com (unknown [10.233.69.202]) by outgoing.linagora.com (Postfix) with ESMTP id 9A7D83B; Mon, 16 Dec 2019 16:58:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linagora.com; s=s20181122; t=1576515539; bh=O+JdFQqxvE/08cpeZu+JdUp8q+p/9kDJ0TDb9SfRx5E=; h=From:Reply-To:To:Subject:Date:References:From; b=PwjNMFRb/VFnWLeyQ47xJdtd/Y71LiaWrHp/XKiH43LJ7XUMwxyweb8eHpnOyR5Fb PqNDOM8RAzAKVqQpwQvKjHd0qjfkY0K+nXmXPCxJaRci+b21Xge3Ojxeu6UqLGZaIe Us6NFVQ1VOLeq/4PvxWabe1u/UBCxP+y9dLPyL4k4mP++qaIcQhox3Lph0/SwGaGJ4 YpEGSjYdqYU3MxzaQIIlXaWqJH2EtCjZj4ZxmE5stGXcVUnL9ENeX9TZo1cEoeBk3E 0Rf3d5jvPKy2ae6XflAAeYHYCfceCThLNW/qe/Tn1hgAKrezDVqRPKQgRM2EUSEoxx jKgeRiun1jeuQ== MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable From: Raphael OUAZANA Sender: Raphael OUAZANA Reply-To: rouazana@linagora.com To: "jmap@ietf.org" , Bron Gondwana Message-ID: Date: Mon, 16 Dec 2019 16:58:53 +0000 References: <1776898c-03ee-4d34-b254-a9c638dd3741@dogfood.fastmail.com> Archived-At: Subject: Re: [Jmap] Working group last call: draft-ietf-jmap-mdn-03 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2019 16:59:06 -0000

Thank you all for your remarks=2E

I uploaded a new version of the = draft=2E I have taken care of all the comments that were made, thank you ve= ry much for the suggestions, it was really helpful=2E

Regards,

= Rapha=C3=ABl=2E

Le 22 novembre 2019 06:19, de brong@fastmailte= am=2Ecom
= Raphael,

With my chair hat o= n - I'm happy for you to either issue drafts with updates during the last c= all period, or wait until the end and issue another draft containing all th= e feedback at the end of the last call period=2E

Either way, I'= m happy to submit to publication after this last call without doing another= last call - so long as those who have given feedback during this time agre= e that it's been addressed in the final draft!

Cheers,

Bron= =2E

On Fri, Nov 2= 2, 2019, at 15:51, Neil Jenkins wrote:
Overall I think this doc is good=2E A few nits:

o  forEmailId: "String" Email I=
d of the received email this MDN is
   relative to=2E

This needs to be nullable, as described in MDN/pa= rse=2E

o  original=
MessageID: "String|null" (server-set)

=
I think this should be originalMessageId (lowercase d on t= he end) for consistency=2E

2=2E1=2E  MDN/set

   Standard "/set" method as des=
cribed in [RFC8620] where o=
nly the
   _create_ parameter is supported=2E
<= div>
This is not quite right: the "accountId" and "ifInState"= arguments are fine=2E I think this text should say something like:

Only create is supported; a= ny attempt to update/destroy MUST be rejected with a "forbidden" SetError= =2E

And as a general comment, in = the final versions of RFC8620/8621 we cleaned up the formatting so it worke= d better in the plain text version of the RFCs; I suggest adopting the same= =2E So we use "quote" for a property name reference (not _underscore_) and = remove the *asterisks* around the property names in the definitions=2E
<= /div>

Cheers,
Neil=2E
______= _________________________________________
Jmap mailing list
Jmap@ietf=2Eorg
https://www=2Eietf=2Eorg/mailman= /listinfo/jmap


--
  Bron Gondwana, CEO, Fastmail Pty Ltd=
  brong@fastmailteam=2Ecom


From nobody Thu Dec 19 08:41:20 2019 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 9A71E1201EF; Thu, 19 Dec 2019 08:41:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Bob Briscoe via Datatracker To: Cc: last-call@ietf.org, draft-ietf-jmap-websocket.all@ietf.org, jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Bob Briscoe Message-ID: <157677367852.27417.14108254460834408683@ietfa.amsl.com> Date: Thu, 19 Dec 2019 08:41:18 -0800 Archived-At: Subject: [Jmap] Tsvart last call review of draft-ietf-jmap-websocket-04 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2019 16:41:19 -0000 Reviewer: Bob Briscoe Review result: Ready with Issues This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. ==Transport-specific review comments== The only transport-specific issues that I can think of would relate to holding open a connection for a long time, which increases the risk of brute-force connection hijacking and has interactions with NATs and mobility. However, they are all WebSockets issues, and adding jmap over WebSockets doesn't change any of that. ==Non-transport-related review comments== I found the document readable and comprehensible. The following is my only concern... ===Shouldn't extensibility be discussed?=== The specification is full of statements saying what peer A MUST do, but lacks statements saying what peer B MUST do if peer A doesn't do what it is supposed to. Perhaps there needs to be a default case for what to do if one peer receives a message that violates the Websockets JMAP subprotocol (or at least one peer believes it violates the version of the protocol that it supports). Examples: 4. JMAP Subprotocol Binary data MUST NOT be uploaded or downloaded through a WebSocket JMAP connection. What if they are? 4.1 Handshake Other message types MUST NOT be transmitted over this connection. What if they are? 4.2 WebSocket Messages The lists of allowed messages following "The messages MUST be in the form of..." do not say what to do if they are not, and do not seem to allow for extensibility. ===Nits=== 4.1 Handshake CURRENT: If a client receives a handshake response that does not include "jmap" in the "Sec-WebSocket-Protocol" header, ... PROPOSED: If a client receives a handshake response in which the value of the "Sec-WebSocket-Protocol" header is not "jmap", ... REASON: 'include' implies it would have been valid for the server to have sent a list of subprotocols. From nobody Thu Dec 19 09:18:46 2019 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 2775612002E; Thu, 19 Dec 2019 09:18:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIkPGkc_UBs5; Thu, 19 Dec 2019 09:18:43 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3501207FC; Thu, 19 Dec 2019 09:18:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1576775919; d=isode.com; s=june2016; i=@isode.com; bh=MIrPOm/hrTUn0lFB+pMzE4bUfgYb5/2EHW4dKFbkK+E=; 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=ZKAnYZra5lcQkvbmLfiDqWufmvJRpzpzt6WNBnZqRsDRU3PMR+odfcIbpboeb8sBoDJ0sg lkM5wJaDC5b4ZMwVjYmchaDXQVf/4wo6VpiII6pm8WlFXHpsQ4ItmgwNGdlfA4ni0Xxcw3 TbDtTBBt5YySpmEmADt8S86pVBKcRc8=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 19 Dec 2019 17:18:39 +0000 To: Bob Briscoe , tsv-art@ietf.org Cc: last-call@ietf.org, draft-ietf-jmap-websocket.all@ietf.org, jmap@ietf.org References: <157677367852.27417.14108254460834408683@ietfa.amsl.com> From: Alexey Melnikov Message-ID: <33b1eb10-ff5c-192e-d7d8-56b200e8de96@isode.com> Date: Thu, 19 Dec 2019 17:17:42 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 In-Reply-To: <157677367852.27417.14108254460834408683@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Jmap] Tsvart last call review of draft-ietf-jmap-websocket-04 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2019 17:18:44 -0000 Hi Bob, Thank you for your review. A few quick comments below: On 19/12/2019 16:41, Bob Briscoe via Datatracker wrote: =C2=A0[snip] > =3D=3D=3DShouldn't extensibility be discussed?=3D=3D=3D > > The specification is full of statements saying what peer A MUST do, but > lacks statements saying what peer B MUST do if peer A doesn't do what it > is supposed to. > > Perhaps there needs to be a default case for what to do if one peer > receives a message that violates the Websockets JMAP subprotocol (or at > least one peer believes it violates the version of the protocol that it > supports). > > Examples: > > 4. JMAP Subprotocol > Binary data MUST NOT be uploaded or downloaded > through a WebSocket JMAP connection. > What if they are? I think this case is not interesting, as it is effectively a separate=20 API endpoint in standard JMAP anyway. So there would be just no way of=20 doing this in JMAP over WebSocket. > 4.1 Handshake > Other message types MUST > NOT be transmitted over this connection. > What if they are? This is a more interesting case. So saying something here would be useful. > 4.2 WebSocket Messages > The lists of allowed messages following "The messages MUST be in the > form of..." do not say what to do if they are not, and do not seem to > allow for extensibility. And so is this. [snip] Best Regards, Alexey From nobody Thu Dec 19 17:48:41 2019 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 055E1120013; Thu, 19 Dec 2019 17:48:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEayNPHqaW9h; Thu, 19 Dec 2019 17:48:37 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36C4712000F; Thu, 19 Dec 2019 17:48:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=d5BdR4BdcTAgRmD2oVBEEDna9u5KVx5e5hIMCEuGgyM=; b=nPXagoPl52PNfyTv+CTcPS5VL5 G4enbIYQ7MJY1snJN+rhsQo4H6/tQT/jlN20N8DBvvA+zID/ppc1+jAnBvzJ4qtFQbRsG7ae3gtLv RfXlI5cwvDSu6w3FL6YbazaipveY4NOrRRFTW0D+P0JB19v74QWSh6buPmHIS1z8caBtlIs7CYhlf rCtBRdXSsmSGxJ8hrE9Rs8+0bwPTZSZWYHwPWdWS7jtc4tXw0BDL7cxa3r6CoXuGbWXF0VeLAq07w +7F5TcK8gI9+sOsnXcl9KzXqzegU1URtmXwZ1UFjFfhNDPtFno2u+U1eajzxW6Aae5P1eKiOe6DJF dB99L1/Q==; Received: from [31.185.135.202] (port=34288 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1ii7P8-0006rO-Q9; Fri, 20 Dec 2019 01:48:35 +0000 To: Alexey Melnikov , tsv-art@ietf.org Cc: last-call@ietf.org, draft-ietf-jmap-websocket.all@ietf.org, jmap@ietf.org References: <157677367852.27417.14108254460834408683@ietfa.amsl.com> <33b1eb10-ff5c-192e-d7d8-56b200e8de96@isode.com> From: Bob Briscoe Message-ID: <31fd1e58-0537-2d7e-b69e-0739228e2776@bobbriscoe.net> Date: Fri, 20 Dec 2019 01:48:32 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <33b1eb10-ff5c-192e-d7d8-56b200e8de96@isode.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [Jmap] [Tsv-art] Tsvart last call review of draft-ietf-jmap-websocket-04 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2019 01:48:40 -0000 Alexey, Pls check the draft for more occurrences than the three I found. I think your word uninteresting meant "not possible for current implementations to do this". You might have misunderstood my point that defining what to do on receipt of an unexpected (i.e uninteresting in your words) message is a useful exercise to allow for extensibility. If you don't say whether to ignore or to abort the connection (or whatever), it becomes impossible to predict what pre-existing implementations will do if you want to extend the protocol in future. Bob On 19/12/2019 17:17, Alexey Melnikov wrote: > Hi Bob, > > Thank you for your review. A few quick comments below: > > On 19/12/2019 16:41, Bob Briscoe via Datatracker wrote: > >  [snip] >> ===Shouldn't extensibility be discussed?=== >> >> The specification is full of statements saying what peer A MUST do, but >> lacks statements saying what peer B MUST do if peer A doesn't do what it >> is supposed to. >> >> Perhaps there needs to be a default case for what to do if one peer >> receives a message that violates the Websockets JMAP subprotocol (or at >> least one peer believes it violates the version of the protocol that it >> supports). >> >> Examples: >> >> 4.  JMAP Subprotocol >>     Binary data MUST NOT be uploaded or downloaded >>     through a WebSocket JMAP connection. >> What if they are? > I think this case is not interesting, as it is effectively a separate > API endpoint in standard JMAP anyway. So there would be just no way of > doing this in JMAP over WebSocket. >> 4.1 Handshake >>     Other message types MUST >>     NOT be transmitted over this connection. >> What if they are? > This is a more interesting case. So saying something here would be > useful. >> 4.2 WebSocket Messages >> The lists of allowed messages following "The messages MUST be in the >> form of..." do not say what to do if they are not, and do not seem to >> allow for extensibility. > > And so is this. > > [snip] > > Best Regards, > > Alexey > > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Fri Dec 20 01:01:53 2019 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 9806A1200B7; Fri, 20 Dec 2019 01:01:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=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 pBlS5i2goBVK; Fri, 20 Dec 2019 01:01:43 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id CE2F61200A1; Fri, 20 Dec 2019 01:01:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1576832501; d=isode.com; s=june2016; i=@isode.com; bh=LPhNb8mI0pduCz/UhURCZZ+8KB4R3Ln48foso0in5d8=; 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=ZuiXKAVprOcuOYw1HPHFnNff7UFQp87qhdLGZBhx8pHY2N/DdhJQEfGBNHA1MxA6E+CdHt Jof15Y+J+G1OH5oA9hkYOh5wARcfe4KQ5kW15Md296/SX1qLMoAlJPxpyCphC9yvFzaZq5 RgwJL41mO05DCl/ZU4wrGXqXMv+DFZM=; Received: from [10.172.117.34] (92.40.249.160.threembb.co.uk [92.40.249.160]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 20 Dec 2019 09:01:41 +0000 From: Alexey Melnikov X-Mailer: iPad Mail (16G102) In-Reply-To: <31fd1e58-0537-2d7e-b69e-0739228e2776@bobbriscoe.net> Date: Fri, 20 Dec 2019 09:01:39 +0000 Cc: tsv-art@ietf.org, last-call@ietf.org, draft-ietf-jmap-websocket.all@ietf.org, jmap@ietf.org Message-Id: <78E4BB6D-13B8-4938-9709-A8887272B3EE@isode.com> References: <157677367852.27417.14108254460834408683@ietfa.amsl.com> <33b1eb10-ff5c-192e-d7d8-56b200e8de96@isode.com> <31fd1e58-0537-2d7e-b69e-0739228e2776@bobbriscoe.net> To: Bob Briscoe MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jmap] [Tsv-art] Tsvart last call review of draft-ietf-jmap-websocket-04 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2019 09:01:45 -0000 Hi Bob, > On 20 Dec 2019, at 01:48, Bob Briscoe wrote: >=20 > Alexey, >=20 > Pls check the draft for more occurrences than the three I found. Right. > I think your word uninteresting meant "not possible for current implementa= tions to do this". Yes. I think your general point is valid, I just wanted to point out that on= e of the cases you mentioned doesn=E2=80=99t need further considerations. >=20 > You might have misunderstood my point that defining what to do on receipt o= f an unexpected (i.e uninteresting in your words) message is a useful exerci= se to allow for extensibility. If you don't say whether to ignore or to abor= t the connection (or whatever), it becomes impossible to predict what pre-ex= isting implementations will do if you want to extend the protocol in future.= No, I agree with you here. >=20 > Bob >=20 >> On 19/12/2019 17:17, Alexey Melnikov wrote: >> Hi Bob, >>=20 >> Thank you for your review. A few quick comments below: >>=20 >> On 19/12/2019 16:41, Bob Briscoe via Datatracker wrote: >>=20 >> [snip] >>> =3D=3D=3DShouldn't extensibility be discussed?=3D=3D=3D >>>=20 >>> The specification is full of statements saying what peer A MUST do, but >>> lacks statements saying what peer B MUST do if peer A doesn't do what it= >>> is supposed to. >>>=20 >>> Perhaps there needs to be a default case for what to do if one peer >>> receives a message that violates the Websockets JMAP subprotocol (or at >>> least one peer believes it violates the version of the protocol that it >>> supports). >>>=20 >>> Examples: >>>=20 >>> 4. JMAP Subprotocol >>> Binary data MUST NOT be uploaded or downloaded >>> through a WebSocket JMAP connection. >>> What if they are? >> I think this case is not interesting, as it is effectively a separate API= endpoint in standard JMAP anyway. So there would be just no way of doing th= is in JMAP over WebSocket. >>> 4.1 Handshake >>> Other message types MUST >>> NOT be transmitted over this connection. >>> What if they are? >> This is a more interesting case. So saying something here would be useful= . >>> 4.2 WebSocket Messages >>> The lists of allowed messages following "The messages MUST be in the >>> form of..." do not say what to do if they are not, and do not seem to >>> allow for extensibility. >>=20 >> And so is this. >>=20 >> [snip] >>=20 >> Best Regards, >>=20 >> Alexey >>=20 >> _______________________________________________ >> Tsv-art mailing list >> Tsv-art@ietf.org >> https://www.ietf.org/mailman/listinfo/tsv-art >=20 > --=20 > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ >=20 From nobody Fri Dec 20 09:48:44 2019 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 18379120856; Fri, 20 Dec 2019 09:48:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Cc: jmap@ietf.org, jmap-chairs@ietf.org, The IESG Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <157686411709.4800.1268300708926457418.idtracker@ietfa.amsl.com> Date: Fri, 20 Dec 2019 09:48:37 -0800 Archived-At: Subject: [Jmap] WG Action: Rechartered JSON Mail Access Protocol (jmap) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2019 17:48:37 -0000 The JSON Mail Access Protocol (jmap) WG in the Applications and Real-Time Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. JSON Mail Access Protocol (jmap) ----------------------------------------------------------------------- Current status: Active WG Chairs: Bron Gondwana Jim Fenton Assigned Area Director: Alexey Melnikov Applications and Real-Time Area Directors: Adam Roach Alexey Melnikov Barry Leiba Mailing list: Address: jmap@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/jmap Archive: https://mailarchive.ietf.org/arch/search/?email_list=jmap Group page: https://datatracker.ietf.org/group/jmap/ Charter: https://datatracker.ietf.org/doc/charter-ietf-jmap/ The JMAP protocol defined in draft-ietf-jmap-core is designed to be extensible to multiple datatypes which are useful for personal information management related to email stores. Now that draft-ietf-jmap-mail is completed, the working group will produce specifications for related data types, beginning with calendars and contacts. The calendar work will be based on draft-ietf-calext-jscalandar as the data format. This working group will consult with the CALEXT working group to ensure that calendar access via JMAP remains compatible with existing calendar standards. The contact work will begin with a JSON format for contact data based upon the work begun in draft-stepanek-jscontact, and in consultation with other users of contact data within the IETF and outside to build an extensible format. Where possible, this format will retain the ability to convert backwards and forwards to RFC6350 vCard format. This format will then be used as the basis of JMAP object types for contacts. Extensions to the existing core and mail JMAP specifications are also within scope for this working group, for example any additional parts of SIEVE, IMAP, SMTP submission, as well as transport of JMAP over WSS (WebSocket over TLS, RFC 6455). Work on JMAP extensions will be bound by the following constraints: 1) The work of this group is limited to developing protocols for a client synchronising data with a server. Any server-to-server issues are out of scope for this working group. 2) Object models will use existing IETF work where possible. 3) JMAP Extensions will be built following the core principles: 3.1) The server will not be required to perform work not explicitly requested by the client, and the default should always be the mode which requires the least server work. 3.2) The client can discover limits enforced by the server on resources or request complexity. 3.3) Where side effects generated by the server are optional, the protocol will default to no side effects, and the client must explicitly request that those side effects happen (for example: sending a calendar invitation or reply when updating an event) The working group will deliver documents for the following: - JMAP access to calendars using the JSCalendar format - JSON formats for representing contacts and groups of contacts (JSContact) - JMAP access to addressbooks using the JSContact format - Accessing JMAP over Websockets - Handling of S/MIME email messages (e.g. signature verification) over JMAP - Message Disposition Notifications (RFC 8098) via JMAP - Other extensions which the working group considers related to email and compatible with the constraints listed above Also within scope for this working group are informational documents for converting between JMAP data representation and other formats already in wide use which can be used to specify the same underlying data. Milestones: Dec 2019 - Submit Message Disposition Notification document to the IESG Jan 2020 - Adopt a document for a JSON Contact format (after recharter) Feb 2020 - Submit JMAP Quotas document to the IESG Feb 2020 - Submit JMAP S/MIME signature validation document to the IESG Feb 2020 - Adopt a document for S/MIME key management and server side signing/encryption Jul 2020 - Adopt a document defining JMAP access to addressbooks Nov 2020 - Submit JMAP Calendars document to the IESG Dec 2020 - Submit document with guidance for implementation of IMAP servers and proxies (Informational) Dec 2020 - Submit JSON Contact document to IESG