From nobody Sun Dec 2 03:27:34 2018 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB1512D7EA for ; Sun, 2 Dec 2018 03:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=tcbioGTC; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mI+7qAiY 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 UOqreQTkN1SC for ; Sun, 2 Dec 2018 03:27:31 -0800 (PST) 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 45DD712D4E8 for ; Sun, 2 Dec 2018 03:27:31 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 5591421990 for ; Sun, 2 Dec 2018 06:27:30 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Sun, 02 Dec 2018 06:27:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:date:from:to:subject :content-type; s=fm1; bh=ptqqderBl6/+OAR2DeoSREK4pEHWEJHE6/fgEav SOl4=; b=tcbioGTCTXfp9xw8Y70VargGqa921nEb2CDrYHw1YofVWNypRGmKsCb R6TCrEtHdC6etR7m6Y3BWtgtyhH1NmhMktY5isMYZG4cVgHBTNcqYRmvzRDr9MLk 8rky+b33apFjZJPxQuEv5ZFw4+hlNHIzQOurYkEfl9G3CL3N0fMslyXGgBDFBS/A 1K0MgdgFCZhfDEKEEOxz8PfPdTcyEYyl8VTnwFJ0MCnkn2JhDy1rt4rp9txIxzdS RdTV38PBzap+24cqU18UznNmiWa4L1ycAePpcNB2QfI3pAGE0ylpAJwMR4fkHFDw ArkXnx50bO18PpKCmVWG7I9DxXPna5A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id:subject :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=ptqqderBl6/+OAR2DeoSREK4pEHWEJHE6/fgEavSOl4=; b=mI+7qAiY UYrqo17Ivf4XboXoRoxYszG6D/vv3YXUMf2w9YQc8FkDXkl4ANjODkpKv9QFygvk gFpALml0yZtIK/BGYQCaYqobmrbL1awoBqTW98I8bjSxxsSv5xnb5CN5+/PpHguN szDc2RFLTDzdFsZKdd/aAKJF0zJOT+qI2niu02lyw6kaTUAf1v7dMduAsPXE9UDN Nq+Nz7Y+gA4qfJBF45UtboIx30rKXJgr1pmHjEDPdAe4mA+VPIKNZXW1QcsN4DLg 9L+ElANsJO/lt75jNkxFGK66+FA0WvB79t3oUlmW9AtlVgiItIjU09A8ZRnenFHl HHzmE9uZnxM9Ew== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 158E220322; Sun, 2 Dec 2018 06:27:29 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: <6053a64d-647d-4689-8fee-c984589b8381@sloti7d1t02> User-Agent: Cyrus-JMAP/3.1.5-656-g84f879f-fmstable-20181126v1 X-Me-Personality: 56629417 Date: Sun, 02 Dec 2018 06:27:28 -0500 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=75f6bac98729427aa17cb920c1a47123 Archived-At: Subject: [Jmap] Document status (AKA: why aren't they submitted yet!) 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: Sun, 02 Dec 2018 11:27:33 -0000 --75f6bac98729427aa17cb920c1a47123 Content-Type: text/plain Neil submitted v11 for both documents the other day. My only substantive "we need to fix it" was making sure that "preview" aligns with the preview draft over in EXTRA. I've had IPR responses back from all authors. So the only remaining issue now is that idnits is complaining about long lines, stale references, and incorrectly marked code blocks - I'll get that looked at this week, and then we can submit for real! I've moved both the draft charter update (unchanged since Bangkok - I'll get to it soon) and the two shepherd documents into git here: https://github.com/jmapio/jmap/tree/master/ietf-docs I'll update them once the idnits is back, then submit for publication! Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --75f6bac98729427aa17cb920c1a47123 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Neil submitted v11 for both documents the other day. = My only substantive "we need to fix it" was making sure that "preview" = aligns with the preview draft over in EXTRA.

I've had IPR= responses back from all authors.

So the only remaining i= ssue now is that idnits is complaining about long lines, stale reference= s, and incorrectly marked code blocks - I'll get that looked at this wee= k, and then we can submit for real!

I've moved both the d= raft charter update (unchanged since Bangkok - I'll get to it soon) and = the two shepherd documents into git here:


I'll update them once = the idnits is back, then submit for publication!

Cheers,<= br>

Bron.

--
  Bron Gondwana, CE= O, FastMail Pty Ltd
  brong@fastm= ailteam.com


--75f6bac98729427aa17cb920c1a47123-- From nobody Sun Dec 2 19:06:13 2018 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 622C1124D68; Sun, 2 Dec 2018 19:06:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <154380636537.7337.5177431818281659277@ietfa.amsl.com> Date: Sun, 02 Dec 2018 19:06:05 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-core-12.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, 03 Dec 2018 03:06:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : JSON Meta Application Protocol Authors : Neil Jenkins Chris Newman Filename : draft-ietf-jmap-core-12.txt Pages : 72 Date : 2018-12-02 Abstract: This document specifies a protocol for clients to efficiently query, fetch and modify JSON-based data objects, with support for push notification of changes and fast resynchronisation, and out-of-band binary data upload/download. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-core/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-core-12 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-core-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-core-12 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 Sun Dec 2 19:07:36 2018 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C8C130DE2; Sun, 2 Dec 2018 19:07:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <154380645518.7321.6793526339709677952@ietfa.amsl.com> Date: Sun, 02 Dec 2018 19:07:35 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-mail-12.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, 03 Dec 2018 03:07:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : JMAP for Mail Authors : Neil Jenkins Chris Newman Filename : draft-ietf-jmap-mail-12.txt Pages : 87 Date : 2018-12-02 Abstract: This document specifies a data model for synchronising email data with a server using JMAP. Clients can use this to efficiently search, access, organise and send messages, and get pushed notifications for fast resynchronisation when new messages are delivered or a change is made in another client. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-mail/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-mail-12 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-mail-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-mail-12 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 Sun Dec 2 19:13:11 2018 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91215130DEC for ; Sun, 2 Dec 2018 19:13:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.084 X-Spam-Level: X-Spam-Status: No, score=-0.084 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=dNj35MM9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=oSLk8Fyy 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 ADZ2nlgpSmPz for ; Sun, 2 Dec 2018 19:13:08 -0800 (PST) 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 2DFB2130DE2 for ; Sun, 2 Dec 2018 19:13:08 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 16FB32174F for ; Sun, 2 Dec 2018 22:13:07 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Sun, 02 Dec 2018 22:13:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=mU9gTgYYMPz8xrT3TnKhAA/SPU8v NRcGlH1p7KSIEyY=; b=dNj35MM9zQHVN759niqtpbiF/pxcj3zfWr9Z1th0jiur ZKxbdyZomEpkF5ZLYgZ7Wyl6G5wpokscJZpih5H90QkCIc4hK6XxA0sN8nBy9Ghb AazO8ddUtlX4fluzcnk0Lz1cng0fVsGwD5kUYj9Y2uduNOnEh4PyZzVrSfGtEdMZ bNejIBFayC1rQwN0XgZpvb1QVmXe1CSbvCETDrH3jiUzFzl96j8t+O2br8AHdWaI kqu7gqjU2QsZfPrHnpQJYo6YAuHjbZUyjCeZH8QW+NZfd4ZvXe1opX4mrJ7pKQ7v gQQaKqAahp7qHO8+CCcoe13uMz7YK7bdPtL1ZsK72g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=mU9gTgYYMPz8xrT3T nKhAA/SPU8vNRcGlH1p7KSIEyY=; b=oSLk8Fyy/ErhTGGFQcWelbJszrC76+lW1 R7dpQLGOaRJ9kuX5k2gUBe1h8GEXreoOVk7/q/mLrmWklyKGqdOvLhIKsQ4cC88Z UodHItin99hn78sXQv39EEZN2NZ6ySdc/kkbjBvx+7psRc4fZ8G5w6N0fEQ+UHk2 pcb9+/FLCr/iHEF25V810iQQLBiQ0NXsVH/jjAxV2IVyep3vUYPgxO+b8+hZ7i0e LZ7jnf38jeuBBEjmaSum0KearhaWglijMQwT6YdQDkoaSGMq+GdSX3v0B6+VTz9m EW9wjrGH7BYscOsCmMnOHqPDQzc3ByGNduU3cnUfO4RILicDpnsug== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6353120322; Sun, 2 Dec 2018 22:13:06 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: <26db5a8f-204d-4a20-be6d-8219d1739d35@sloti7d1t02> User-Agent: Cyrus-JMAP/3.1.5-656-g84f879f-fmstable-20181126v1 X-Me-Personality: 64588216 In-Reply-To: <6053a64d-647d-4689-8fee-c984589b8381@sloti7d1t02> References: <6053a64d-647d-4689-8fee-c984589b8381@sloti7d1t02> Date: Sun, 02 Dec 2018 22:13:06 -0500 From: "Neil Jenkins" To: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=e80818c02e02496e916a8035aaa51c82 Archived-At: Subject: Re: [Jmap] Document status (AKA: why aren't they submitted yet!) 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, 03 Dec 2018 03:13:10 -0000 --e80818c02e02496e916a8035aaa51c82 Content-Type: text/plain I've now published v12 with fixes for the idnits errors. Neil. --e80818c02e02496e916a8035aaa51c82 Content-Type: text/html
I've now published v12 with fixes for the idnits errors.

Neil.
--e80818c02e02496e916a8035aaa51c82-- From nobody Sun Dec 2 22:59:21 2018 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F089124408; Sun, 2 Dec 2018 22:59:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Bron Gondwana To: X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Cc: jmap@ietf.org, Bron Gondwana , iesg-secretary@ietf.org, jmap-chairs@ietf.org, brong@fastmailteam.com Message-ID: <154382036005.7229.955916957284667981.idtracker@ietfa.amsl.com> Date: Sun, 02 Dec 2018 22:59:20 -0800 Archived-At: Subject: [Jmap] Publication has been requested for draft-ietf-jmap-core-12 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, 03 Dec 2018 06:59:20 -0000 Bron Gondwana has requested publication of draft-ietf-jmap-core-12 as Proposed Standard on behalf of the JMAP working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-jmap-core/ From nobody Sun Dec 2 22:59:48 2018 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5476A1276D0; Sun, 2 Dec 2018 22:59:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Bron Gondwana To: X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Cc: jmap@ietf.org, Bron Gondwana , iesg-secretary@ietf.org, jmap-chairs@ietf.org, brong@fastmailteam.com Message-ID: <154382038733.7277.15783608624186053735.idtracker@ietfa.amsl.com> Date: Sun, 02 Dec 2018 22:59:47 -0800 Archived-At: Subject: [Jmap] Publication has been requested for draft-ietf-jmap-mail-12 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, 03 Dec 2018 06:59:47 -0000 Bron Gondwana has requested publication of draft-ietf-jmap-mail-12 as Proposed Standard on behalf of the JMAP working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-jmap-mail/ From nobody Tue Dec 4 16:46:33 2018 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE5D1200B3 for ; Tue, 4 Dec 2018 16:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=xBmwoahn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ihfmDKnc 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 CBVYgsnR7o43 for ; Tue, 4 Dec 2018 16:46:30 -0800 (PST) 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 14ECF130DC2 for ; Tue, 4 Dec 2018 16:46:30 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 2C47221FBA for ; Tue, 4 Dec 2018 19:46:29 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Tue, 04 Dec 2018 19:46:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=24rDffsk+fPEzSHpOpyrw9G99PY0 TfbBJnP09gapk4Y=; b=xBmwoahnCnAJiA8oMpJzE4B7M+ibUVTbXWoOsZmtq9sb e1RY/RNH52CL8xEWHk3tcjomjmdVvOn2AED2D2JsfbfXNspI5avTZUnpCcrWvPHQ T2Gx0egiDetEu9AUQjQ+P6IoDqQ5rWgbsaLbYykxEUob16c0a+9NMVuCp60yJrv5 K9hbfXdu++smyulW7aR7FU/SzjH46iXYXM/tX20vWGys+hwaC2Rn9QSjlhCkxuDB 2A0w3Fg0VZon5EslqCbRyR4BgmI3aqgIxYgJEFSUkehaI7D3G48LU2x2hbF/evOo RU1UO5/RnFDojYOAUIKYkp0Y+HpkhcFPW3pWEnkAyw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=24rDffsk+fPEzSHpO pyrw9G99PY0TfbBJnP09gapk4Y=; b=ihfmDKnc09jAYKlCC+vuGDwKWH7QH6Ecj BFa5sJQfX0BbNWTRr6TJORWKJ2nemEy+oTzA6YGvBhkfwp9BugIMs/WE44INiXYp 2OpsBQei+UxOhk/bymZS0JAbWiriPARhIJYY6cG3kzD+V94xQeAKONsiHSGoRiKD M+9liMbx3tH5Ww370YZZ8ifb3ws/JasWUMaNPMR9KgbanamzgMcqJfUXmG/5EZpI zU9/rY9ZsWxgPbwuKo24sYnUkxo/wlLpIuD+sXhwA2jdLDcJQ93ovUNZ2pZ3Xaux yR5pRPXthf7r9x7ZT7izjv8mMQhJlQiugaLjS2B48JWum8yNkdpcw== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5BCA1203F3; Tue, 4 Dec 2018 19:46:28 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: <2cf743f3-1c18-4062-848e-f85ca505fa55@sloti7d1t02> User-Agent: Cyrus-JMAP/3.1.5-656-g84f879f-fmstable-20181126v1 X-Me-Personality: 64588216 In-Reply-To: <153270520782.32707.4419621555491459322@ietfa.amsl.com> References: <153270520782.32707.4419621555491459322@ietfa.amsl.com> Date: Tue, 04 Dec 2018 19:46:28 -0500 From: "Neil Jenkins" To: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=e6927263a07a4c3b90abd1175572c94a Archived-At: Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-mdn-00.txt 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: Wed, 05 Dec 2018 00:46:32 -0000 --e6927263a07a4c3b90abd1175572c94a Content-Type: text/plain Finally sending my feedback on this draft, as promised in Bangkok. Sorry for the delay! Generally this looks good, just some comments to bring it up to date with the current JMAP conventions and a confusion over how you're actually meant to send the MDN! > * > 2 . Email/createMDN > * > The Email/createMDN method create a [RFC5322 ] message from MDN properties. Where are these Email objects being created? It's not clear to me whether these are intended to be saved to the account's mail store or not. If they *are* being saved to the mail store, we need to give mailboxIds and keywords arguments. If they are not being saved, but just being sent immediately, that needs to be made clear and the method probably renamed to *sendMDN*. > It takes the following arguments: o *accountId*: "String|null" The id of the account to use for this call. If "null", defaults to the "urn:ietf:params:jmap:mail" primary account. This should be non-optional now to match the same change in the other JMAP specs. > o *mdns*: "String[MDN]" A map of creation id (client specified) to MDN objects An *MDN* object has the following properties: o *referencedMessageId*: "String" Message Id of the received message the user wants to create an MDN for. Again, to match current JMAP convention this should be `referencedEmailId`, or maybe just `forEmailId`? > o *subject*: "String" Subject that will be used as "Subject" header for this MDN. o *textBody*: "String" Human readable part of the MDN, as plain text. o *reportingUA*: "String" Name of the MUA creating this MDN. It is used to build the MDN Report part of the MDN. o *disposition*: "Disposition" Object containing the diverse MDN disposition options. A *Disposition* object has the following properties: o *actionMode*: "String" This MUST be one of the following strings: "manual-action" / "automatic-action" o *sendingMode*: "String" This MUST be one of the following strings: "MDN-sent-manually" / "MDN-sent-automatically" o *type*: "String" This MUST be one of the following strings: "deleted" / "dispatched" / "displayed" / "processed" See [RFC8098 ] for the exact meaning of these different fields. This all looks fine. > If the _referencedMessageId_, _subject_, _textBody_, _reportingUA_, _disposition_ properties are invalid (e.g. missing, wrong type, id not found), the server MUST reject the import with an "invalidProperties" SetError. > > If the email cannot be created because it would take the account over quota, the creation should be rejected with a "maxQuotaReached" SetError. import -> create (I presume this is a copy-paste error) and the maxQuotaReached error is now just called `overQuota`. But rather than specify the last two paragraphs, probably better just to say it may return any standard SetError that is defined for a *create* in the core spec. > The response has the following arguments: o *accountId*: "String" The id of the account used for this call. o *created*: "String[Email]" A map of the creation id to an object build from the referenced properties. The _blobId_ field of the Email objects can then be used to effectively send the MDN. Again, I'm unclear how you are supposed to use the blobId to send this MDN. The EmailSubmission object uses an emailId reference rather than a blobId. If it's creating an email object, it also needs to be clear about which properties the servers should return for each object in the response (e.g. id, threadId, blobId, etc.). > o *notCreated*: "String[SetError]" A map of creation id to a SetError object for each Email that failed to be created. The possible errors are defined above. This document needs a security considerations section at the end. Cheers, Neil. --e6927263a07a4c3b90abd1175572c94a Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Finally sending= my feedback on this draft, as promised in Bangkok. Sorry for the delay!= Generally this looks good, just some comments to bring it up to date wi= th the current JMAP conventions and a confusion over how you're actually= meant to send the MDN!

2. Email/createMDN

The Email/createMDN method create a [= RFC5322] message from MDN properties.

Where are= these Email objects being created? It's not clear to me whether these a= re intended to be saved to the account's mail store or not. If they a= re being saved to the mail store, we need to give mailboxIds and key= words arguments. If they are not being saved, but just being sent immedi= ately, that needs to be made clear and the method probably renamed to sendMDN.

It takes the following arguments: o *accountId*: "String|null" The id of the account to use for this call. If "null", defaults to the "urn:ietf:params:jmap:mail" primary account.

T= his should be non-optional now to match the same change in the other JMA= P specs.

o *mdns*: "String[MDN]" A map of creation id (client specified) to MDN objects An *MDN* object has the following properties: o *referencedMessageId*: "String" Message Id of the received message= the user wants to create an MDN for.
<= div>
Again, to match current JMAP convention this should b= e referencedEmailId, or maybe just forEmailId?

o *subject*: "String" Subject that will be used as "Subjec= t" header for this MDN. o *textBody*: "String" Human readable part of the MDN, as plain text. o *reportingUA*: "String" Name of the MUA creating this MDN. It is used to build the MDN Report part of the MDN. o *disposition*: "Disposition" Object containing the diverse MDN disposition options. A *Disposition* object has the following properties: o *actionMode*: "String" This MUST be one of the following strings: "manual-action" / "automatic-action" o *sendingMode*: "String" This MUST be one of the following strings:= "MDN-sent-manually" / "MDN-sent-automatically" o *type*: "String" This MUST be one of the following strings: "deleted" / "dispatched" / "displayed" / "processed" See [RFC8098] for the exact meanin= g of these different fields.

=
This all looks fine.

If the _referencedMessag= eId_, _subject_, _textBody_, _reportingUA_, _disposition_ properties are invalid (e.g. missing, wrong type, id not found), the server MUST reject the import with an "invalidProperties" SetError.
If the email cannot be created because it would take t= he account over quota, the creation should be rejected with a "maxQuotaReached" SetError.

import ->= ; create (I presume this is a copy-paste error) and the maxQuotaReached = error is now just called overQuota. But rather than specify the la= st two paragraphs, probably better just to say it may return any standar= d SetError that is defined for a create in the core spec.

The response has the following arguments: o *accountId*: "String" The id of the account used for this call. o *created*: "String[Email]" A map of the creation id to an object build from the referenced properties. The _blobId_ field of the Email objects can then be used to effectively send the MDN.

Again, I'm unclear how you are= supposed to use the blobId to send this MDN. The EmailSubmission object= uses an emailId reference rather than a blobId. If it's creating an ema= il object, it also needs to be clear about which properties the servers = should return for each object in the response (e.g. id, threadId, blobId= , etc.).

o *notCreated*: "String[SetError]" A map= of creation id to a SetError object for each Email that failed to be created. The possible errors are defined above.

This document needs a security considerations section a= t the end.

Cheers,
Neil. --e6927263a07a4c3b90abd1175572c94a-- From nobody Wed Dec 5 08:06:56 2018 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91111130E3A for ; Wed, 5 Dec 2018 08:06:54 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Dxi8_dxCEOv for ; Wed, 5 Dec 2018 08:06:47 -0800 (PST) Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C4EA130E2B for ; Wed, 5 Dec 2018 08:06:47 -0800 (PST) Received: by mail-ua1-x933.google.com with SMTP id d19so7273849uaq.11 for ; Wed, 05 Dec 2018 08:06:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=fGaXozJdguqI4fTGKxor6xFYkcdyzjY146T+JUhl5Po=; b=oiKjvuswabgzMkWO0Zd8xubIouno7v5Kf79lEVRzRmiwOHwqzmTpT+1Xaj/OQcOqnh jMtKpggA4wpqmHokOQPyKxJ+8mXyxgJuepRe9WCxAWaAzxtF/ZVZe/7NLx1UFPTHQphl Cc9/jbITgqrtyZkrGYVKNwi7+3q3UoOkgQkquP6W6eFKmYQ4JuQbTzThvnv62HS0WELZ kjIrljBENCL4uIBqnaA8NX7LbeU5HIc8eVHAdvQpEhl4CI/6fe6PPUuU3jEDn8cJhNvT jP+P93OLu7+Z2XlWFFuahfxWLiDlHG+F7rE17LbKSSaPdTUvHv0ha7ZvMolBt81FeUG1 oY7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=fGaXozJdguqI4fTGKxor6xFYkcdyzjY146T+JUhl5Po=; b=f/UcNkcg7j878HkzO5N360Xm3TlXq3OzDfWS9a0SUgdOnsLwN22FH7tdPpus1hgGzD LKchveiGfiVDkVnY7OMs7CHcwqKUuKOzrEC3FY+Q2tOBVogWesfqXj+iJKymeWjHDfZR lVltkmcU0T8ovVtJlh1/PnKrW+VrNeUbyPaz6FJQ669LZGX54xtoQ2IZAMS9lX951D9u 2iRvAHvTOOiz7jOvGBiyDGjlW/f8G7fTDifbIbRH28IDqLANGQE9qPU1wGRkwNc5Bnai EisGxoY+f20Vg3RMFRd+g7n46yt+iVFsnfxMv5KmoZuocF5HkGTvo6iWQ+LEuKtiRMW4 eDAQ== X-Gm-Message-State: AA+aEWYnl0hTf2EXBKXOnKwmAfRfs0UAi5UKxcgk9W8dbcS6eImjXJbE LeZi/Dhh94le/auzXusKD1/g40a6WpRUtv7NKtSIl6WZ X-Google-Smtp-Source: AFSGD/Wuket6NLuKdnwEsxvC+JfoAlFvOsJr23h1xHK4b6T3C8lHUCdM/33tHwetVVjv+b/VRW2GuzGFaBDUsnYpFgw= X-Received: by 2002:ab0:225a:: with SMTP id z26mr9482613uan.100.1544026006114; Wed, 05 Dec 2018 08:06:46 -0800 (PST) MIME-Version: 1.0 References: <154382036005.7229.955916957284667981.idtracker@ietfa.amsl.com> In-Reply-To: <154382036005.7229.955916957284667981.idtracker@ietfa.amsl.com> From: "Matthew Horsfall (alh)" Date: Wed, 5 Dec 2018 11:06:34 -0500 Message-ID: To: IETF JMAP Mailing List Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Jmap] Publication has been requested for draft-ietf-jmap-core-12 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: Wed, 05 Dec 2018 16:06:55 -0000 On Mon, Dec 3, 2018 at 1:59 AM Bron Gondwana wrote: > > Bron Gondwana has requested publication of draft-ietf-jmap-core-12 as Proposed Standard on behalf of the JMAP working group. > > Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-jmap-core/ In this document and in the mail spec, properties are often referenced as `"foo"` property or `_foo_` property. These get turned into bold vs italics I think. I think we should pick one way and be consistent. For example, _role_ vs "isSubscribed" in the descriptions here: > o *hasAnyRole*: "Boolean" If "true", a Mailbox matches if it has any > non-"null" value for its _role_ property. vs > o *isSubscribed*: "Boolean" The "isSubscribed" property of the > mailbox must be identical to the value given to match the > condition. > 9.5.3. Initial JMAP Error Codes registry > The "Intended Use" table header is broken into two lines funny - "Intende\nd Use" Cheers, -- Matthew Horsfall (alh) From nobody Wed Dec 5 08:10:44 2018 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E560130E3A for ; Wed, 5 Dec 2018 08:10:42 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZG2fi6yh6hB for ; Wed, 5 Dec 2018 08:10:35 -0800 (PST) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F93E130E2B for ; Wed, 5 Dec 2018 08:10:35 -0800 (PST) Received: by mail-vs1-xe33.google.com with SMTP id p74so12420743vsc.0 for ; Wed, 05 Dec 2018 08:10:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Pbhjyo8oEoXf7rCjMLG+lqbsAcpXhOETPruK1VgUWpU=; b=Ylf59b47+MU4kR1Vbtu+X198M0Z7taYxGviUoJRczB2JdFQRfvAEScWVIHqho3VRSZ KIDgD8qmUPM40elZXzHhD200JbA11hgO/kjSwXGsVaXexFx+mlgUE70FqvhAp8gEY2Hb jLq6JyyyJN6/xRMSoHp1qKJ+ceIK9LFp8kM3YgeY5yzybT2YAdB+f0bw5BjnwxU4Wj3S x6kHyAHsn20qtXbQQJgt28Q6+gkCdem2g/PfMoUMkeih1xSw3KA3Ssm/FYFpnhdYv8mR g1sBVRBodWjsULYX1BIe8rHYrwf5h+lE4b4T0VYgzJ7XKdX8waYVj7Ebhg+zsZMZ4gdH dx7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Pbhjyo8oEoXf7rCjMLG+lqbsAcpXhOETPruK1VgUWpU=; b=D05FFHVcTG0/acwv2hHx5UmzdNGhVCZ7RXyYwwGjVzr+BELnM3WCj/yd2JiytpPr1Y a0Zi44wvRsEfi5SrZoW6j7DJeVvn/aHT2SnftOSSr6syNJVyBYHGQLljCsWjc8w4cSWI exRIOAunzm5e+AzWZvrp6wfnYEfU+OdlXU+j8McKxJ1FK4MOVIeB7FGfUSAghnUtFwLM qwDjhVR9Iau8QGwr7lLa/I7pk0Nn3QgPP/ujRr8tQ/+8CsjRAYOuZTfepAJFUPMxK9Po PyWwVqWuTVyPw1gAz7rsU/cq1BANUaZbcpWAQLr2uyDuJsHqk77GZyiBLnlZ6PAHhvE5 ioMg== X-Gm-Message-State: AA+aEWaw8Q2rCAfqoYMDOrudaoYD7zIeLpCJl4FMHvKi/kGI/PXeL+HQ zRj1fCyIqkZMx+WU2MfWe3Qz41Dv9lmBb+YKmJBeHszv X-Google-Smtp-Source: AFSGD/UlW5xNw2lKDaYfsGxSE8sK2ZL2bJTpxT1oqyBCn8tUkWRcQjPEW/VVnvxENVQ4Fn4CrkAUWpkDlRpEgIe3x1E= X-Received: by 2002:a67:808a:: with SMTP id b132mr11101550vsd.224.1544026233981; Wed, 05 Dec 2018 08:10:33 -0800 (PST) MIME-Version: 1.0 References: <154382038733.7277.15783608624186053735.idtracker@ietfa.amsl.com> In-Reply-To: <154382038733.7277.15783608624186053735.idtracker@ietfa.amsl.com> From: "Matthew Horsfall (alh)" Date: Wed, 5 Dec 2018 11:10:21 -0500 Message-ID: To: IETF JMAP Mailing List Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Jmap] Publication has been requested for draft-ietf-jmap-mail-12 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: Wed, 05 Dec 2018 16:10:42 -0000 On Mon, Dec 3, 2018 at 1:59 AM Bron Gondwana wrote: > > Bron Gondwana has requested publication of draft-ietf-jmap-mail-12 as Proposed Standard on behalf of the JMAP working group. > > Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-jmap-mail/ > Sometimes examples appear only 4 spaces over (section 7.5.1), other times they appear very far over (section 5.2 in the request) or not indented at all (section 5.2 in the response). > 7. Email Submission > > > o *undoStatus*: "String" (server-set) This represents whether the > submission may be canceled. This is server set and MUST be one of > the following values: So this is server-set. Later we say: > If in pending > state, a client can attempt to cancel the submission by setting > this property to "canceled" The core spec makes it sound like server-set attributes *cannot* be altered by a client: Any server-set properties MAY be included in the patch if their value is identical to the current server value (before applying the patches to the object). Otherwise, the update MUST be rejected with an _invalidProperties_ SetError. So is this allowed? Should the core spec say "there may be exceptions"? > 8. Vacation Response > > > o *textBody*: "String|null" The plain text body to send in response > to emails when the vacation response is enabled. If this is > "null", when the vacation message is sent a plain-text body part > SHOULD be generated from the _htmlBody_ but the server MAY choose > to send the response as HTML only. > > o *htmlBody*: "String|null" The HTML body to send in response to > emails when the vacation response is enabled. If this is "null", > when the vacation message is sent an HTML body part MAY be > generated from the _textBody_, or the server MAY choose to send > the response as plain-text only. What if both are null? I've also opened a number of merge requests with other minor issues: https://github.com/jmapio/jmap/pull/269 https://github.com/jmapio/jmap/pull/270 https://github.com/jmapio/jmap/pull/271 Cheers, -- Matthew Horsfall (alh) From nobody Wed Dec 5 10:33:32 2018 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 78926130EA8; Wed, 5 Dec 2018 10:33:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <154403480545.31989.9172409912706910401@ietfa.amsl.com> Date: Wed, 05 Dec 2018 10:33:25 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-websocket-00.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: Wed, 05 Dec 2018 18:33:26 -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 : A JSON Meta Application Protocol (JMAP) Subprotocol for WebSocket Author : Kenneth Murchison Filename : draft-ietf-jmap-websocket-00.txt Pages : 11 Date : 2018-12-05 Abstract: This document defines a binding for the JSON Meta Application Protocol (JMAP) over a WebSocket transport layer. A WebSocket binding for JMAP provides higher performance than the current HTTP binding for JMAP. Open Issues o What mechanism should be used to allow the client to choose what types of objects for which is wishes to receive push notifications over the WS connection? Shoul this be done via a new method type or can it be done with header fields and/or query parameters on the WS handshake? The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-websocket/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-websocket-00 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-websocket-00 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 Wed Dec 5 19:02:53 2018 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4281C130DC2 for ; Wed, 5 Dec 2018 19:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=Dx21YzIf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=c1o7h2bT 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 rKlWB63DwZtc for ; Wed, 5 Dec 2018 19:02:49 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2838B1292F1 for ; Wed, 5 Dec 2018 19:02:49 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id E0EEB21D07 for ; Wed, 5 Dec 2018 22:02:47 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Wed, 05 Dec 2018 22:02:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=4GZDVFjEMdl68GlwkfmH9druMnoq OL7b3bgnOrEzn/s=; b=Dx21YzIf0qB2zxbEeEdq3g6oAq0IEhadqLefWh5l+b9H 3kEFCGZwcih+/UsnOmwy9qR7shDRlvhuB48FrMyU0qtcyJJis9gZkMwYhLihJ7PS yeYE2wcD/o8GqMij7IeNjPMloZFCaxT3efLWVhGtslJTKYmrZicrIE2Y2JD9wO5T MQIgkQ4ZYjD4pzmBHnpTKzi07onQHJr+i3ear1cf05xto3HAnQ1RSj319UMsz2O5 CECLk0o0VcBEZgKMj+QjV1La8z45HSl9vkuGjlUdbsbgXxCu8/MTTNTUb9QCZmXe +ZKN0A70Ps1mlAopFPGV3yF3NFO/QNqgtVosIIKi2Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=4GZDVFjEMdl68Glwk fmH9druMnoqOL7b3bgnOrEzn/s=; b=c1o7h2bTVBuUVumcw5v6S4NKtwQbL8Of7 Rk7fVGFK/Fd7V8YbMExOHFMzJPRdpnoaMtrh7xECynXEGrN5tNi0zO/FGa6yYgIh +ei9slwh5jBUOD5d7262qLO/Q86fOLU5pT7hEMiNeeeN6ggWOMTYyzLSmWeU3rDu HkKiuoS1NqIV4VnmgELR/pv4qgAp9p3Zqm97RPy8SaYnXAdlUUHOnLpZ313DRGw5 ly843GUG5kobzgpgpEu38FqH56yxy9ixhfYjN7DbDgBvPPWI3u8HejJL1qqjZNq9 z8i/wn2Ue4JLi9BpMM/1vy33XaZAYAID5IHuVZhabTDeSgfDIH47g== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E8D242030C; Wed, 5 Dec 2018 22:02:46 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: <6eb38384-1f33-48ac-9f90-af2cd0d0b4ff@sloti7d1t02> User-Agent: Cyrus-JMAP/3.1.5-681-g8713b31-fmstable-20181205v1 X-Me-Personality: 64588216 In-Reply-To: References: <154382038733.7277.15783608624186053735.idtracker@ietfa.amsl.com> Date: Wed, 05 Dec 2018 22:02:46 -0500 From: "Neil Jenkins" To: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=5ff362aafc8b4c73aa15920637447cb1 Archived-At: Subject: Re: [Jmap] Publication has been requested for draft-ietf-jmap-mail-12 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, 06 Dec 2018 03:02:51 -0000 --5ff362aafc8b4c73aa15920637447cb1 Content-Type: text/plain Hi Matt, On Thu, 6 Dec 2018, at 3:10 AM, Matthew Horsfall (alh) wrote: > Sometimes examples appear only 4 spaces over (section 7.5.1), other times > they appear very far over (section 5.2 in the request) or not indented > at all (section 5.2 in the response). I'm not sure why this is happening; something weird with the converter I'm using from the markdown source files. I'm hoping this can be fixed up manually as a final edit pass. > > 7. Email Submission > > > > > > o *undoStatus*: "String" (server-set) This represents whether the > > submission may be canceled. This is server set and MUST be one of > > the following values: > > So this is server-set. Later we say: > > > If in pending > > state, a client can attempt to cancel the submission by setting > > this property to "canceled" > > The core spec makes it sound like server-set attributes *cannot* be > altered by a client: > > Any server-set properties MAY be included in the patch if their > value is identical to the current server value (before applying > the patches to the object). Otherwise, the update MUST be > rejected with an _invalidProperties_ SetError. > > So is this allowed? Should the core spec say "there may be exceptions"? Yeh, this shouldn't be marked as server-set. That label is explicitly for properties the client may never change. Good catch. > > > 8. Vacation Response > > > > > > o *textBody*: "String|null" The plain text body to send in response > > to emails when the vacation response is enabled. If this is > > "null", when the vacation message is sent a plain-text body part > > SHOULD be generated from the _htmlBody_ but the server MAY choose > > to send the response as HTML only. > > > > o *htmlBody*: "String|null" The HTML body to send in response to > > emails when the vacation response is enabled. If this is "null", > > when the vacation message is sent an HTML body part MAY be > > generated from the _textBody_, or the server MAY choose to send > > the response as plain-text only. > > What if both are null? It's probably reasonable to say the server should use a default body in this case like it does with subject etc. Neil. --5ff362aafc8b4c73aa15920637447cb1 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi Matt,
<= div>
On Thu, 6 Dec 2018, at 3:10 AM, Matthew Horsfall (alh= ) wrote:
= Sometimes examples appear only 4 spaces over (section 7.5.1), other time= s
they appear very far over (section 5.2 in the request) o= r not indented
at all (section 5.2 in the response).

I'm not sure why this is happening;= something weird with the converter I'm using from the markdown source f= iles. I'm hoping this can be fixed up manually as a final edit pass.
=

> 7. Email Submission
>
>
>   o  *undoStatus*: "String" (server-set) Thi= s represents whether the
>     = ; submission may be canceled.  This is server set and MUST be one o= f
>      the following values:=

So this is server-set. Later we say:

>      If in pending=
>      state, a client can at= tempt to cancel the submission by setting
>  =     this property to "canceled"

<= div>The core spec makes it sound like server-set attributes *cannot* be<= br>
altered by a client:

 &n= bsp;    Any server-set properties MAY be included in the = patch if their
      value is ide= ntical to the current server value (before applying
 =      the patches to the object).  Otherwise, th= e update MUST be
      rejected w= ith an _invalidProperties_ SetError.

So is = this allowed? Should the core spec say "there may be exceptions"?

Yeh, this shouldn't be marked as server-set. Th= at label is explicitly for properties the client may never change. Good = catch.


> 8. Vacation Response
>
=
>
>   o  *textBody*: "Stri= ng|null" The plain text body to send in response
> = ;     to emails when the vacation response is enable= d.  If this is
>      "nu= ll", when the vacation message is sent a plain-text body part
<= div>>      SHOULD be generated from the _htm= lBody_ but the server MAY choose
>   &nb= sp;  to send the response as HTML only.
>
>   o  *htmlBody*: "String|null" The HTML body t= o send in response to
>      e= mails when the vacation response is enabled.  If this is "null",
>      when the vacation message= is sent an HTML body part MAY be
>   &n= bsp;  generated from the _textBody_, or the server MAY choose to se= nd
>      the response as plai= n-text only.

What if both are null?

It's probably reasonable to say the s= erver should use a default body in this case like it does with subject e= tc.

Neil.
--5ff362aafc8b4c73aa15920637447cb1-- From nobody Fri Dec 14 09:04:54 2018 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 79BFE130DC0; Fri, 14 Dec 2018 09:04: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.89.1 Auto-Submitted: auto-generated Precedence: bulk CC: brong@fastmailteam.com, jmap@ietf.org, draft-ietf-jmap-core@ietf.org, alexey.melnikov@isode.com, Bron Gondwana , jmap-chairs@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <154480709144.30557.9506906739502039692.idtracker@ietfa.amsl.com> Date: Fri, 14 Dec 2018 09:04:51 -0800 Archived-At: Subject: [Jmap] Last Call: (JSON Meta Application Protocol) 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: Fri, 14 Dec 2018 17:04:52 -0000 The IESG has received a request from the JSON Mail Access Protocol WG (jmap) to consider the following document: - 'JSON Meta Application Protocol' 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 ietf@ietf.org mailing lists by 2018-12-28. 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 specifies a protocol for clients to efficiently query, fetch and modify JSON-based data objects, with support for push notification of changes and fast resynchronisation, and out-of-band binary data upload/download. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-jmap-core/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-jmap-core/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Dec 21 09:05:24 2018 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07971286D9 for ; Fri, 21 Dec 2018 09:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=smtpcorp.com header.b=AwTlxukB; dkim=pass (2048-bit key) header.d=linagora.com header.b=ZLt1zzaV 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 jaOcd8rTd6w3 for ; Fri, 21 Dec 2018 09:05:20 -0800 (PST) Received: from e2i64.smtp2go.com (e2i64.smtp2go.com [103.2.140.64]) (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 AFE45130E54 for ; Fri, 21 Dec 2018 09:05:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smtpcorp.com; s=a1-4; h=Feedback-ID:X-Smtpcorp-Track:Message-ID:Subject:To: From:Date:Reply-To:Sender:List-Unsubscribe; bh=8aFcySrjCEzshPI1F4cbVvC9WIsf0ek6/ifFNEPtwQg=; b=AwTlxukBeR4YsAYq5oDkiPh2ZH gjlaiJx4ACuU0pj+DUTguLFW85i0qwTYfilP8rUeE+i2TwUXLb+sHIVmz3XzJT93Ar5dAL/toLKQ1 zqYL+9zBITIJUCzNUcq+0T9xJ7HYk4HQDhMYW5BjkVfxQYfPPaqAQsXimTKZNPpI/jpP+0w0RN56r 3f8fuRfdSCtbcGe8YkPvDd2udOatwiUg3TRm74OIWqV9oiXNec6lYwAuKCOnhmP2EPnD22jPuN6DM s67u2H6kRbvjMUQTNxL6P+ClgVZ6IrjHfhlZ4VEAC5j4MnGF51nQm1miUYgzMTc87+J+g8Fm7XtCs bvlsjfDQ==; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linagora.com; i=@linagora.com; q=dns/txt; s=s266739; t=1545411919; h=from : subject : to : message-id : date; bh=8aFcySrjCEzshPI1F4cbVvC9WIsf0ek6/ifFNEPtwQg=; b=ZLt1zzaV8PPNhz9OvVVMK6zUqMeXcgxvf3BZt9bf4+gjbwW+hZDx40/9lRzG8y5TPOEY41 wpgNjZ7McPS4JkHxaRM/NgI2Lo3MmYqspRAqzcrJP+u6YD1A3sitIv4CUbCUzM4QkLE0Ggx4 u7qEfT8SjxSYLiPxxry9ymXokgNYwn/B7xJIzvmUdPM8hIWAdcW6JFLSAzmMWz2PfMCApi9p SQYNNofM6oakRtZiX11kZGZadMDsY9lqFyC96rPEAz4rmu+9Fs3G7qiVdEJafDB/VlOVLFFu uuJKJKAfsab+hDjFjvI1LzRsHc1MxI9cFR2xjF06R0RNX6Fooio/DPJw== Received: from [10.45.33.53] (helo=SmtpCorp) by smtpcorp.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.91) (envelope-from ) id 1gaOEa-cp4XuK-9q; Fri, 21 Dec 2018 17:05:12 +0000 Received: from [10.54.36.8] (helo=smtp.linagora.com) by smtpcorp.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.91) (envelope-from ) id 1gaOEY-rlZExI-El; Fri, 21 Dec 2018 17:05:10 +0000 Received: from extranet.linagora.com (obm3-ui.linagora.dc2 [172.24.128.227]) by smtp.linagora.com (Postfix) with ESMTP id DA36B40B1F; Fri, 21 Dec 2018 18:05:07 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 21 Dec 2018 18:05:07 +0100 X-LINAGORA-Copy-Delivery-Done: 1 From: Raphael OUAZANA To: Neil Jenkins Cc: IETF JMAP Mailing List In-Reply-To: <2cf743f3-1c18-4062-848e-f85ca505fa55@sloti7d1t02> References: <153270520782.32707.4419621555491459322@ietfa.amsl.com> <2cf743f3-1c18-4062-848e-f85ca505fa55@sloti7d1t02> Message-ID: X-Sender: raphael.ouazana@linagora.com User-Agent: Roundcube Webmail/1.1.4 X-Smtpcorp-Track: 1gaOEYr_ZExmE_.Ha1EHK0cK Feedback-ID: 266739m:266739aja3LFS:266739sqomqQgQ91 X-Report-Abuse: Please forward a copy of this message, including all headers, to Archived-At: Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-mdn-00.txt 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, 21 Dec 2018 17:05:23 -0000 Hi Neil, Thank you very much for your feedback. Not enough time to handle it for the moment, but it will be in my next year resolutions. Regards, Raphaël. Le 2018-12-05 01:46, Neil Jenkins a écrit : > Finally sending my feedback on this draft, as promised in Bangkok. > Sorry for the delay! Generally this looks good, just some comments to > bring it up to date with the current JMAP conventions and a confusion > over how you're actually meant to send the MDN! > >> 2 [1]. Email/createMDN >> >> The Email/createMDN method create a [RFC5322 [2]] message from >> MDN >> properties. > > Where are these Email objects being created? It's not clear to me > whether these are intended to be saved to the account's mail store or > not. If they _are_ being saved to the mail store, we need to give > mailboxIds and keywords arguments. If they are not being saved, but > just being sent immediately, that needs to be made clear and the > method probably renamed to _sendMDN_. > >> It takes the following arguments: >> >> o *accountId*: "String|null" The id of the account to use for >> this >> call. If "null", defaults to the "urn:ietf:params:jmap:mail" >> primary account. > > This should be non-optional now to match the same change in the other > JMAP specs. > >> o *mdns*: "String[MDN]" A map of creation id (client specified) >> to >> MDN objects >> >> An *MDN* object has the following properties: >> >> o *referencedMessageId*: "String" Message Id of the received >> message >> the user wants to create an MDN for. > > Again, to match current JMAP convention this should be > referencedEmailId, or maybe just forEmailId? > >> o *subject*: "String" Subject that will be used as "Subject" >> header >> for this MDN. >> >> o *textBody*: "String" Human readable part of the MDN, as plain >> text. >> >> o *reportingUA*: "String" Name of the MUA creating this MDN. It >> is >> used to build the MDN Report part of the MDN. >> >> o *disposition*: "Disposition" Object containing the diverse MDN >> disposition options. >> >> A *Disposition* object has the following properties: >> >> o *actionMode*: "String" This MUST be one of the following >> strings: >> "manual-action" / "automatic-action" >> >> o *sendingMode*: "String" This MUST be one of the following >> strings: >> "MDN-sent-manually" / "MDN-sent-automatically" >> >> o *type*: "String" This MUST be one of the following strings: >> "deleted" / "dispatched" / "displayed" / "processed" >> >> See [RFC8098 [3]] for the exact meaning of these different >> fields. > > This all looks fine. > >> If the _referencedMessageId_, _subject_, _textBody_, >> _reportingUA_, >> _disposition_ properties are invalid (e.g. missing, wrong type, >> id >> not found), the server MUST reject the import with an >> "invalidProperties" SetError. >> >> If the email cannot be created because it would take the account >> over >> quota, the creation should be rejected with a "maxQuotaReached" >> SetError. > > import -> create (I presume this is a copy-paste error) and the > maxQuotaReached error is now just called overQuota. But rather than > specify the last two paragraphs, probably better just to say it may > return any standard SetError that is defined for a _create_ in the > core spec. > >> The response has the following arguments: >> >> o *accountId*: "String" The id of the account used for this >> call. >> >> o *created*: "String[Email]" A map of the creation id to an >> object >> build from the referenced properties. The _blobId_ field of >> the >> Email objects can then be used to effectively send the MDN. > > Again, I'm unclear how you are supposed to use the blobId to send this > MDN. The EmailSubmission object uses an emailId reference rather than > a blobId. If it's creating an email object, it also needs to be clear > about which properties the servers should return for each object in > the response (e.g. id, threadId, blobId, etc.). > >> o *notCreated*: "String[SetError]" A map of creation id to a >> SetError object for each Email that failed to be created. The >> possible errors are defined above. > > This document needs a security considerations section at the end. > > Cheers, > > Neil. > > Links: > ------ > [1] https://tools.ietf.org/html/draft-ietf-jmap-mdn-00#section-2 > [2] https://tools.ietf.org/html/rfc5322 > [3] https://tools.ietf.org/html/rfc8098 > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap From nobody Fri Dec 28 10:31:02 2018 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A39091310A2; Fri, 28 Dec 2018 10:30:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Allison Mankin To: Cc: jmap@ietf.org, draft-ietf-jmap-core.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154602184661.21654.7987714371574539114@ietfa.amsl.com> Date: Fri, 28 Dec 2018 10:30:46 -0800 Archived-At: Subject: [Jmap] Tsvart last call review of draft-ietf-jmap-core-12 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, 28 Dec 2018 18:30:47 -0000 Reviewer: Allison Mankin Review result: Ready 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. This standards track specification is in good shape from a transport point of view. Topics considered in this assessment were its discovery mechanism, its support of tools for denial of service and rate control issues on both the server and clients side, its ordering and data flow for the allowed disparate client endpoints, and its transport mapping, which is mandatory HTTPS. One question that is referred to other areas is what recommendations would be given (or what spec referenced) for validation of uploaded blob objects (it looks like the flow control for these is fine). From nobody Fri Dec 28 20:09:52 2018 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDCEE127B4C; Fri, 28 Dec 2018 20:09:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.973 X-Spam-Level: X-Spam-Status: No, score=-1.973 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_MIME_MALF=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=jkiIjJbU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ifBrCinm 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 r3hZ8Ddx3TpH; Fri, 28 Dec 2018 20:09:37 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D43C124BF6; Fri, 28 Dec 2018 20:09:34 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 64F09DC2; Fri, 28 Dec 2018 23:09:33 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Fri, 28 Dec 2018 23:09:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:cc:subject:content-type; s=fm1; bh=EjnVuGrCUob0ayl1LVGCE9UTP KUcxEOOn4CqGHhcprE=; b=jkiIjJbUDgbHORNjAgJ/cpRjQNCL2kCZkmZf9UY0M E10TtvYjF27XSBh10CJEOTwaoDY6w/pTY8ItjZOYD3qAliIXXtIdWFUHfeSrgoEQ xCpZMxHJNuEejy0bCNyIBXbKbL62M7aUk7/nafaC7MRp1llOOgK932Cx/uUICmgj JicBttbXhQl/iRe24lalYbuX3Rpx5M0AHRgICBqwPEnVS2yvQucp7HsFq0DKm7u5 TJsDjUnXrP5uikiV/RDfgsFBJ+27TgQEYy2yQZTaM2mGCfx/+Gho5xHhSYAGibu0 R+FIdX/WTibIhvTsJH+dqYYxQPT+HHjplMTKRBl12Cm0g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=EjnVuGrCUob0ayl1L VGCE9UTPKUcxEOOn4CqGHhcprE=; b=ifBrCinmaBRjR6cTsL/HdQxDau/oDtieS O7cBgMLcw2mUcNgQuKM+qeQP9JfSmDupQpSl4FrsH/JjxM08/eLlhBFAjkHdCvcS YN5ugEyqcjfi06Grych7c67fjyN1O2p/7XSnpFua+YVNH1g2GGjnrbBfrW8faBNS EoYfLxj+lMi32YghIBCdy4FTg360UUOJ8/pXbAcJkQL4/r/0b4mzi3YbIpkUuPhv yjzlX004PItEcvkxAIGBMTFBZSpjr8hb1f/gotbR4OUnRq+7ILGdK7THWBaX7Kyd 7dUj4ZXYJGshdINT/n1gzvibxfXkjKwDxNqlf1atpTly3a9CaUMPQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrtdejgdeivdculddtuddrgedtkedrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfuehrohhn ucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucffohhmrghinhephhhtthhpshdrohhnvgenucfrrghrrghmpehmrghilhhfrhhomhep sghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivg eptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 734E8202AD; Fri, 28 Dec 2018 23:09:32 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-714-g75bf9ad-fmstable-20181221v5 X-Me-Personality: 56629417 Message-Id: <7dbcbc19-a513-4d2a-80e5-0417d5f2685f@www.fastmail.com> In-Reply-To: <154602184661.21654.7987714371574539114@ietfa.amsl.com> References: <154602184661.21654.7987714371574539114@ietfa.amsl.com> Date: Fri, 28 Dec 2018 23:09:31 -0500 From: "Bron Gondwana" To: tsv-art@ietf.org, "Allison Mankin" Cc: jmap@ietf.org, draft-ietf-jmap-core.all@ietf.org, ietf@ietf.org Content-Type: multipart/alternative; boundary=28d7fbdd0e714909bc2e27c9ad726ed9 Archived-At: Subject: Re: [Jmap] Tsvart last call review of draft-ietf-jmap-core-12 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: Sat, 29 Dec 2018 04:09:39 -0000 --28d7fbdd0e714909bc2e27c9ad726ed9 Content-Type: text/plain Hi Allison, The blob deliberately isn't validated at upload time, so that it can be used by any Foo/import function or referenced in the generation of a later object of any type. For example I uploaded a PDF file as a blob: Content-Length: 312597 Content-Type: application/pdf And my server returned the details I gave: { "expires":"2018-12-30T03:57:18Z", "type":"application/pdf", "size":312597, "blobId":"Gb5eb763ad75e77101226181e01bb5c20f6aaf412", "accountId":"uac7641b2" } But that type field isn't saved on the server at all, it's just there in the response (as can be seen in the "Downloading" section, where "type" must be included in the request URL pattern and filled by the client) When that blob gets later used as an email attachment, the interpretation of the blob is given by the client as part of the bodyStructure (see the draft-ietf-jmap-mail document for how Email/set uses uses blobs as part of email creation if you're interested): { "blobId":"Gb5eb763ad75e77101226181e01bb5c20f6aaf412", "cid":null, "disposition":"attachment", "name":"certificate.pdf", "size":312597, "type":"application/pdf" } And then the server uses that to generate an appropriate representation of the object that's being created: --fa073057ee4b4ff58e7209f66d32cd7a Content-Disposition: attachment;filename="certificate.pdf" Content-Type: application/pdf; name="certificate.pdf" Content-Transfer-Encoding: BASE64 [...] --fa073057ee4b4ff58e7209f66d32cd7a-- Cheers, Bron. On Sat, Dec 29, 2018, at 05:30, Allison Mankin wrote: > Reviewer: Allison Mankin > Review result: Ready > > 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. > > This standards track specification is in good shape from a transport point of > view. Topics considered in this assessment were its discovery mechanism, its > support of tools for denial of service and rate control issues on both the > server and clients side, its ordering and data flow for the allowed disparate > client endpoints, and its transport mapping, which is mandatory HTTPS. > > One question that is referred to other areas is what recommendations would be > given (or what spec referenced) for validation of uploaded blob objects (it > looks like the flow control for these is fine). > > -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --28d7fbdd0e714909bc2e27c9ad726ed9 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi Allison,

The blob deliberately isn'= t validated at upload time, so that it can be used by any Foo/import fun= ction or referenced in the generation of a later object of any type.&nbs= p; For example I uploaded a PDF file as a blob:

Content-Length<= /span>: 312597
Content-Type: application/pdf

And my serve= r returned the details I gave:

{
&nb= sp; "expires":"2018-12-30T03:57:18Z",
  "type":"application/pdf",
<= /div>
  "size":312597,=
  "b= lobId":"Gb5eb763ad75e77101226181e01bb5c20f6aaf412",
  "accountId":"uac7641b2"=
}<= br>

But that type field isn't saved on the server at all, it'= s just there in the response (as can be seen in the "Downloading" sectio= n, where "type" must be included in the request URL pattern and filled b= y the client)

When that blob gets later used as an email = attachment, the interpretation of the blob is given by the client as par= t of the bodyStructure (see the draft-ietf-jmap-mail document for how Em= ail/set uses uses blobs as part of email creation if you're interested):=

{
  "blobId":"Gb5eb763ad75e77101226181e01bb5c20f6aaf412",<= span style=3D"font-family: menlo, consolas, monospace, sans-serif;" clas= s=3D"font">
&nbs= p; "cid":null,
  "disposition":"attachment",
=
  "name":"certificate.pdf",
  "size":312= 597,
  "type":"applic= ation/pdf"
}

And then the se= rver uses that to generate an appropriate representation of the object t= hat's being created:

--fa073057ee4b4ff58e7209f66d32cd7a
Content-Disposition: attachment;filename=3D"certificate.pdf"
Content-Type: application/pdf; name=3D"certificate.pdf"
Content-Transfer-Encoding: BASE64

[...]
--fa073057ee4b4ff58e7209f66d32cd7a--

Cheers,

Bron.

On Sat, Dec 29, 2018, at 05:30, Allison Mankin wrote:
Reviewer: Allison Mankin
Review result: Ready

This document has been re= viewed as part of the transport area review team's
ongoing effort to review key IETF documents. These = comments were written
primari= ly 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 do= ne at the time of IETF Last Call, the authors should consider this
review as part of the last-call co= mments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

This standards track specification is in good shape from a tran= sport point of
view. Topics c= onsidered in this assessment were its discovery mechanism, its
=
support of tools for denial of service= and rate control issues on both the
server and clients side, its ordering and data flow for the allo= wed disparate
client endpoint= s, and its transport mapping, which is mandatory HTTPS.

O= ne question that is referred to other areas is what recommendations woul= d be
given (or what spec refe= renced) for validation of uploaded blob objects (it
looks like the flow control for these is fine).
=


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

--28d7fbdd0e714909bc2e27c9ad726ed9-- From nobody Sun Dec 30 05:22:32 2018 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7CD12F18C; Sun, 30 Dec 2018 05:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_MIME_MALF=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBT7jU-SnpRJ; Sun, 30 Dec 2018 05:22:21 -0800 (PST) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54CE1130EF3; Sun, 30 Dec 2018 05:22:21 -0800 (PST) Received: by mail-pg1-x52b.google.com with SMTP id v28so11832314pgk.10; Sun, 30 Dec 2018 05:22:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+fqdLX/WQP8YTlkie9jLQ4Zdh9aYmc4fUqU5hqrOzeE=; b=TG8SsNWdZnN6dBl1/FYX5ymK6uCAPbeIiBwO+ksC8Dncq+Wx79+HMxgjexoG17Ss2q KniwUKSlcvxd3Fs3MiUSW0bG1Sk8HXbrBLveHJ6Ec1qpzWsSw20Jh80YVajFOKYiLheU ix9ITceR+I+0WAjJNHK48gOwrRKM7rzncGqY0D2H9vGqW8I11veRafP5UdYfmV5qfZ6D zQG+gK7QIB88ZS+IcwlZj1Lv6Knbv1CKLrjqbOd63tmvQ3d1Ow8yaS3YJ546jNQAfKuD ru/LwmA2V32pGOwAd7KOJz1WJczQcI250yc0vJxoIWeYRLTAwMu32faXFof0QG6c0F7e MpIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+fqdLX/WQP8YTlkie9jLQ4Zdh9aYmc4fUqU5hqrOzeE=; b=X+tQIBDdj4zMf0lZ/nPKaEUkmt83msKBqTYMOum4elp+AHe+vXegOWMEnlrDunbZ2I iZ1pppt5MB06x0pmtWAWLl8zBnsp1PYcXYhXXyae2p+zyNukKbpgznj7Ut92dJrzDLDK 4n+QQ3n3nDGc22UxCT+51AnxMmoq+/eMGV/IGncaO1tMbnlXTF9fELt+R5g5rs78sqfU 2x/2Qc00V405b71vemyFoPa9TzHoUzFxD1i3LCMOsmUp0UZA6WMUDlWuF4GNR9jesnd1 WvCtEA9xQY0zSrJCH3aRbPLcI7/M6Z+mKv3EbiZO0gVwVcuiNLgxscXRfmazxdSkiDvG ygrA== X-Gm-Message-State: AJcUukdsnrXuioumMBSnrfC11bFQoMxxh47Z3hPcDsayCvZbzjEaJAyY sF8vuR3/crT+R/Wtrrhxm/cSZZ3u/kb5KBeXVUU= X-Google-Smtp-Source: ALg8bN54GwwKd5jrvR6fTHLDKKF/DYs4tF+Oom+sw1BfRkGO4ynjC8lR4/j73TwwOkS87Gw+i/yb43nP0uObR2udEtc= X-Received: by 2002:a65:434d:: with SMTP id k13mr4521164pgq.269.1546176140779; Sun, 30 Dec 2018 05:22:20 -0800 (PST) MIME-Version: 1.0 References: <154602184661.21654.7987714371574539114@ietfa.amsl.com> <7dbcbc19-a513-4d2a-80e5-0417d5f2685f@www.fastmail.com> In-Reply-To: <7dbcbc19-a513-4d2a-80e5-0417d5f2685f@www.fastmail.com> From: Allison Mankin Date: Sun, 30 Dec 2018 08:22:09 -0500 Message-ID: To: Bron Gondwana Cc: draft-ietf-jmap-core.all@ietf.org, ietf@ietf.org, jmap@ietf.org, tsv-art@ietf.org Content-Type: multipart/alternative; boundary="000000000000a1a75e057e3d2fc4" Archived-At: Subject: Re: [Jmap] Tsvart last call review of draft-ietf-jmap-core-12 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: Sun, 30 Dec 2018 13:22:24 -0000 --000000000000a1a75e057e3d2fc4 Content-Type: text/plain; charset="UTF-8" Bron, Thanks for detailing that and explaining where to find it in the draft. Best wishes, Allison On Fri, Dec 28, 2018 at 11:09 PM Bron Gondwana wrote: > Hi Allison, > > The blob deliberately isn't validated at upload time, so that it can be > used by any Foo/import function or referenced in the generation of a later > object of any type. For example I uploaded a PDF file as a blob: > > Content-Length: 312597 > Content-Type: application/pdf > > And my server returned the details I gave: > > { > "expires":"2018-12-30T03:57:18Z", > "type":"application/pdf", > "size":312597, > "blobId":"Gb5eb763ad75e77101226181e01bb5c20f6aaf412", > "accountId":"uac7641b2" > } > > But that type field isn't saved on the server at all, it's just there in > the response (as can be seen in the "Downloading" section, where "type" > must be included in the request URL pattern and filled by the client) > > When that blob gets later used as an email attachment, the interpretation > of the blob is given by the client as part of the bodyStructure (see the > draft-ietf-jmap-mail document for how Email/set uses uses blobs as part of > email creation if you're interested): > > { > "blobId":"Gb5eb763ad75e77101226181e01bb5c20f6aaf412", > "cid":null, > "disposition":"attachment", > "name":"certificate.pdf", > "size":312597, > "type":"application/pdf" > } > > And then the server uses that to generate an appropriate representation of > the object that's being created: > > --fa073057ee4b4ff58e7209f66d32cd7a > Content-Disposition: attachment;filename="certificate.pdf" > Content-Type: application/pdf; name="certificate.pdf" > Content-Transfer-Encoding: BASE64 > > > [...] > --fa073057ee4b4ff58e7209f66d32cd7a-- > > Cheers, > > Bron. > > On Sat, Dec 29, 2018, at 05:30, Allison Mankin wrote: > > Reviewer: Allison Mankin > Review result: Ready > > 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. > > This standards track specification is in good shape from a transport point > of > view. Topics considered in this assessment were its discovery mechanism, > its > support of tools for denial of service and rate control issues on both the > server and clients side, its ordering and data flow for the allowed > disparate > client endpoints, and its transport mapping, which is mandatory HTTPS. > > One question that is referred to other areas is what recommendations would > be > given (or what spec referenced) for validation of uploaded blob objects (it > looks like the flow control for these is fine). > > > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > > > --000000000000a1a75e057e3d2fc4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Bron,

Thanks for detailing that and explaining where to find it in the= draft.

Best wishes,

Allison

On Fri, Dec 28, 2018 at 11:09 PM Bro= n Gondwana <brong@fastmailteam= .com> wrote:
Hi Allison,

The blob deliberately i= sn't validated at upload time, so that it can be used by any Foo/import= function or referenced in the generation of a later object of any type.=C2= =A0 For example I uploaded a PDF file as a blob:

Content-L= ength: 312597
Content-Type: application/pdf

And my server returned the details I gave:

{
=C2=A0 "expires":&quo= t;2018-12-30T03:57:18Z",
=C2=A0 "type":"application/p= df",
=C2=A0 "size":312597,
=C2=A0 "blobId":"G= b5eb763ad75e77101226181e01bb5c20f6aaf412",
=C2=A0 "accountId&quo= t;:"uac7641b2"
<= span style=3D"font-family:menlo,consolas,monospace,sans-serif" class=3D"m_-= 4270094605486268546font">}

But that type field isn't s= aved on the server at all, it's just there in the response (as can be s= een in the "Downloading" section, where "type" must be = included in the request URL pattern and filled by the client)

Whe= n that blob gets later used as an email attachment, the interpretation of t= he blob is given by the client as part of the bodyStructure (see the draft-= ietf-jmap-mail document for how Email/set uses uses blobs as part of email = creation if you're interested):

{
=C2=A0 "blobId":&qu= ot;Gb5eb763ad75e77101226= 181e01bb5c20f6aaf412",<= br>
=C2=A0 "cid":null,=
=C2=A0 "disposition":&qu= ot;attachment&quo= t;,
=C2=A0 "name= ":"certificate.pdf",
=C2=A0 "size":312= 597,
=C2=A0 "typ= e":"app= lication/pdf"
}<= br>

And then the server uses that to generate an appropriate represen= tation of the object that's being created:

--fa073057ee4b4ff58e7209f66d32cd7a
Content-Disposition: attachment;filename=3D"certificate.pdf"
Content-Type: application/pdf; name=3D"certificate.pdf"
Content-Transfer-Encoding: BASE64

[...]
--fa0730= 57ee4b4ff58e7209f66d32cd7a--

Cheers,

Bron.
=
On Sat, Dec 29, 2018, at 05:30, = Allison Mankin wrote:
Reviewer: Allis= on Mankin
Review result: Ready

This document has been reviewed as part of the transport area revie= w team's
ongoing effort to re= view key IETF documents. These comments were written
primarily for the transport area directors, but are cop= ied 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@i= etf.org if you reply to or forward this review.

This standard= s track specification is in good shape from a transport point of
<= div style=3D"font-family:Arial">view. Topics considered in this assessment = were its discovery mechanism, its
support of tools for denial of service and rate control issues on both the=
server and clients side, its ord= ering and data flow for the allowed disparate
client endpoints, and its transport mapping, which is mandator= y HTTPS.

One question that is referred to other areas is what rec= ommendations would be
given (or w= hat spec referenced) for validation of uploaded blob objects (it
<= div style=3D"font-family:Arial">looks like the flow control for these is fi= ne).



=
--
=C2=A0 Bron Gondwana, CEO, FastMail Pty Ltd


--000000000000a1a75e057e3d2fc4--